[R-C] LEDBAT - introductions?

[Piers O'Hanlon]

On 11 Apr 2012, at 13:11, Saverio Mascolo wrote:

> is someone trying rate-based control?
> 
Google's proposal is essentially rate based.

> On Wed, Apr 11, 2012 at 1:39 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker at ericsson.com> wrote:
> 
> 
> On 2012-04-05 13:53, Michael Welzl wrote:
> 
> 
> I don't think anybody advocated using LEDBAT as it is here. But
> personally, I would favor "adjusting" LEDBAT by e.g. adding the "TCP
> equation as a lower limit" trick (which I think is neat!) and tuning
> its parameters over having a from-scratch design of a new delay-based
> mechanism. LEDBAT has already undergone some investigation, and so
> we'd have a more stable basis.
> I am sure LEDBAT CC algorithm has gone through strict examination and serves its purpose but as pointed out by others (Jim) those were not related to real-time interactive media.
> 
As far as I understand avoiding upset of Voip flows was explicitly something LEDBAT aimed at - it is mentioned both in the Charter and specifically in section 4.3 of the LEDBAT draft - it aims to keep below the ITU's G.114 recommendation of 150ms. There are some studies done here - where LEDBAT does allow voip flows to operate - referenced in the draft (but there is more work to be done in this area):
[Sch10]    Schneider, J., Wagner, J., Winter, R., and H. Kolbe, "Out
              of my Way -- Evaluating Low Extra Delay Background
              Transport in an ADSL Access Network", Proceedings of  22nd
              International Teletraffic Congress (ITC22), September
              2010.
Though this paper brings up an additional active component which hasn't really surfaced much in these discussions - the 'Advanced Home Gateway' which typically provides for AQM (which could answer some of Jim's prayers ;) - often in the form of WFQ with multiple classes (which is the case the UK where a substantial number of home gateways are now shipped 'for free' with ADSL and come preconfigured with WFQ). Though these have a curious effect on LEDBAT flows and can serve to increase the priority of the LEDBAT flows and thus increasing their impact somewhat (though this effect is down to actual HGW classification of LEDBAT flows). I'm curious if any large providers have any stats on the deployment of these boxes and their experience of impact on differing traffic types....?



> LEDBAT CC algorithm is window based (Congestion window) that is one extra queue at the sender side. I think Magnus Westerlund has already pointed out the possible issues with this kind of design in another mail.
> 
The fact that it is window based doesn't preclude Magnus' suggestions - it is a question of whether the algorithm allows for low latency operation and potentially coping with bursts. If it can only clock out packets on ACKs then it may be problem but there are paced versions of window based algorithms that may suit.

> The path of fine tuning of LEDBAT may not be as smooth as one think.
> 
Yes it may be tricky - if LEDBAT wants an algorithm that can be dropped into TCP implementations.

Piers

> BR
> 
> -- 
> Zahed
> 
> ============================================
> ANM ZAHEDUZZAMAN SARKER
> 
> 
> Ericsson AB
> Multimedia Technologies (MMT)
> Ericsson Research
> P.O. Box 920, SE-971 28, Luleå, Sweden
> Phone +46 10 717 37 43
> Fax +46 920 996 21
> SMS/MMS +46 76 115 37 43
> zaheduzzaman.sarker at ericsson.com
> www.ericsson.com
> ============================================
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> 
> 
> 
> -- 
> Prof. Saverio Mascolo
> Dipartimento di Elettrotecnica ed Elettronica
> Politecnico di Bari
> Via Orabona 4, 70125 Bari Italy
> Tel. +39 080 5963621
> Fax. +39 080 5963410
> email:mascolo at poliba.it
>  
> http://c3lab.poliba.it
> 
> 
> =================================
>  This message may contain confidential and/or legally privileged information.
>   If you are not the intended recipient of the message, please destroy it.
>  Any unauthorized dissemination, distribution, or copying of the material in
>  this message, and any attachments to the message, is strictly forbidden.
> _______________________________________________
> 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/20120411/c6a97fda/attachment.html>