[Bloat] Questions for Bufferbloat Wikipedia article

[Bless, Roland (TM)]

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