Re: [ledbat] [R-C] LEDBAT vs RTCWeb

[Randell Jesup <[e-mail]>]

On 4/13/2012 3:03 AM, Stefan Holmer wrote:
>
>
> On Thu, Apr 12, 2012 at 10:52 PM, Randell Jesup <[e-mail]
> <mailto:[e-mail]>> 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.)

-- 
Randell Jesup
[e-mail]