[Bloat] Questions for Bufferbloat Wikipedia article

[Erik Auerswald]

Hi,

On Mon, Apr 05, 2021 at 11:49:00PM +0200, Sebastian Moeller wrote:
> 
> all good questions, and interesting responses so far.

I'll add some details below, I mostly concur with your responses.

> > On Apr 5, 2021, at 14:46, Rich Brown <richb.hanover at gmail.com> wrote:
> > 
> > Dave Täht has put me up to revising the current Bufferbloat article
> > on Wikipedia (https://en.wikipedia.org/wiki/Bufferbloat)
> > [...]
> [...] while too large buffers cause undesirable increase in latency
> under load (but decent throughput), [...]

With too large buffers, even throughput degrades when TCP considers
a delayed segment lost (or DNS gives up because the answers arrive
too late).  I do think there is _too_ large for buffers, period.

> The solution basically is large buffers with adaptive management that

I would prefer the word "sufficient" instead of "large."

> works hard to keep latency under load increase and throughput inside
> an acceptable "corridor".

I concur that there is quite some usable range of buffer capacity when
considering the latency/throughput trade-off, and AQM seems like a good
solution to managing that.

My preference is to sacrifice throughput for better latency, but then
I have been bitten by too much latency quite often, but never by too
little throughput caused by small buffers.  YMMV.

> [...]
> But e.g. for traditional TCPs the amount of expected buffer needs
> increases with RTT of a flow

Does it?  Does the propagation delay provide automatic "buffering" in the
network?  Does the receiver need to advertise sufficient buffer capacity
(receive window) to allow the sender to fill the pipe?  Does the sender
need to provide sufficient buffer capacity to retransmit lost segments?
Where are buffers actually needed?

I am not convinced that large buffers in the network are needed for high
throughput of high RTT TCP flows.

See, e.g., https://people.ucsc.edu/~warner/Bufs/buffer-requirements for
some information and links to a few papers.

> [...]

Thanks,
Erik
-- 
The computing scientist’s main challenge is not to get confused by
the complexities of his own making.
                        -- Edsger W. Dijkstra