<br><br><div class="gmail_quote">On Wed, Apr 11, 2012 at 8:56 AM, Randell Jesup <span dir="ltr"><<a href="mailto:randell-ietf@jesup.org">randell-ietf@jesup.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 4/10/2012 10:35 PM, Wesley Eddy wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 4/10/2012 2:58 PM, Randell Jesup wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yes, having two algorithms with different delay targets compete should<br>
be approximately the same thing as having a delay-based algorithm<br>
compete with a loss-based algorithm, although the effects seen may be<br>
more or less bad depending on how close the targets are. To be clear,<br>
our draft (draft-alvestrand-rtcweb-<u></u>congestion) has a 0 delay target,<br>
which means that it will always let the queues drain before increasing<br>
the rate.<br>
</blockquote>
<br>
Yeah... Not pretty. Any delay-based algorithm should target<br>
minimal/zero queue lengths to ensure fairness, otherwise it's an evil<br>
game/race where whomever cares least about delay gets all the bandwidth.<br>
</blockquote>
<br>
<br>
The target is a balancing act, and a heuristic.<br>
<br>
Aiming for overly small queue lengths (or zero) is poor due to<br>
delay variability of lower layers (e.g. WLAN or cellular) as<br>
well as measurement error. These are not specific to LEDBAT<br>
and will be problematic for other delay-based proposals, such<br>
as the Google one we have discussed somewhat.<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right - which means someone should raise this issue about LEDBAT<br>
ASAP. Which WG is handling it?<br>
<br>
</blockquote>
LEDBAT WG ;)<br>
<br>
Though for the moment it's not clear how many flows are using LEDBAT -<br>
It's been mentioned that a few bittorrent clients are using it but I'm<br>
not clear on numbers - also some of them seem to implement a 'variant'<br>
called uTP, which I'm guessing isn't going to err on the side of lower<br>
throughput and delay....<br>
<br>
I noticed that LEDBAT now ships as an available congestion control for<br>
TCP on OSX Lion for 'background' flows though again it's unclear how<br>
many apps actually use it.<br>
</blockquote>
<br>
Also not good. We should actively discourage it, IMHO, until this is<br>
resolved.<br>
</blockquote>
<br>
<br>
I'm not sure who the "we" is above. Have you tried sharing a link<br>
with BitTorrent traffic before and after the clients implemented<br>
LEDBAT? You might decide to actively encourage it; VoIP is totally<br>
unusable in the "before" configuration and quite usable "after",<br>
with uTP.<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
100ms is just bad, bad, bad for VoIP on the same links. The only case<br>
where I'd say it's ok is where it knows it's competing with significant<br>
TCP flows. If it reverted to 0 queuing delay or close when the channel<br>
is not saturated by TCP, then we might be ok (not sure). But I don't<br>
think it does that.<br>
</blockquote>
<br>
<br>
My experience suggests otherwise. 100ms is quite a bit better than<br>
the alternative of multiple seconds.<br>
</blockquote>
<br></div>
Well sure, in the same way that punched in the nose is better than shot through the head. :-)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You can easily use Skype with<br>
modern BitTorrent clients running. Zero queueing delay is an<br>
unreasonable target since it can't be accurately measured versus<br>
variations caused by wireless MAC, OS, and other factors. Since<br>
Windows OS over WLAN is probably one of the main ways that people<br>
run either BitTorrent or will run RTCWEB, these variations in<br>
delay need to be understood.<br>
</blockquote>
<br></div>
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?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-- <br>
Randell Jesup<br>
<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a></font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no" target="_blank">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/<u></u>mailman/listinfo/rtp-<u></u>congestion</a><br>
</div></div></blockquote></div><br>