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: [email protected]
