Re: [ippm] Proposed charter updates for IPPM

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Sun, 09 July 2017 22:02 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBEB12F290 for <ippm@ietfa.amsl.com>; Sun, 9 Jul 2017 15:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 sPyAuR8CtV-o for <ippm@ietfa.amsl.com>; Sun, 9 Jul 2017 15:02:26 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679531200ED for <ippm@ietf.org>; Sun, 9 Jul 2017 15:02:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30580; q=dns/txt; s=iport; t=1499637746; x=1500847346; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gQujgR3tm6zNYRfcMTyAlK8hncmqqHUxkeeHKwBOkgc=; b=TRmVV0MaYTxNTTLf7uCtpF8a3oEDEaujwXoGOmPLYSRwUuD3YmTGIxuR EIN8sq3IA5mT1S8h+ZEOpwsbc+VtcBS1j+bodK8hxTE4ARAqouQRojBPR qyI2thJVxLF3eAK0oBCo0Ij+f0DoM6YHT7WbbuAgbadpAsUbkkjG4gGQ7 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CYAAClp2JZ/4MNJK1cGQEBAQEBAQEBAQEBBwEBAQEBgy0tZIEUhFOJNpFpdJUQghEhAQqFcAKDST8YAQIBAQEBAQEBayiFGAEBAQEDAQFlBwsMBAIBCBEEAQEWCwcHJwsUCQgCBA4FiUtkEKx5izkBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMog0yBYAErgkU0hEZKGYMEgjEFiU2NaIdpAosLiH2CDIVLikuJWoc6KYQCAR84gQp1FUkSAYcDdgGGO4I/AQEB
X-IronPort-AV: E=Sophos;i="5.40,336,1496102400"; d="scan'208,217";a="450865004"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2017 22:02:10 +0000
Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v69M2Alj001517 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 9 Jul 2017 22:02:10 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 9 Jul 2017 18:02:09 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sun, 9 Jul 2017 18:02:09 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "MORTON, ALFRED C (AL)" <acmorton@att.com>
CC: Brian Trammell <ietf@trammell.ch>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] Proposed charter updates for IPPM
Thread-Index: AQHS+Mdt3sP56RdGc0O1/0iMB0dTR6JMAYKAgAAK9Do=
Date: Sun, 09 Jul 2017 22:02:09 +0000
Message-ID: <1E003B2B-4C44-4E75-BCA2-C1DB1CF037B8@cisco.com>
References: <F00C2A6F-7907-4676-ABAF-E405AEECF544@trammell.ch>, <4D7F4AD313D3FC43A053B309F97543CF45005B91@njmtexg4.research.att.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF45005B91@njmtexg4.research.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_1E003B2B4C444E75BCA2C1DB1CF037B8ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/WKi2cBVBUVFnaQnQg4NlNgANstc>
Subject: Re: [ippm] Proposed charter updates for IPPM
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jul 2017 22:02:29 -0000

Thank you Brian for proactively bringing this discussion on the list before Prague.

All the proposed changes below bring the charter (i.e., the contract between the WG and the IETF) closer to reality and remove potential ambiguities and sources of misinterpretation. I believe that all these edits serve the higher purpose of charter hygiene and forward-looking polishing, and are not narrowly written solely with iOAM in mind.

As such, I very much support this proposal.

Related, and likely a question for Benoit, but curious about the PM-Directorate and whether this is OBE (I've not seen traffic for a couple years):
https://www.ietf.org/iesg/directorate/performance-metrics.html

I also agree with Al and support the removal (instead of rewrite) of the extra sentence.

Please find a couple small follow-ups inline.

Sent from my iPad

On Jul 9, 2017, at 1:23 PM, MORTON, ALFRED C (AL) <acmorton@att.com<mailto:acmorton@att.com>> wrote:

Hi Brian and Bill,

Thanks for preparing a new charter proposal and organizing
this message to highlight the changes. I agree with your
proposals.

I have one further proposal for the last sentence of
paragraph 1.

OLD (and your NEW):
Metrics developed by the IPPM WG are intended to provide unbiased
quantitative performance measurements and not a value judgement.

I propose to delete/replace the last phrase, which I think has been present
since the very first charter. IIRC, the concern was that contributions
might attempt to establish service acceptance thresholds, or other
numerical performance requirements/objectives using the metrics.
The work of setting numerical objectives proceeded elsewhere
(ITU-T Rec Y.1541), and the Earth continued to rotate.

If we want to ensure the status quo, we could say:
s/and not a value judgement/but numerical thresholds for the metrics are out-of-scope/

I also suggest this change with MBM in mind, where we have
testing outcomes of Pass/Fail/Inconclusive (PFI). Of course, the user
supplies the target rate, RTT, and/or loss ratio numerical values,
not the working group.

So we could express an explicit restriction that does not hamper MBM PFI:

NEW^2:
Metrics developed by the IPPM WG are intended to provide unbiased
quantitative performance measurements, but numerical thresholds for
the metrics are out-of-scope.

Or, we could remove the phrase, and refer any contributions on
numerical thresholds to ITU-T SG 12, Question 17, to avoid
overlapping work with another SDO (coordination with this SDO
should also be mentioned somewhere).

NEW^3:
Metrics developed by the IPPM WG are intended to provide unbiased
quantitative performance measurements.


+1 to this one.

thanks for considering this proposal, and regards,
Al

-----Original Message-----
From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell
Sent: Sunday, July 09, 2017 11:24 AM
To: IETF IPPM WG
Subject: [ippm] Proposed charter updates for IPPM

Greetings, all,

Bill and I met briefly last week to discuss a proposed change to the
charter, as a way to resolve the rough consensus to adopt the IOAM work
within IPPM with concerns that have been raised that that work doesn't
really fit on the charter. We arrived at a minimal suggested set of
edits. Though inspired by IOAM, these aren't so much focused on bringing
IOAM on charter as they are making the charter reflect the direction
work in IPPM has been going over the five years since we last updated
the charter.

We propose only to touch three paragraphs, as below:

---

OLD Paragraph 1:

The IP Performance Metrics (IPPM) Working Group develops and maintains
standard metrics that can be applied to the quality, performance, and
reliability of Internet data delivery services and applications running
over transport layer protocols (e.g. TCP, UDP) over IP. Specifying
network or lower layer OAM mechanisms is out of scope of the IPPM
charter. It also develops and maintains protocols for the measurement of
these metrics. These metrics are designed such that they can be used by
network operators, end users, or independent testing groups. Metrics
developed by the IPPM WG are intended to provide unbiased quantitative
performance measurements and not a value judgement.

NEW Paragraph 1:

The IP Performance Measurement (IPPM) Working Group develops and
maintains standard metrics that can be applied to the quality,
performance, and reliability of Internet data delivery services and
applications running over transport layer protocols (e.g. TCP, UDP) over
IP. It also develops and maintains methodologies and protocols for the
measurement of these metrics. These metrics are designed such that they
can be used by network operators, end users, or independent testing
groups. Metrics developed by the IPPM WG are intended to provide
unbiased quantitative performance measurements and not a value
judgement.


Two basic edits here:

(1) Rename working group from IP Performance Metrics to IP Performance
Measurement,

This is a very important change. Thanks for raising it.

and add "methodologies" to the set of things we do. In our
opinion, this reflects work that has been happening on charter for a
while: MBM, PDM, and alt-mark are all methodology work as opposed to
metric work.


I agree.

Editorial question: where it says: "These metrics are designed such that..." should that be: "These metrics, protocols, and methodologies are designed such that..."?

(2) Remove the sentence "Specifying network or lower layer OAM
mechanisms is out of scope of the IPPM charter". In my personal opinion,
this isn't really necessary to bring the IOAM work on, since though IOAM
can be carried on lower-layer headers, it doesn't really specify an OAM
mechanism as I understand that term to be defined in the routing area.
However, this restriction on the IPPM doesn't appear to do anything
useful beyond reinforcing an artificial silo dividing data-plane and
control-plane measurement, make it difficult for us to work together
with other (e.g. INT or RTG area) working groups on performance
measurement, and cause confusion as to whether we can do a thing called
"IOAM" in IPPM.

---

OLD Paragraph 6:

The WG has produced protocols for communication among test equipment to
enable the measurement of the one- and two-way metrics (OWAMP and TWAMP
respectively). These protocols will be advanced along the standards
track. The work of the WG will take into account the suitability of
measurements for automation, in order to support large-scale measurement
efforts. This may result in further developments in protocols such as
OWAMP and TWAMP. Agreement about the definitions of metrics and methods
of measurement enables accurate, reproducible, and equivalent results
across different implementations. To this end, the WG will define and
maintain a registry of metric definitions. The WG encourages work which
assesses the comparability of measurements of IPPM metrics with metrics
developed elsewhere.

NEW Paragraph 6:

The WG has produced protocols for communication among test equipment to
enable the measurement of the one- and two-way metrics (OWAMP and TWAMP
respectively). These protocols will be advanced along the standards
track. The work of the WG will take into account the suitability of
measurements for automation, in order to support large-scale measurement
efforts. This may result in further developments in protocols such as
OWAMP and TWAMP. Agreement about the definitions of metrics and methods
of measurement enables accurate, reproducible, and equivalent results
across different implementations. To this end, the WG defines and
maintains a registry of metric definitions. The WG encourages work which
assesses the comparability of measurements of IPPM metrics with metrics
developed elsewhere.


This is a purely editorial change: move definition and maintenance of
registry to present tense, since we're doing it.

---

OLD Paragraph 7:

The WG also encourages work which improves the availability of
information about the context in which measurements were taken.

NEW Paragraph 7:

The WG also encourages work which improves the availability of
information about the context in which measurements were taken, for
example, measurement implementation information, conditions on the
networks on which measurements are taken, or information about the data-
plane topology of the measured network.


This is an arguably editorial change. It makes it clear that work
targeted at IPPM that focuses on measurement on the spatial
characteristics of paths as context for metrics (e.g. parts of IOAM, but
also work like draft-amf-ippm-route, which attempts to answer the
question "what about traceroute" applied to the registry).


Good clarification.

The "for example" speaks to these, but I would add that context is not limited to this enumeration.

---

We additionally propose to strike the (out of date) near term milestones
from the charter text; milestones are separately managed.


Beyond these updates, we propose to leave the charter unchanged. We've
got some time to have this discussion on the agenda in Prague, but in
the meantime please send your thoughts on this proposal to the mailing
list.


Thanks!!!

Carlos.


Many thanks, best regards,

Brian (for the chairs)

_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm