From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-04-iad.dyndns.com (mxout-195-iad.mailhop.org [216.146.32.195]) by lists.bufferbloat.net (Postfix) with ESMTP id D55D42E04FF for ; Tue, 8 Feb 2011 20:24:31 -0800 (PST) Received: from scan-01-iad.mailhop.org (scan-01-iad.local [10.150.0.206]) by mail-04-iad.dyndns.com (Postfix) with ESMTP id 58C798349A7 for ; Wed, 9 Feb 2011 04:24:31 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 74.125.82.171 Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by mail-04-iad.dyndns.com (Postfix) with ESMTP id BEE74834747 for ; Wed, 9 Feb 2011 04:24:30 +0000 (UTC) Received: by wyb38 with SMTP id 38so6336635wyb.16 for ; Tue, 08 Feb 2011 20:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I4pmAOYGbtnIPEpCJwKB13U6WbFfr4T03XHJZ7VktMc=; b=FrwSxLbZny1yTjCTnMUbuexJBC2I50K90OaQq7czeEopj9ww9Y7sAx0d/RCG0e+o6Q YjKGDhB5yQPouBgU/pMuo464eP+2SdpA09eanx6QqeTgTiCbhf8H8kH6qIksuDVYnyJo SCNJ0gyqC6xP6jGofjK7oWcxkVN0SSuJ9xa6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=H6tUfphm5UFIXAnyIHKmCYVSMvM9qU6qPTFN7QRklo+3lulP6B6KT98cGKTN6FqU0l vCAu+nin3IlW8vjFidWsIhT/Xp8WmOwEtsd8W2ETWEvCPFvZqhIBAMrDu/Q1eW4nIvTG xA+mQsVud1m227Be7HhSA/NuhQoPocfigSr4k= MIME-Version: 1.0 Received: by 10.227.134.69 with SMTP id i5mr18690752wbt.139.1297225468470; Tue, 08 Feb 2011 20:24:28 -0800 (PST) Received: by 10.227.2.208 with HTTP; Tue, 8 Feb 2011 20:24:28 -0800 (PST) In-Reply-To: <20110208181811.GD7744@thyrsus.com> References: <20110205132305.GA29396@thyrsus.com> <20110208181811.GD7744@thyrsus.com> Date: Tue, 8 Feb 2011 23:24:28 -0500 Message-ID: From: Justin McCann To: esr@thyrsus.com Content-Type: text/plain; charset=ISO-8859-1 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 List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 04:24:33 -0000 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). For example, if you're trying to transmit on a wireless link, you may have to wait a while before you can use it (noise, contention, scheduling). If you have a buffer full of packets, you'll jam them out at a much higher rate than you were doing just moments ago. That really screws with ACK clocking/pacing, and leads to wild swings in what TCP sends out--- slides 48 and 49 from that link (http://sd.wareonearth.com/woe/Briefings/tcptune/sld048.htm) are examples of what we don't want. Justin [1] This skips all sorts of details about varying packet sizes and so on, but you get the idea.