Re: [ippm] WG Review: Recharter of IP Performance Metrics (ippm)
<Ruediger.Geib@telekom.de> Fri, 16 January 2009 08:29 UTC
Return-Path: <ippm-bounces@ietf.org>
X-Original-To: ippm-archive@megatron.ietf.org
Delivered-To: ietfarch-ippm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17283A6936; Fri, 16 Jan 2009 00:29:05 -0800 (PST)
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA743A6936 for <ippm@core3.amsl.com>; Fri, 16 Jan 2009 00:29:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8btg0KbgG3M for <ippm@core3.amsl.com>; Fri, 16 Jan 2009 00:29:04 -0800 (PST)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 1FAF63A63EB for <ippm@ietf.org>; Fri, 16 Jan 2009 00:29:03 -0800 (PST)
Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 16 Jan 2009 09:28:45 +0100
Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 09:28:45 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 16 Jan 2009 09:28:44 +0100
Message-ID: <151C164FE2E066418D8D44D0801543A5382610@S4DE8PSAAQA.mitte.t-com.de>
In-Reply-To: <200901151556.n0FFumb3021302@klph001.kcdc.att.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ippm] WG Review: Recharter of IP Performance Metrics (ippm)
Thread-Index: Acl3KfIraEdnboobSqym3HWqTaYSNgAh5xZg
References: <20090114203058.0DBCC3A6A8F@core3.amsl.com> <200901151556.n0FFumb3021302@klph001.kcdc.att.com>
From: Ruediger.Geib@telekom.de
To: acmorton@att.com
X-OriginalArrivalTime: 16 Jan 2009 08:28:45.0457 (UTC) FILETIME=[72709810:01C977B4]
Cc: K.Aldinger-Stein@telekom.de, ippm@ietf.org
Subject: Re: [ippm] WG Review: Recharter of IP Performance Metrics (ippm)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org
Al, from my recollection of the IPDV metric, RFC3393 only determines that there must be a selction function F by which one defines an IPDV metric based on a set of delay singletons. The AS draft discusses two different selection functions and recommends one. The AS draft as is discusses constructed examples, so I don't think it qualifies for a BCP, which I think may be another option where to go with it besides standards track. The selection function of RFC3393 allows for flexibility and may be useful to allow for search of the "perfect" IPDV specification. On the other hand, flexibility opens a door for incompatibility. So there's a point in determining a selection function for IPDV and making it a standard. Regards, Ruediger -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton Sent: Thursday, January 15, 2009 4:57 PM To: henk@ripe.net; matt@internet2.edu; ippm@ietf.org Subject: Re: [ippm] WG Review: Recharter of IP Performance Metrics (ippm) At 03:30 PM 1/14/2009, IESG Secretary wrote: >...The working group will advance these metrics along the standards >track within the IETF. It will be guided by applicable IESG documents >in this area. Additionally, the WG will produce Proposed Standard >AS documents, comparable to applicability statements in RFC 2026, >that will focus on procedures for measuring the individual metrics >and how these metrics characterize features that are important to >different service classes, such as bulk transport, periodic streams, >packet bursts or multimedia streams. Each AS document will discuss... <more of this paragraph below> I think there may be some confusion about the role of AS memos in IPPM, and possibly it is just my confusion, but let's find out. This discussion may end-up as a comment on the charter text. Should the Delay Variation AS draft have been a Standards Track memo? (It is currently categorized as Informational) It fits the description in the charter, except that I thought it made more sense as a non-standards track document, because we have a challenge ahead of us to advance our TS metrics along the stds track. I didn't see any need to verify the material in the delay-var-AS draft against implementations (but that's not needed for AS?). Also, we have some elements of the AS charter description in our current TS metrics documents (RFC 2026 allows for this possibility); methods of measurement come to mind. So, while I think IPPM can live with the current Informational status, I may have made a mistake in the categorization of the delay-var-as memo, and I'd like to hear other's thoughts on the topic. thanks and regards, Al <complete charter paragraph follows> The working group will advance these metrics along the standards track within the IETF. It will be guided by applicable IESG documents in this area. Additionally, the WG will produce Proposed Standard AS documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, packet bursts or multimedia streams. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. The AS documents can also discuss the use of the metrics to verify performance expectations, such as SLA's, report results to specific user groups or investigate network problems. The focus is, again, to define how this should be done, not to define a value judgment. The WG may define additional statistics for its metrics if needed. Specific topics of these AS documents must be approved by the Area Directors as charter additions. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm
- [ippm] WG Review: Recharter of IP Performance Met… IESG Secretary
- Re: [ippm] WG Review: Recharter of IP Performance… Al Morton
- Re: [ippm] WG Review: Recharter of IP Performance… Ruediger.Geib