[aqm] review of fq-codel draft

[Wesley Eddy <[e-mail]>]

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