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
- [aqm] review of draft-ietf-aqm-fq-implementation Wesley Eddy
- Re: [aqm] review of draft-ietf-aqm-fq-implementat… Fred Baker (fred)