Hi,
On 06.04.21 at 20:50 Erik Auerswald wrote:
Hi,
On Tue, Apr 06, 2021 at 08:31:01AM +0200, Sebastian Moeller wrote:
On Apr 6, 2021, at 02:47, Erik Auerswald <[email protected]> wrote:
On Mon, Apr 05, 2021 at 11:49:00PM +0200, Sebastian Moeller wrote:
On Apr 5, 2021, at 14:46, Rich Brown <[email protected]> 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.
Fair enough, timeouts could be changed though if required ;) but I fully
concur that laergeish buffers require management to become useful ;)
Yes, large unmanaged buffers are at the core of the bufferbloat problem.
I disagree here: it is basically the combination
of loss-based congestion control with unmanaged
tail-drop buffers. There are at least two solutions
to the bufferbloat problem
1) better congestion control algorithms
2) active queue management (+fq maybe)
You can achieve high throughput and low delay with
a corresponding congestion control (e.g., see this
study of how to achieve a common limit on queuing
delay for multiple flows: https://ieeexplore.ieee.org/document/8109356)
even in large buffers.
One can make buffers small again, or manage them appropriately.
The latter promises better results, the former is much simpler.
Small buffers definitely limit the queuing delay as well as
jitter. However, how much performance is potentially lost due to
the small buffer depends a lot on the arrival distribution.
Regards,
Roland
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
