[R-C] LEDBAT - introductions?

[Randell Jesup]

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.

> 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).

>>     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