[R-C] [ledbat] LEDBAT vs RTCWeb

[Jim Gettys]

On 04/20/2012 09:13 AM, Jim Gettys wrote:
> 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.
I meant to day delay sensitive congestion control algorithms, of course...
                - Jim

>
> 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
>