[aqm] OPS-DIR review of draft-ietf-aqm-ecn-benefits-06

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 12 October 2015 14:02 UTC

Return-Path: <dromasca@avaya.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 8D05D1B326F; Mon, 12 Oct 2015 07:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zn3y60llTkmC; Mon, 12 Oct 2015 07:02:16 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651ED1B32A2; Mon, 12 Oct 2015 07:02:06 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,673,1437451200"; d="scan'208,217";a="140891275"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Oct 2015 10:02:04 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 12 Oct 2015 10:02:04 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([]) with mapi id 14.03.0174.001; Mon, 12 Oct 2015 16:02:02 +0200
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "ops-dir@ietf.org" <ops-dir@ietf.org>
Thread-Topic: OPS-DIR review of draft-ietf-aqm-ecn-benefits-06
Thread-Index: AdEE9o7O2K9OHkbYRl27JEHf3jawKQ==
Date: Mon, 12 Oct 2015 14:02:02 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB48C91@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CB48C91AZFFEXMB04globa_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/65BwdfVMVIro4g2yU6T3xoTpH1c>
Cc: "aqm@ietf.org" <aqm@ietf.org>, "draft-ietf-aqm-ecn-benefits.all@tools.ietf.org" <draft-ietf-aqm-ecn-benefits.all@tools.ietf.org>
Subject: [aqm] OPS-DIR review of draft-ietf-aqm-ecn-benefits-06
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: Mon, 12 Oct 2015 14:02:27 -0000


I have reviewed draft-ietf-aqm-ecn-benefits-06 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

I believe the document is 'Ready' for publication.

This document is a little bit more than its title says 'The Benefits of using Explicit Congestion Notification (ECN'. ECN was actually defined about 15 years ago, and this document describes its benefits but also provides valuable information as well as recommendations for implementation in network devices and hosts and for deployment in the Internet and in controlled environments. This document is informational, no new protocol is defined, so that an RFC 5706 review would not apply. However, the information in the document is interesting and important for operators.

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.

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

3.        Sections 4.3 and 5 uses the following phrase about endpoints - 'it can ... conservatively react to congestion'. Please explain what this means.