[iccrg] LEDBAT++, rLEDBAT, and slowdowns

[Neal Cardwell <[e-mail]>]

Thanks for today's presentations on LEDBAT++ and rLEDBAT. These are
nice work, and I agree they are important improvements on LEDBAT, and
worth pursuing as working group efforts, with a goal of standardizing
these algorithms in some form.

I had two related questions on slowdowns:

(1) Regarding LEDBAT++ and slowdowns:
https://tools.ietf.org/html/draft-balasubramanian-iccrg-ledbatplusplus-00#section-4.4
To try to avoid latency drift in the base delay, the LEDBAT++ design
describes periodic slowdowns that cut cwnd to 2 packets. As far as I'm
aware, the only way the flows would be able to refresh an accurate
notion of the base delay would be if there is at least one slowdown
during the base delay filter window in which the bottleneck queue is
essentially empty. But if a LEDBAT++ flow has a fair share of the BDP
that is less than the depth of the queue, then having that flow remove
all of its packets from the path, by itself, will not fully drain the
bottleneck queue (the packets from the remaining flows that are not in
slowdown will be enough to fill the pipe and create a non-zero queue,
obscuring the base delay).

So AFAICT uncoordinated slow-downs won't drain the queue; then the
only approach I can think of to achieve this would be for the flows to
coordinate in some fashion to all do a slowdown during overlapping
time intervals (as in BBR's PROBE_RTT mechanism). But AFAICT in the
design described in the draft, if there are many flows then I did not
see a mechanism described in the draft that would achieve this.

The IETF 100 LEDBAT++ slides show a multi-flow example, on page 14:
  https://datatracker.ietf.org/meeting/100/materials/slides-100-iccrg-ledbat-low-priority-tcp-congestion-control-in-windows-01
But that example has just two flows. And two flows is an easy case for
this kind of scheme: if there are two flows that are sharing a link
equally, then when one of them stops sending then this will almost
always drain the queue quite well.

Do you have test results you can share with more flows, showing how
the slowdown mechanism works for cases with more flows? Or is there a
way to add more text in the draft to explain how the slowdown design
in LEDBAT++ handles this issue already?

(2) The rLEDBAT draft:
https://tools.ietf.org/html/draft-bagnulo-iccrg-rledbat-00
mentions: "rLEDBAT estimates the Base RTT (i.e. the RTT when there is
no queuing delay) as the minimum observed RTT in the last n minutes."
However it doesn't seem to mention a slowdown mechanism to try to
refresh the estimate of the base RTT. Does it have such a mechanism?
AFAICT rLEDBAT, like LEDBAT++, would need a mechanism to do a
coordinated cut in cwnds, like BBR's PROBE_RTT mechanism, if multiple
rLEDBAT flows are to all maintain a good estimate of the base RTT of
the path. Any thoughts on that question?

Apologies if I'm missing something on either of these issues. :-)

And thank you both for presenting these respective algorithms. I think
both algorithms are important advances, and standardizing something
like each of them would be valuable for the community.

thanks,
neal