Effects of BitTorrent on a Starbucks-AT&T hotspot
I recently discussed the phenomenon of a single application accidentally taking down a T-Mobile cell and how BitTorrent would have an even worse effect. I wanted to test this with BitTorrent, but doing so on a cell tower isn’t feasible at this moment and it’s not something that any wireless carrier would want me to test on their production network. So I found the next best thing during off hours at a Starbucks hotspot operated by or in conjunction with AT&T and Wayport. I conducted the tests well after store closing in front of the store from my car when no one was at the store, and the BitTorrent test only ran for 141 seconds so that it wouldn’t disrupt any background activity that the store might be running.
There are a lot of similarities between a Wi-Fi “hotspot” (effectively a cell) and a wireless 3G cell, but the Wi-Fi cell has a lot more wireless capacity because it has 20 MHz of spectrum compared to a typical 5 MHz or 10 MHz cell on a 3G cell and because Wi-Fi is working at closer range with hundreds of times higher radio frequency (RF) field density. Public hotspots like the ones operated by Starbucks usually employ a T1 (symmetrical 1.554 Mbps) backhaul as confirmed by Figure 1 below which is similar to many cell tower backhauls. The backhauls on 3G and LTE towers are likely faster than a T1, but the 3G tower has less capacity than a hotspot running 802.11g. That means what harms a Wi-Fi hotspot will also harm a 3G cell in a similar manner.
Note that the measured speed is below “1.554” because it is measuring data throughput excluding overhead and because they’re using the binary definition of megabit which calls for 1,048,576 bits/sec instead of a decimal definition of 1 million bits/sec.
First I had to get a baseline measurement when nothing was running. Figure 2 shows that the Starbucks hotspot had a baseline latency of 148.8 milliseconds (ms) to the first pingable hop (IP address = 220.127.116.11) on the network.
Figure 2: Starbucks Wi-Fi – baseline latency
Next, I fired up BitTorrent and it was uploading and downloading at around 1.4 Mbps including overhead bandwidth which is about as fast as I could push it with no user defined bandwidth constraints in the BitTorrent application. Figure 3 shows that the average latency with BitTorrent running went up to 772.3 ms which is an increase in jitter of 623.5 ms. From further testing, I verified that the jitter was induced on the T1 backhaul and it didn’t stress the 54 Mbps capacity of the Wi-Fi access link, but it could easily stress the wireless link of a 2G or 3G cell. It’s also noteworthy that even faster 3, 5, or 15 Mbps broadband downstream links can be harmed by BitTorrent. This type of application would certainly bring down a typical cell tower backhaul which would harm dozens of wireless cells served by a single tower. That would affect hundreds or thousands of active users.
Figure 3: Starbucks Wi-Fi – Latency with BitTorrent active
So how would this affect other users during operational hours? They probably wouldn’t know what hit them but they would be angry with the massive increase in jitter and bandwidth starvation due to the fact that BitTorrent has the ability to hog most of the bandwidth at the expense of other users and applications. Even when BitTorrent is capped at a lower bandwidth, the sheer volume of signaling and payload packets per second can overwhelm a wireless network and even low bandwidth BitTorrent can cause a lot of jitter. This is why I ran the tests off hours.
On a production cellular network, there is likely little to prevent a user from running bandwidth hogging and jitter inducing applications like BitTorrent other than the “Acceptable Use Policy” (AUP) that forbids these network disruptive applications and possibility some technical mechanisms that throttle overactive users. But there are Net Neutrality advocates who want the regulators to forbid these network management practices and application restriction policies because they want to pretend that wireless networks are the same as wired networks. But it’s clear that from an engineering perspective, such policies would be harmful to the vast majority of paying customers on the network and it would prevent the network carriers from maintaining an operational network.
Now some would argue that carriers shouldn’t have blanket prohibitions against an entire set of applications because those applications might be able to operate in a non-disruptive manner. But that doesn’t address the reality of how the applications perform in real world tests like the ones conducted above. The better approach to blunt regulatory force would be if application providers like BitTorrent worked with the wireless carriers on application certification where the application provider demonstrates that their application avoids generating jitter and avoids taking a disproportionate amount of bandwidth. The alternative is a more actively managed data network where the wireless base station actively distributes bandwidth fairly between subscribers and prevents a single application from inducing jitter. That level of network management doesn’t exist today so until it does, the networks do the best they can to keep the networks running which includes prohibiting certain applications.