[R-C] LEDBAT vs RTCWeb

[Wesley Eddy]

On 4/10/2012 2:58 PM, Randell Jesup wrote:
>>
>> 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.
> 
> Yeah... Not pretty.  Any delay-based algorithm should target
> minimal/zero queue lengths to ensure fairness, otherwise it's an evil
> game/race where whomever cares least about delay gets all the bandwidth.


The target is a balancing act, and a heuristic.

Aiming for overly small queue lengths (or zero) is poor due to
delay variability of lower layers (e.g. WLAN or cellular) as
well as measurement error.  These are not specific to LEDBAT
and will be problematic for other delay-based proposals, such
as the Google one we have discussed somewhat.


>>> 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.
> 
> Also not good.  We should actively discourage it, IMHO, until this is
> resolved.


I'm not sure who the "we" is above.  Have you tried sharing a link
with BitTorrent traffic before and after the clients implemented
LEDBAT?  You might decide to actively encourage it; VoIP is totally
unusable in the "before" configuration and quite usable "after",
with uTP.


> 100ms is just bad, bad, bad for VoIP on the same links.  The only case
> where I'd say it's ok is where it knows it's competing with significant
> TCP flows.  If it reverted to 0 queuing delay or close when the channel
> is not saturated by TCP, then we might be ok (not sure).  But I don't
> think it does that.


My experience suggests otherwise.  100ms is quite a bit better than
the alternative of multiple seconds.  You can easily use Skype with
modern BitTorrent clients running.  Zero queueing delay is an
unreasonable target since it can't be accurately measured versus
variations caused by wireless MAC, OS, and other factors.  Since
Windows OS over WLAN is probably one of the main ways that people
run either BitTorrent or will run RTCWEB, these variations in
delay need to be understood.


-- 
Wes Eddy
MTI Systems