[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
Network Working Group                                         E. Stephan
Internet-Draft                                            France Telecom
Expires: September 15, 2005                                     L. Liang
                                                    University of Surrey
                                                          March 17, 2005


    IP Performance Metrics (IPPM) metrics for spatial and multicast
                 draft-stephan-ippm-multimetrics-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 15, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   The IETF IP Performance Metrics (IPPM) working group has standardized
   metrics for measuring end-to-end performance between 2 points.  This
   memo defines 2 sets of metrics to extend these end-to-end ones.  It
   defines spatial metrics for measuring the performance of segments
   along a path and metrics for measuring the performance of a group of
   users in multiparty communications.





Stephan & Liang        Expires September 15, 2005               [Page 1]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   Multiparty metric  . . . . . . . . . . . . . . . . . . . .  5
     2.2   Spatial metric . . . . . . . . . . . . . . . . . . . . . .  5
     2.3   One-to-group metric  . . . . . . . . . . . . . . . . . . .  5
   3.  Motivations for multiparty metrics . . . . . . . . . . . . . .  5
   4.  Spatial metrics definitions  . . . . . . . . . . . . . . . . .  6
     4.1   A Definition for Spatial One-way Delay Stream  . . . . . .  6
     4.2   A Definition for Spatial One-way Packet Loss Stream  . . .  8
     4.3   A Definition for Spatial One-way Jitter Stream . . . . . .  9
     4.4   Discussion on spatial statistics . . . . . . . . . . . . . 10
   5.  One-to-group metrics definitions . . . . . . . . . . . . . . . 10
     5.1   A Definition for one-to-group One-way Delay Stream . . . . 10
     5.2   A Definition for one-to-group One-way Packet Loss
           Stream . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.3   A Definition for one-to-group One-way Jitter Stream  . . . 12
     5.4   Discussion on one-to-group statistics  . . . . . . . . . . 13
   6.  Open issues  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 16
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 18

























Stephan & Liang        Expires September 15, 2005               [Page 2]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


1.  Introduction

   The metrics specified in this memo are built on notions introduced
   and discussed in the IPPM Framework document, RFC 2330 [RFC2330].
   The reader should be familiar with these documents.

   This memo makes use of definitions of end-to-end One-way Delay
   Metrics defined in the RFC 2679 [RFC2679] to define metrics for
   decomposition of end-to-end one-way delays measurements.

   This memo makes use of definitions of end-to-end One-way Packet loss
   Metrics defined in the RFC 2680 [RFC2680] to define metrics for
   decomposition of end-to-end one-way packet loss measurements.

   The IPPM defined a framework for metric definitions and end-to-end
   measurements:

   o  A general framework for defining performance metrics, described in
      the Framework for IP Performance Metrics, RFC 2330 [RFC2330];

   o  A One-way Active Measurement Protocol Requirements, RFC 3763
      [RFC3763];

   o  A One-way Active Measurement Protocol (OWAMP) [work in progress];

   o  An IP Performance Metrics Registry [work in progress];

   It specified a set of end-to-end metrics, which conform to this
   framework:

   o  The IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678];

   o  The One-way Delay Metric for IPPM, RFC 2679 [RFC2679];

   o  The One-way Packet Loss Metric for IPPM, RFC 2680 [RFC2680];

   o  The Round-trip Delay Metric for IPPM, RFC 2681 [RFC2681];

   o  A Framework for Defining Empirical Bulk Transfer Capacity Metrics
      RFC 3148 [RFC3148];

   o  One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357];

   o  IP Packet Delay Variation Metric for IPPM, RFC 3393 [RFC3393];

   o  Network performance measurement for periodic streams, RFC 3432
      [RFC3432];




Stephan & Liang        Expires September 15, 2005               [Page 3]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


   o  Packet Reordering Metric for IPPM [Work in progress];

   Based on these works, this memo defines 2 kinds of multi party
   metrics.

   Firstly it defines spatial metrics:

   o  Using the Type-P-One-way-Delay metric, a 'sample', called
      Type-P-Spatial-One-way-Delay-Stream, will be introduced to
      decompose an end-to-end Type-P-One-way-Delay in a spatial sequence
      of one-way delays.

   o  Using the Type-P-Spatial-One-way-Delay-Stream metric, a 'sample',
      called Type-P-Spatial-One-way-Packet-Loss-Stream, will be
      introduced to decompose an end-to-end Type-P-One-way-Packet-Loss
      in a spatial sequence of packet loss.

   o  Using the Type-P-Spatial-One-way-Delay-Stream metric, a 'sample',
      called Type-P-Spatial-One-way-Jitter-Stream, will be introduced to
      decompose an end-to-end Type-P-One-way-ipdv in a spatial sequence
      of jitter.

   Then it defines one-to-group metrics.

   o  Using one test packet sent from one sender to a group of
      receivers, a 'sample', called
      Type-P-one-to-group-One-way-Delay-Stream, will be introduced to
      define the list of Type-P-one-way-delay between this sender and
      the group of receivers.

   o  Using one test packet sent from one sender to a group of
      receivers, a 'sample', called
      Type-P-one-to-group-One-way-Packet-Loss-Stream, will be introduced
      to define the list of Type-P-One-way-Packet-Loss between this
      sender and the group of receivers

   o  Using one test packet sent from one sender to a group of
      receivers, a 'sample', called
      Type-P-one-to-group-One-way-Jitter-Stream, will be introduced to
      define the list of Type-P-One-way-ipdv between this sender and the
      group of receivers

   o  Then a discussion section presents the set of statistics that may
      be computed on the top of these metrics to present the QoS in a
      view of a group of users as well as the requirements of relative
      QoS on multiparty communications.





Stephan & Liang        Expires September 15, 2005               [Page 4]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


2.  Terminology

2.1  Multiparty metric

   A metric is said to be multiparty if the definition involved two or
   more measurement points.

2.2  Spatial metric

   A metric is said to be spatial if one of the hosts involved is
   neither the source nor the destination of the metered packet.

2.3  One-to-group metric

   A metric is said to be one-to-group if the measured packet is sent by
   one source and received by several destinations.

3.  Motivations for multiparty metrics

   All IPPM metrics are defined for end-to-end measurement.  These
   metrics provide very good guides for measurement in the pair
   communications.  However, further efforts should be put to define
   metrics for multiparty measurements such as one to one trajectory
   metrics and one to multipoints metrics.

   To understand the connection situation between one source and any one
   receiver in the multiparty communication group, we need the
   decomposition of instantaneous end-to-end measures.  It will give us
   very detailed insight into each branch of the routing tree in terms
   of node-to-node absolute QoS.  It can provide clear and helpful
   information for engineers to identify the connection with problems in
   a complex multiparty routing tree.

   Decomposition of instantaneous end-to-end measures is needed:

   o  The PCE WG requires definitions of protocol-independent metrics
      for measuring path quality.  The minimum criteria are spatial
      one-way delay, spatial packet loss and spatial jitter.

   o  The PSAMP WG defines capabilities to sample packets in a way to to
      support measurement.  Defining spatial one-way metrics provides
      PSAMP and IPPM measurement frameworks with common definition to
      measure trajectory performance.

   o  Traffic engineering and troubleshooting applications require
      spatial views of the  one-way delay consumption and packet loss
      location identification.




Stephan & Liang        Expires September 15, 2005               [Page 5]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


   o  Monitoring the QoS of point-to-multipoint and inter-domain
      communication require spatial decomposition of the one-way delay
      and of the packet loss.

   While the node-to-node based spatial measures can provide very useful
   data in the view of each connection, we also need measures to present
   the performance of a multiparty communication in the view of a group
   with consideration that it involves a group of people rather than
   two.  As a consequence a simple one-way metric cannot describe the
   multi-connection situation.  We need some new metrics to collect
   performance of all the connections for further statistics analysis.
   A group of metrics are proposed in this stage named one-to-group
   performance metrics based on the unicast metrics defined in IPPM WG.

   One-to-group performance metrics are needed for several reasons:

   o  For designing and engineering multicast trees and MPLS
      point-to-multipoint LSP;

   o  For evaluating and controlling of the quality of the multicast
      services;

   o  For controlling the performance of the inter domain multicast
      services;

   o  For presenting and evaluating the relative QoS requirements for
      the multiparty communications.


4.  Spatial metrics definitions

4.1  A Definition for Spatial One-way Delay Stream

   This section is coupled with the definition of Type-P-One-way-Delay.
   Consequently when a parameter from section 3 of [RFC2679] is first
   used in this section, it will be tagged with a trailing asterisk.

4.1.1  Metric Name

   Type-P-Spatial-One-way-Delay-Stream











Stephan & Liang        Expires September 15, 2005               [Page 6]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


4.1.2  Metric Parameters

          + Src*, the IP address of the sender.

          + Dst*, the IP address of the receiver.

          + i, An integer which ordered the hosts in the path.

          + Hi, exchange points of the path digest.

          + T*, a time.

          + dT* a delay,

          + dT1,..., dTn a list of delay.

          + P*, the specification of the packet type.

          + <Src, H1, H2,..., Hn, Dst>, a path digest.



4.1.3  Metric Units

   A sequence of times.

4.1.4  Definition

   Given a Type-P packet sent by the sender Src at wire-time (first bit)
   T to the receiver Dst in the path <H1, H2,..., Hn>.  Given the
   sequence of values <T+dT1,T+dT2,...,T+dTn,T+dT> such that dT is the
   Type-P-One-way-Delay from Src to Dst and such that for each Hi of the
   path, T+dTi is either a real number corresponding to the wire-time
   the packet passes (last bit received)  Hi, or undefined if the packet
   never passes Hi.

   Type-P-Spatial-One-way-Delay-Stream metric is defined for the path
   <Src, H1, H2,..., Hn, Dst> as the sequence of values
   <T,dT1,dT2,...,dTn,dT>.

4.1.5  Discussion and Methodologies

   TODO: See sections 3.5 and 3.6 of [RFC2679].

   TODO: discuss the impact of the MP location in the passive decive
   with PSAMP: wiretime of the last bit of the packet on the receiver
   side' seems appropriate.




Stephan & Liang        Expires September 15, 2005               [Page 7]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


4.2  A Definition for Spatial One-way Packet Loss Stream

   This section is coupled with the definition of
   Type-P-One-way-Packet-Loss.  Then when a parameter from the section 2
   of [RFC2680] is first used in this section, it will be tagged with a
   trailing asterisk.

4.2.1  Metric Name

   Type-P-Spatial-One-way-Packet-Loss-Stream

4.2.2  Metric Parameters

        + Src*, the IP address of the sender.

        + Dst*, the IP address of the receiver.

        + i, An integer which ordered the hosts in the path.

        + Hi, exchange points of the path digest.

        + T*, a time.

        + dT1,..., dTn, dT, a list of delay.

        + P*, the specification of the packet type.

        + <Src, H1, H2,..., Hn, Dst>, a path digest.

        + B1, B2, ..., Bi, ..., Bn,      a list of boolean.



4.2.3  Metric Units

   A sequence of booleans.

4.2.4  Definition

   Given a Type-P packet sent by the sender Src at time T to the
   receiver Dst in the path <H1, H2, ..., Hn>.  Given the sequence of
   times <T+dT1,T+dT2,...,T+dTn,T+dT> the packet passes <H1, H2 ..., Hn,
   Dst>,

   Type-P-One-way-Packet-Lost-Stream metric is defined as the sequence
   of  values <B1, B2, ..., Bn> such that for each Hi of the path, a
   value of Bi of 0 means that dTi is a finite value, and a value of 1
   means that dTi is undefined.



Stephan & Liang        Expires September 15, 2005               [Page 8]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


4.3  A Definition for Spatial One-way Jitter Stream

   This section uses parameters from the definition of
   Type-P-One-way-ipdv.  When a parameter from section 2 of [RFC3393] is
   first used in this section, it will be tagged with a trailing
   asterisk.

4.3.1  Metric Name

   Type-P-Spatial-One-way-Jitter-Stream

4.3.2  Metric Parameters

          + Src*, the IP address of the sender.

          + Dst*, the IP address of the receiver.

          + i, An integer which ordered the hosts in the path.

          + Hi, exchange points of the path digest.

          + T1*, the time the first apcket was sent.

          + T2*, the time the second apcket was sent.

          + P, the specification of the packet type.


          + P1, the first packet sent at time T1.

          + P2, the second packet sent at time T2.

          + <Src, H1, H2,..., Hn, Dst>, a path digest.

          + <T1,dT1.1, dT1.2,..., dT1.n,dT1>,
          the Type-P-Spatial-One-way-Delay-Stream for packet sent at
          time T1;

          + <T2,dT2.1, dT2.2,..., dT2.n,dT2>,
          the Type-P-Spatial-One-way-Delay-Stream for packet sent at
          time T2;

          + L*, a packet length in bits. The packets of a Type P
          packet stream from which the
          Type-P-Spatial-One-way-Delay-Stream metric is taken MUST
          all be of the same length.





Stephan & Liang        Expires September 15, 2005               [Page 9]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


4.3.3  Metric Units

   A sequence of times.

4.3.4  Definition

   Given the Type-P packet having the size L and sent by the sender Src
   at wire-time (first bit) T1 to the receiver Dst in the path <H1,
   H2,..., Hn>.  Given the Type-P packet having the size L and sent by
   the sender Src at wire-time (first bit) T2 to the receiver Dst in the
   same path.  Given the Type-P-Spatial-One-way-Delay-Stream <T1,dT1.1,
   dT1.2,..., dT1,n,dT1> of the packet P1.  Given the
   Type-P-Spatial-One-way-Delay-Stream <T2,dT2.1, dT2.2,..., dT2,n,dT2>
   of the packet P2.

   Type-P-Spatial-One-way-Jitter-Stream metric is defined as the
   sequence of values
   <T2-T1,dT2.1-dT1.1,dT2.2-dT1.2,...,dT2.n-dT1.n,dT2-dT1> Such that for
   each Hi of the path, dT2.i-dT1.i is either a real number if the
   packets P1 and P2 passes Hi at wire-time (last bit)dT1.i,
   respectively dT2.i, or undefined if at least one of them never passes
   Hi.  T2-T1 is the inter-packet emission interval and dT2-dT1 is ddT*
   the Type-P-One-way-ipdv at T1,T2*.

4.3.5  Discussion and Methodologies

   TODO: See sections ?? and ?? of [RFC3393].

   TODO: discuss the fact that the path may change: T2-T1 should be very
   small.  max 1 ms ?

4.4  Discussion on spatial statistics

   TODO

5.  One-to-group metrics definitions

5.1  A Definition for one-to-group One-way Delay Stream

5.1.1  Metric Name

   Type-P-one-to-group-One-way-Delay-Stream









Stephan & Liang        Expires September 15, 2005              [Page 10]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


5.1.2  Metric Parameters

        + Src, the IP address of a host acting as the source.

        + Recv1,..., RecvN, the IP addresses of the N hosts acting as
        receivers.

        + T, a time.

        + dT1,...,dTn a list of time.

        + P, the specification of the packet type.



5.1.3  Metric Units

   The value of a Type-P-one-to-group-One-way-Delay-Stream is a set of
   singletons metrics Type-P-One-way-Delay [RFC2679].

5.1.4  Definition

   Given a Type P packet sent by the source Src at Time T, given the N
   hosts { Recv1,...,RecvN } which receive the packet at the time {
   T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Stream is
   defined as the set of the Type-P-One-way-Delay singleton between Src
   and each receiver with value of { dT1, dT2,...,dTn }.

5.2  A Definition for one-to-group One-way Packet Loss Stream

5.2.1  Metric Name

   Type-P-one-to-group-One-way-Packet-Loss-Stream

5.2.2  Metric Parameters

        + Src, the IP address of a host acting as the source.

        + Recv1,..., RecvN, the IP addresses of the N hosts acting as
        receivers.

        + T, a time.

        + T1,...,Tn, a list of time.

        + P, the specification of the packet type.





Stephan & Liang        Expires September 15, 2005              [Page 11]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


5.2.3  Metric Units

   The value of a Type-P-one-to-group-One-way-Packet-Loss-Stream is a
   set of singletons metrics Type-P-One-way-Packet-Loss [RFC2680].

5.2.4  Definition

   Given a Type P packet sent by the source Src at T and the N hosts,
   Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a
   Type-P-one-to-group-One-way-Packet-Loss-Stream is defined as a set of
   the Type-P-One-way-Packet-Loss singleton between Src and each of the
   receivers {<T1,0|1>,<T2,0|1>,..., <Tn,0|1>}.

5.3  A Definition for one-to-group One-way Jitter Stream

5.3.1  Metric Name

   Type-P-one-to-group-One-way-Jitter-Stream

5.3.2  Metric Parameters

        + Src, the IP address of a host acting as the source.

        + Recv1,..., RecvN, the IP addresses of the N hosts acting as
        receivers.

        + T1, a time.

        + T2, a time.

        + ddT1,...,ddTn, a list of time.

        + P, the specification of the packet type.

        + F, a selection function defining unambiguously the two
        packets from the stream selected for the metric.



5.3.3  Metric Units

   The value of a Type-P-one-to-group-One-way-Jitter-Stream is a set of
   singletons metrics Type-P-One-way-ipdv [RFC3393].

5.3.4  Definition

   Given a Type P packet stream, Type-P-one-to-group-One-way-
   Jitter-Stream is defined for two packets from the source Src to the N



Stephan & Liang        Expires September 15, 2005              [Page 12]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


   hosts {Recv1,...,RecvN },which are selected by the selection function
   F, as the difference between the value of the
   Type-P-one-to-group-One-way-Delay-Stream from Src to { Recv1,...,
   RecvN } at time T1 and the value of the Type-P-one-to-group-
   One-way-Delay-Stream from Src to { Recv1,...,RecvN } at time T2.  T1
   is the wire-time at which Scr sent the first bit of the first packet,
   and T2 is the wire-time at which Src sent the first bit of the second
   packet.  This metric is derived from the Type-P-one-to-
   group-One-way-Delay-Stream metric.

   Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one-
   to-group-One-way-Jitter-Stream from Src to { Recv1,...,RecvN } at T1,
   T2 is {ddT1,...,ddTn} means that Src sent two packets, the first at
   wire-time T1 (first bit), and the second at wire-time T2 (first bit)
   and the packets were received by { Recv1,...,RecvN } at wire-time
   {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time
   {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that
   {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}.

5.4  Discussion on one-to-group statistics

   The defined one-to-group metrics above can all be directly achieved
   from the relevant unicast one-way metrics.  They managed to collect
   all unicast measurement results of one-way metrics together in one
   profile and sort them by receivers and packets in a multicast group.
   They can provide sufficient information regarding the network
   performance in terms of each receiver and guide engineers to
   indentify patential problem happened on each branch of a multicast
   routing tree.  However, these metrics can not be directly used to
   conveniently present the performance in terms of a group and neither
   to identify the relative QoS situation.

   One may say that no matter how many people join the communication,
   the connections can still be treated as a set of one-to-one
   connection.  However, we might not describe a multiparty
   communication by a set of one-way measurement metrics because of the
   difficulty for understanding and the lack of convenience.  For
   instance, an engineer might not describe the connections of a
   multiparty online conference in terms of one-to-group one-way delay
   for user A and B, B and C, and C and A because people might be
   confused.  If there are more users in the same communication, the
   description might be very long.  And he might use the one-way metrics
   with worst and the best value to give users an idea of the QoS range
   of the service they are providing.  But it is not clear enough and
   might not be accurate in a large multiparty communication scenario.

   From the QoS point of view, the multiparty communication services not
   only require the absolute QoS support but also the relative QoS.  The



Stephan & Liang        Expires September 15, 2005              [Page 13]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


   relative QoS means the difference between absolute QoS of all users.
   Directly using the one-way metrics cannot present the relative QoS
   situation.  However, if we use the variations of all users one-way
   parameters, we can have new metrics to measure the difference of the
   absolute QoS and hence provide the threshold value of relative QoS
   that a multiparty service might demand.  A very good example of the
   high relative QoS requirement is the online gaming.  A very light
   worse delay will result in failure in the game.  We have to use the
   new statitic metrics to define exactly how small the relative delay
   the online gaming requires.  There are many other services, e.g.
   online biding, online stock market, etc., need a rule to judge the
   relative QoS requirement.  Therefore, we can see the importance of
   new statistic metrics to feed this need.

   We might use some one-to-group statistic conceptions to present the
   group performance and relative QoS.  In this stage, we define
   one-to-group mean stream and one-to-group variation stream.  These
   statistics are offered mostly to be illustrative of what could be
   done.

   One-to-group mean streams are trying to measure the overall QoS for a
   multicast group associated to one source.  It is a reflection of the
   absolute QoS of a multiparty communication service when we treat all
   receivers as one customer.  It can also present the trend of the
   absolute QoS of all receivers, i.e., it shows that most of the
   receivers in the multiparty communication service trend to receive an
   absolute QoS close to the mean.

   One-to-group variation streams are trying to measure how the QoS
   varies among all of the users in a multicast group associated to one
   source.  The word "variation" in this memo is the population standard
   deviation.  It reflects the relative QoS situation in a multiparty
   communication service, i.e., the level of the difference between the
   absolute QoS of each receivers.

   Using the one-to-group mean and one-to-group variation concepts, we
   can have a much clear understand on the QoS of a multiparty
   communication service in terms of its trend and range.  There can be
   mean and variation stream definitions for each of the three
   one-to-group metrics defined above.  We only present the definition
   of Type-P-one-to-group-One-way- Delay-Mean-Stream and
   Type-P-one-to-group-One-way-Delay-Variation-Stream as examples in
   this memo.

5.4.1  Type-P-one-to-group-One-way-Delay-Mean-Stream

   Given a Type-P-one-to-group-One-way-Delay-Stream, the mean stream of
   all { dT1, dT2,...,dTn } for the packet from Src at time T to {



Stephan & Liang        Expires September 15, 2005              [Page 14]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


   Recv1,...,RecvN }.

   For example, suppose we take a sample and the results are:

        Delay_Stream = <
        {T1,...,Tn}
        {T'1,...,T'n}
        {T''1,...T''n}
        >

   Then the mean stream would be:

        Delay_Mean_Stream = <
        DM1
        DM2
        DM3
        >
        = <
        sum{T1,...,Tn}/n
        sum{T'1,...,T'n}/n
        sum{T''1,...T''n}/n
        >


5.4.2  Type-P-one-to-group-One-way-Delay-Variation-Stream

   Given a Type-P-one-to-group-One-way-Delay-Stream, the variation
   stream of all { dT1, dT2,...,dTn } for the packet from Src at time T
   to { Recv1,...,RecvN }.

   We still take the above Delay_Stream as a sample and the variation
   stream would be:

      Delay_Variation_Stream = <
      DV1
      DV2
      DV3
      >
      =<
      (SUM{(T1-DM1)^2,...,(Tn-DM1)^2)}/n)^(1/2)
      (SUM{(T'1-DM2)^2,...,(T'n-DM2)^2)}/n)^(1/2)
      (SUM{(T''1-DM3)^2,...,(T''n-DM3)^2)}/n)^(1/2)
      >


6.  Open issues

   Do we define statistic for spatial delay, loss and jitter ?



Stephan & Liang        Expires September 15, 2005              [Page 15]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


7.  Security Considerations

   TODO: see owd pl, jitter rfc.

   TODO: Add a sentence on relation with passive.

   TODO: one-to-group metrics defined here are not intrusive: they rely
   on measures of owd...

8.  References

8.1  Normative References

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330, May
              1998.

   [RFC2679]  Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way
              Delay Metric for IPPM", RFC 2679, September 1999.

   [RFC2680]  Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way
              Packet Loss Metric for IPPM", RFC 2680, September 1999.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

8.2  Informative References

   [RFC2678]  Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
              Connectivity", RFC 2678, September 1999.

   [RFC2681]  Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip
              Delay Metric for IPPM", RFC 2681, September 1999.

   [RFC3148]  Mathis, M. and M. Allman, "A Framework for Defining
              Empirical Bulk Transfer Capacity Metrics", RFC 3148, July
              2001.

   [RFC3357]  Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
              Metrics", RFC 3357, August 2002.

   [RFC3432]  Raisanen, V., Grotefeld, G. and A. Morton, "Network
              performance measurement with periodic streams", RFC 3432,
              November 2002.

   [RFC3763]  Shalunov, S. and B. Teitelbaum, "One-way Active
              Measurement Protocol (OWAMP) Requirements", RFC 3763,



Stephan & Liang        Expires September 15, 2005              [Page 16]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


              April 2004.


Authors' Addresses

   Stephan Emile
   France Telecom Division R & D
   2 avenue Pierre Marzin
   Lannion,   F-22307

   Fax:   +33 2 96 05 18 52
   EMail: emile.stephan@francetelecom.com


   Lei Liang
   CCSR, University of Surrey
   Guildford
   Surrey,   GU2 7XH

   Fax:   +44 1483 683641
   EMail: L.Liang@surrey.ac.uk






























Stephan & Liang        Expires September 15, 2005              [Page 17]


Internet-Draft    Spatial and Multicast Metrics for IPPM      March 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Stephan & Liang        Expires September 15, 2005              [Page 18]