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

["Fred Baker (fred)" <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm