Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt

["Fred Baker (fred)" <[e-mail]>]

On Mar 13, 2013, at 1:25 PM, Mikael Abrahamsson <[e-mail]>
 wrote:

> On Wed, 13 Mar 2013, Fred Baker (fred) wrote:
> 
>> Folks. I posted the email I sent yesterday as a draft, for discussion. I welcome comments, and if substantive comments are made, suggested text.
> 
> I voiced my opinion on the tsv-area meeting via jabber that AQM especially on low/medium bw links (up to 10-20 megabits/s) is needed and bufferbloat is a serious problem. As an employee of an operator, I would like to see documents in the line of RFC6204, ie basic requirements, for (in this case) AQM that I can use in procurement documents. Preferrably these would be implemented by kernel vendors (linux kernel and others) so the actual device vendor only needs to turn it on and perhaps set a few parameters (like communicate the link speed to the queue handler).

> Coming back to the document at hand, reading draft-baker-tsvwg-aqm-recommendation-00.txt, I notice a few things. Am I misinterpreting text such as:
> 
> "Hence, network communication to the host regarding the moderation of
>   its traffic flow SHOULD include both ECN and loss, with ECN being
>   triggered earlier than loss."
> 
> ... that it recommendeds that ECN traffic will be marked before non-ECN traffic is dropped? I believe desired behaviour is that ECN traffic is marked and non-ECN traffic is dropped at the exact same queue depth (or whatever mechanism causes packets to be dropped/marked).

Hmm. I probably didn't word that all that well.

My point is that at some level of congestion stress, we should mark ECN-capable traffic and drop non-ECN-capable traffic. At some higher level of stress, we should drop from all streams, ECN-capable or not. In general, I'd like to believe that ECN is effective in managing end-to-end throughput.

> Also, the documents seem to handle both host stack implementations and device queue management. Am I correct? Perhaps it would be preferable to have one document handling queueing (including the queue on the host towards its network interface (wifi/fixed/cellular etc), and another document talking about "TCP congestion control mechanisms"? Or this the document at hand trying to be an umbrella document for other documents?

One could argue for the separation. To my mind, though, they are firmly linked. Besides self-defense, the reason the network marks/drops traffic is to signal to TCP/SCTP. if that's the case, it seems like it's useful to say what that signal means to TCP/SCTP, and how we hope it might work.

> Anyhow, I feel this (AQM/congestion) area of discussion is extremely important and it solves a real life problem that impacts a lot of people on the Internet as it works today. Personally I have routers with quite advanced AQM on my home connection (100/100 megabit/s) because I feel that FIFO even with WRED isn't good enough. However I understand that "fair-queue" uses a lot of CPU at these speeds, so it might not be feasable to do too advanced stuff at those speeds. However, at ADSL type accesses, for the uplink interface there is definitely a huge upside to have AQM.

That depends on how FQ is implemented. The implementation I did in 1994 probably would have been high overhead. It has been minted by others, and I believe rewritten to be a calendar queue implementation. For that, I would not expect it was that much higher. I'll go take a look, though.

> When evaluating AQM the test scenarios should be quite advanced (I liked what I heard in ICCRG meeting yesterday) including VoIP, hundreds of TCP sessions using bittorrent, gaming (could be over TCP) etc. The ideal solution would be something that automatically allow at least per-user fairness in the upstream and something that perhaps sent ACKs and other smaller packets ahead of the queue of larger data packets.
> 
> -- 
> Mikael Abrahamsson    email: [e-mail]