Comcast, Reset Packets, and Network Neutrality

Comcast was kind enough to invite me to a conference call between one of their engineers and some think tank folks. They feel their policies have been mischaracterized in the press. While I found some of the information they shared helpful, I frankly don’t think they helped their case very much.

While he didn’t say so explicitly, the Comcast guy seemed to implicitly concede that the basic allegations are true. He emphasized that they were not blocking any traffic, but that in high-congestion situations they did “delay” peer-to-peer traffic to ease the load. Apparently the Lotus Notes thing was a bug that they’re working to fix. He refused to go into much detail about exactly how this “delay” was accomplished, but presumably if the AP’s story about TCP resets were inaccurate, he would have said so.

To be fair, most of the people on the call were lawyers or economists, not technologists, so it’s possible he just didn’t think anyone other than me would care about these details. Still, it seems like part of the the point of having an engineer on the call would be to answer engineering-type questions. He also made a couple of points that I found a little patronizing. For example, he emphasized that most users wouldn’t even be able to detect the traffic-shaping activities they use without special equipment and training. Which is true, I guess, but rather beside the point.

If you haven’t read it yet, I recommend the discussion in response to Jerry’s post. I don’t know enough about the internals of cable modem protocols to know for sure who’s right, but Tom seems to me to make a good point when he says that forging reset packets is a wasteful and disruptive way to accomplish traffic shaping. The TCP/IP protocol stack is layered for a reason, and I can’t see any reason for routers to be mucking around at the TCP layer, when throttling can perfectly well be accomplished in a protocol-neutral manner at the IP layer.

Someone asked why Comcast didn’t throttle on a user-by-user basis rather than a protocol-by-protocol basis, and he said they were concerned with the privacy implications of that approach. That doesn’t make a lot of sense to me. Very few users are going to consider the number of bits they’ve transferred in a given time period to be confidential information.

We also asked about why there wasn’t more transparency about what throttling methods were being used and against which protocols. Apparently, Comcast feels that disclosing those sorts of details will make it easier for users to circumvent their throttling efforts. That doesn’t strike me as terribly persuasive; customers are entitled to know what they’re getting for their money, and people are going to figure it out sooner or later anyway. All secrecy accomplishes is to make them look bad when someone discovers it and reports it to the press.

With all that said, I’m not sure I see an obvious policy response. It seems to me that regardless of what the law says, there’s always going to be a certain amount of cat-and-mouse between ISPs and the heaviest network users. As Don Marti has pointed out, workarounds are easy to find. Add in a healthy dose of negative publicity, and it seems to me that while Comcast’s behavior is far from laudable, it’s far from obvious it’s a serious enough problem to justify giving the FCC the opportunity to second-guess every ISP’s routing policies.