Re: [Bloat] Questions for Bufferbloat Wikipedia article

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 6 Apr 2021 23:59:53 +0200
Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:

> Hi,
> 
> On Tue, Apr 06, 2021 at 10:02:21PM +0200, Bless, Roland (TM) wrote:
> > On 06.04.21 at 20:50 Erik Auerswald wrote:  
> > >On Tue, Apr 06, 2021 at 08:31:01AM +0200, Sebastian Moeller wrote:  
> > >>>On Apr 6, 2021, at 02:47, Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:
> > >>>On Mon, Apr 05, 2021 at 11:49:00PM +0200, Sebastian Moeller wrote:  
> > >>>>>On Apr 5, 2021, at 14:46, Rich Brown <richb.hanover@gmail.com> wrote:
> > >>>>>
> > >>>>>Dave Täht has put me up to revising the current Bufferbloat article
> > >>>>>on Wikipedia (https://en.wikipedia.org/wiki/Bufferbloat)
> > >>>>>[...]  
> > >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.  
> 
> That worked for decades, then stopped working as well as before.
> What changed?
> 
> Yes, there are complex interactions with how packet switched networks
> are used.  Otherwise we would probably not find ourselves in the current
> situation.
> 
> To me, the potential of having to wait minutes (yes, minutes!) for
> the result of a key stroke over an SSH session is not worth the potential
> throughput performance gain of buffers that cannot be called small.
> 
> > There are at least two solutions
> > to the bufferbloat problem
> > 1) better congestion control algorithms
> > 2) active queue management (+fq maybe)  
> 
> Both approaches aim to not use all of the available buffer space, if
> there are unreasonably large buffers, i.e., they aim to not build a
> large standing queue.
> 
> > [...]
> > 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.  
> 
> Could the better congestion control algorithms avoid the potential
> performance loss by not requiring large buffers for high throughput?
> Might small buffers incentivise to not send huge bursts of data and hope
> for the best?
> 
> FQ with AQM aims to allow the absorption of large traffic bursts (i.e.,
> use of large buffers) without affecting _other_ flows too much.
> 
> I would consider the combination of FQ+AQM, better congestion control
> algorithms, and large buffers as an optimization, but using just large
> buffers without any of the other two approaches as a mistake currently
> called bufferbloat.  As such I see large unmanaged buffers at the core
> of the bufferbloat problem.
> 
> FQ+AQM for every large buffer may solve the bufferbloat problem by
> attacking the "unmanaged" part of the problem.  Small buffers may solve
> it by attacking the "large" part of the problem.  Small buffers may
> bring their own share of problems, but IMHO those are much less than
> those of bufferbloat.
> 
> I do not see TCP congestion control improvements, even combining
> sender-side improvements with receiver-side methods as in rLEDBAT[0],
> as a solution to bufferbloat, but rather as a mitigation.
> 
> [0] https://datatracker.ietf.org/doc/draft-irtf-iccrg-rledbat/
> 
> Anyway, I think it is obvious that I am willing to sacrifice more
> throughput for better latency than others.
> 

For Wikipedia it is important to make clear:
  * the symptoms = large latency
  * the cause = large buffers and aggressive protocols
  * the solutions = AQM, smaller buffers, pacing, better congestion control, etc.

People can argue over best combination of solutions but the symptoms and
causes should be defined, and non-contentious.

It is too easy to go off in the weeds and have the solution of the day.