Re: [aqm] Please review: Benefits and Pitfalls of using ECN

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 17 March 2015 18:45 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 93BF41A886C for <aqm@ietfa.amsl.com>; Tue, 17 Mar 2015 11:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z8FpizVaSL6g for <aqm@ietfa.amsl.com>; Tue, 17 Mar 2015 11:45:52 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 8359C1A888A for <aqm@ietf.org>; Tue, 17 Mar 2015 11:45:31 -0700 (PDT)
Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:21f:5bff:fe38:7354]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 85F8B1B004B1 for <aqm@ietf.org>; Tue, 17 Mar 2015 18:45:51 +0000 (GMT)
Message-ID: <55087645.1080900@erg.abdn.ac.uk>
Date: Tue, 17 Mar 2015 18:45:25 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: aqm@ietf.org
References: <1c346467d632ba10979d78c93d6a71ee.squirrel@erg.abdn.ac.uk> <5508442A.6060503@mti-systems.com>
In-Reply-To: <5508442A.6060503@mti-systems.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/TfuC8Kvs6wcujaK2SF94P1SkV2U>
Subject: Re: [aqm] Please review: Benefits and Pitfalls of using ECN
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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: Tue, 17 Mar 2015 18:45:54 -0000

On 17/03/2015 15:11, Wesley Eddy wrote:
> On 3/11/2015 4:10 PM, gorry@erg.abdn.ac.uk wrote:
>>
>> Alas, due to a slight technical mistake by me, we missed the ID deadline.
>> So I have posted an interim version here:
>>
>> http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.txt
>> http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.xml
>>
>
>
> I've reviewed this copy and have some comments, one larger and
> the rest smaller.
>
> Large comment:
>
> I (personally) really do not like using the word "pitfall" in this
> document, given that we want people to use ECN, and not scare them
> about this list of pitfalls that await them the day they start using
> it.
>
> We could call these "operational difficulties that have been
> encountered" or "challenges due to misbehaving network devices and
> endpoints".
>
> I worry about someone that doesn't have time to carefully read and
> consider all the benefits and whether they outweigh the "pitfalls",
> and may not fully grok that the pitfalls have known mitigations and
> will hopefully go away over time.
>
> We *should* be more clear that there are mitigations and that plenty of
> nodes are able to use ECN happily today because it is implemented in
> the major OSes and network devices.
>
See below.

> For instance, there is no mention of things like ECN blackhole
> detection, and measurements of this, such as:
> http://conferences.sigcomm.org/imc/2011/docs/p171.pdf
>
OK - Happy to cite this.

> We *definitely* need to stress that bleaching, lying, and cheating
> behaviors are non-conformant, in some cases may be from legacy code,
> and should be expected to go away over time rather than proliferate,
> because these behaviors will cause problems for the growing critical
> mass of conforming nodes.
>
Agree, we can emphasise this.

> So, in summary, I would really suggest that we go through the document
> searching for every instance of "pitfall" and try to be more gentle,
> and even change the title just to "The Benefits of Using Explicit
> Congestion Notification (ECN)".  There is way more text in the document
> about benefits than pitfalls anyways, and I think we could consider the
> section discussing pitfalls as just fairly presenting possible
> challenges to successfully using ECN.
>
> That's just my opinion ... I'd be curious what others think.
>
Personally, I'd be really happy to do rework this language.

I would also like to revert the title (to just say "benefits", as in the 
original Individual ID submission), I believe we changed the title in 
response to comments from the group, but this was at a time when we had 
not describe some of the realities of deploying ECN. I'd like to think 
these have been addressed, and revert to the original title.

Note: If any people prefer to keep the "pitfall" word, then send an 
email asap - and give me some advice, otherwise I'll likely follow the 
edits suggested above.

>
> Small comments:
> - In section 1, paragraph 3, I suggest changing the text:
>    "where the exact combination of AQM/ECN algorithms is generally
>     not known by the transport endpoints."
>    to:
>    "where the exact combination of AQM/ECN algorithms does not need
>     to be known by the transport endpoints."
>
Agree.

>    Since the document is for people that might not be familiar with
>    this, it seems worth rewording so they don't think it's somehow
>    bad or suboptimal that the endpoints don't know if AQM or ECN is
>    supported within the network.
>
> - section 1, paragraph 4, I suggest changing:
>    "that would otherwise have been dropped"
>    to:
>    "that would otherwise have been dropped if the application or
>     transport did not support ECN"
>
Agree.

>    I think this kind of wording will emphasize that they need to
>    make sure they're enabling it at the endpoint.
>
> - section 2, paragraph 3 should be changed:
>    "Applications that experience congestion in such endpoints"
>    to:
>    "Applications that experience congestion in such network devices"
>
Oh dear, yes will fix -- or we could just say "experience congestion"?

>
> Even smaller comments:
> - section 1, paragraph 2, "forward" -> "forwards"
> - section 1, paragraph 2, "this packet" -> "packets"
> - section 1, paragraph 3,
>    "The focus of this document is on usage of ECN"
>    to:
>    "The focus of this document is on usage of ECN by transport and
>     application flows"
> - section 2, paragraph 2, I think the ECN RFC (3168) could also be cited
>    in addition to 2309bis for the recommended behavior for network
>    devices
>
I'll also fix these in the draft before we upload.

Gorry