Prompted by Comcast's traffic management practices, which use TCP reset packets that seem to come from elsewhere on the Internet, and Comcast's initial denial of same, the makers of peer-to-peer application Vuze (previously known as Azureus) decided to investigate how widespread this practice is. They did this by creating a plugin for the popular BitTorrent client that monitors and reports TCP resets—from any application running at the time. They then ranked ISPs by how many attempted TCP connections were interrupted by reset packets. And guess who is at the top of the list.

If you said "Comcast," you guessed correctly. According to the Vuze people's initial results, the number of reset connections was 20 percent for that ISP's subscribers. For AOL it's only 15 percent, 11 for RoadRunner and less than 3 percent for Euronet Orange in the Netherlands, to name just a few of the ISPs in the report. Based on these results, Vuze sent letters asking for traffic management transparency to four ISPs with "irregular percentages": Cablevision, Cogeco in Canada, BellSouth (now owned by AT&T), and AOL.

But what, if anything, do these measurements tell us? The Vuze people carefully avoid drawing hard and fast (or any) conclusions, and rightly so. Their methodology appears unable to discern the difference between a TCP reset that came from the peer or server on the other side of a TCP connection and one generated by an ISP in the middle.

What TCP resets do

The function of TCP resets is twofold: first of all, they serve as a mechanism to indicate that there's no server process running on a certain port number. If a user is running a peer-to-peer application, the application opens up one or more port numbers for incoming sessions so that other peers can connect. When the user stops the program, the port is closed, but peers may still try to connect for some time. If they do, they'll get a reset.

The second function of resets is to clean up stale sessions. For instance, if a computer crashes in the middle of a download, the server will probably still be sending packets after the client reboots. The client then sees packets that belong to a session that it doesn't recognize, so it sends a reset to make the session disappear on the server side. Something similar happens when a session has been idle for a while and there is a home router in the middle that performs NAT (network address translation). NAT boxes remove idle TCP sessions after a while. When there are subsequently more packets, those can't be translated properly, so the session will end in a reset.

On top of all of this, it seems that Microsoft is playing fast and loose with the TCP specification. Normally, TCP sessions end after an exchange of "fin" packets. But according to an analysis by researchers from the University of Calgary, both Microsoft's IIS web server and Internet Explorer use resets rather than fins to end HTTP sessions. This can easily generate the levels of resets seen by the Vuze plug-in.

The differences in numbers of resets between ISPs are still curious. It's entirely possible that some of them use the same traffic management method as Comcast. But there are other possible explanations as well. For instance, some ISPs use HTTP proxies or even transparent HTTP proxies (that intercept all HTTP traffic). If these proxies end TCP sessions with resets rather than fins, this could easily explain a high number of resets. Vuze tells Ars that it can't fully explain the results. "We cannot say what is normal or irregular RST levels, we can only compare the data to itself," a company spokesperson told Ars. "What the data shows is that there is a significant discrepancy between those ISPs on the high end and those on the low, indicating that further research and explanations are necessary."

If two peers both have the plug-in, it shouldn't be too hard to see if incoming resets at one end match outgoing ones at the other end, but the company tells Ars that the plug-in was "developed to simply observe the network connections being made" and that matching incoming and outgoing resets would "require further development." Without that additional development, we can't know what percentage of the resets are generated by someone in the middle.