On Wed, Apr 11, 2012 at 8:56 AM, Randell Jesup
<randell-ietf@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.
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@jesup.org