[Bloat] queuebloat

[Bob Briscoe <bob.briscoe@bt.com>]

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.

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.

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.

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.

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