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

[Mikael Abrahamsson <[e-mail]>]

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

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?

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.

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]