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