[R-C] [ledbat] LEDBAT vs RTCWeb

[Jim Gettys]

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

We *have* to fix the edge.  Drop tail queues of 100ms or bigger have got
to go....

> If you choose a delay-based congestion control I don't think your problem is 
> LEDBAT but standard loss-based TCP that will frequently fill up the queue 
> completely. 

Yup.  All it takes is one.

And once you eliminate the delays with AQM in the edge of the net, then
delay based controls immediately go back to competing.
                                - Jim


>
> Maybe you don't want to look at the total queuing delay but at the changes in 
> queuing delay...? LEDBAT will keep the delay constant.
>
> Mirja
>
>
> On Friday 13 April 2012 11:17:31 Randell Jesup wrote:
>> On 4/13/2012 3:03 AM, Stefan Holmer wrote:
>>> On Thu, Apr 12, 2012 at 10:52 PM, Randell Jesup <randell-ietf at jesup.org
>>> <mailto:randell-ietf at jesup.org>> wrote:
>>>
>>>     It's *possible* that RRTCC will 'win', it's also definitely possible
>>>     that they'll end up semi-stable where neither goes too far away from
>>>     a 'fair' share.  The one thing I don't predict is stable, fair and
>>>     predictable sharing of the bandwidth.  :-/
>>>
>>>
>>> I agree. Because of different averaging and trigger thresholds they will
>>> likely not end up in a stable state. It for sure seems unlikely that
>>> they will happen to fairly share the bandwidth.
>> The real problem here is that LEDBAT is designated a "scavenger"
>> protocol that should get out of the way of primary uses (which includes
>> rtcweb traffic).  While it's possible that will be the result
>> experimentally, I tend to doubt it and it's certainly unclear without
>> experiments - and I also doubt a fair sharing will occur.  So my guess
>> (which should be checked!) is that LEDBAT and RRTCC are not compatible
>> on the same bottleneck links.  This means that manual intervention will
>> be needed to enable RRTCC traffic to be usable; either stopping or
>> bandwidth-limiting any LEDBAT flows.
>>
>> In theory if the OS was controlling the LEDBAT flows it could be asked
>> by an RRTCC (userspace) application to have them get out of the way
>> (which probably means halt or virtually so during RRTCC operation) or to
>> in some manner use send() traffic as a flag to do so.  An example might
>> be applications using LEDBAT in OSX for 'background' download/update
>> that may not have external controls that a user could use to suspend
>> transfers during a call.  I'm not holding my breath on this one; and it
>> wouldn't help if there's another endpoint behind the same bottleneck
>> using LEDBAT.
>>
>> The last recourse is the advanced modem/router with classification
>> (again, not something we can do anything about).  However, as Jim Gettys
>> will tell you, this may not help you as much if another link is the
>> bottleneck, such as a wifi router behind the modem or primary router.
>>
>> I think we're going to find that LEDBAT has failed in (what should be) a
>> primary goal, which is to avoid hurting "foreground" traffic, largely
>> because they appear to have only considered TCP flows (from review of
>> their mailing list and specs).  Regular inflexible VoIP traffic is
>> likely badly hurt by the current spec (since 100+ms of extra delay will
>> push typical VoIP traffic well into the "bad" part of the MOS slope),
>> and delay-sensing foreground protocols like RRTCC are probably blown out
>> of the water.
>>
>> If LEDBAT actually is to be a 'scavenger' protocol, it must have some
>> mechanism other than purely queue depth to allow foreground protocols to
>> push it out of the way.  It's possible it could stick to queue depth but
>> use very small values, and/or use slower time constants than
>> "foreground" delay-sensing algorithms to guarantee they 'win' when
>> competing with it.
>>
>> Cross-posting to the LEDBAT list in the hopes that I'm wrong.  (For
>> reference, RRTCC is a delay-sensing CC algorithm for RTP traffic,
>> recently discussed at IETF83 in the ICCRG and planned for use in rtcweb
>> clients.  RRTCC is a brand-new moniker for the algorithm in Harald
>> Alvestrand's draft, but similar algorithms have been in use (but not
>> standardized) since at least 2004, long predating LEDBAT/uTP.)
>
>