Almost 70,000 users from locations around the world have used our
tool, Glasnost, to test whether their BitTorrent traffic is being
manipulated. On this page, we present preliminary results from these
tests. The tests were conducted between March 18th and October 20th, 2008.
We will update this page with more detailed results as we get more data from the tests. We also hope to uncover more cases of blocking as we refine our measurement tool and our analysis. So make sure to check back later. Alternately, you can stay up-to-date on our findings by subscribing to the glasnost-updates mailing list.
We have released the source code of our tool. You are welcome to download and inspect the code. Please contact us if you find any bugs or have questions, comments, or suggestions.
We published a paper on this work in the ACM Internet Measurement Conference 2008.
It contains updated results up to July 25th, 2008 from more than 47,300 end users.
You can download the paper in pdf format here.
You can find the older version of this page from 25.07.2008 here.
Table of contents|
1. How do we detect BitTorrent blocking by ISPs?
At a high level, our test sets up a series of
BitTorrent flows between an end user's host and our Glasnost test
We collect the packet trace for each flow on the server side,
and we closely monitor both end points for any error conditions that
might cause a flow to be aborted. If a flow is aborted by a
control (RST) packet that was not sent by either
of the end points, we report the flow as being blocked by some ISP
along its path.
For more details on how we detect BitTorrent blocking, please click here.
2. Are ISPs blocking BitTorrent traffic?
Note: This map was created using GeoLite data by MaxMind, available from http://www.maxmind.com/.
The map plots the geographic location of the 69,696 nodes that ran
our BitTorrent tests. These hosts are distributed across 149 countries
and 2,614 access ISPs. Hosts that found their BitTorrent transfers being
blocked are marked in red.
Circles represent multiple measurements from the same location; the bigger the circle the more the number of measurements from the same place.
Note: ISPs may throttle (rate-limit) BitTorrent traffic without blocking it. The results we present here are limited to hosts whose BitTorrent transfers to our servers are blocked, i.e., interrupted by RST packets generated by some ISP along the path. We are still actively investigating techniques to accurately detect throttling. So we do not report any results on rate-limiting BitTorrent traffic at this time and we do not mark such throttled hosts in red.
The table below shows for each country (a) the number of hosts that ran our test, (b) the number of hosts for which we detected BitTorrent blocking, (c) the number of distinct access ISPs from which our test was run, and (d) the number of these ISPs that contained one or more hosts for which we detected BitTorrent blocking.
3. Details of blocked BitTorrent transfers
1. All hosts which observed blocking did so in the upstream
direction (i.e., when the client host attempted to upload data to one
of our Glasnost servers). Only a handful of hosts observed blocking for downstream
2. We found widespread blocking of BitTorrent transfers only in the U.S. and Singapore. Interestingly, even within these countries, most of the hosts that observed blocking belonged to a few large ISPs.
3. Both in the U.S. and in Singapore, all hosts that suffered BitTorrent blocking are located in cable ISPs. We did not see any blocking of BitTorrent transfers from DSL hosts in these countries.
Most (3,894 of 4,100) U.S. hosts that observed blocking are located in Comcast and Cox networks. In Singapore, all blocked hosts are connected using the StarHub network. While we did observe blocking for hosts in 88 other ISPs (35 of which are in the U.S.), we did not see widespread blocking of BitTorrent traffic for hosts in those ISPs.
The table below shows the details of BitTorrent blocking for Comcast, Cox, and StarHub. For each ISP, we show (a) the number of distinct hosts we measured, and (b) the number of these hosts for which we detected BitTorrent blocking.
4. Is BitTorrent blocked only during periods of network congestion?
Recently it has been reported
that Comcast defended its BitTorrent
blocking before FCC as a necessary practice that is done only during
periods of heavy network traffic. It is widely known
that network traffic exhibits a strongly diurnal pattern. So we analyzed
our data to see if hosts in Comcast and Cox networks see fewer of
their upstream transfers blocked during early morning or weekends (when network
load is generally low) than during other times of the day.
The left graph below shows (a) the number of measurements to Comcast hosts at different hours of the day and (b) the percentage of these measurements for which we observed BitTorrent blocking. The percentage of blocked tests remains high at all times of the day. Our data suggests that the BitTorrent blocking is independent of the time of the day.
The right graph below shows that the percentage of blocked BitTorrent connections remains fairly high even during the weekends for Comcast hosts.
Similarly, the left graph below shows that Cox hosts suffer BitTorrent blocking at all times of the day. Note that the data for Cox is more noisy than Comcast, due to smaller number of measured hosts.
The right graph below shows that the percentage of blocked BitTorrent connections remains fairly high even during the weekends for Cox hosts.
5. Are ISPs changing their BitTorrent blocking policies?
The graphs below show how the percentage of blocked BitTorrent connections changed during the last 6 months for Comcast, Cox, and StarHub customers. We notice a significant reduction in blocked BitTorrent tests for all three ISPs.
We are researchers at the Max Planck Institute for Software Systems. Our research focuses on characterizing residential broadband networks and understanding their implications for the designers of future protocols and applications. In case you have questions about this tool or our research, please visit our network transparency project webpage or contact us via e-mail:
Krishna P. Gummadi