From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-14-ewr.dyndns.com (mxout-192-ewr.mailhop.org [216.146.33.192]) by lists.bufferbloat.net (Postfix) with ESMTP id A23B52E0438 for ; Thu, 10 Feb 2011 06:55:14 -0800 (PST) Received: from scan-11-ewr.mailhop.org (scan-11-ewr.local [10.0.141.229]) by mail-14-ewr.dyndns.com (Postfix) with ESMTP id 753A49D1C2B for ; Thu, 10 Feb 2011 14:55:12 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 76.96.62.96 Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mail-14-ewr.dyndns.com (Postfix) with ESMTP id 827D59D1CCE for ; Thu, 10 Feb 2011 14:55:10 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id 6EKV1g0011ZXKqc59EvB9G; Thu, 10 Feb 2011 14:55:11 +0000 Received: from [192.168.1.119] ([98.229.99.32]) by omta21.westchester.pa.mail.comcast.net with comcast id 6Ev81g00M0hvpMe3hEvAS4; Thu, 10 Feb 2011 14:55:11 +0000 Message-ID: <4D53FC4B.5000307@freedesktop.org> Date: Thu, 10 Feb 2011 09:55:07 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <20110205132305.GA29396@thyrsus.com> <20110208181811.GD7744@thyrsus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] First draft of complete "Bufferbloat And You" enclosed. X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 14:55:15 -0000 On 02/08/2011 11:24 PM, Justin McCann wrote: > On Tue, Feb 8, 2011 at 1:18 PM, Eric Raymond wrote: >> ... >> The underlying image in my just-so stories about roads and parking lots >> is that packet flow coming in smooth on the upstream side of a buffwer >> gets turned into a buffer fill, followed by a burst of packets as it >> overflows, followed by more data coming into the buffer, followed by >> overflow...repeat. > > I think this image isn't quite right for wired networks, but happens a > lot in wireless networks. > >> ... >> I don't understand "ack clocking". Alas, my grasp of networking becomes >> sketchy below the level of socket APIs. I know what's in a TCP packet, >> roughly, but have no precise feel for what happens with bits on the wire. > > The first figure in the paper Bill Sommerfeld linked to is the best > explanation; here's another decent picture of it: > > http://sd.wareonearth.com/woe/Briefings/tcptune/sld038.htm > > I can explain in more detail, but I figure it will be less precise > than what's in the paper. in the analogy, the parking lot has a > metered-rate exit--- cars coming in from ten different entrances at > different rates can *never* exit faster than the fixed outgoing rate. > They can exit slower than the metered rate, but not faster, so any > "clumping" has to be caused by something other than the size of the > parking lot (at least at this link). > > Considering Richard's email, I think the VJ paper assumes that the > scheduling in the OS and hardware are not bursty. That is, that the OS > doesn't send clumps of packets to the interface hardware to transmit, > so the hardware buffer doesn't oscillate between full and empty. If > the OS *does* send in bursts due to interrupt latency, scheduling, bus > contention, or a weird application, then you have a different nasty > problem. That sort of clumpy/flighty/bursty behavior is problematic in > general, but I think bufferbloat is only an indirect cause (glad to be > corrected here). > > Well, another way to think about transport protocols is as servo systems, that apply feedback to control the rates. If you look at the TCP traces that set me off on this merry chase, you see quite violent periodic behaviour, where the periods are quite long (of order 10 seconds). Injecting delays way beyond the natural RTT is hazardous to the stability of transport protocols. You can see TCP slowly losing its mind it's RTT estimation gets longer and longer as the buffer fills. Eventually, it goes ballistic. The servo system's stability has been destroyed... - Jim