I agree. What's the moral of the story here? Causing a bottleneck by saturating a T1 causes jitter and latency? Not exactly a game changer there. It seems like the point of the article was simply to vilify bit torrent. For example if they had tried to download a large file via FTP over a T1 the same thing would have happened. Does that make FTP evil? Not hardly. Conversely, if he had chosen a torrent that only used 200kbps would that have ruled bit torrent safe for use at every Starbucks? No again.
This is the point of separating traffic into classes, the idea that we can increase bandwidth until the bottlenecks go away is just as flawed as the idea of throttling less profitable traffic to almost nothing. A popular torrent will run at about 5M - 10M on a residential internet connection. If you have several users (or even a single user) downloading different torrents on the same cell you will have a problem. Increasing the bandwidth without taking measures to prevent file transfer protocols (bit torrent, ftp, http/https) from using all available bandwidth would only delay the inevitable. I remember using napster when I was younger and I would have filled up whatever pipe I was given. It would have been much worse if I could have done so at Starbucks with my friends while drinking passion tea. Just my 2c. Keegan On Tue, Oct 26, 2010 at 12:35 PM, Bob Frankston <[email protected]>wrote: > A T1 backhaul? If you’ve got a 54Mbps connection on a T1 backhaul then > that’s the problem! Why blame the user (AKA the victim) when a provider has > created an extreme constriction? The idea of then giving the unproviders who > created the problem the ability to certify the applications adds insult to > injury!! How can one say the user is hogging the bandwidth when the > unprovider has taken 99.99% of the capacity off the table. Who is the hog? > > > > You can read http://rmf.vc/?n=Unbaked as to why the idea of baking in the > naiveté of today’s provider is so dangerous. Just wait till we have > connected devices as the norm – http://rmf.vc/?n=MakerDisconnect. > > > > > > *From:* Dave Farber [mailto:[email protected]] > *Sent:* Tuesday, October 26, 2010 11:52 > *To:* ip > *Subject:* [IP] Effects of BitTorrent on a wireless hotspot > > > > > > > Begin forwarded message: > > *From:* Jon Henke <[email protected]> > *Date:* October 26, 2010 11:47:24 AM EDT > *To:* [email protected] > *Subject:* *Effects of BitTorrent on a wireless hotspot* > > [For your IP-consideration] > > > > George Ou posted this interesting piece about the impact of BitTorrent on a > wireless hotspot. Result: "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." > > > > > http://www.digitalsociety.org/2010/10/effects-of-bittorrent-on-a-starbucks-att-hotspot/ > > > Effects of BitTorrent on a Starbucks-AT&T hotspot > By George Ou <http://www.digitalsociety.org/author/georgeou/> 25 October > 2010 > > > > > > I recently discussed the phenomenon of a single application accidentally > taking > down a T-Mobile > cell<http://www.digitalsociety.org/2010/10/aggressive-im-app-took-down-t-mobile-wireless/>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. > > *Figure 1: Starbucks performance indicates T1 backhaul* > > 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 = 209.85.243.160) 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 links can be harmed by BitTorrent which would > certainly bring down a typical cell tower backhaul which would harm the > dozens of wireless cells served by a single tower. That would affect > hundreds or thousands of users. > > *Figure 3: Starbucks Wi-Fi – Latency with BitTorrent active* > > So how would this affect other users during operational hours? They’d be > pretty upset with the massive degradation in performance not to mention the > fact that BitTorrent has the ability to hog most of the > bandwidth<http://www.digitalsociety.org/2009/11/analysis-of-bittorrent-utp-congestion-avoidance/>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<http://www.formortals.com/why-bittorrent-causes-so-much-jitter-high-ping-and-how-to-fix-it/>. > 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<http://www.digitalsociety.org/2010/03/we-cant-pretend-wireless-and-wired-networks-are-the-same/>. > 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 measure in tests like the ones conducted > above. The better approach than 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 prohibitions on applications. > > > > > _______ > > Jon Henke > > 202-595-4323 > > Twitter: @jonhenke > > > > > > > > > > Archives <https://www.listbox.com/member/archive/247/=now> > <https://www.listbox.com/member/archive/rss/247/504681-1464f1c1>| > Modify<https://www.listbox.com/member/?member_id=504681&id_secret=504681-f8ca49a9>Your > Subscription | Unsubscribe > Now<https://www.listbox.com/unsubscribe/?member_id=504681&id_secret=504681-a6e8d5ec> > > <http://www.listbox.com> > > >
