[R-C] LEDBAT vs RTCWeb

[Randell Jesup]

On 4/10/2012 10:35 PM, Wesley Eddy wrote:
> 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.

Agreed, though Google's algorithm does not directly target 0 queuing 
delay; it only indirectly targets it. Since it doesn't attempt to 
measure actual queue depth, and merely focuses staying below (in 
bandwidth use) the point where delay appears to rise, it can stabilize 
at higher queuing depths.  If LEDBAT's estimates are reasonably accurate 
it may make sense to incorporate that into the algorithm in some manner.

How the algorithms will interact is very hard to predict right now.  In 
theory, an algorithm tolerant of a larger delay *should* end up 
collecting most of all of the bandwidth, but that assumes similar 
methods of probing for delay.

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

I've found a lot of people have gotten used to tolerating much more 
delay from their VoIP client than I'd ever find comfortable; I still use 
landlines a lot because people on Skype and other VoIP softclients often 
talk over each other.  I cringe when I see engineers blithely 
interviewing candidates over Skype or a VoIP softclient with a clear 
one-way mouth-to-ear delay over 200 or 300ms - it's an uncomfortable 
experience encouraging people to "hold the floor" and/or awkward 
pauses/talkover.

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

Well sure, in the same way that punched in the nose is better than shot 
through the head.  :-)

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

Agreed.  I assume the LEDBAT WG did VoIP tests?  Did they measure MOS? 
(not that it's a great measure, but it's well-known and understood). 
Any links to results?


-- 
Randell Jesup
randell-ietf at jesup.org