Analyzing Comcast's "data discrimination" incident
Was it network management or data discrimination? Comcast’s “denial of service” incident, which I wrote about earlier, provided a fresh impetus to Net Neutrality proponents in their crusade for improved regulation of Internet service. Public interest groups like Public Knowledge and Save the Internet called on Net Neutrality champions in the Senate to move more aggresively on their agenda. Comcast customer John Hart filed a lawsuit against the company for interfering with his file sharing.
However, caught up in the hype was the question of what exactly the Net Neutrality camp was protesting. Were Comcast’s actions, however deceptive they may have been, driven by the need to manage network traffic or were they indeed discriminating against file-sharing services BitTorrent and Lotus. And how could we ensure a clear separation of the two motives that would be transparent to the user. I decided to dig a little deeper into the technical details of the incident to improve my understanding of the issue and help me separate facts from rhetoric.
On the first point, George Ou of ZDNet has a very informative article in which he explains what actually happened, and what it got publicized as —
“Comcast was found to be actively resetting TCP connections on BitTorrent peer-to-peer file trading connections by forging TCP reset packets that appear to be coming from the BitTorrent peers. When most of us hear the term “forged TCP reset packets”, it sounds like Comcast has crossed the line of reasonable network management Comcast is guilty of application discrimination. So when word of this got out, all hell broke loose and the knifes were out for Comcast’s blood.”
Ou says that the TCP reset packets seem to have originated from the host, or “upload” machine because of the way the modem transfer protocol is written. He quotes Richard Bennett, who designed the protocol —
“Cable modems have a crappy upstream protocol. When it wants to send, it sends a request to send packet to the controller, and waits for a reply that gives it a time slot. But the RTS packet is sent in a contention slot, such that any two stations sending RTS in the same cycle will collide, and then nobody gets to transmit. The more data you have queued at the cable modem, the more likely a collision.
The network is physically large, with a long propagation delay relative to the size of the collision window. And when collisions start to happen, they ripple as more and more stations have data queued for transmission. So the only way to make this protocol stable is to actively limit the amount of data queued at the cable modem for upstream delivery, and only way to do that for Torrent is to stifle connections at the TCP level. I’ve tried to scheme up a better way to do this, and there isn’t one.”
Meaning, essentially, that it is the flawed design of the modem itself, which, under certain traffic conditions, makes the return TCP address look “forged”.
So there we have it from the horse’s mouth. Comcast doesn’t specificially block you from using BitTorrent, it simply limits the number of simultaneous uploads you can perform at once, to avoid a possible network meltdown. Thus, “content-based discrimination” is one thing they cannot be accused of in this instance, although the company’s repeated denials, and refusal to explain their traffic management practices did affect their image.
And this plays into the problem that I have with some of the more vocal public interest groups in the Net Neutrality camp - their arguments are sometimes based on perceptions that, technically, don’t have a leg to stand on. And when confronted with a strong techncial argument — as in this case that the network routing was just not sophisticated enough to deal repeated demands for large bandwidth — their stand is weakened. To win the network neutrality argument, each side needs to be on a strong footing vis a vis the nuts and bolts of the internet, and not make far flying assumptions which would only hurt their position.
So what would it take for the “content discrimination” issue to become more transparent, without having to call in the experts? Susan Crawford offers a possible solution, which she calls “Structural separation”, which stipulates a financial separation network providers, and any content they carry over the network.
David Isenberg expands on the concept, saying —
“If, instead, we had a law that said, “Network operators must not have a financial interest in any of the content carried by that network,” we could be assured that any network operator’s network management would be for the sole purpose of running the network. Such a law would keep government out of the network management business. Enforcement would be via financial audit.”
Thus, the network provider would gain nothing out of content or services, because it would own no services, applications or content.
Improved disclosure of network bandwidth capacity and network management practices wouldn’t hurt either.