[R-C] LEDBAT vs RTCWeb

[Stefan Holmer]

On Wed, Apr 11, 2012 at 8:56 AM, Randell Jesup <randell-ietf at jesup.org>wrote:

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

Correct, noisy variations in delay are suppressed. And there's also an
outlier filter with the purpose of not reacting to a few packets being
delayed.


>
> 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
>
> ______________________________**_________________
> 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/20120411/ea0c7917/attachment-0001.html>