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@jesup.org