On Fri, Jul 3, 2015 at 2:52 AM, Fred Baker <[email protected]> wrote: > >> On Jul 3, 2015, at 2:45 AM, Polina Goltsman <[email protected]> wrote: >> >> As I understand the FQ-Codel draft, it seems to be fundamental to FQ-Codel >> that each queue has separate state variables. >> So my question is: is it indeed fundamental ? > > If you're asking whether it is fundamental to fair queuing, I'll recommend > you start researching that question with RFC 970 and the articles in SIGCOMM > and INFOCOMM on the topic circa 1988-1995 or so. Also take a look at > Class-based Queing (aka CBQ) in the same timeframe. I think you'll find that > FQ systems are not approached as collections of queues with different > characteristics; they are collections of queues with essentially the same set > of characteristics, using scheduling to make the queues share bandwidth in a > manner similar to the Generalized Processor Sharing model. On the other hand, > CBQ systems are systems with separate queues or classes for different sets of > traffic, with different characteristics such as drop policy or target latency.
I do not think how FQ-codel works is fundamental to FQ, rather, it is an innovation that seems to work well in practice, with extremely low overhead, leaving (mostly) untouched, request-response traffic like dns, and other low rate traffic, but while getting large bursts under control *rapidly*, yet allowing short flows through, with no further configuration. So it is a set of queues with different characteristics - which is why we ended up calling it "Flow queueing", not fair queuing. AQMs (like pie) traditionally rely on applying increasing amounts of random drops/marks to a stream of packets, hoping to eventually pick out the fattest flows and shoot at them, and yet modern traffic is A) assymmetric, and B) bidirectional, and C) bursty, with large bursts coming from various forms off TSO/GSO/GRO offloads, IW10 (and now quic IW10+22 paced packets), and things like web browsers opening up many connections simultaneously. Any form of FQ reduces the impact of C) enormously. So much so that I regard FQ as the biggest part of the answer to achieving reliably low latency for all forms of traffic. No AQM deals particularly well with B - if you have 20 acks vs 1 full size MTU packet filling up the queue, it can take a lot longer for the AQM to find an ideal drop rate - which is not, actually, ideal. Toke did a preso on this on B and C. As for A) - I am seeing a 12x1 ratio of down to up in my current cable modem services, and this makes acks actually far more important and painful than they ever have been before. It does not take a lot of fat uplink traffic to start starving the downlink. Wifi and LTE are also often painfully assymmetric. FQ does impose some structure - per packet fairness has problems in some scenarios, byte fairness at the MTU size does not shoot at enough acks, the compromise in deployed fq_codel systems at lower bandwidths is a DRR quantum of 300 bytes. Cake uses peeling (to deal with up to 64k byte "packets" common now in consumer and server hardware), an 8 way set associative hash (much more flow isolation) and has a variable quantum (presently), based on the number of extant flows, and has some thoughts about the ideal BDP in the AQM, as the number of flows goes up, and is smarter about quite a few things, and perhaps dumber about others. http://www.bufferbloat.net/projects/codel/wiki/Cake I think FQ-pie is a good idea (aside from worrying about it over-prioritizing millions of small flows). I lean still towards stochastic methods (as in cake and fq_codel) along the edge. As for the core, or where you have a lot of cpus on the ingress side, damned if I know. As for wifi/wireless, we still have tons of work left to do there. On my benchmarks fq-pie, fq_codel, and cake all win pretty big. I think cake is now more or less "better" than sqm-scripts was, and handles more edge cases. > When we built the differentiated services model, we modeled a FQ subsystem as > if it were a single queue in a larger CBQ system, We might, for example, have > a FQ system for an AF class, but give EF priority over the entire FQ > subsystem. What we did with sqm-scripts (and other deployed fq_codel based systems, like free.fr's) was to have 3 tiers of relative fq_codel queues for priority, best effort, and background. That seems to work pretty well. There is not a lot of effective use of classification in my sample sets. Cake is experimenting with various means of layering diffserv on top of that, presently with a default of 4 fq_codel-ish queues, We are collecting a great deal more stats on queue behavior and actual loads in cake, now, example here: http://pastebin.com/bX1HmDP6 Couple notes on that url: Class 0 is just a name (background traffic goes here), class 1 is CS0, classes 2 and 3 are higher prio than 1. We need a better name than "class" as CS0 is actually in class 1.... " Sent 65725311796 bytes 52559409 pkt (dropped 11935, overlimits 0 requeues 449329) " requeues are when the FQ system kicks in, which is about 44 times more often than the AQM in this case. as for drops vs marks - every machine on this campus that I have got my hands on (which is only a few percent) has ecn enabled. Obviously, that is not enough... ... There are also weighted FQ systems (like qfq+ + pie or codel) under development. (Actually you can prototype qfq+ codel/pie/red/whatever today - we used QFQ + red/codel HEAVILY while evaluating various means to make a hybrid fq+aqm system more lightweight, doing up "sfqred" first, before codel arrived. A hope is to simplify QFQ+ and see how it does, one day. > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
