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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 18 March 2015 13:43 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 CC8D21A0095 for <aqm@ietfa.amsl.com>; Wed, 18 Mar 2015 06:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 aqOVZZv5a8FM for <aqm@ietfa.amsl.com>; Wed, 18 Mar 2015 06:43:45 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7741A01A8 for <aqm@ietf.org>; Wed, 18 Mar 2015 06:43:45 -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 7EFE11B00505; Wed, 18 Mar 2015 13:44:04 +0000 (GMT)
Message-ID: <5509810B.8080808@erg.abdn.ac.uk>
Date: Wed, 18 Mar 2015 13:43:39 +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: Greg Skinner <gregskinner0@icloud.com>
References: <8b6f280a-57b8-4dae-8c16-416846d615be@me.com>
In-Reply-To: <8b6f280a-57b8-4dae-8c16-416846d615be@me.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/irV4HaT5T0t1PRn844rmC2B5O_M>
Cc: aqm@ietf.org
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: Wed, 18 Mar 2015 13:43:52 -0000

Thanks for getting back with comments.

On 18/03/2015 00:38, Greg Skinner wrote:
> I noticed that the RFC 2119 boilerplate text (Key words for use in RFCs
> to Indicate Requirement Levels such as "MUST") is missing.  IMO, several
> issues in Section 6 (and possibly Section 7) should have the
> uncapitalized text replaced with the requirement levels.  (For example,
> the beginning of the last paragraph of Section 6.1 would start with "A
> network device MUST NOT change a packet with a CE mark to a zero
> codepoint ...")
>
That's actually a question for our WG Chairs. The original idea was this 
that this draft simply restated or clarified recommendations already 
made. There could be some cases where this is no longer the case - and 
some where we have yet to cite the appropriate reference.

> Removing "pitfalls" in the title, and replacing its use in the draft
> with "operational difficulties", or words to that effect, seems
> reasonable to me.
>
Thanks, this is something I think we can propose to the WG at the Dallas 
meeting. Thoughts from others welcome.

Gorry

> Greg
>
> On Mar 17, 2015, at 11:46 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>
>> On 17/03/2015 15:11, Wesley Eddy wrote:
>>> On 3/11/2015 4:10 PM, gorry@erg.abdn.ac.uk
>>> <mailto: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
>>
>> _______________________________________________
>> aqm mailing list
>> aqm@ietf.org <mailto:aqm@ietf.org>
>> https://www.ietf.org/mailman/listinfo/aqm
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>