Subject: [aqm] review of draft-ietf-aqm-fq-implementation

From: Wesley Eddy <[email-masked]>
Date: Tue, 10 Mar 2015 22:31:41 -0400

I reviewed the working group document "On Queueing, Marking,
and Dropping" in preparation for the next meeting.

It's due to expire just as the IETF meeting starts.  Folks
haven't been beating it up much in the working group, and yet
we (chairs) know it's been looked at because a critical mass
of people supported it in the past and said it was useful.

So, either it's nearly perfect (and done), or people just
haven't had the bandwidth to send reviews recently.

I personally think it's fairly complete, and could be last-
called ... here are my comments, none of which are major
technical issues, just attempts at clarification or
strengthening.

Comments:
- It will probably be a good idea in the introduction to say
  that in the document, many alternatives are discussed, and
  that this is all just informational to describe what can be
  done and many things that are "reasonable", but the goal isn't
  to flat out say that certain things are right or wrong.  For
  instance section 2.2.3 has discussion of multiple possible
  valid lines of reasoning in how a calendar queue's details look.

- I think most of the discussion is relevant to the IP layer,
  and not really as clearly addressing queues at other layers.
  That's probably fine, but worth being explicit about, maybe
  in the introduction.

- In section 2.1.2, it seems worthwhile to cite Bob Briscoe's
  CCR paper or other publications on flow-rate fairness:
  http://dl.acm.org/citation.cfm?id=1232926

- In section 2.1.3, it seems like it would be worthwhile to
  cite RFC 7141, which has tons of discussion about measuring
  things in bytes versus packets

- In 2.2.1, I'm not clear on the need or purpose behind
  mentioning the methods for creating and destroying queues in
  the list of properties of a queueing algorithm.  It doesn't
  seem to be discussed much (if at all), and IMHO, may not
  really be needed ... More importantly, it might be reasonable
  to mention a management interface to configure the queue (set
  max depth, etc).  These might be "manageable" and not just
  "inspectable" as currently described.

- section 3 covers tail-drop, CoDel, and PIE mark/drop; would
  it make sense to have a brief subsection on RED mark/drop,
  as this is a large "deployed base"?

- I think we can end section 4 (conclusions) more strongly.
  Instead of the current paragraph at the end, saying the
  authors don't think people should mix things up, I think
  we should say something more like:
  "There is value in implementing and coupling the operation
   of both queueing algorithms and queue management algorithms,
   and there is definitely interesting research in this area,
   but specifications, measurements, and comparisons should
   decouple the different algorithms and their contributions to
   system behavior."

Not-so-important-comments:
- section 2.1 has "he duration" instead of "the duration"

- mentioning the arrival rate of TCP acknowledgements at
  the end of section 2.1.1 is probably not necessary, and
  not quite pedantically correct (e.g. if ABC is in use,
  for instance) ... I would just not mention this here.

- I suggest "ring of sub-queues" rather than "ring of queues"
  in section 2.2.2.  It should be explicit that sub-queues
  can be managed in any way themselves e.g. with AQMs (and
  even have further sub-sub-queues nested).

- some references are out of data (e.g. codel draft), but
  the authors probably know this

-- 
Wes Eddy
MTI Systems

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Mar 2015 19:03:09 +0000

OK. I think I did it all. See attached. If you’re OK with it, I’ll post when the repository opens.

What I did with RED - it was actually mentioned and covered in the section that describes integration with PIE. I added “RED or” to the section title, and inserted a bibliographic reference to RFC 2309.

> On Mar 10, 2015, at 7:31 PM, Wesley Eddy <[email-masked]> wrote:
> 
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm