Re: [iccrg] LEDBAT++, rLEDBAT, and slowdowns

[Neal Cardwell <[e-mail]>]

On Tue, Sep 3, 2019 at 5:05 AM marcelo bagnulo braun <[e-mail]> wrote:
>
> Hi Neal,
>
> Thanks for the comments and sorry for the delay in replying, I was away.
>
> Reading RFC6817, the goals of LEDBAT are:
>
> " LEDBAT congestion control seeks to achieve the following goals:
>
>     1.  to utilize end-to-end available bandwidth and to maintain low
>         queueing delay when no other traffic is present,
>
>     2.  to add limited queuing delay to that induced by concurrent flows,
>         and
>
>     3.  to yield quickly to standard TCP flows that share the same
>         bottleneck link."
>
> So, as i read this, when other traffic is present, the goal of LEDBAT is
> expressed in the additional queueing delay added by the LEDBAT flow and
> NOT in terms of the absolute queueing delay in the bottleneck. (I think
> this differs form other efforts targetting of limiting the absolute
> queueing delay.
>
>  From this perspective, simply slowing down the flow, would allow
> LEDBAT++ to measure the base delay in its absence and comply with the
> goal of limited additional delay.

I guess what I'm trying to get at is that:

(1) AFAICT the LEDBAT++ and rLEDBAT algorithms so far do not seem to
provide a bound on "the additional queueing delay added by the LEDBAT
flow", in the case where there are several  LEDBAT++/rLEDBAT flows and
the fair share of in-flight data is less than the queue depth.
Instead, the group dynamics would be such that the queue would
gradually but steadily ratchet up until the buffer is full. This does
not seem to meet the goals expressed in RFC6817 ("limiting the
consequent increase in queueing delay on that path...avoiding
interference with the network performance of competing flows") or the
LEDBAT++/rLEDBAT drafts.

(2) With minor tweaks to coordinate slowdowns, the LEDBAT++/rLEDBAT
algorithms could be tweaked to avoid this problem in common multi-flow
scenarios.

best,
neal