The problem that we ultimately run into is this: the TCP sliding window mechanism solves Internet congestion at the expense of fairness. Sessions that don’t get their packets randomly dropped have a larger chunk of bandwidth than those that don’t, and the more data a connection carries, the larger its window.

Good fairness control works in exactly the opposite way: the more data a stream offers, the lower its priority should go. And that’s the root of the problem that carriers have to solve.

Do note that the BitTorrent tracker doesn’t monitor which peers are connected to each other, nor does it measure peer popularity. As long as the seeder-tracker connection is established (Sandvine, for example, does not terminate this connection), new leechers that don’t know any better will still attempt to contact the seeder.

With respect to CMTS upstream bandwidth clamping making the problem worse, I’m not sure it does long term. Yes, you will have additional “bandwidth request contention” when the CMTS starts ignoring requests, but TCP (even multiple TCP streams) will adjust to this by reducing the transmit rate [eventually].

I also wanted to clarify that I am suggesting an upstream bandwidth throttle on a per-user, not on a system level. The 80% who don’t consume won’t be affected. The 20% who do consume will be affected, but this, to me, is fine–they are the ones sucking up the bandwidth and/or violating the TOS/AUP.

It probably goes without saying that I think operators need to be very clear about their expectations and what sort of actions they take (e.g., violate the AUP and you are cut-off/throttled).

Your alternative suggestion actually aggravates the contention problem. If the subscriber’s modem doesn’t get a reservation when it asks for it, it will simply retry (following some backoff interval.) The requests themselves are subject to collision, and that’s one thing Comcast wants to minimize.

The cable modem operator doesn’t want to put down application-independent throttles on all upstream bandwidth requests from subscribers because most of them are legitimate. The 20% who consume 80% of the bandwidth are the target.

Correcting some ambiguity in my previous comment, I meant to suggest having the cable headend (CMTS) clamp the user’s upstream bandwidth through its “bandwidth request response” algorithm. If fewer upstream bandwidth requests are approved, the cable modem will limit the traffic that gets to the cable headend causing less impact on other users–this addresses the “upstream bandwidth contention” issue in an application-independent way.

If we’re back to just a bandwidth usage argument[2], wouldn’t the more “neutral” method/solution be a network appliance that identifies bad behavior and clamps the user’s upstream bandwidth at the cable headend[3]? This method is also asynchronous and is as general as the “bad behavior” detection algorithm. The big con is that it requires tighter integration with the cable infrastructure (likely a greater expense depending on infrastructure “openness” [3],[4]). In your initial post, you claim that such a method/solution (bandwidth cap) won’t work; I still don’t buy this argument as connection requests and DOCSIS bandwidth allocation contention shouldn’t drastically change with a TCP reset-based solution.

—
[1]: Sandvine apparently doesn’t terminate tracker connections so a seeder will continue to show up in the tracker’s peerlist

[2]: The argument that BitTorrent users hog the upstream pipe degrading the usability of the service for [other] paying customers

[3]: Comcast seems to have this capability (in reverse)–PowerBoost temporarily increases the allowed upstream bandwidth.

[4]: It could be argued that this is an opportunity for cable infrastructure vendors. More solutions could conceivably drive prices down…

The fact that the Resets are asynchronous to the data stream allows the manufacturer (Sandvine, in this case) to use cheaper hardware than an in-line packet-dropping solution. Money matters.

It has been shown (in referenced papers) that DOCSIS networks are vulnerable to a DoS attack resulting in potentially severe service degradation to [other] clients of the shared uplink/downlink channels.
Seeding BitTorrent clients create network traffic analogous to the DoS attack.
Network operators (e.g., Comcast) can offer a better (more ‘fair’) experience to their customer base if they avoid the DoS by preventing excessive BitTorrent seeding behavior. The cost-effective way for an operator to do this is to destroy BitTorrent connections (e.g., “forged RST” from a Sandvine network appliance).

While I see the similarity [in (b)] between network traffic resulting from BitTorrent seeders and the DoS attack, I’m still not convinced that the “forged RST” solution solves anything more than the P2P bandwidth consumption issue[1]. Specifically, these “forged RST” packets are injected into the TCP flow after the connection is established[2]–the RST packets do not eliminate uplink traffic or uplink contention. If this is the case[3], I would prefer to see operators address this through application-independent traffic shaping techniques that don’t attempt to classify traffic/applications… I believe it is this “deep classification” behavior, not traffic shaping issues, that most irks network neutrality proponents.

—
[1]: I realize that bandwidth consumption by BitTorrent users is also be a big problem on DOCSIS networks as described in the Martin/Westall paper. While BitTorrent is efficient at utilizing uplink bandwidth, this is not a BitTorrent-specific issue and does not, to me, justify destroying TCP connections as a traffic shaping technique.

[2]: Example TCP dump.

[3]: Any pointers to data and/or research examining this effect would be very welcome.