Hi,

thanks to the session recordings I just listened to the very
interesting ICCRG related discussion in the tsvarea meeting from
Monday.

Lars Eggert said something like:
"Bufferbloat is something that a congestion controller
can't really do anything about anyway...
it's not necessarily a congestion control problem."

I believe that this statement is not correct.
A large buffer will not be filled completely by a delay-based
congestion control (e.g., Vegas was a very early
one). Thus even if the buffer is large, the queuing
delay doesn't increase dramatically and we wouldn't
see that bufferbloat effect so prominently (as in slide 3 of
https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-reflections-on-congestion-control-praveen-balasubramanian-00.pdf).

So if _everyone_ would use such a delay-based variant, we wouldn't
have the bufferbloat problem.

However, since we have more loss-based congestion control variants
deployed, which will fill a tail-drop buffer completely, such
delay-based variants get suppressed and cannot get a reasonable share
of the bottleneck bandwidth. Therefore, several variants have a
fallback to a more aggressive mode in order to get a reasonable
share (I think Christian Huitema also referred to this by the different
modes). What could help is some kind of co-existence mechanism that
separates queue-filling TCP CC variants from delay-based variants
(e.g., see http://ieeexplore.ieee.org/document/7796842/ for details).
So IMHO getting rid of the queue filling variants would be useful,
but is probably hard in practice, i.e., replacing them isn't easy
due to the co-existence problem.

Consequently, fighting against bufferbloat could be done in the network
using AQMs (enforcing shorter queues) or by using a different
congestion control algorithm (trying to limit inflicted queuing delay),
or even by a combination of both. However, what delay and throughput
performance can be achieved with AQMs is limited, so better performance
in both metrics requires eventually a better congestion control algorithm.

Regards,
 Roland

Reply via email to