[Bloat] queuebloat

[Jim Gettys]

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 
> <http://www.google.com/trends?q=bufferbloat>. 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat