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

"Fred Baker (fred)" <fred@cisco.com> Wed, 11 March 2015 19:03 UTC

Return-Path: <fred@cisco.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53C1A0149 for <aqm@ietfa.amsl.com>; Wed, 11 Mar 2015 12:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.801
X-Spam-Level:
X-Spam-Status: No, score=-106.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkLvU0hNVg2Z for <aqm@ietfa.amsl.com>; Wed, 11 Mar 2015 12:03:12 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1C51A0242 for <aqm@ietf.org>; Wed, 11 Mar 2015 12:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=390123; q=dns/txt; s=iport; t=1426100591; x=1427310191; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZaqN2PzyxlywuNaniLJODuJCwJauUJ6RlyaxF5pcg5Y=; b=Jm6zbgz+FCNmqa0fBSHvRpDPsqVskhwkGf4s5xsYmxeo/1ZPzmWD4Es+ UU2jRTxJyW717RSWOng/MToqV7FtVj5Ll/5m0QI6Zk2GbR1Xyzc0o2o6w fW7KBviroTW8voLjOUKoymzVTAVFLbzpZJdgMFRCEMd3zcYK/HQAH52wm 8=;
X-Files: Diff: draft-ietf-aqm-fq-implementation.txt - draft-ietf-aqm-fq-implementation-01.txt.pdf, draft-ietf-aqm-fq-implementation-01.txt, draft-ietf-aqm-fq-implementation-01.xml, signature.asc : 226048, 35375, 37367, 487
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CeBADVkABV/5pdJa3QbgICAQ
X-IronPort-AV: E=Sophos;i="5.11,383,1422921600"; d="asc'?xml'217?txt'217?scan'217,208,217";a="402812894"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 11 Mar 2015 19:03:10 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2BJ3ASJ017951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 19:03:10 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 11 Mar 2015 14:03:10 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Wesley Eddy <wes@mti-systems.com>
Thread-Topic: [aqm] review of draft-ietf-aqm-fq-implementation
Thread-Index: AQHQXC4DI6uYHrC61E69UsZFBmMDfw==
Date: Wed, 11 Mar 2015 19:03:09 +0000
Message-ID: <5D19C9D1-564C-4578-AA63-AF83930BB87D@cisco.com>
References: <54FFA90D.8080802@mti-systems.com>
In-Reply-To: <54FFA90D.8080802@mti-systems.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.24.134.133]
Content-Type: multipart/signed; boundary="Apple-Mail=_9DB82EA6-E1E9-4265-AEA1-8CCA2DDC010A"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/OJqdj1fb40zM_KCdJjM5g8FdK9c>
Cc: "Rong Pan \(ropan\)" <ropan@cisco.com>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [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 19:03:14 -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 <wes@mti-systems.com> 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
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm