On Tue, 6 Apr 2021 23:59:53 +0200 Erik Auerswald <[email protected]> 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 <[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) > > >>>>>[...] > > >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. _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
