Hogging the Trough: The EFF Strikes Back

My latest salvo in the ongoing debate with the EFF over Comcast is up at the Register today, Hogging the Trough: The EFF Strikes Back

BitTorrent’s behavior on the Comcast network is like a glutton at an all-you-can-eat buffet who insists on planting himself at the trough, preventing others from getting to the food. This causes multiple problems for DOCSIS cable networks, which caused Comcast’s network managers to throttle uploads under high-load conditions (but not prohibit them outright) using a technique called Reset Spoofing.

The EFF has a preferred way of dealing with this, random packet drop. For EFF this is the One True Method of traffic management. But as I’ve explained to Eckersley both in print and over the phone, the problems BitTorrent causes can’t be healed by random packet drop.

Packet drop would work with the regular diner who takes a plateful and moves on, but not with this super-hungry dude.

This discussion will be continued Saturday at the Toll Roads symposium in Frisco, which you can catch via webcast on UStream.tv.

6 thoughts on “Hogging the Trough: The EFF Strikes Back”

  1. I think your article is right in its technical analysis, and EFF was unwise to enter into such a debate. I still think their fundamental point is right, however: Comcast has approached this issue in a hamhanded way.

    In the context of unmetered broadband, it’s odd to call people who are using a service they have paid for a “hog.” If you pay for unlimited broadband, you’re entitled to unlimited broadband. Fine print caveats like “unlimited reasonable use” are too weasly.

  2. Can you elaborate on this point:

    “The bottleneck on the
    upstream side isn’t bandwidth per se, it’s the packet rate. So a
    number of connection requests use up the cable modem’s contention
    slots before raw bandwidth is maxed out. It’s not about bandwidth,
    it’s about duty cycle.”

    Is your argument, in sum, the following?

    In contrast to
    other forms of traffic, Bittorrent produces a large number of small
    synchronization (SYN/ACK) packets which substantially increases
    contention at the DOCSIS MAC level (through collisions on the
    “contention slot”? Or contention for mini-slots?). Packet drop has no
    appreciable effect on the number of these packets and so such
    “throttling” is ineffective.

    I would expect the rate of contention to be a function of the amount
    of data to be transmitted and not the number of packets: if you are
    constantly sending data you need to vie for the same transmit slots
    regardless of the size or type of the individual packets. That is, the
    same data rate HTTP transfer should create the same degree of
    contention as a Bittorrent transfer.

    Second, the amount of contention is limited in some way (it is not
    unbounded). How?

    Finally, in the paper you cited, “Assessing the Impact of
    BitTorrent on DOCSIS Networks” I see no comparison to performance
    degradation caused by other forms of traffic (e.g. HTTP). That there
    is contention when links are highly utilized is not under
    question. There is no evidence in that paper that Bittorrent, as a
    protocol, causes more contention that other forms of traffic.

    Please do not shy away from precise, technical explanations.

  3. DOCSIS requires a bandwidth request for each packet*, regardless of the packet’s size. Each request goes upstream in one of 6 or 8 contention slots reserved for bandwidth requests. This activity is packet-rate-dependent, not packet-size dependent, so it’s not a function of bandwidth consumption.

    *Bandwidth requests can be piggy-backed on data packets, but that only works when there are multiple data packets queued in the modem, and even in that case is dependent on the presence of optimization in the modem’s firmware.

  4. Thanks for the response.

    Just to clarify: A single bandwidth request can only serve a single TCP packet? That is, the modem cannot make a request for slots for multiple packets simultaneously during the use of a single contention slot?

Leave a Reply

Your email address will not be published. Required fields are marked *