[R-C] LEDBAT vs RTCWeb

[Randell Jesup]

On 4/12/2012 4:05 AM, Stefan Holmer wrote:

>     Right - which means someone should raise this issue about LEDBAT
>     ASAP. Which WG is handling it?
>
>
> Gave this some more thought, and the problem might not be as big as I
> first anticipated.
>
> When an receive-side inter-arrival time-based congestion control
> algorithm such as RRTCC (will refer
> to draft-alvestrand-rtcweb-__congestion as Receive-side Real-Time
> Congestion Control, RRTCC for now. Other suggestions are welcome)
> compete with LEDBAT we will see a situation where the the LEDBAT flow
> builds up queues of 100 ms. RRTCC will observe increased inter-arrival
> time and react back off (although, it will probably not back off too
> far).

Agreed, RRTCC will back off, though probably not dramatically (depending 
on how aggressive the slow-start/etc of LEDBAT is).

> Sooner or later I think we will reach a steady state with 100 ms
> delay, and that point RRTCC will act as normal.

Hmm, not sure I agree here.  Both LEDBAT and RRTCC will probe for more 
bandwidth, and both will see the results of the other's probes.  When 
either increases bandwidth use enough to cause a delay queue rise, one 
or both will react; and there's a question of which is more likely to 
react, how fast, and how will re-stabilization occur.

I significantly doubt this is a stable situation; one side or the other 
will likely drop earlier, drop faster or stabilize and start probing 
again slower.  You can even see aspects of this with LEDBAT competing 
with itself if the target depths are close.  Since RRTCC and LEDBAT have 
different algorithms and time constants (I assume), it's likely that it 
will be unstable in a consistent direction, and one will "win".  Also 
they'll act differently in response to minor disruptions from other traffic.

If RRTCC tries to (most of the time) stay slightly below the point where 
delay queues increase, this backoff will be a small amount of 'clear' 
bandwidth that will cause queue draining and cause LEDBAT to increase 
usage.  Again leading to instability (and likely LEDBAT monopolizing).

It's *possible* that RRTCC will 'win', it's also definitely possible 
that they'll end up semi-stable where neither goes too far away from a 
'fair' share.  The one thing I don't predict is stable, fair and 
predictable sharing of the bandwidth.  :-/

> If the LEDBAT flow
> stops, RRTCC will see decreasing inter-arrival time for some time and
> let the queue flush before trying to grab the newly available bandwidth.

Right; I don't expect any problems there.


-- 
Randell Jesup
randell-ietf at jesup.org