Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-recommendation-09: (with DISCUSS and COMMENT)

Benoit Claise <bclaise@cisco.com> Tue, 24 February 2015 10:04 UTC

Return-Path: <bclaise@cisco.com>
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 168231A6F34; Tue, 24 Feb 2015 02:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 xzkBvlPwuiuj; Tue, 24 Feb 2015 02:04:28 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C7E1A0379; Tue, 24 Feb 2015 02:04:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10947; q=dns/txt; s=iport; t=1424772268; x=1425981868; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7h/NEaZ5uOaEEMYs3MHh5MAzTFB7kPvLMGVFCBpc2Rg=; b=d8AhdvIiDclDPhEoAT6QUdFv4NYyRIIIt1L1K7BnM6mXKnl2oe66lp80 /936TPXWSEqo4F8Obgg5NBOTtRq/argAh0+F3Va2In1bNnLJ5w3ZKXyfq KDIplNlW2CYWOMtQ0chkCF8UqO4nTRZhzmAqWfJ0F+58x9QcSR0OaniKo g=;
X-IronPort-AV: E=Sophos;i="5.09,637,1418083200"; d="scan'208,217";a="354720204"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 24 Feb 2015 10:04:26 +0000
Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1OA4PnN005735; Tue, 24 Feb 2015 10:04:25 GMT
Message-ID: <54EC4CA9.8060600@cisco.com>
Date: Tue, 24 Feb 2015 11:04:25 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: gorry@erg.abdn.ac.uk
References: <20150218224325.29443.89305.idtracker@ietfa.amsl.com> <9e5393f59950a047bdcc4cc5dde50259.squirrel@erg.abdn.ac.uk>
In-Reply-To: <9e5393f59950a047bdcc4cc5dde50259.squirrel@erg.abdn.ac.uk>
Content-Type: multipart/alternative; boundary="------------020509080906010502040201"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/-CY5EmunTVTZ8ba3lKUH5lbdN1M>
Cc: rs@netapp.com, aqm-chairs@ietf.org, mehmet.ersue@nsn.com, The IESG <iesg@ietf.org>, me <bclaise@cisco.com>, draft-ietf-aqm-recommendation.all@ietf.org, aqm@ietf.org, fred@cisco.com
Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-recommendation-09: (with DISCUSS and COMMENT)
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: Tue, 24 Feb 2015 10:04:31 -0000

Hi Gorry,

Thanks for engaging.
> Benoit,
>
> We think we have resolved the remaining issues and would like to propose
> text that we think could address you DISCUSS:
>
> We think our point was that tuning should not be required
> *in*the*normal*case*, not
> that they should *never* require tuning (I'm not sure we have created
> anything that
> is 100% auto-tuning).
If it was a never, then the sentence would be

   3.  AQM algorithm deployment MUST NOT require tuning of initial or
configuration parameters.

> I'm OK with his phrasing in both cases, but would
> suggest the
> words "in common use cases" should be added:
>
>    3.  AQM algorithm deployment SHOULD NOT require tuning of initial or
> configuration
I believe that the "in common use case" is redundant (and somehow 
confusing) with the SHOULD in your proposal.
SHOULD (RFC 2119):

    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
        may exist valid reasons in particular circumstances to ignore a
        particular item, but the full implications must be understood and
        carefully weighed before choosing a different course.

However, I don't want to be picky on that point. I'll let your 
responsible AD decide.
My main point is covered. I'll clear that DISCUSS point.

> parameters in common use cases.
>
> 4.3 AQM algorithm deployment SHOULD NOT require tuning in common use cases.
I don't see this change in the v10.
There is an important word in here "deployment" as opposed to "deployed" 
in the current 4.3 section title (4.3. AQM algorithms deployed SHOULD 
NOT require operational tuning)
"Deployment" brings to the notion of initial deployment as opposed to 
"deployed".
This is the reason why I propose:

NEW:
4.3 AQM algorithm deployment SHOULD NOT require operational tuning

I hope you will include this change, but it's not DISCUSS-worth IMO.
Same remark as above regarding "AQM algorithm deployment"

Regards, Benoit
>
> Please let us know your thoughts,
>
> Fred & Gorry
>
>> Benoit Claise has entered the following ballot position for
>> draft-ietf-aqm-recommendation-09: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Hopefully an easy DISCUSS.
>>    3.  The algorithms that the IETF recommends SHOULD NOT require
>>         operational (especially manual) configuration or tuning.
>>
>> This sentence above could be understood in different ways. For example,
>> that any configuration is wrong.
>> The ability to activate AQM is a good thing IMO.
>> The section 4.3 title is closer to what you intend to say: "AQM
>> algorithms deployed SHOULD NOT require operational tuning"
>> The issue is that you only define what you mean by "operational
>> configuration" in section 4.3
>>
>> Proposal:
>>
>> OLD:
>>    3.  The algorithms that the IETF recommends SHOULD NOT require
>>         operational (especially manual) configuration or tuning.
>>
>> NEW:
>>    3.  AQM algorithm deployment SHOULD NOT require tuning of initial or
>> configuration parameters.
>>
>> OLD:
>> 4.3 AQM algorithms deployed SHOULD NOT require operational tuning
>>
>> NEW:
>> 4.3 AQM algorithm deployment SHOULD NOT require tuning
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> - RFC 2309 introduced the concept of "Active Queue Management" (AQM), a
>>     > class of technologies that, by signaling to common congestion-
>>     controlled transports such as TCP, manages the size of queues that
>>
>> Remove >
>>
>>
>> -
>>    Network devices SHOULD use an AQM algorithm to measure local local
>>     congestion
>>
>> local local
>>
>>
>> _______________________________________________
>> aqm mailing list
>> aqm@ietf.org
>> https://www.ietf.org/mailman/listinfo/aqm
>>
>
> .
>