[R-C] LEDBAT vs RTCWeb

[Stefan Holmer]

On Thu, Apr 12, 2012 at 10:52 PM, Randell Jesup <randell-ietf at jesup.org>wrote:

> 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.  :-/


I agree. Because of different averaging and trigger thresholds they will
likely not end up in a stable state. It for sure seems unlikely that they
will happen to fairly share 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
> ______________________________**_________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120413/e774f89a/attachment.html>