From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-11-ewr.dyndns.com (mxout-129-ewr.mailhop.org [216.146.33.129]) by lists.bufferbloat.net (Postfix) with ESMTP id CBFC52E03C2 for ; Wed, 13 Apr 2011 07:30:32 -0700 (PDT) Received: from scan-11-ewr.mailhop.org (scan-11-ewr.local [10.0.141.229]) by mail-11-ewr.dyndns.com (Postfix) with ESMTP id 53F6B92F4E4 for ; Wed, 13 Apr 2011 14:30:32 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.216.43 Received: from mail-qw0-f43.google.com (mail-qw0-f43.google.com [209.85.216.43]) by mail-11-ewr.dyndns.com (Postfix) with ESMTP id D7ACE92F4E2 for ; Wed, 13 Apr 2011 14:30:28 +0000 (UTC) Received: by qwf6 with SMTP id 6so517898qwf.16 for ; Wed, 13 Apr 2011 07:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:organization :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Loc3ADcySEXEN1SmsBGjucaleYZmhJZtHAdIlAl3oC8=; b=nuSIPGb8KZvFtynQ/bamk6cZpfPgxLpJquc59gLF+pgBmO8Yi8t7pbk7N1xIvN6wCr rMsN66YvxzQMJLbIDfwiqdXESBzme04auVtRBZTozof6v4n1UPR6kqSBolEylh7mb2DG kA1+yZJ4dPxrAb1NBcfX6V92ZHJvA0cgtm2v8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=QQJgjqXXy+zqyeFHxkRfzUDI+XnVBhK9Ly3JwznTqu0nJ1T7Z71Jg9oAOjbmmry61g B6YQX5/F7saLE0+dUSGjVQ0zDc064oSpiK4/GncAnHqgJPprc2CRiwY4OW8TGB8ihimF 0/wBYO3Q655gwnlglLamFqCoHoJOWXvChwLDg= Received: by 10.224.174.81 with SMTP id s17mr3088942qaz.333.1302705026361; Wed, 13 Apr 2011 07:30:26 -0700 (PDT) Received: from [192.168.1.119] (c-98-229-99-32.hsd1.ma.comcast.net [98.229.99.32]) by mx.google.com with ESMTPS id m7sm422914qcg.5.2011.04.13.07.30.24 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 07:30:25 -0700 (PDT) Sender: Jim Gettys Message-ID: <4DA5B37F.7040504@freedesktop.org> Date: Wed, 13 Apr 2011 10:30:23 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <201104131119.p3DBJIBu025003@bagheera.jungle.bt.co.uk> In-Reply-To: <201104131119.p3DBJIBu025003@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] queuebloat 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, 13 Apr 2011 14:30:33 -0000 On 04/13/2011 07:19 AM, Bob Briscoe wrote: > Folks, > > [This is to repeat to the list one of many conversations I had with > Jim Gettys at the recent IETF...] > > The term bufferbloat seemed to hit a rich vein in marketing the > importance of this problem > . But actually it's a > misleading name that will confuse (unsavvy) equipment vendors when > they come to work out what to do about it. > > The problem is actually queuebloat, not bufferbloat. The buffer is the > memory set aside for the queue. The queue is how much of the memory is > used to store packets or frames. I think you are picking nits on the naming, though if you'd had the suggestion last fall, I might have gone for it And there are buffers that hide in systems that are not packet queues, that people also should be aware of (e.g. encryption buffers, error correction buffers, buffers in applications used for pipelining, etc). So I'm not convinced that queuebloat is a better term, as it is less general than the phenomena I was trying to describe. In any case, I think it's water under the dam at this date. > > We don't want vendors to (necessarily*) reduce the size of the buffer, > we want them to reduce the size of the standing queue. They can do > that with active queue management (AQM) (if we only knew how to code > it robustly). Ideally with ECN too, but AQM would be a good start. Some of these buffers are truly bloated, and/or not sized even approximately related to the bandwidth available (e.g. the 1.2 seconds of buffering I observed on my DOCSIS3 modem, or similar horror stories in DSL), or the 1000 packet transmit queue in Linux. These buffers are often sized by all the memory that is available, and the hardware vendors can't get small enough chips to "correctly" size them, (as though we knew what the bandwidth was, or the delay was, one of the mythologies that got us into this mess). One of the first steps (well short of the nirvana of AQM), is to at least get the buffers sized to something sane, and related to the bandwidth the hardware is being operated at. And as each generation of new kit is built (and often as a market requirement has to plug into downward compatible hardware), it's been getting worse. This is what the cable folks are in the middle of doing; it's obviously safe to at least have the buffer sizes approximately proportional to the bandwidth at which the device is operating (similarly for the Linux transmit queue; if you are at 100Mbps, you can cut the size by a factor of 10 without any danger). With the ability to go hundreds of megabits/second but most customers paying for 10-20Mbps, it is pretty obvious the buffer size had better be related to the bandwidth of operation, and never be a static buffer sized for the worst case. Let's not lose sight of immediate, safe mitigations that are at hand, while working on AQM with or without ECN, though that is the only real, long term solution. > > A reasonable* sized buffer is still needed to absorb bursts without > loss. If builders of kit make their buffers smaller in response to our > criticism, during bursts users will experience loss rather than delay. > That will lead transports to wait for a timeout to detect these > losses. So small buffers would just introduce a new cause of poor > responsiveness. The focus should be on small queues, not small buffers. See above about the observed buffer sizes, along with the fact that the buffers/queues are not sized to the operating bandwidth. See the frightening scatterplot of the ICSI netalyzr data, and keep in mind that that dataset under detected bufferbloat. Multi-second size buffers are commonplace. > > OK, maybe it's not a good idea to ditch a catch-phrase that has > captured the public imagination. But we should be careful to nuance > its meaning when explaining to kit builders what they should do about it. Yup. I agree that nuance is necessary. I think we have to be firm that AQM is the only real solution, but there is mitigation they can often apply quickly to make the situation less horrible. - Jim > > Cheers > > > Bob > ___________ > * You don't need buffers larger than the timeouts in typical transport > protocols, otherwise a burst can build up more delay than a transport > is prepared to wait for. Then you start wasting energy maintaining > unnecessary amounts of fast memory. > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat