Controlled Delay Active Queue Management
RFC 8289

Note: This ballot was opened for revision 07 and is now closed.

(Alia Atlas) Yes

Comment (2017-04-12 for -07)
No email
send info
Thank you for a clear and very well written document.  This was well worth staying up
past 1am to read fully.  I do have one primary comment and a couple minor points.

First, the document status is Experimental.   While encouraging experimentation, the
document doesn't really articulate what the concerns are or how experimentation might
determine that this should be changed to standards track.  While regrettably I haven't
personally followed the AQM work, I might assume that some of the issues to general
applicability might be tied to aspects around the challenges of applying CoDel to a 
system architecture built around WRED AQM and enqueue complexity rather than dequeue
complexity.  Having a paragraph that gave context in the introduction for the questions
still to be explored would be helpful.

a) In Sec 3.4 :  "This property of CoDel has been exploited in
   fq_codel [FQ-CODEL-ID], which hashes on the packet header fields to
   determine a specific bin, or sub-queue, for each five-tuple flow,"
  For the general case of traffic, it would be better to focus on using a microflow's
  entropy information  - whether that is derived from a 5-tuple, the IPv6 flow label, 
  an MPLS Entropy label, etc.  Tying this specifically to the 5-tuple is not ideal.
  Obviously I missed this for draft-ietf-aqm-fq-codel-06 - but even a slight rephrasing
to "for each microflow, identifiable via five-tuple hash, src/dest + IPv6 flow label, or
other entropy information" would encourage better understanding of micro-flow identification.
Of course, this is just a comment - so do with it what you will.

b) (Nit) In Sec 5.1: " We use this insight in the pseudo-code for CoDel later in the draft."
  The pseudo-code is actually earlier in the draft.  Also s/draft/document for publication.

Alissa Cooper Yes

Comment (2017-04-11 for -07)
No email
send info
Glad to see this document progress.

From Fernando's Gen-ART review:

* Page 17:
  simulation that this result holds for Reno, Cubic, and
  Westwood[TSV84].

Missing space.

(Spencer Dawkins) Yes

Comment (2017-04-13 for -07)
No email
send info
I'm a strong Yes on this document, but encourage the authors to work through comments about readability from other ADs.

Warren Kumari Yes

Comment (2017-04-07 for -07)
No email
send info
I think that this is a useful document - I also think that it would make a good introductory document to describe queuing for e.g a collage class. 

I do have some readability suggestions to make it even better; these do not need any action, but if the authors happen to edit the document for any other reason, they may want to address them.

1: I found the overall structure of the document a little odd -- I'm assuming that this is an artifact of its history, or merging multiple documents into one, or similar. It starts off with a nice description of queuing and CoDel. It then gets all technical with the pseudo-code (which was really helpful). Where it feels a little odd is that it then suddenly goes back to being much more introductory feeling (Section 5 - ), and feels like it repeats some of the earlier material. Reformatting it all to address this seems like overkill, but perhaps a readers note to suggest people who want more background should skip ahead then come back.

2: Section 1.  Introduction
- "determined set point derived from maximizing the network power metric" -- I'd suggest referencing Section 5.2 where power is explained (or, if we assume readers understand this, section 5.2 can be dropped).

3: Section 3.  Overview of the Codel AQM
Sojourn time is a really important concept in this document, but it isn't really defined - Section 5.1 is closest to defining it, but still not great.

4: Section 3.1
"The MTU size can be set adaptively to the largest packet seen so far or can be read from the driver."
It was unclear what driver -- perhaps "interface driver" or simply "interface"?

5: Section 3.2 has an opening parens but no closing one ("known or measure (though ...").
This is a tiny nit, but set off my OCD tendencies :-)

6: Section 5.1
"We use this insight in the  pseudo-code for CoDel later in the draft.)
 - earlier in the draft...

Section 5.2: 
AIMD TCP could use a reference.

Mirja Kühlewind Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2017-04-12 for -07)
No email
send info
Same view as Warren point 1. I just wondered: why this section 5 as that position?
1: I found the overall structure of the document a little odd -- I'm assuming that this is an artifact of its history, or merging multiple documents into one, or similar. It starts off with a nice description of queuing and CoDel. It then gets all technical with the pseudo-code (which was really helpful). Where it feels a little odd is that it then suddenly goes back to being much more introductory feeling (Section 5 - ), and feels like it repeats some of the earlier material. Reformatting it all to address this seems like overkill, but perhaps a readers note to suggest people who want more background should skip ahead then come back.

Suresh Krishnan No Objection

(Kathleen Moriarty) No Objection

Comment (2017-04-13 for -07)
No email
send info
Thanks for your work on this draft.  I have one question, it seems that problems with CoDel could lead to DoS attacks.  I understand that the goal here is reducing buffer bloat, so I would expect to see some discussion in the security considerations section that mentions improved availability from the Confidential, Integrity, Availability security principle discussed along with possible DoS considerations.  Please correct me if I'm wrong, otherwise it would be helpful to see some text added.

(Eric Rescorla) No Objection

Comment (2017-04-07 for -07)
No email
send info
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).

Alvaro Retana No Objection