Analysis of BitTorrent uTP congestion avoidance

[1epi]

The story that the new BitTorrent client uTorrent 2.0 is “network friendly” is making the top headlines on the Web and mailing lists. The only problem with this story it that it has no actual data to back up its assertions. I took the time yesterday to run some tests on the new uTorrent 2.0 beta build 16850 which supports the new “friendly” BitTorrent UTP. Based on my initial testing, the claim that the new BitTorrent client is network friendly appears to be false.

My initial thought was that perhaps there were simply too few uTP enabled BitTorrent clients in the wild to make this test meaningful, but it turns out that previous versions of uTorrent also support the new uTP protocol. The old clients simply won’t initiate a uTP connection while the new client will by default. Because the vast majority of peers deployed on the Internet is running the newest stable uTorrent 1.8.4 or above due to the fact that uTorrent is the most dominant BitTorrent client in the world, the vast majority of connections I made were in fact using the new uTP mode of communications.

Methodology disclosure
* Windows Vista with SP2
* Tests conducted on an Intel Quad-core CPU with Intel X38 chipset and gigabit wired Ethernet
* DSL service with 3 Mbps down and 500 Kbps up signaling speed. Peak usable data throughput measured to 2.5 Mbps down and 410 Kbps. Base ping measurements to the first ISP router is a stable 12 milliseconds.
* uTorrent 2.0 build 16850 used for BitTorrent download and upload. It is worth noting that BitTorrent corporation acquired uTorrent in 2006 and that the official BitTorrent client called “BitTorrent” is nearly identical to uTorrent although the vast majority of users use uTorrent.
* Google Chrome build 3.0.195.6 used for HTTP download
* Downloaded files were roughly 100 MB for both BitTorrent and HTTP
* HTTP download source was a YouTube cache that can reliably deliver close to the peak 2.4 Mbps on downstream
* BitTorrent file had 40 connections (5 high throughput peers and 14 moderate or low throughput peers) on downstream and 5 connections on upstream
* Used bandwidth reported in KB/sec in uTorrent and Chrome
* Almost every peer that connected to me during my testing were uTorrent 1.8.4 or 1.8.5.

Figure 1: uTorrent 2.0 still hogs over 90% of the network over HTTP


As we can see in figure 1, the new BitTorrent uTP protocol which now runs over UDP instead of TCP still manages to hog over 90 percent of the network’s resources over HTTP (the protocol used by web browsers) when the two applications are used concurrently. So even though we’re primarily using BitTorrent over UDP instead of TCP, the same principle of unfairness in TCP congestion control still applies. Furthermore, it’s not just the bandwidth hogging aspect of BitTorrent that’s problematic, BitTorrent running over uTP induces just as much jitter (measured in ping) as it did before. This jitter is illustrated in figure 2 and 3.

Figure 2: uTorrent 2.0 upload & download traffic causes massive jitter


Figure 3: BitTorrent uTP upload traffic causes significant jitter


With uTorrent 2.0 running primarily over uTP with downstream running at ~90% capacity and upstream running at ~80% capacity over my DSL connection, ping times were increased 100 to 200 milliseconds with occasional 1000+ millisecond measurements where the ping measurement timed out. These ping times are absolutely toxic to real-time applications like VoIP or online gaming. Even with upstream only traffic, ping times still increased up to 70 milliseconds over the baseline ping measurement of 12 milliseconds.

Even a ping increase of 70 milliseconds is unbearable for online gaming. For VoIP communications, 70 milliseconds might sound tolerable but my Lingo VoIP phone service routinely drops audio when I’m only uploading with BitTorrent much less uploading and downloading.

The user has a blunt way of throttling how much bandwidth their BitTorrent client consumes but this is a very inefficient way that over penalizes and under penalizes BitTorrent because it doesn’t allow for intelligent bandwidth sharing. User throttling means BitTorrent bandwidth is hard capped at some arbitrary percentage when it would be much more efficient if the P2P protocol were given lower priority so it can move out of the way when necessary but be allowed to consume 100% of the network most of the time. Figure 4 below illustrates how intelligent networks are better.

Figure 4: Intelligent network bandwidth sharing better for everyone.


Furthermore, even capping BitTorrent to 20% of upstream capacity still generates significant amounts of jitter that would be problematic for online gaming and VoIP as shown in figure 5. If we managed the network intelligently with smart queue management, we could permit BitTorrent or any other P2P application to operate at full speed without any kind of throttling which would be extremely beneficial to P2P users. Upstream jitter management would ideally be performed in the DSL or Cable modem while downstream jitter management would need to be performed at the Cable or DSL headend. This is important because a large number of P2P users are online gamers and VoIP users who deliberately shut off P2P whenever they game or use VoIP.

Figure 5: Low bandwidth BitTorrent still causes high ping times


In conclusion, the need to intelligently manage the network to improve the efficiency of the network and fairly allocate bandwidth between applications and users remains a top priority. Unfortunately, the FCC’s current NPRM draft rules does not allow broadband providers to favor any applications because it believes this is always a bad form of “discrimination”. But the reality is that there is a universally fair way to prioritize applications by always giving low bandwidth and low duration applications priority over high bandwidth and high duration applications. The FCC should make exceptions for good discrimination in its NPRM.

UPDATE 5:17PM

Ernesto from Torrent Freak (the author of the original story debated here) was kind enough to link back to this article. I realize that there’s going to be people angry with me about this but I’d like to remind people that I am one of the earliest fans of uTorrent and that I still believe that uTorrent VERY good code. I am also a uTorrent user myself and I want to see solutions that make every protocol work better including BitTorrent. I don’t like hard bandwidth caps whether they’re implemented by the user because they’re afraid to bomb their own broadband connection or if they’re implemented by the ISP (typically in Canada). I’d much rather see per-subscriber fairness at the broadband level and per-user fairness at the home level with intelligent prioritization and queue management that maximizes throughput for everything and minimizes jitter. Also important is the fact that lower priority P2P could be given far more generous usage caps (think of cheap bulk shipping rates) especially if it causes no congestion for other subscribers. Ultimately what is really needed is good dialog between BitTorrent users and network operators.

Update 7:24PM

I’ve contacted BitTorrent’s engineers and they have posted a response here (in comment section). Note that they do not contradict any data in here. They don’t even claim to address the fact that BitTorrent will hog 10 times or more bandwidth due to the multi-flow aspect of BitTorrent. The only thing they’ve said in email to me with regard to bandwidth usage was that “use of idle bandwidth was a design objective”. The problem that they’re not just using “idle” bandwidth; they’re taking away a lot of bandwidth from other applications and other users and taking a much bigger piece of the pie (as shown in figure 1 above) than justified.

About the only thing BitTorrent claims is that the new uTP protocol tries to keep upstream jitter to less than 100 milliseconds which is still way too high for online gaming and even my Lingo VoIP telephone service. The downstream jitter is admittedly much greater. At best, the new uTP protocol has minimal benefits upstream jitter and it completely ignores the problem of downstream jitter and bandwidth hogging. If we were to be generous, uTP solves half of one congestion problem out of three.

From the looks of it, it seems that people are reading too much into the claims that the new BitTorrent protocol is “network friendly” and that it somehow obviates the need for smarter network management. From the data that I have collected and from BitTorrent’s response, these claims appear to be greatly exaggerated.

shamelessly ripped from:
Digital Society Blog Archive Analysis of BitTorrent uTP congestion avoidance