Re: [Bloat] Questions for Bufferbloat Wikipedia article

[Dave Taht <dave.taht@gmail.com>]

roland do you have running code for lola on linux? I'm running some
starlink tests...

On Wed, Apr 7, 2021 at 4:06 AM Bless, Roland (TM) <roland.bless@kit.edu> wrote:
>
> Hi Erik,
>
> see inline.
>
> On 06.04.21 at 23:59 Erik Auerswald 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?
> Larger buffers in many places and several orders of magnitude higher
> link speeds
> as well as higher awareness for latency as an important QoS parameter.
> > 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?
> Yes, at least our TCP LoLa approach achieves high throughput without
> loss and
> a configurable limited queuing delay. So in principle this is possible.
> > Might small buffers incentivise to not send huge bursts of data and hope
> > for the best?
> There are different causes of bursts. You might get a huge burst from
> many flows
> that send only a single packet each, or you might get a huge burst from
> a few connections
> that transmit lots of back-to-back packets. Therefore, it depends on the
> location
> of the bottleneck and on the traffic arrival distribution.
> > 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.
> My counter example is that large unmanaged buffers would not necessarily
> lead to the bufferbloat problem if we had other congestion controls that
> avoid
> creating large standing queues. However, in practice, I also see only AQMs
> and better CCs in combination, because we have to live with legacy CCs
> for some time.
> > 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/
> As already said: the TCP LoLa concept shows that it is possible
> to solve the bufferbloat problem by a different congestion control approach.
> However, the coexistence of LoLa with loss-based CCs will always be
> a problem unless you separate both CC types by separate queues.
> Currently, LoLa is rather an academic study showing what is possible
> in theory, but it is far from being usable in the wild Internet,
> as it would require much more work to cope with all the peculiarities
> out there.
>
> Regards,
>   Roland
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729