Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits-04.txt
Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Wed, 10 June 2015 15:18 UTC
Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 2A4B31B2B8D for <aqm@ietfa.amsl.com>; Wed, 10 Jun 2015 08:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 EuSyOjlT27Yy for <aqm@ietfa.amsl.com>; Wed, 10 Jun 2015 08:18:55 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C341B2B7A for <aqm@ietf.org>; Wed, 10 Jun 2015 08:18:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 41E50D9315; Wed, 10 Jun 2015 17:18:53 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RRtNwu1vwi3Y; Wed, 10 Jun 2015 17:18:53 +0200 (MEST)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0BD26D9302; Wed, 10 Jun 2015 17:18:53 +0200 (MEST)
Message-ID: <5578555C.9040907@tik.ee.ethz.ch>
Date: Wed, 10 Jun 2015 17:18:52 +0200
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, aqm@ietf.org, Michael Welzl <michawe@ifi.uio.no>
References: <20150505184955.17501.42937.idtracker@ietfa.amsl.com>
In-Reply-To: <20150505184955.17501.42937.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/tPqcrU3in9tnpMXcq2b28r5l-rk>
Subject: Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits-04.txt
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, 10 Jun 2015 15:18:58 -0000
Hi Gorry, hi Michael, to catch up with this: I think most of my comments were addressed. Especially the restructuring and removing of all normative language is good. Thanks! The one point I'm still not super happy with is section 3.6 and 3.6.1. I don't think it reflects the problems and opportunities of using a different AQM and different congestion control for ECN accordingly. If I see this correctly, you didn't change the text very much and I think that the current text is just not fully correct. The main issue is that the text sounds like if you have accECN, you can just go ahead and implement a different congestion control. However, if you use something like DCTCP on the Internet, you'd be very aggressive and push away other traffic. Therefore we should be more careful what we say here. I'm not even sure if this should be discussed in the 'Benefits' section, but I do think it's important to mention in this doc. Maybe we can also ask Bob Briscoe what he think should be in this section because he has been very actively working on this recently. The other smaller point is that I'd like to see more explicitly mentioned somewhere that ECN does not always help with tail loss because often the queue simply is too short if a large burst is sent. (Therefore avoiding burst might still be useful). These are the two points I'd like to see better addressed from my review comments. However, based on the other comments on the list, I think there are more people who agree with me that this document sounds extremely positive and it should more explicitly also address potentially negative consequences. Those things are mentioned in the document but from my point of view are rather hidden as a reasoning for a recommendation. Therefore I would like to see some further restructuring of the document. This is not the same than the original 'pitfalls' section was like because that section actually also tried to give recommendation instead of just documenting things. However, that's nothing that is for me to decide; maybe we should discuss this again in the next meeting (because I think the mailing list discussion did not really led to a conclusion...?)...? Further, I have to say, I'm personally not super happy with sections 3-5. Even though the normative language was removed, it still tries to give recommendations instead of just summarizing what other docs hopefully already recommend. Further there seems to be still quite a bit of redundancy which, if removed, would probably improve readability. At the same time on other points the "recommendations" are still too high level to actually be really useful, from my point of view; e.g. see section 5 'Prerequisites for network endpoints...": This basically says (in 3 bullets) that the used transport must implement ECN to use ECN. That's rather obvious for me. However, it does not say more useful things like: it should still implement the ECN SYN fallback as specified in RFC3168 because this cases actually still happens and that e.g. Apple has a smaller RTO for SYNs with ECN which seems actual useful. Another things we've just discovered while implementing this fallback for Linux was that it is actually not clear which state TCP should be in if a second SYN without ECN was send but a SYNACK with ECN is received. I think those things would be interesting if recommendations are given. However, this might need additional expertise from different people that can bring in more experience in implementing ECN and therefore I'm not sure if this doc should give any recommendations. That's another point that might need to be discuss at the next meeting (or a separate discussion on this should be started at the mailing list). All in all, if there is/would be consensus to move the document forward as it is, I'm in principle also fine with that expect that I'd would still like to see a few changes in section 2.6/2.6.1. However, I personally think there is more discussion needed to what the scope and purpose of this document is. Mirja On 05.05.2015 20:49, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF. > > Title : The Benefits of using Explicit Congestion Notification (ECN) > Authors : Godred Fairhurst > Michael Welzl > Filename : draft-ietf-aqm-ecn-benefits-04.txt > Pages : 17 > Date : 2015-05-05 > > Abstract: > The goal of this document is to describe the potential benefits when > applications use a transport that enables Explicit Congestion > Notification (ECN). The document outlines the principal gains in > terms of increased throughput, reduced delay and other benefits when > ECN is used over network paths that include equipment that supports > ECN-marking. It also describes methods that can help successful > deployment of ECN. It does not propose new algorithms to use ECN, > nor does it describe the details of implementation of ECN in endpoint > devices (Internet hosts), routers or other network devices. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-aqm-ecn-benefits-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-ecn-benefits-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------
- [aqm] I-D Action: draft-ietf-aqm-ecn-benefits-04.… internet-drafts
- Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits… Mirja Kühlewind
- Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits… gorry
- Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits… Mirja Kühlewind
- Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits… gorry
- Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits… Wesley Eddy
- Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits… Dave Taht
- Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits… Mirja Kühlewind
- Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits… gorry