3 ms·

Limiting the fraction of bandwidth used is a much harder problem than it sounds like, thanks to torrents. When you join the torrent you're inviting lots of UDP

Limiting the fraction of bandwidth used is a much harder problem than it sounds like, thanks to torrents. When you join the torrent you're inviting lots of UDP traffic to you. You can keep it from getting to the endpoint by traffic shaping, but that won't help if your uplink gets saturated by all of the incoming requests. Your typical asymmetric DSL is therefore very hard to safely share. You can try to block torrents, but there's no truly reliable way of doing so that doesn't involve blocking all encrypted traffic.

wpietri 12y ago
Could this be solved by a collaborative protocol? A simple home router has the advantage that all resources are being consumed by a small group of people that already are used to cooperating around resource allocation. E.g.: The router has some sort of bandwidthd. The Torrent app checks in, asks how much it can use for a low-priority bulk download, and gets a token good for a 30-second lease on 10 megabits down. Before that expires, it tries to renew the token, and maybe it gets only 5 megabits because somebody is watching Netflix. If at some point the connection quality gets bad, the router's owner gets an email saying that the router has noticed a lot of BitTorrent traffic from "Timmy's MacBook" and that maybe they should switch to a BT client that supports bandwidthd. And so dad gets Timmy to upgrade.
- rektide 12y ago
  The parent simply skipped past the part that a connected peer will send less traffic if they sense packet loss. It's a little problematic, in that there are a lot of clients all sending at once and all looking to see if they can increase their rate of send, but if you ingress limit (drop packets, or via ECN) BitTorrent is controllable. BitTorrent peers are collorative, because otherwise turning on BitTorrent anywhere would immediately result in the parent's boogeyman showing up: being flooded by way more traffic than can be handled. That's not an overlooked part of designing a client: it's known that when writing UDP protocols one has to do one's own flow control.
  - dannypgh 12y ago
    Yes, that's absolutely correct on a per-peer basis. The trouble is that for a large torrent, there could be hundreds of peers each attempting to negotiate on the link, and that can cause problems. My experience is with experimenting with just about every QoS setting possible on a Cisco ASA hooked up to the cheapest Verizon DSL several years back- I haven't bothered lately but that's because my home pipe these days is thick enough to make it not matter. BT would be a lot friendlier for traffic shaping if the tracker played a more active role in flow control, or if otherwise some distributed consensus was negotiated regarding wanting more unsolicited connections.
    - dtaht 12y ago
      I'd rather like better data on the problem you describe, as it does not seem to line up with the experimental data I have so far on the interaction of AQM and packet scheduling techniques with bittorrent. The first paper we did was: http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-b.pdf http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-b... Which predated the development of fq_codel, which is the fair queue (flow queue) + aqm hybrid now deployed in cerowrt, openwrt, and countless other QoS systems. That paper only explored RED or SFQ, not a hybrid. What I think the positive effects we are seeing now are several factors. 1) a "torrent" is usually on 6 flows at a time, rotating to a new flow every 15 seconds or so. 2) The additional peers trying to negotiate IS a problem at very low rates (say below 4mbit) but invisible at higher rates. 3) reducing latencies under load to under 5ms has enormous gains in bidirectional throughput, which more than compensate for losing torrent's delay based backoff mechanism, which only backs off at 100ms. Which would you rather have, 100ms latency or 5ms? See, for example, what the fq_codel system does for verizon and comcast here: https://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery https://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_... We got back 5x free bandwidth on the verizon test. And if you are experiencing 5ms worth of latency does it really matter if you have 6 torrents in the background? (80, yes! but it's a function of your bandwidth also and... and... more testing is indicated.) ... so I haven't got around to redoing the research and writing a successor paper on it, and probably won't anytime soon. The original authors of that paper have gone off to do several papers of extensive analyses of RED vs ledbat, and I think they've largely gone off into the weeds, not that I mind having that analysis as a basis if ever we (or someone) gets around to analyzing fq_codel with some of those techniques. Please feel free to test re torrent with a system that uses something like openwrt's qos-scripts or cerowrt's SQM system. The conclusion of the original paper was that only classification seemed to be an answer to even further deprioritize torrent in an AQM'd and FQ'd world. (which the above systems can do also) http://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00 http://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-... http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02 http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02

wpietri 12y ago

Could this be solved by a collaborative protocol? A simple home router has the advantage that all resources are being consumed by a small group of people that already are used to cooperating around resource allocation. E.g.: The router has some sort of bandwidthd. The Torrent app checks in, asks how much it can use for a low-priority bulk download, and gets a token good for a 30-second lease on 10 megabits down. Before that expires, it tries to renew the token, and maybe it gets only 5 megabits because somebody is watching Netflix. If at some point the connection quality gets bad, the router's owner gets an email saying that the router has noticed a lot of BitTorrent traffic from "Timmy's MacBook" and that maybe they should switch to a BT client that supports bandwidthd. And so dad gets Timmy to upgrade.

rektide 12y ago
The parent simply skipped past the part that a connected peer will send less traffic if they sense packet loss. It's a little problematic, in that there are a lot of clients all sending at once and all looking to see if they can increase their rate of send, but if you ingress limit (drop packets, or via ECN) BitTorrent is controllable. BitTorrent peers are collorative, because otherwise turning on BitTorrent anywhere would immediately result in the parent's boogeyman showing up: being flooded by way more traffic than can be handled. That's not an overlooked part of designing a client: it's known that when writing UDP protocols one has to do one's own flow control.
- dannypgh 12y ago
  Yes, that's absolutely correct on a per-peer basis. The trouble is that for a large torrent, there could be hundreds of peers each attempting to negotiate on the link, and that can cause problems. My experience is with experimenting with just about every QoS setting possible on a Cisco ASA hooked up to the cheapest Verizon DSL several years back- I haven't bothered lately but that's because my home pipe these days is thick enough to make it not matter. BT would be a lot friendlier for traffic shaping if the tracker played a more active role in flow control, or if otherwise some distributed consensus was negotiated regarding wanting more unsolicited connections.
  - dtaht 12y ago
    I'd rather like better data on the problem you describe, as it does not seem to line up with the experimental data I have so far on the interaction of AQM and packet scheduling techniques with bittorrent. The first paper we did was: http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-b.pdf http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-b... Which predated the development of fq_codel, which is the fair queue (flow queue) + aqm hybrid now deployed in cerowrt, openwrt, and countless other QoS systems. That paper only explored RED or SFQ, not a hybrid. What I think the positive effects we are seeing now are several factors. 1) a "torrent" is usually on 6 flows at a time, rotating to a new flow every 15 seconds or so. 2) The additional peers trying to negotiate IS a problem at very low rates (say below 4mbit) but invisible at higher rates. 3) reducing latencies under load to under 5ms has enormous gains in bidirectional throughput, which more than compensate for losing torrent's delay based backoff mechanism, which only backs off at 100ms. Which would you rather have, 100ms latency or 5ms? See, for example, what the fq_codel system does for verizon and comcast here: https://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery https://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_... We got back 5x free bandwidth on the verizon test. And if you are experiencing 5ms worth of latency does it really matter if you have 6 torrents in the background? (80, yes! but it's a function of your bandwidth also and... and... more testing is indicated.) ... so I haven't got around to redoing the research and writing a successor paper on it, and probably won't anytime soon. The original authors of that paper have gone off to do several papers of extensive analyses of RED vs ledbat, and I think they've largely gone off into the weeds, not that I mind having that analysis as a basis if ever we (or someone) gets around to analyzing fq_codel with some of those techniques. Please feel free to test re torrent with a system that uses something like openwrt's qos-scripts or cerowrt's SQM system. The conclusion of the original paper was that only classification seemed to be an answer to even further deprioritize torrent in an AQM'd and FQ'd world. (which the above systems can do also) http://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00 http://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-... http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02 http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02