[aqm] Eric Rescorla's No Objection on draft-ietf-aqm-codel-07: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-aqm-codel-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The normative part of this document seems reasonably clear and I
believe I could implement it. Note: I have not attempted to assess the
technical quality of the algorithm described in this protocol.

I found the descriptive part a little hard to follow in places.
Specifically:

- It's a little hard to work out which things are informal terms
  and which are defined terms of art.
  
  "power" is used first on page 4 but it's only clear that
  it's a term of art in S 16. This could be fixed by a
  forward reference and a cite to Kleinrock.

  "target" and "interval" are constants in the algorithm,
  but this wasn't entirely clear to me in S 3.2. You could
  deal with this by stating in S 3 that the algorithm
  takes in two variables (TARGET and INTERVAL). Perhaps
  capitalize them. I see you also use "setpoint" and
  "target" and "target setpoint". I would stick to one
  if you can.

- It seems that the document went through some reordering
  because S 5.1. refers to the pseudo-code as coming later
  in the draft. Perhaps some of the rationale could come
  before the pseudo-code. Specifically, the intuition that
  the dropping happens only when you are able to send
  packets (dequeue) is kind of counter-intuitive.

- Following up on the above point, you must be able to
  drop packets when the queue is entirely full, but S
  4.4 doesn't seem to contemplate this. What is the impact
  of this? You just drop and ignore?

Finally, you seem a bit inconsistent about whether you are
capitalizing 2119 terms (see for instance the use of should
vs. SHOULD in the second graf of S 3.2).