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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
