[R-C] LEDBAT - introductions?

[David Ros]

On 12 avr. 2012, at 00:41, Piers O'Hanlon wrote:

> 
> On 11 Apr 2012, at 21:02, Randell Jesup wrote:
> 
>> On 4/11/2012 10:18 AM, Piers O'Hanlon wrote:
>>> 
>>>>   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.
>> 
>> This shows a VoIP flow increased 35ms for a 25ms LEDBAT.  One assumes a 100ms LEDBAT would delay VoIP >100ms, and when you count other delays you're probably already over 150ms mouth->ear even on a good, local call.
> 
> Agreed 100ms is pretty tight. It seems that the focus on LEDBAT has been about testing with TCP, whilst it seems little work has been done with lower latency applications....

FWIW, the LEDBAT draft talks only (sec. 4.3) about "anecdotal evidence" about a target delay <= 100 ms (and the whole mechanism not harming VoIP flows?) "working well".

Also FWIW, I just checked very quickly the full list of papers on LEDBAT we went through when writing RFC 6297 -- in all, about a dozen documents (including the one you mentioned before) and it would seem that, save for the paper you mentioned, no one *actually* studied *explicitly* the interaction of LEDBAT with VoIP. The focus is either LEDBAT vs. TCP or LEDBAT vs. LEDBAT.

So yes, IMHO there is definitely more work to be done in this area.

Regards,

David.


> 
>> 
>>> 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)
>> 
>> This points out that rtcweb flows will probably not be automatically classified as realtime flows to be given priority; we should look into this and what they use as triggers, and how we can get them to rev their firmware (especially for future designs).
>> 
> In the box I have access to (which is pretty typical for the UK and maybe europe as it's made by Thomson/Technicolor) - it mostly has a bunch of port and DSCP based classifiers. I have seen boxes that have Signalling protocol sniffers in them for SIP/H323 and but I'm not sure about ICE (Which could be handy in RTCweb). These boxes are also mostly configured to be remotely configured and updated usually using the CPE WAN Management Protocol (CWMP)/TR-069.
> 
>>>>   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 article mentioned their implementation doesn't do pacing but implied it was allowed.
>> 
> 
>> 
>> -- 
>> Randell Jesup
>> randell-ietf at jesup.org
>> _______________________________________________
>> Rtp-congestion mailing list
>> Rtp-congestion at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> 
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> 

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

"It would seem that you have no useful skill or talent whatsoever," he said. "Have you thought of going into teaching?" -- Terry Pratchett