[R-C] LEDBAT vs RTCWeb

[Stefan Holmer]

On Tue, Apr 10, 2012 at 4:55 PM, Randell Jesup <randell-ietf at jesup.org>wrote:

> On 4/10/2012 10:40 AM, Stefan Holmer wrote:
>
>>
>>
>> On Tue, Apr 10, 2012 at 4:02 PM, Randell Jesup <randell-ietf at jesup.org
>> <mailto:randell-ietf at jesup.org**>> wrote:
>>    As do I.  Also, I *REALLY* worry about the interaction of LEDBAT
>>    flows and rtcweb flows...  If it targets 100ms queuing delay as the
>>    "I'm out of the way of TCP" level, that could seriously negatively
>>    impact us (and general VoIP as well, but even more so us, since
>>    we'll again get driven into the ground trying to keep the queues
>>    drained.  It may take longer, but LEDBAT flows tend to be
>>    close-to-infinite I would assume.
>>    If it targets 25ms, that's less problematic I suspect.
>>
>>    I'm not saying I know there will be a problem here, but that I fear
>>    there will be since LEDBAT has a non-0 queuing target - it may
>>    "poison the waters" for any delay-based algorithm that wants to
>>    target a lower number.
>>
>>
>> Yes, having two algorithms with different delay targets compete should
>> be approximately the same thing as having a delay-based algorithm
>> compete with a loss-based algorithm, although the effects seen may be
>> more or less bad depending on how close the targets are. To be clear,
>> our draft (draft-alvestrand-rtcweb-**congestion) has a 0 delay target,
>> which means that it will always let the queues drain before increasing
>> the rate.
>>
>
> 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).
Sooner or later I think we will reach a steady state with 100 ms delay, and
that point RRTCC will act as normal. 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.


>
>
>
>
> --
> 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/20120412/ba86d69e/attachment-0001.html>