Re: [Bloat] Solving bufferbloat with TCP using packet delay

[Juliusz Chroboczek <jch@pps.jussieu.fr>]

> - Is TCP using packet delay considered as part of the solution for
> bufferbloat?

Not on this list, apparently.  However, there has been a fair amount
of research on that approach in the late noughts.  I'd suggest
you search for papers on TCP Vegas, TCP-LP and LEDBAT.

In particular, LEDBAT is very widely deployed as part of uTP.  (Your
students are probably using it right now for making a backup of their
DVD collection.)

> - What are the problems of TCP delay variants that keep it from
> solving bufferbloat?

The main issue is the so-called late joiner advantage: these
algorithms tend to give an unfair advantage to flows that only joined
when the network was already congested, as compared to older flows.
I don't know if the issue has been solved yet, it's been some time
since I last looked at that stuff.

> - What are the drawbacks of the TCP delay variants that would favor
> AQM over TCP?

> - What are the advantages of TCP delay varaints that would favor TCP
> over AQM?

Please be aware that they are not competitors: the two can coexist in
the same network.  I would say that there is consensus that AQM is
necessary, and that delay-based congestion control is a nice thing to
have for low-priority traffic (e.g. uTP).  In other words, you cannot
do without AQM, but that certainly doesn't mean there aren't people
interested in deploying low-delay congestion control.

-- Juliusz