Slashdot Mirror
Why BitTorrent Causes Latency and How To Fix It
Sivar recommends an article by George Ou examining why BitTorrent affects performance so much more than other types of file transfer and a recommendation on how to fix it. The suggestion is to modify P2P clients so that, at least on upload, they space their traffic evenly in time so that other applications have a chance to fit into the interstices. "[Any] VoIP [user] or online gamer who has a roommate or a family member who uses BitTorrent (or any P2P application) knows what a nightmare it is when BitTorrent is in use. The ping (round trip latency) goes through the roof and it stays there making VoIP packets drop out and game play impossible."
Hey, I have a really spiffy idea. How about creating a router that can determine which packets take precedence? I'll make millions off that idea...
What? Oh, damn Linux! What? Oh, Windows can do it too now? Why do I always have the good ideas about 10 years too late?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Why BitTorrent causes network bandwidth to be used. And network packets to be sent & received. Really sometimes I wonder.
While I prefer Tomato on a WRT-54GL, that would do absolutely nothing at all to solve this issue. A router behind a modem can really only regulate the upload, and can't easily prevent a flood of data on the downstream side.
This issue is with the queue on the Telco's DSLAM, or on the other side of the cable from the modem. This is more like an invited DDOS, which no amount of filtering at or behind the modem can resolve, because the modem is getting the traffic from the DSLAM after it goes through the queue.
The only way to have QOS solve this issue would be to ask the telco to do the QOS for you, and the amount of processing power to do that nicely isn't trivial.
If I have nothing to hide, don't search me
Homebrew traffic shaping. *facepalm*
Do you know how many times I've died in WoW because of his porn downloading?
;)
As long as you haven't signed a contract with your roommate, then you could throttle him
Jumpstart the tartan drive.
I don't mind traffic shaping at all, anywhere. QoS is a good thing, even when the ISPs do it. What I mind a whole awful lot is traffic blocking, ala Comcast.
Dewey, what part of this looks like authorities should be involved?
And we admit that on a small scale, we need to control our eating, but we don't want the grocery store telling us how much of things we can buy.
Traffic shaping and QOS will help a little, but the real problem is simply that you can't afford to delay priority traffic by more then one or two full-sized packets on any connection less then a few megabits (meaning: just about all home interconnects). If you wait any longer then that, it becomes noticeable.
Traffic shaping and QOS are not usually able to make that guarantee. A straight priority queue with bandwidth guarantees can, as long as you are able to actually classify the torrent traffic differently from your other traffic.
Part of the problem is that it is often not possible to distinguish between the batch and the interactive traffic with Shaping/QOS. Not only is QOS almost universally set wrong, but the simple fact is that one can mix interactive and batch traffic over the SAME ports (http, ssh, dynamically allocated ports)and that can make it virtually impossible to use traffic shaping or QOS to keep the mess away from your interactive traffic.
The best general solution is to use a straight priority mechanic with minimum bandwidth settings to separate as much of the bulk traffic out as you can, and then run fair-queueing at each priority level to take care of any that leaks through. This will do a very good job cleaning up the traffic. DragonFly has a fair-queue implementation for PF that does this. There is also at least one fair-queue implementation for PF in the wild.
Fair-queueing essentially classifies connections (the one in DFly uses PF's keep-state to classify connections), generates a hash and indexes a large array of mini-queues. One packet is then pulled off the head of each mini-queue. One enhancement I would like to make to the DFly implementation which I haven't done yet is to use the keep-state to actually determine which connections are batch and which are interactive, and have a parameter that allows the queue to give additional priority to the interactive connections by occasionally skipping the hoppers related to the batch connections. A quick and dirty way to do that is to simply check the queue length for each mini-queue.
In anycase, its a problem for which solutions are available. Regardless of what you use it has become apparent in the last few years that the only way one can classify the traffic well enough to properly queue it is by building keep-state knowledge on a connection by connection basis.
-Matt
"...then you could throttle him"
eewww. he no doubt can handle that himself.
We long ago learned that when inserting time between protocol events that it is far better to use a time randomized between an upper and lower bound than to use a repeating interval.
When fixed repeating intervals are used, separate instances of a protocol (and other protocols that use repeating intervals) slowly tend to fall into lock-step patterns with pulsating waves of traffic in accord with those patterns.
In other words, fixed protocol timers can create the traffic equivalent of the Tacoma Narrows bridge.
By-the-way, ping (ICMP Echo request/reply) is a terrible way to measure network latency. ICMP is often a disfavored form of traffic as it crosses routers, sometimes even rate limited.
There are better tools for measuring link properties, for example there is "pchar" - http://www.kitchenlab.org/www/bmah/Software/pchar/
I worked on a method to do even better measurements, but I put it aside several years ago: Fast Path Characterization Protocol at http://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html
Read the bloody article. He shows that bittorent traffic capped to 10% of total bandwidth still causes more latency than an http download using 90% of the pipe. The total latency hit is small, but still significant for VOIP or high intensity gaming.
--why?
When are ethical issues not directly derived from self interest? The issue with throttling at an ISP level is receiving the service one pays for. Bandwidth shaping for a personal network, deciding what one would like to do with the service they purchased, is an entirely separate issue.