[R-C] LEDBAT vs RTCWeb

[Piers O'Hanlon]

On 10 Apr 2012, at 15:55, Randell Jesup 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?
> 
LEDBAT WG ;)

Though for the moment it's not clear how many flows are using LEDBAT - It's been mentioned that a few bittorrent clients are using it but I'm not clear on numbers - also some of them seem to implement a 'variant' called uTP, which I'm guessing isn't going to err on the side of lower throughput and delay....

I noticed that LEDBAT now ships as an available congestion control for TCP on OSX Lion for 'background' flows though again it's unclear how many apps actually use it.

It seems that the 100ms is an agreed maximum delay bound which seems to have been adopted after an earlier 25ms proposal. As mentioned in the draft it is a question of balancing their throughput concerns with achieving suitable a accommodation with TCP flows.

The 100ms is a default for the OSX implementation, whilst the (telecom-paristech.fr) Linux one has the earlier 25ms target.

Piers.


> 
> 
> -- 
> Randell Jesup
> randell-ietf at jesup.org
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion