Broadband Politics - Latest Comments in DOCSIS vs. BitTorrent

Re: DOCSIS vs. BitTorrent

Richard Bennett — Mon, 03 Dec 2007 19:59:11 -0000

The tracker doesn't monitor performance, it monitors who has the file parts. Performance is a distributed problem. Is a leecher going to retry a seeder who sends him Resets, or is he going to try another one? The data indicates that it tries another.

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.

Re: DOCSIS vs. BitTorrent

David Scherba — Sun, 02 Dec 2007 21:07:15 -0000

I don't disagree that the TCP RST works.

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).

Re: DOCSIS vs. BitTorrent

Richard Bennett — Sun, 02 Dec 2007 15:13:07 -0000

The TCP RST will prevent the leecher from retrying the connection, at some point, so it is effective; a number of measurements confirm this, in fact. The leecher decides the seeder is down and moves on. When the Tracker is next updated, nobody has connections with the throttled seeder to report, so his popularity declines.

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.

Re: DOCSIS vs. BitTorrent

David Scherba — Sun, 02 Dec 2007 13:16:03 -0000

BitTorrent clients do not know what data rate they will achieve with a given peer before trying. The BitTorrent tracker does not store/communicate this information; communication is facilitated simply by maintaining and providing a list of peers. This protocol behavior is why reseting TCP connections won't stop/slow connection attempts and associated "request contention" of the cable modem link.

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.

Re: DOCSIS vs. BitTorrent

Richard Bennett — Thu, 29 Nov 2007 06:24:43 -0000

BitTorrent clients choose the servers with the best reported data rates, don't they? The tracker simply facilitates this. Again, Comcast's goal is to limit the traffic that gets to the cable headend, not drop it after it's already got there.

Re: DOCSIS vs. BitTorrent

David Scherba — Tue, 27 Nov 2007 03:01:49 -0000

Looking at the BitTorrent specification (unofficial, yet detailed, wiki) and at a couple of tracker implementations, it doesn't appear that BitTorrent trackers "demote" anything in practice. Yes, TCP resets will [inexpensively] kill "file server" behavior (asymmetric upstream bandwidth), but this does not necessarily reduce the number of contentious network requests[1]. Do you know otherwise?

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...

Re: DOCSIS vs. BitTorrent

Richard Bennett — Mon, 26 Nov 2007 20:21:00 -0000

The effect of injecting TCP Resets in the data stream is the demotion of the seeder in the BitTorrent tracker's list of eligible seeders, which reduces the number of connection requests it's going to see. This is the behavior that Comcast wants, a near-total reduction in file servers operating on residential accounts. There isn't another method that accomplishes this goal as efficiently, as IP lacks support for traffic shaping and bandwidth hog throttling in particular.

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.

Re: DOCSIS vs. BitTorrent

David Scherba — Sun, 18 Nov 2007 20:44:27 -0000

Thank you for bringing some more technical information into the discussion of BitTorrent on DOCSIS networks—I've enjoyed reading your thoughts and the referenced academic papers. Your argument/explanation for/of network operator behavior seems to be:

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.