Re: [aqm] Benoit Claise's No Objection on draft-ietf-aqm-ecn-benefits-06: (with COMMENT)
gorry@erg.abdn.ac.uk Tue, 20 October 2015 16:02 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 E50871B3503; Tue, 20 Oct 2015 09:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8vHMyv3zRc86; Tue, 20 Oct 2015 09:02:03 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D3A191B34EC; Tue, 20 Oct 2015 09:01:58 -0700 (PDT)
Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id CE9BE1B00225; Tue, 20 Oct 2015 17:09:05 +0100 (BST)
Received: from 148.122.45.160 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Tue, 20 Oct 2015 17:01:57 +0100
Message-ID: <a8f3716c461f4c66025c0dcc2afa0de8.squirrel@erg.abdn.ac.uk>
In-Reply-To: <20151020145733.17027.9514.idtracker@ietfa.amsl.com>
References: <20151020145733.17027.9514.idtracker@ietfa.amsl.com>
Date: Tue, 20 Oct 2015 17:01:57 +0100
From: gorry@erg.abdn.ac.uk
To: Benoit Claise <bclaise@cisco.com>
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/4i43PW1mM7IjvhAdQcknNTe0Zv4>
Cc: rs@netapp.com, aqm-chairs@ietf.org, dromasca@avaya.com, The IESG <iesg@ietf.org>, draft-ietf-aqm-ecn-benefits@ietf.org, aqm@ietf.org
Subject: Re: [aqm] Benoit Claise's No Objection on draft-ietf-aqm-ecn-benefits-06: (with COMMENT)
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 20 Oct 2015 16:02:08 -0000
Thanks for the feedback. Gorry > Benoit Claise has entered the following ballot position for > draft-ietf-aqm-ecn-benefits-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - The discard of packets serves > as a signal to the end-to-end transport that there may be congestion > on the network path being used. > > Why not? > The discard of packets serves > as a signal to the end-to-end transport that there is congestion > on the network path being used. > Because a loss can also be due to other reasons than congestion, it would help to explain this. I will add. > > - Section 3.5. Bleaching and Middlebox Requirements to deploy ECN > > Sligthly confused by ECT(0) is different the zero codepoint > > When ECN-capable IP packets, marked as ECT(0) or ECT(1), are remarked > to non-ECN-capable (i.e., the ECN field is set to zero codepoint), > OK, We'll add - probably need to explain the numerical value for non-ECT, etc. > ... > > A network device must not change a packet with a CE mark to a zero > codepoint, if the network device decides not to forward the packet > with the CE-mark, > > I had to look up https://tools.ietf.org/html/rfc3168 > > +-----+-----+ > | ECN FIELD | > +-----+-----+ > ECT CE [Obsolete] RFC 2481 names for the ECN bits. > 0 0 Not-ECT > 0 1 ECT(1) > 1 0 ECT(0) > 1 1 CE > > If you had one or two sentences to introduce the codepoints, that would > avoid the confusion and would ease the readability. > > And below is Dan Romascanu's OPS DIR review: > The following three comments are editorial in nature, triggered by > difficulties in understanding some of the information (otherwise clearly > presented): > > > > 1. It would be useful to break the definition of âECN-capableâ > in > two separate definitions for âECN-capable packetâ and âECN-capable > network deviceâ. It also would be good to copy or refer the definition > of > ECN codepoint from RFC 3168. > Understood, will update. > 2. Section 2.5 uses both CE-marking and ECN-marking terms. They are > meant to be synonymous, so chosing one of them would make the text more > clear > All should be "CE-marked", will change. > 3. Sections 4.3 and 5 uses the following phrase about endpoints â > âit can ⦠conservatively react to congestionâ. Please explain what > this means. > I'll discuss with my co-author on how to add more text here. Gorry