<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Broadband Politics - Latest Comments in Hogging the Trough: The EFF Strikes Back</title><link>http://bennettblog.disqus.com/</link><description>Networking technology and policy</description><atom:link href="https://bennettblog.disqus.com/hogging_the_trough_the_eff_strikes_back/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Mon, 04 Feb 2008 14:13:01 -0000</lastBuildDate><item><title>Re: Hogging the Trough: The EFF Strikes Back</title><link>http://bennett.com/blog/2008/01/hogging-the-trough-the-eff-strikes-back/#comment-2135044</link><description>&lt;p&gt;It can request multiple reservations at one time, but won't typically do so unless it has the packets already queued.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Richard Bennett</dc:creator><pubDate>Mon, 04 Feb 2008 14:13:01 -0000</pubDate></item><item><title>Re: Hogging the Trough: The EFF Strikes Back</title><link>http://bennett.com/blog/2008/01/hogging-the-trough-the-eff-strikes-back/#comment-2135043</link><description>&lt;p&gt;Thanks for the response.&lt;/p&gt;&lt;p&gt;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?&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bugmenot</dc:creator><pubDate>Thu, 31 Jan 2008 18:57:59 -0000</pubDate></item><item><title>Re: Hogging the Trough: The EFF Strikes Back</title><link>http://bennett.com/blog/2008/01/hogging-the-trough-the-eff-strikes-back/#comment-2135042</link><description>&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;*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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Richard Bennett</dc:creator><pubDate>Mon, 28 Jan 2008 05:54:59 -0000</pubDate></item><item><title>Re: Hogging the Trough: The EFF Strikes Back</title><link>http://bennett.com/blog/2008/01/hogging-the-trough-the-eff-strikes-back/#comment-2135041</link><description>&lt;p&gt;Can you elaborate on this point: &lt;br&gt;&lt;/p&gt;&lt;blockquote&gt; "The bottleneck on the&lt;br&gt;upstream side isn't bandwidth per se, it's the packet rate. So a&lt;br&gt;number of connection requests use up the cable modem's contention&lt;br&gt;slots before raw bandwidth is maxed out. It's not about bandwidth,&lt;br&gt;it's about duty cycle."  &lt;/blockquote&gt;&lt;p&gt;&lt;/p&gt;&lt;p&gt;Is your argument, in sum, the following?  &lt;br&gt;&lt;/p&gt;&lt;blockquote&gt; In contrast to&lt;br&gt;other forms of traffic, Bittorrent produces a large number of small&lt;br&gt;synchronization (SYN/ACK) packets which substantially increases&lt;br&gt;contention at the DOCSIS MAC level (through collisions on the&lt;br&gt;"contention slot"? Or contention for mini-slots?). Packet drop has no&lt;br&gt;appreciable effect on the number of these packets and so such&lt;br&gt;"throttling" is ineffective. &lt;/blockquote&gt;&lt;p&gt;&lt;/p&gt;&lt;p&gt;I would expect the rate of contention to be a function of the amount&lt;br&gt;of data to be transmitted and not the number of packets: if you are&lt;br&gt;constantly sending data you need to vie for the same transmit slots&lt;br&gt;regardless of the size or type of the individual packets. That is, the&lt;br&gt;same data rate HTTP transfer should create the same degree of&lt;br&gt;contention as a Bittorrent transfer.&lt;/p&gt;&lt;p&gt;Second, the amount of contention is limited in some way (it is not&lt;br&gt;unbounded). How?&lt;/p&gt;&lt;p&gt;Finally, in the paper you cited, "Assessing the Impact of&lt;br&gt;BitTorrent on DOCSIS Networks" I see no comparison to performance&lt;br&gt;degradation caused by other forms of traffic (e.g. HTTP). That there&lt;br&gt;is contention when links are highly utilized is not under&lt;br&gt;question. There is no evidence in that paper that Bittorrent, as a&lt;br&gt;protocol, causes more contention that other forms of traffic.&lt;/p&gt;&lt;p&gt;Please do not shy away from precise, technical explanations.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bugmenot</dc:creator><pubDate>Fri, 25 Jan 2008 19:20:56 -0000</pubDate></item><item><title>Re: Hogging the Trough: The EFF Strikes Back</title><link>http://bennett.com/blog/2008/01/hogging-the-trough-the-eff-strikes-back/#comment-2135040</link><description>&lt;p&gt;I agree that Comcast hasn't handled the issue well. They should be the ones defending their actions, not me.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Richard Bennett</dc:creator><pubDate>Thu, 24 Jan 2008 22:45:39 -0000</pubDate></item><item><title>Re: Hogging the Trough: The EFF Strikes Back</title><link>http://bennett.com/blog/2008/01/hogging-the-trough-the-eff-strikes-back/#comment-2135039</link><description>&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">yesno</dc:creator><pubDate>Thu, 24 Jan 2008 22:39:39 -0000</pubDate></item></channel></rss>