[R-C] [ledbat] LEDBAT vs RTCWeb

[Stefan Holmer]

On Fri, Apr 20, 2012 at 3:13 PM, Jim Gettys <jg at freedesktop.org> 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.
>
> 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.
>

Agreed, it's indeed important to have a mechanism using signals from the
AQM in parallel to the delay sensitive one.


>                         - Jim
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120420/fef66f81/attachment.html>