22 October 2007
Comcast has finally made some statements on what they're doing to peer-to-peer traffic. Briefly, they likened it to a telephone busy signal: when the network is too busy — though they won't say what their criteria are — some connections are interrupt. It's supposedly almost transparent, since "the software automatically tries again".
That won't fly. Stating that the software will retry assumes a certain model of software. Perhaps some particular clients will retry. Others may not. The semantics of a TCP Reset are quite well-defined; there's even an Internet Best Current Practice that warns against other inappropriate TCP Resets.
In my earlier post, I noted that Comcast did have one legitimate concern: upstream bandwidth is expensive. According to some reports, though, that isn't what Comcast is trying to conserve. TorrentFreak notes that the technology "breaks every (seed) connection with new peers after a few seconds if its not a Comcast user." In other words, you're allowed to consume the expensive upstream bandwidth; however, you're not allowed to use too much of Comcast's connections to its peers. Eric Rescorla notes that this is "a pretty attractive way to reduce network traffic without overly annoying too many of your users." It's also reminiscent of Comcast's 2003 attempt to redirect web traffic through a "transparent" proxy. They quickly gave up that behavior, though the major concern expressed at the time was customer privacy.
It's worth noting that others have used TCP Resets to block traffic they don't want. The most notorious offender is China, which uses Resets to implement its Great Firewall. Is this the model that Comcast wishes to emulate?