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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Wed, 08 June 2016 08:52 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29B12D534 for <aqm@ietfa.amsl.com>; Wed, 8 Jun 2016 01:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 zl22-OfowpKV for <aqm@ietfa.amsl.com>; Wed, 8 Jun 2016 01:52:47 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4929212D112 for <aqm@ietf.org>; Wed, 8 Jun 2016 01:52:47 -0700 (PDT)
Received: (qmail 3898 invoked from network); 8 Jun 2016 10:46:02 +0200
Received: from p5dec28a2.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.40.162) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Jun 2016 10:46:02 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <8D2CEA6F-BC90-4606-B737-1F5837178C1A@kuehlewind.net>
Date: Wed, 08 Jun 2016 10:46:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEC82FD2-9F80-465A-AA16-C13C4766B54C@kuehlewind.net>
References: <20160519093824.17314.65212.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D458D3D3108@NJFPSRVEXG0.research.att.com> <8D2CEA6F-BC90-4606-B737-1F5837178C1A@kuehlewind.net>
To: "MORTON, ALFRED C (AL)" <acmorton@att.com>, Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/5TiR8HmDfvdWvsOgmktDpdVkUXE>
Cc: "wes@mti-systems.com" <wes@mti-systems.com>, "aqm-chairs@ietf.org" <aqm-chairs@ietf.org>, "aqm@ietf.org" <aqm@ietf.org>, "draft-ietf-aqm-eval-guidelines@ietf.org" <draft-ietf-aqm-eval-guidelines@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-guidelines-11: (with DISCUSS and COMMENT)
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 08 Jun 2016 08:52:49 -0000

Hi Benoit,

I finally had another look at the document as well as at RFC6390. I guess the metrics in question are Flow completion time (sec 2.1.), Flow start up time (2.2.) and Packet loss synchronization (2.4.). And you are right that these metric could be see as Application-Specific Performance Metric as defined in RFC6390. However, I agree with Al that given the scope of this document is providing 
"a generic list of scenarios against which an
   AQM proposal should be evaluated, considering both potential
   performance gain and safety of deployment.“,
I don’t think these metric need to be defined and registered this way.

I guess as soon as we have a registry, maybe there is someone interest in IPPM to catch up these metrics again and provide a RFC6390 definition but I would rather not like this document doing it.

Is that acceptable for you?

We could add one more sentence in the abstract to make the scope on lab testing during development and before deployment clear. Would that help?

Mirja



> Am 25.05.2016 um 14:22 schrieb Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>:
> 
> Hi Al, Benoit, hi all,
> 
> thanks for the feedback. Sorry for me delaying this maybe a little but I need t have another look at the document which will be next week at this point. In general I agree that this does not need to only rely on registered metrics because is mostly for lab tests; further this might probably not the right doc to register new metrics. However, I would still like to have another look at the doc and see if we can improve anything or figure out if any of the ’new’/non-registed metrics should/could be taken up by e.g. ippm.
> 
> Mirja
> 
> 
> 
>> Am 20.05.2016 um 14:53 schrieb MORTON, ALFRED C (AL) <acmorton@att.com>:
>> 
>> All,
>> a few replies in-line below,
>> Al
>> 
>>> -----Original Message-----
>>> From: Benoit Claise [mailto:bclaise@cisco.com]
>>> Sent: Thursday, May 19, 2016 5:38 AM
>>> To: The IESG
>>> Cc: draft-ietf-aqm-eval-guidelines@ietf.org; wes@mti-systems.com; aqm-
>>> chairs@ietf.org; wes@mti-systems.com; aqm@ietf.org; linda Dunbar;
>>> MORTON, ALFRED C (AL)
>>> Subject: Benoit Claise's Discuss on draft-ietf-aqm-eval-guidelines-11:
>>> (with DISCUSS and COMMENT)
>>> 
>>> Benoit Claise has entered the following ballot position for
>>> draft-ietf-aqm-eval-guidelines-11: Discuss
>>> 
>> ...
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> Has a RFC6390 performance directorate review done for the 2.X metrics?
>>> It
>>> should.
>> [ACM] 
>> I reviewed this draft about 18 months ago.
>> Mostly, it points to existing RFCs for fundamental metrics,
>> and discusses others.  I read this:
>>  ...This document provides characterization guidelines that
>>  can be used to assess the deployability of an AQM, whether it is
>>  candidate for standardization at IETF or not.
>> as restricted to lab testing.
>> 
>>> See http://www.ietf.org/iesg/directorate/performance-metrics.html
>>> I guess that the metrics will be recorded in the future (See
>>> draft-ietf-ippm-metric-registry-06
>>> ), right?
>> [ACM] 
>> That's up to the authors, they might simply point to 
>> metrics in the registry contributed by others 
>> (when following these guidelines at a future time).
>> 
>>> For example, Flow Completion Time and Packet Loss Synchronization are
>>> new, I believe.
>> [ACM] 
>> Flow Completion Time is close to a definition for a new metric,
>> and could benefit from more attention, perhaps a few more details.
>> RFC6390 will provide some areas for improvement.
>> 
>> Packet loss sync full methodology is described in [JAY006],
>> according to the text. 
>> 
>>> And some other metrics are already documented in RFC6390 compliant
>>> documents. Pointers should be provided.
>> [ACM] 
>> Most others are discussion sections and provide references.
>> 
>>> See
>>> https://tools.ietf.org/html/draft-ietf-xrblock-independent-burst-gap-
>>> discard-01#appendix-A
>>> for an example
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> - Random Early Detection (RED), BLUE, and Proportional Integral
>>> controller (PI)
>>> Would you have references?
>>> 
>>> - BDP is mentioned a few times. Please expand.
>>> 
>>> - Glossary section = terminology section, right? If we want to be
>>> consistent across documents
>>> 
>>> - section 12.2. Why not a MUST below?
>>>  In order to understand an AQM's deployment considerations and
>>>  performance under a specific environment, AQM proposals SHOULD
>>>  describe the parameters that control the macroscopic AQM behavior,
>>>  and identify any parameters that require tuning to operational
>>>  conditions.
>>> 
>> 
> 
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm