[R-C] LEDBAT vs RTCWeb

Wesley Eddy wes at mti-systems.com
Wed Apr 11 20:38:36 CEST 2012


On 4/11/2012 2:56 AM, Randell Jesup wrote:
> 
> 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.
>


Yes, the other relevant aspect is the "latecomer advantage" that's
been discussed in LEDBAT.  Basically, if there's already a standing
queue when your flow starts, you may not have a good chance of
measuring the "base delay" without a queue.  So even if your target
delays from base delay are equal, if the base delays aren't, there
can be problems.


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


Agreed!


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


To my knowledge, there hasn't been specific test results like
this presented to the working group.  The working group is
actually planning to close "real soon now", as the specification
is on the way to the IESG and the rest of the discussion has
really died off.

Such tests would be interesting and useful (maybe even necessary)
in thinking about progressing from Experimental to Standards
Track, in my opinion.

Since this will be part of the deployed base that RTCWEB is
sharing links with, it will be good to think about in terms
of how we evaluate candidate RTCWEB mechanisms/algorithms.

-- 
Wes Eddy
MTI Systems


More information about the Rtp-congestion mailing list