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 <mirja.kuehlewind@ikr.uni-stuttgart.de> 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 <randell-ietf@jesup.org <mailto:randell-ietf@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.)
-- ------------------------------------------------------------------- Dipl.-Ing. Mirja Kühlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de ------------------------------------------------------------------- _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat