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
------------------------------------------