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) <[email protected]> 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 <[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? > 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 > [email protected] > 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 [email protected] <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
