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

Gorry Fairhurst <> Tue, 17 March 2015 18:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 93BF41A886C for <>; Tue, 17 Mar 2015 11:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z8FpizVaSL6g for <>; Tue, 17 Mar 2015 11:45:52 -0700 (PDT)
Received: from ( [IPv6:2001:630:241:204::f0f0]) by (Postfix) with ESMTP id 8359C1A888A for <>; Tue, 17 Mar 2015 11:45:31 -0700 (PDT)
Received: from (unknown [IPv6:2001:630:241:207:21f:5bff:fe38:7354]) by (Postfix) with ESMTPSA id 85F8B1B004B1 for <>; Tue, 17 Mar 2015 18:45:51 +0000 (GMT)
Message-ID: <>
Date: Tue, 17 Mar 2015 18:45:25 +0000
From: Gorry Fairhurst <>
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
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [aqm] Please review: Benefits and Pitfalls of using ECN
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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, wrote:
>> Alas, due to a slight technical mistake by me, we missed the ID deadline.
>> So I have posted an interim version here:
> 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:
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."

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

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