From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-22-ewr.dyndns.com (mxout-151-ewr.mailhop.org [216.146.33.151]) by lists.bufferbloat.net (Postfix) with ESMTP id DEF922E04C5 for ; Tue, 8 Feb 2011 10:18:17 -0800 (PST) Received: from scan-22-ewr.mailhop.org (scan-22-ewr.local [10.0.141.244]) by mail-22-ewr.dyndns.com (Postfix) with ESMTP id 6EAFA34764 for ; Tue, 8 Feb 2011 18:18:16 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 71.162.243.5 Received: from snark.thyrsus.com (static-71-162-243-5.phlapa.fios.verizon.net [71.162.243.5]) by mail-22-ewr.dyndns.com (Postfix) with ESMTP id 3585C3430E for ; Tue, 8 Feb 2011 18:18:12 +0000 (UTC) Received: by snark.thyrsus.com (Postfix, from userid 23) id A5DCA20C1BE; Tue, 8 Feb 2011 13:18:11 -0500 (EST) Date: Tue, 8 Feb 2011 13:18:11 -0500 From: Eric Raymond To: Justin McCann Message-ID: <20110208181811.GD7744@thyrsus.com> References: <20110205132305.GA29396@thyrsus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.20 (2009-06-14) Cc: bloat@lists.bufferbloat.net 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 Reply-To: esr@thyrsus.com List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:18:18 -0000 Justin McCann : > This may be intentional, but the text launches into an explanation of > why bufferbloat is bad without concisely explaining what it is--- you > have to read the whole first two sections before it's very clear. Not intentional, exactly, but's inherent. Thec reader *can't* get what bufferbloat. > The second of the three main tactics states, "Second, we can decrease > buffer sizes. This cuts the delay due to latency and decreases the > clumping effect on the traffic." Latency *is* delay; perhaps "cuts the > delay due to buffering" or "due to queueing" would be better, if more > tech-ese. Good catch, I'll fix. > I've re-read through the Bell Labs talk, and some of the earlier > posts, but could someone explain the "clumping" effect? I understand > the wild variations in congestion windows ("swing[ing] rapidly and > crazily between emptiness and overload"), but clumping makes me think > of closely spaced packet intervals. It's intended to. This is what I got from jg's talk, and I wrote the SOQU scenario to illustrate it. If my understanding is incorrect (and I see that you are saying it is) one of the real networking people here needs to whack me with the enlightenment stick. 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. > This statement is one I find problematic: "A constantly spaced string > of cars coming in tends to turn into a series of clumps coming out, > with size of each clump controlled by the width of the exit from the > the parking lot." If the bottleneck bandwidth is a constant 10 Mbps, > then the outgoing packets will be spaced at the 10 Mbps rate (the ACK > clocking effect). They aren't really more clumped going out than they > came in-- in fact, with more traffic joining at the choke point, a > given flow's packets will be spaced out even more than they were > before. This isn't quite so true on a wireless link, where it's not > the buffering so much as the variation in actual layer-2 goodput due > to retransmissions and rate changes that cause clumping. > > The essential problem is that the increase in RTT slows the feedback > loop, so if a queue is creating an 8 second delay, there can be 8 > seconds of badness and changes before *any* connection slows down (or > speeds up). The problem isn't clumping so much as it is the delay in > feedback. 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. -- Eric S. Raymond