<br><br><div class="gmail_quote">On Fri, Apr 20, 2012 at 3:13 PM, Jim Gettys <span dir="ltr"><<a href="mailto:jg@freedesktop.org">jg@freedesktop.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 04/20/2012 08:41 AM, Piers O'Hanlon wrote:<br>
> On 20 Apr 2012, at 13:32, Michael Welzl wrote:<br>
><br>
>> On Apr 20, 2012, at 2:23 PM, Jim Gettys wrote:<br>
>><br>
>>> On 04/20/2012 07:55 AM, Mirja Kuehlewind wrote:<br>
>>>> Hi Randell,<br>
>>>><br>
>>>> I didn't follow the whole discussion but regarding LEDBAT we have a TARGET<br>
>>>> delay of max. 100ms. That means you can choose a smaller one. We've chosen<br>
>>>> 100ms as a max as there is an ITU recommendation that 150 ms delay is<br>
>>>> acceptable for most user voice applications and we wanted for sure stay below<br>
>>>> that.<br>
>>> 100 ms + 75ms speed of light delay across the US (or equivalent across<br>
>>> Europe, for example) + 100ms at the receiving end....<br>
>>><br>
>>> Of course, it's even worse between continents, even without broken networks.<br>
>>><br>
>>> Not so nice....<br>
>> Not argueing about your point here (I agree that we have to fix the edge), but: LEDBAT is an end-to-end mechanism, so I think that the 100ms reflect the total measured end-to-end delay.<br>
>><br>
> I think LEDBAT's target is the relative delay (i.e. from queues) - It's not clear how it would measure the total end-to-end delay.<br>
><br>
<br>
</div>Sorry, I wasn't really clear enough.  It may be that LEDBAT will stop<br>
adding at 100ms; my point is that even with "traditional" drop-tail<br>
queues sized at the "traditional" 100ms level, you have to think about<br>
the fact there are two ends.  Either/both may be filled, and filled by<br>
even a single TCP connection.  So the total delays are as I lay out: you<br>
can trivially get to 300ms without trying hard under some circumstances,<br>
twice the ITU max recommendation for telephony, and about 10x human<br>
perception time for other applications.<br>
<br>
And the variable bandwidth case makes this all much worse (both<br>
Powerboost or equivalent in the broadband connections, and tremendously<br>
more so in wireless.  Fixed size, unmanaged, drop tail queues have *got*<br>
to go.<br>
<br>
To "fix" this disaster, we have to make the edge "smarter", probably<br>
with a combination of some sort of "fair" queueing/diffserv *and* AQM.<br>
This is that tack that some of us are taking in Dave Taht's CeroWrt home<br>
router work. Once we've done that, delay sensitive AQM's stop being<br>
effective, since the delays drop to relative zero.<br>
<br>
So people need to think about how delay sensitive algorithms such as<br>
LEDBAT compete with other traffic in the absence of delays that trigger<br>
them.  Because any fix removes the very delay that they use to try to<br>
get out of the way.<br></blockquote><div><br></div><div>Agreed, it's indeed important to have a mechanism using signals from the AQM in parallel to the delay sensitive one.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888">                        - Jim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a><br>
</div></div></blockquote></div><br>