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

Wesley Eddy <wes@mti-systems.com> Wed, 11 March 2015 02:31 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 785E61A8967 for <aqm@ietfa.amsl.com>; Tue, 10 Mar 2015 19:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id loZMxmOyEIi1 for <aqm@ietfa.amsl.com>; Tue, 10 Mar 2015 19:31:51 -0700 (PDT)
Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com []) by ietfa.amsl.com (Postfix) with ESMTP id 609061A88A4 for <aqm@ietf.org>; Tue, 10 Mar 2015 19:31:51 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t2B2VmXZ025609 for <aqm@ietf.org>; Tue, 10 Mar 2015 22:31:48 -0400
Received: (qmail 6146 invoked by uid 0); 11 Mar 2015 02:31:48 -0000
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ? (wes@mti-systems.com@ by 0 with ESMTPA; 11 Mar 2015 02:31:48 -0000
Message-ID: <54FFA90D.8080802@mti-systems.com>
Date: Tue, 10 Mar 2015 22:31:41 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "aqm@ietf.org" <aqm@ietf.org>, Fred Baker <fred@cisco.com>, "Rong Pan (ropan)" <ropan@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/snnsZ-ZZ0UXN9sUBmryTeD1Siyc>
Subject: [aqm] review of draft-ietf-aqm-fq-implementation
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2015 02:31:53 -0000

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

- 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:

- 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."

- 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