For the Love of Kaity...

Recently, it has been observed that Comcast is disrupting TCP connections using forged TCP reset (RST) packets [1]. These reset packets were originally targeted at TCP connections associated with the BitTorrent file-sharing protocol. However, Comcast has stated that they are transitioning to a more "protocol neutral" traffic shaping approach [2]. We have recently observed this shift in policy, and have collected network traffic traces to demonstrate the behavior of their traffic shaping. In particular, we are able (during peak usage times) to synthetically generate a relatively large number of TCP reset packets aimed at any new TCP connection regardless of the application-level protocol. Surprisingly, this traffic shaping even disrupts normal web browsing and e-mail applications.

New traffic shaping can disrupt a Comcast Internet connection

I think I hear the entire Comcast tech support department committing seppuku.

From a technical standpoint, there are few options that are more idiotic than sending reset packets to kill BitTorrent connections, as Comcast was doing previously. They just did one: killing ALL connections in that manner. This option is so bad, in fact, that it leads me to seriously consider the possibility that Comcast is doing this intentionally to teach the FCC a lesson: that its resetting BT connections wasn't so bad. What could/should Comcast have done differently? Let's look at a few possibilities.

The best option (excluding improving their infrastructure) would be to monitor the amount of traffic going through each modem, and if a disproportionately large amount is coming from one modem, tell the modem to limit traffic rate for that one modem. Unfortunately, I'm told Comcast modems do not have the ability to change maximum speed without a reboot, so this isn't really possible.

Failing that, there is an extremely simple yet efficient method: simply start randomly dropping packets when there's congestion. While this may sound like a sarcastic suggestion, it's not. The TCP protocol uses two pieces of information to determine how fast to send data: the amount of buffer space the receiver has (used to prevent the sender on a fast connection from flooding a receiver on a slow connection), and dropped packets. If a dropped packet is detected, TCP lowers its send rate. And if BT is a large proportion of traffic, randomly dropping traffic will result is a larger number of BT connections getting throttled than non-BT connections.

Thus this is a simple and easy way to effectively lower the amount of data being sent in a way biased against heavy bandwidth users, without interrupting any of the connections. This works even better if their Sandvine hardware can detect BT traffic and selectively drop packets only from BT traffic. As long as they weren't dropping so many packets that BT slowed to a crawl, I wouldn't mind my ISP doing this.