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@jesup.org