I reviewed the fq-codel draft and have some comments: https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/
Overall, it's a clear document that someone could definitely write code from without much difficulty, and I hope we can quickly finish it in this working group. I do have a few comments below that I think would improve it though. In section 1, the 2nd-to-last paragraph, I had some confusion on the sentence: "Exactly how much data a flow has to send to keep its queue in this state ..." By my understanding, it would be a matter of how _little_, not "how much" data the flow has to send to remain in that state of never having a queue that persists between rounds of the scheduler. In section 3, something big is missing here in terms of explaining the intention to have N queues such that flows mostly uniquely hash to their own queue. It would also be worth explaining here what the impact will be of things like tunnels and people doing things like using multiple DSCP values within the same 5-tuple (like in the TSVWG RTCWEB QoS draft). If everything in a tunnel and everything on a 5-tuple (regardless of DSCP) hash into the same flow/queue, then it should be clearly noted. (I know there's brief mention later in the document about DiffServ, but IMO it's a big enough architectural issue that it should be well-understood by the reader and clear up front in the document) In section 5.1, it could/should be stressed more strongly that configuration of a custom filter for classification has a huge impact on how the system performs, and in this light, it seems to me like the "standard filter" should be more strongly recommended, and custom rules noted as not really encouraged for people that won't actively be measuring and possibly updating them. The decapsulation capability described in 5.1 seems like something that can't generically be assumed in an implementation because there are N different encapsulations and more on the way. I think the paragraph mentioning this should stress that it's a feature of one implementation, that others could mimic, that it does impact performance, and that it isn't a panacea for all flavors of tunnel, especially ones that use encryption. Section 7.3 should probably reference the LEDBAT RFC directly. I believe from notes scattered throughout the document that it would be helpful to have a "Further Research" section near the end of the document to collect and summarize the productive future work that the authors would suggest. For instance, the things that I can see would be: - alternate FQ mechanisms like QFQ - variations of the classification algorithm - measured interactions with delay-based CC (e.g. LEDBAT) - sensitivity of parameters (interval, # of queues, etc) - including other fields in the hash (i.e. "entropy fields") in order to deal with tunnels more elegantly (e.g. the way that flow label or other things are being used for ECMP). -- Wes Eddy MTI Systems _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
