Re: [Bloat] Questions for Bufferbloat Wikipedia article

["Bless, Roland (TM)" <roland.bless@kit.edu>]

Hi Dave,

On 27.04.21 at 03:41 Dave Taht wrote:
> roland do you have running code for lola on linux? I'm running some
> starlink tests...

I think the latest code is here and unfortunately
it hasn't been updated for a while:
https://git.scc.kit.edu/TCP-LoLa/TCP-LoLa_for_Linux

However, in case that there are loss-based congestion controls
present at the bottleneck in addition to LoLa flows, LoLa will not get
any reasonable bandwidth, because we did not yet build in a more
aggressive mode for these cases in order to not sacrifice LoLa's low
delay goal. So you can give it a try, but it has not been
engineered for real world usage so far, so some default parameters
may not fit to your use case.

Regards,
  Roland

> 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
> 
> 
>