[R-C] [ledbat] LEDBAT vs RTCWeb

[Jim Gettys]

On 04/20/2012 08:41 AM, Piers O'Hanlon wrote:
> On 20 Apr 2012, at 13:32, Michael Welzl wrote:
>
>> On Apr 20, 2012, at 2:23 PM, Jim Gettys wrote:
>>
>>> On 04/20/2012 07:55 AM, Mirja Kuehlewind wrote:
>>>> Hi Randell,
>>>>
>>>> I didn't follow the whole discussion but regarding LEDBAT we have a TARGET
>>>> delay of max. 100ms. That means you can choose a smaller one. We've chosen
>>>> 100ms as a max as there is an ITU recommendation that 150 ms delay is
>>>> acceptable for most user voice applications and we wanted for sure stay below
>>>> that.
>>> 100 ms + 75ms speed of light delay across the US (or equivalent across
>>> Europe, for example) + 100ms at the receiving end....
>>>
>>> Of course, it's even worse between continents, even without broken networks.
>>>
>>> Not so nice....
>> 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.
>>
> 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.
>

Sorry, I wasn't really clear enough.  It may be that LEDBAT will stop
adding at 100ms; my point is that even with "traditional" drop-tail
queues sized at the "traditional" 100ms level, you have to think about
the fact there are two ends.  Either/both may be filled, and filled by
even a single TCP connection.  So the total delays are as I lay out: you
can trivially get to 300ms without trying hard under some circumstances,
twice the ITU max recommendation for telephony, and about 10x human
perception time for other applications.

And the variable bandwidth case makes this all much worse (both
Powerboost or equivalent in the broadband connections, and tremendously
more so in wireless.  Fixed size, unmanaged, drop tail queues have *got*
to go.

To "fix" this disaster, we have to make the edge "smarter", probably
with a combination of some sort of "fair" queueing/diffserv *and* AQM. 
This is that tack that some of us are taking in Dave Taht's CeroWrt home
router work. Once we've done that, delay sensitive AQM's stop being
effective, since the delays drop to relative zero.

So people need to think about how delay sensitive algorithms such as
LEDBAT compete with other traffic in the absence of delays that trigger
them.  Because any fix removes the very delay that they use to try to
get out of the way.
                        - Jim