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

[Arjuna Sathiaseelan <[e-mail]>]

Hi Mirja - I am wondering how the mechanism discussed in the following
paper could be useful to predict the network state and then ledbat or
even TCP choosing its aggressiveness based on the state..

End-to-End Transmission Control by Modeling Uncertainty about the Network State
http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf

cc-ed to the authors too..

Arjuna

On 20 April 2012 12:55, Mirja Kuehlewind
<[e-mail]> 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.
>
> 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.
>
> 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 <[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.)
>
>
>
> --
> -------------------------------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Institute of Communication Networks and Computer Engineering (IKR)
> University of Stuttgart, Germany
> Pfaffenwaldring 47, D-70569 Stuttgart
>
> tel: [phone]
> email: [e-mail]
> web: www.ikr.uni-stuttgart.de
> -------------------------------------------------------------------
> _______________________________________________
> ledbat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ledbat



--
http://about.me/arjuna.sathiaseelan