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