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
- Re: [aqm] Please review: Benefits and Pitfalls of… Wesley Eddy
- Re: [aqm] Please review: Benefits and Pitfalls of… Gorry Fairhurst
- Re: [aqm] Please review: Benefits and Pitfalls of… Greg Skinner
- Re: [aqm] Please review: Benefits and Pitfalls of… Mikael Abrahamsson
- Re: [aqm] Please review: Benefits and Pitfalls of… Gorry Fairhurst
- [aqm] Please review: Benefits and Pitfalls of usi… gorry