On Mar 13, 2013, at 1:25 PM, Mikael Abrahamsson <[email protected]> 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: [email protected]
