Comcast Reveals How it Throttled BitTorrent

Complies with recent FCC ruling demanding that it detail it's network management practices, while also admitting that it was infective 80% of the time.

Comcast has finally submitted a formal response to the FCC's recent ruling that the ISP violated the agency's principles for electively targeting and throttling the connection speeds of a single application - BitTorrent - as part of its overall efforts in managing network traffic.

"Accordingly, we institute a plan that will bring Comcast’s unreasonable conduct to an end," reads the ruling. "In particular, we require Comcast within 30 days to disclose the details of their unreasonable network management practices, submit a compliance plan describing how it intends to stop these unreasonable management practices by the end of the year, and disclose to both the Commission and the public the details of the network management practices that it intends to deploy following termination of its current practices."

In the first part of Comcast's disclosure it reveals that it began testing out Sandvine Policy Traffic Switch 8210 (“Sandvine PTS 8210”) as early as May 2005 after determining that the "...use of several P2P protocols was regularly generating disproportionate burdens on the network, primarily on the upstream portion." At the start of 2006 it then began deploying the Sandvine equipment on a commercial basis, achieving wide-scale deployment in 2007.

Now, in selecting which P2P protocol uploads to manage, Comcast analyzed network data to identify the particular protocols that were generating disproportionate amounts of unidirectional traffic (uploading or seeding only). Based on that analysis, five P2P protocols were identified to be managed: Ares, BitTorrent, eDonkey, FastTrack, and Gnutella. Four of those protocols have been subject to Comcast’s management practices since Comcast first implemented these practices. Ares was added in November 2007 after traffic analysis showed that it, too, was generating disproportionate demands on network resources.

WHAT COMCAST EXAMINED...

The following table lays out by protocol the simultaneous unidirectional upload session thresholds for each protocol as well as the typical ratio of bidirectional to unidirectional traffic observed on our HSI network for those P2P protocols that use both, and other factors that contribute to the overall bandwidth consumption by protocol.

When the number of unidirectional upload sessions for any of the managed P2P protocols reaches the pre-determined session threshold as shown above, the Sandvine PTS issues instructions called “reset packets” that delay unidirectional uploads for that particular P2P protocol in the geographic area managed by that Sandvine PTS. Once the number of simultaneous unidirectional uploads falls below the pre-determined session limit threshold for a particular protocol, new uploads using that protocol are then allowed to proceed.

Oddly enough, Comcast also readily admits that its congestion management efforts - Sandvine PTS - had no effect, even for the most heavily used P2P protocols, on more than 90 percent of the P2P upstream traffic. It adds that in cases when a P2P upload was delayed by a reset packet, that that same PC successfully reinitiated a P2P upload within one minute in 80% of the cases. I presume that's why it's decided to scrap P2P throttling efforts in favor of more tangible restrictions like the 250GB p/mo data cap it plans to begin enforcing October 1st.