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.