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 <auers...@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.hano...@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
