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
- [ippm] Proposed charter updates for IPPM Brian Trammell
- Re: [ippm] Proposed charter updates for IPPM MORTON, ALFRED C (AL)
- Re: [ippm] Proposed charter updates for IPPM Carlos Pignataro (cpignata)
- Re: [ippm] Proposed charter updates for IPPM Brian Trammell (IETF)
- Re: [ippm] Proposed charter updates for IPPM Brian Trammell (IETF)
- Re: [ippm] Proposed charter updates for IPPM Carlos Pignataro (cpignata)
- Re: [ippm] Proposed charter updates for IPPM Brian Trammell (IETF)
- Re: [ippm] Proposed charter updates for IPPM Joachim Fabini