Comcast FCC filing shows gap between hype, bandwidth reality

By Nate Anderson | Published: February 13, 2008 - 12:42PM CT
http://arstechnica.com/

Comcast has come clean to the FCC about its secretive traffic- management practices... not that Comcast thinks it has been keeping  
secrets. According to its 57-page filing, "experience suggests that  
Comcast needs to ensure that its disclosures on matters such as  
network management are timely and in sufficient detail to ensure  
transparency while not providing a roadmap to those who would seek to  
defeat its efforts at reasonable network management." While that  
doesn't explain the months of stonewalling from the company, at least  
now we have some official answers to how Comcast's Sandvine network  
management system works.


The FCC launched an investigation into Comcast's network management  
practices earlier this year after Vuze, a company that uses P2P to  
legally distribute video content, objected to Comcast's practice of  
degrading P2P connections on its network. Comcast has finally changed  
its Terms of Service to make more clear that the company reserves this  
right, but the FCC wants to know whether Comcast's system goes beyond  
"reasonable network management."

How it works

To understand the system, it's important to realize that each  
household with cable lacks an individual line back to the central  
office. Instead, homes are wired up to local nodes, with every home on  
that node drawing from the same pool of bandwidth. In the Comcast  
network, each node typically serves 450 households, but when as few as  
15 BitTorrent upload sessions are running concurrently, all 450 homes  
can see their network access impeded enough to be noticeable when  
surfing and making VoIP calls. This is due to a second feature of  
cable networks (and ADSL networks): upload bandwidth is far more  
limited than download bandwidth.

These networks were built to suck data from the center of the 'Net to  
the edges. P2P inverts that model, pulling data directly from other  
users along the edge of the network. This creates a problem for  
Comcast, which asserts that it applies no blocking, delaying, or  
throttling to downloads, no matter how many are proceeding  
simultaneously on a local node.

But Comcast doesn't delay all P2P uploads, either. According to its  
filing, network management only kicks in "when P2P unidirectional  
upload sessions (i.e., sessions where a computer is only uploading and  
not simultaneously uploading and downloading) reach a predetermined  
congestion threshold in a particular neighborhood." The goal here is  
to stop unattended machines from using significant upload bandwidth,  
though Comcast says that the "delay" is removed once the "number of  
active uploading sessions drops below that threshold."

How does the delay work? Exactly as the AP and the EFF have claimed:  
TCP reset packets. These are generated from Comcast's network  
management hardware and tell the uploading computer that some sort of  
error has developed in the connection and that it needs to start over.

According to Comcast, "it is not accurate to describe these reset  
packets as 'forged'," though it doesn't say why. (To the uploading  
computer, the packets appear to come from the machine on the other end  
of the connection.) Comcast also calls critics guilty of "inflammatory  
hyperbole" on this point.

[snip]

This is ironically exactly the mechanism used by the Great Firewall of China. When China does it, we call it "censorship" . \

Details on the use of TCP resets and how users can ignore forged TCP resets are here:
http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf
Richard Clayton, "Ignoring the Great Firewall of China", 6th Workshop on Privacy Enhancing Technologies, Cambridge UK, June 2006

"    Abstract The so-called "Great Firewall of China" operates, in part, by inspecting TCP packets for keywords that are to be blocked. If the keyword is present, TCP reset packets (viz: with the RST flag set) are sent to both endpoints of the connection, which then close. However, because the original packets are passed through the firewall unscathed, if the endpoints completely ignore the firewall's resets, then the connection will proceed unhindered. Once one connection has been blocked, the firewall makes further easy-to-evade attempts to block further connections from the same machine. This latter behaviour can be leveraged into a denial-of-service attack on third-party machines. "