& Conjecture

Comcast has gotten in some pretty hot water lately over its blocking of peer-to-peer (P2P) protocols like BitTorrent (BT). I was fortunate enough to get off Comcast before this whole affair began. However, things aren't altogether different on my current ISP: SBC/Yahoo DSL. Though I haven't had much luck in the past finding others having the same problem, and while there have only been a handful (this is a word I've given my own definition to, meaning five or less) of cases, I've observed BT blocking on my current ISP as well.

In this post I'm going to talk about some theories I have about how this blocking system works on AT&T, based on my observations. It should be noted first of all that this is drawn from a very small number of observations; statistics 101 tells you that the smaller the sample size, the less accurate conclusions are expected to be. Nevertheless, I have observed behavior between these incidents that seems more or less consistent.

The system appears to consist of a stateful process which determines how to deal with traffic in several steps. In its normal mode of operation, there is no blocking or throttling of BT traffic. However, when a large volume of traffic is observed through one internet connection, the system enters an activated state, where it inspects the connection more carefully. However, it's still not blocking or throttling traffic. This state is relatively hard to get into, and from my experience requires multiple gigs of traffic over a period of time (exact amount unknown, but I tend to think a couple days; I believe I've only observed this when downloading one or more entire anime series at a time).

The second factor needed to trigger blocking/throttling is a smaller (but still substantial - on the order of dozens or hundreds of megs) amount of traffic on a single port (or maybe it's tracking individual TCP connections; I'm not certain at this point). I've typically observed this as taking several hours to activate.

Once this occurs, the system goes into throttle mode for that specific port. While I'm still not sure of the details of the mechanisms involved, I'll describe the symptoms I've observed when this mode is activated. Effective bandwidth in uploading through that port gradually decreases, until no TCP connection is able to pass more than a few dozen KB before being strangled to death (I'm not sure of the exact mechanism by which connections are strangled and killed).

As throttling mode is activated per port, other ports are unaffected. If you change BT to use a different port, BT will be able to resume full use of bandwidth. However, the system is still in an activated state and watching, and will strangle that port as well if it observes too much traffic flowing through it.

I've not done experiments to determine how long it takes for a port to leave throttle mode. I have, however, observed it to take a considerable amount of time (days) to return from activated mode to normal mode. Presumably it's watching how long it's been since the last port left throttle mode.

I would hypothesize that the reason for the two levels of activation is due to the cost of tracking per-port bandwidth, and the system does not wish to allocate that kind of computing resources for something which isn't considered to be a serious problem. But this is just conjecture - I don't know for certain that it only tracks port bandwidth when in an activated state; I'm merely attempting to fit a curve to a handful of points.

If you find any more information on the matter, I'd be interested to hear it.