Network Working Group                                          A. Morton
Internet-Draft                                                 AT&T Labs
Intended status: Standards Track                              E. Stephan
Expires: April 21, October 16, 2010                    France Telecom Division R&D
                                                        October 18, 2009
                                                          April 14, 2010

                     Spatial Composition of Metrics
                 draft-ietf-ippm-spatial-composition-10
                 draft-ietf-ippm-spatial-composition-11

Abstract

   This memo utilizes IPPM metrics that are applicable to both complete
   paths and sub-paths, and defines relationships to compose a complete
   path metric from the sub-path metrics with some accuracy w.r.t. the
   actual metrics.  This is called Spatial Composition in RFC 2330.  The
   memo refers to the Framework for Metric Composition, and provides
   background and motivation for combining metrics to derive others.
   The descriptions of several composed metrics and statistics follow.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   In this memo, the characters "<=" should be read as "less than or
   equal to" and ">=" as "greater than or equal to".

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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. progress."

   This Internet-Draft will expire on April 21, October 16, 2010.

Copyright Notice
   Copyright (c) 2009 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   This memo utilizes IPPM metrics that are applicable to both complete
   paths and sub-paths, and defines relationships to compose a complete
   path metric  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the sub-path metrics with some accuracy w.r.t. Trust Legal Provisions and are provided without warranty as
   described in the
   actual metrics. Simplified BSD License.

   This is called Spatial Composition in RFC 2330. document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The
   memo refers to person(s) controlling the Framework for Metric Composition, and provides
   background and motivation for combining metrics copyright in some of this
   material may not have granted the IETF Trust the right to derive others.
   The descriptions allow
   modifications of several composed metrics and statistics follow.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document are to may not be interpreted as described in RFC 2119 [RFC2119].

   In this memo, modified
   outside the characters "<=" should IETF Standards Process, and derivative works of it may
   not be read created outside the IETF Standards Process, except to format
   it for publication as "less than an RFC or
   equal to" and ">=" as "greater to translate it into languages other
   than or equal to". English.

Table of Contents

   1.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Scope and Application  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Scope of work  . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Application  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Incomplete Information . . . . . . . . . . . . . . . . . .  8
   4.  Common Specifications for Composed Metrics . . . . . . . . . .  8
     4.1.  Name: Type-P . . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Metric Parameters  . . . . . . . . . . . . . . . . . .  8
       4.1.2.  Definition and Metric Units  . . . . . . . . . . . . .  9
       4.1.3.  Discussion and other details . . . . . . . . . . . . .  9
       4.1.4.  Statistic: . . . . . . . . . . . . . . . . . . . . . .  9
       4.1.5.  Composition Function . . . . . . . . . . . . . . . . .  9
       4.1.6.  Statement of Conjecture and Assumptions  . . . . . . .  9
       4.1.7.  Justification of the Composition Function  . . . . . . 10
       4.1.8.  Sources of Deviation from the Ground Truth . . . . . . 10
       4.1.9.  Specific cases where the conjecture might fail . . . . 11
       4.1.10. Application of Measurement Methodology . . . . . . . . 11
   5.  One-way Delay Composed Metrics and Statistics  . . . . . . . . 12
     5.1.  Name:
           Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream  . . . 12
       5.1.1.  Metric Parameters  . . . . . . . . . . . . . . . . . . 12
       5.1.2.  Definition and Metric Units  . . . . . . . . . . . . . 12
       5.1.3.  Discussion and other details . . . . . . . . . . . . . 12
       5.1.4.  Statistic: . . . . . . . . . . . . . . . . . . . . . . 13
     5.2.  Name: Type-P-Finite-Composite-One-way-Delay-Mean . . . . . 13
       5.2.1.  Metric Parameters  . . . . . . . . . . . . . . . . . . 13
       5.2.2.  Definition and Metric Units of the Mean Statistic  . . 13
       5.2.3.  Discussion and other details . . . . . . . . . . . . . 14
       5.2.4.  Statistic: . . . . . . . . . . . . . . . . . . . . . . 14
       5.2.5.  Composition Function: Sum of Means . . . . . . . . . . 14
       5.2.6.  Statement of Conjecture and Assumptions  . . . . . . . 14
       5.2.7.  Justification of the Composition Function  . . . . . . 14
       5.2.8.  Sources of Deviation from the Ground Truth . . . . . . 14
       5.2.9.  Specific cases where the conjecture might fail . . . . 15
       5.2.10. Application of Measurement Methodology . . . . . . . . 15
     5.3.  Name: Type-P-Finite-Composite-One-way-Delay-Minimum  . . . 15
       5.3.1.  Metric Parameters  . . . . . . . . . . . . . . . . . . 15
       5.3.2.  Definition and Metric Units of the Minimum
               Statistic  . . . . . . . . . . . . . . . . . . . . . . 15
       5.3.3.  Discussion and other details . . . . . . . . . . . . . 16
       5.3.4.  Statistic: . . . . . . . . . . . . . . . . . . . . . . 16
       5.3.5.  Composition Function: Sum of Minima  . . . . . . . . . 16
       5.3.6.  Statement of Conjecture and Assumptions  . . . . . . . 16
       5.3.7.  Justification of the Composition Function  . . . . . . 16
       5.3.8.  Sources of Deviation from the Ground Truth . . . . . . 16
       5.3.9.  Specific cases where the conjecture might fail . . . . 17
       5.3.10. Application of Measurement Methodology . . . . . . . . 17
   6.  Loss Metrics and Statistics  . . . . . . . . . . . . . . . . . 17
     6.1.  Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 17
       6.1.1.  Metric Parameters: . . . . . . . . . . . . . . . . . . 17
       6.1.2.  Definition and Metric Units  . . . . . . . . . . . . . 17
       6.1.3.  Discussion and other details . . . . . . . . . . . . . 17
       6.1.4.  Statistic:
               Type-P-One-way-Packet-Loss-Empirical-Probability . . . 17
       6.1.5.  Composition Function: Composition of Empirical
               Probabilities  . . . . . . . . . . . . . . . . . . . . 18
       6.1.6.  Statement of Conjecture and Assumptions  . . . . . . . 18
       6.1.7.  Justification of the Composition Function  . . . . . . 18
       6.1.8.  Sources of Deviation from the Ground Truth . . . . . . 18
       6.1.9.  Specific cases where the conjecture might fail . . . . 18
       6.1.10. Application of Measurement Methodology . . . . . . . . 19
   7.  Delay Variation Metrics and Statistics . . . . . . . . . . . . 19
     7.1.  Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream  . 19
       7.1.1.  Metric Parameters: . . . . . . . . . . . . . . . . . . 19
       7.1.2.  Definition and Metric Units  . . . . . . . . . . . . . 20
       7.1.3.  Discussion and other details . . . . . . . . . . . . . 20
       7.1.4.  Statistics: Mean, Variance, Skewness, Quanitle . . . . 20
       7.1.5.  Composition Functions: . . . . . . . . . . . . . . . . 21
       7.1.6.  Statement of Conjecture and Assumptions  . . . . . . . 22
       7.1.7.  Justification of the Composition Function  . . . . . . 22
       7.1.8.  Sources of Deviation from the Ground Truth . . . . . . 23
       7.1.9.  Specific cases where the conjecture might fail . . . . 23
       7.1.10. Application of Measurement Methodology . . . . . . . . 23
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
     8.1.  Denial of Service Attacks  . . . . . . . . . . . . . . . . 23
     8.2.  User Data Confidentiality  . . . . . . . . . . . . . . . . 23
     8.3.  Interference with the metrics  . . . . . . . . . . . . . . 24
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   10. Acknowlegements  . . . . . . . . . . . . . . . . . . . . . . . 24
   11. Issues (Open and Closed) . . . . . . . . . . . . . . . . . . . 24
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     13.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27

1.  Contributors

   Thus far, the following people have contributed useful ideas,
   suggestions, or the text of sections that have been incorporated into
   this memo:

   - Phil Chimento <vze275m9@verizon.net>

   - Reza Fardid <RFardid@Covad.COM>

   - Roman Krzanowski <roman.krzanowski@verizon.com>

   - Maurizio Molina <maurizio.molina@dante.org.uk>

   - Lei Liang <L.Liang@surrey.ac.uk>

   - Dave Hoeflin <dhoeflin@att.com>

2.  Introduction

   The IPPM framework [RFC2330] describes two forms of metric
   composition, spatial and temporal.  The new composition framework
   [I-D.ietf-ippm-framework-compagg]
   [RFC5835] expands and further qualifies these original forms into
   three categories.  This memo describes Spatial Composition, one of
   the categories of metrics under the umbrella of the composition
   framework.

   Spatial composition encompasses the definition of performance metrics
   that are applicable to a complete path, based on metrics collected on
   various sub-paths.

   The main purpose of this memo is to define the deterministic
   functions that yield the complete path metrics using metrics of the
   sub-paths.  The effectiveness of such metrics is dependent on their
   usefulness in analysis and applicability with practical measurement
   methods.

   The relationships may involve conjecture, and [RFC2330] lists four
   points that the metric definitions should include:

   o  the specific conjecture applied to the metric and assumptions of
      the statistical model of the process being measured (if any, see
      [RFC2330] section 12),

   o  a justification of the practical utility of the composition in
      terms of making accurate measurements of the metric on the path,

   o  a justification of the usefulness of the composition in terms of
      making analysis of the path using A-frame concepts more effective,
      and

   o  an analysis of how the conjecture could be incorrect.

   Also, [RFC2330] gives an example using the conjecture that the delay
   of a path is very nearly the sum of the delays of the exchanges and
   clouds of the corresponding path digest.  This example is
   particularly relevant to those who wish to assess the performance of
   an Inter-domain path without direct measurement, and the performance
   estimate of the complete path is related to the measured results for
   various sub-paths instead.

   Approximate functions between the sub-path and complete path metrics
   are useful, with knowledge of the circumstances where the
   relationships are/are not applicable.  For example, we would not
   expect that delay singletons from each sub-path would sum to produce
   an accurate estimate of a delay singleton for the complete path
   (unless all the delays were essentially constant - very unlikely).
   However, other delay statistics (based on a reasonable sample size)
   may have a sufficiently large set of circumstances where they are
   applicable.

2.1.  Motivation

   One-way metrics defined in other IPPM RFCs all assume that the
   measurement can be practically carried out between the source and the
   destination of the interest.  Sometimes there are reasons that the
   measurement can not be executed from the source to the destination.
   For instance, the measurement path may cross several independent
   domains that have conflicting policies, measurement tools and
   methods, and measurement time assignment.  The solution then may be
   the composition of several sub-path measurements.  This means each
   domain performs the One-way measurement on a sub path between two
   nodes that are involved in the complete path following its own
   policy, using its own measurement tools and methods, and using its
   own measurement timing.  Under the appropriate conditions, one can
   combine the sub-path One-way metric results to estimate the complete
   path One-way measurement metric with some degree of accuracy.

3.  Scope and Application
3.1.  Scope of work

   For the primary IPPM metrics of Loss, Delay, and Delay Variation,
   this memo gives a set of metrics that can be composed from the same
   or similar sub-path metrics.  This means that the composition
   function may utilize:

   o  the same metric for each sub-path;

   o  multiple metrics for each sub-path (possibly one that is the same
      as the complete path metric);

   o  a single sub-path metric that is different from the complete path
      metric;

   o  different measurement techniques like active and passive
      (recognizing that PSAMP WG will define capabilities to sample
      packets to support measurement).

   We note a possibility: Using a complete path metric and all but one
   sub-path metric to infer the performance of the missing sub-path,
   especially when the "last" sub-path metric is missing.  However, such
   de-composition calculations, and the corresponding set of issues they
   raise, are beyond the scope of this memo.

3.2.  Application

   The new composition framework [I-D.ietf-ippm-framework-compagg] [RFC5835] requires the specification of
   the applicable circumstances for each metric.  In particular, each
   section addresses whether the metric:

   Requires the same test packets to traverse all sub-paths, or may use
   similar packets sent and collected separately in each sub-path.

   Requires homogeneity of measurement methodologies, or can allow a
   degree of flexibility (e.g., active or passive methods produce the
   "same" metric).  Also, the applicable sending streams will be
   specified, such as Poisson, Periodic, or both.

   Needs information or access that will only be available within an
   operator's domain, or is applicable to Inter-domain composition.

   Requires synchronized measurement time intervals in all sub-paths, or
   largely overlapping, or no timing requirements.

   Requires assumption of sub-path independence w.r.t. the metric being
   defined/composed, or other assumptions.

   Has known sources of inaccuracy/error, and identifies the sources.

3.3.  Incomplete Information

   In practice, when measurements cannot be initiated on a sub-path (and
   perhaps the measurement system gives up during the test interval),
   then there will not be a value for the sub-path reported, and the
   entire test result SHOULD be recorded as "undefined".  This case
   should be distinguished from the case where the measurement system
   continued to send packets throughout the test interval, but all were
   declared lost.

   When a composed metric requires measurements from sub paths A, B, and
   C, and one or more of the sub-path results are undefined, then the
   composed metric SHOULD also be recorded as undefined.

4.  Common Specifications for Composed Metrics

   To reduce the redundant information presented in the detailed metrics
   sections that follow, this section presents the specifications that
   are common to two or more metrics.  The section is organized using
   the same subsections as the individual metrics, to simplify
   comparisons.

   Also, the following index variables represent the following:

   o  m = index for packets sent

   o  n = index for packets received

   o  s = index for involved sub-paths

4.1.  Name: Type-P

   All metrics use the Type-P convention as described in [RFC2330].  The
   rest of the name is unique to each metric.

4.1.1.  Metric Parameters

   o  Src, the IP address of a host

   o  Dst, the IP address of a host

   o  T, a time (start of test interval)

   o  Tf, a time (end of test interval)
   o  lambda, a rate in reciprocal seconds (for Poisson Streams)

   o  incT, the nominal duration of inter-packet interval, first bit to
      first bit (for Periodic Streams)

   o  T0, a time that MUST be selected at random from the interval [T,
      T+dT] to start generating packets and taking measurements (for
      Periodic Streams)

   o  TstampSrc, the wire time of the packet as measured at MP(Src)

   o  TstampDst, the wire time of the packet as measured at MP(Dst),
      assigned to packets that arrive within a "reasonable" time.

   o  Tmax, a maximum waiting time for packets at the destination, set
      sufficiently long to disambiguate packets with long delays from
      packets that are discarded (lost), thus the distribution of delay
      is not truncated.

   o  M, the total number of packets sent between T0 and Tf

   o  N, the total number of packets received at Dst (sent between T0
      and Tf)

   o  S, the number of sub-paths involved in the complete Src-Dst path

4.1.2.  Definition and Metric Units

   This section is unique for every metric.

4.1.3.  Discussion and other details

   This section is unique for every metric.

4.1.4.  Statistic:

   This section is unique for every metric.

4.1.5.  Composition Function

   This section is unique for every metric.

4.1.6.  Statement of Conjecture and Assumptions

   This section is unique for each metric.

4.1.7.  Justification of the Composition Function

   It is sometimes impractical to conduct active measurements between
   every Src-Dst pair.  Since the full mesh of N measurement points
   grows as N x N, the scope of measurement may be limited by testing
   resources.

   There may be varying limitations on active testing in different parts
   of the network.  For example, it may not be possible to collect the
   desired sample size in each test interval when access link speed is
   limited, because of the potential for measurement traffic to degrade
   the user traffic performance.  The conditions on a low-speed access
   link may be understood well-enough to permit use of a small sample
   size/rate, while a larger sample size/rate may be used on other sub-
   paths.

   Also, since measurement operations have a real monetary cost, there
   is value in re-using measurements where they are applicable, rather
   than launching new measurements for every possible source-destination
   pair.

4.1.8.  Sources of Deviation from the Ground Truth

4.1.8.1.  Sub-path List Differs from Complete Path

   The measurement packets, each having source and destination addresses
   intended for collection at edges of the sub-path, may take a
   different specific path through the network equipment and links when
   compared to packets with the source and destination addresses of the
   complete path.  Examples sources of parallel paths include Equal Cost
   Multi-Path and parallel (or bundled) links.  Therefore, the
   performance estimated from the composition of sub-path measurements
   may differ from the performance experienced by packets on the
   complete path.  Multiple measurements employing sufficient sub-path
   address pairs might produce bounds on the extent of this error.

   We also note the possibility of re-routing during a measurement
   interval, as it may affect the correspondence between packets
   traversing the complete path and the sub-paths that were "involved"
   prior to the re-route.

4.1.8.2.  Sub-path Contains Extra Network Elements

   Related to the case of an alternate path described above is the case
   where elements in the measured path are unique to measurement system
   connectivity.  For example, a measurement system may use a dedicated
   link to a LAN switch, and packets on the complete path do not
   traverse that link.  The performance of such a dedicated link would
   be measured continuously, and its contribution to the sub-path
   metrics SHOULD be minimized as a source of error.

4.1.8.3.  Sub-paths Have Incomplete Coverage

   Measurements of sub-path performance may not cover all the network
   elements on the complete path.  For example, the network exchange
   points might be excluded unless a cooperative measurement is
   conducted.  In this example, test packets on the previous sub-path
   are received just before the exchange point and test packets on the
   next sub-path are injected just after the same exchange point.
   Clearly, the set of sub-path measurements SHOULD cover all critical
   network elements in the complete path.

4.1.8.4.  Absence of route

   At a specific point in time, no viable route exists between the
   complete path source and destination.  The routes selected for one or
   more sub-paths therefore differs from the complete path.
   Consequently, spatial composition may produce finite estimation of a
   ground truth metric between a source and a destination, even when the
   route between them is undefined.

4.1.9.  Specific cases where the conjecture might fail

   This section is unique for most metrics (see the metric-specific
   sections).

   For delay-related metrics, One-way delay always depends on packet
   size and link capacity, since it is measured in [RFC2679] from first
   bit to last bit.  If the size of an IP packet changes (due to
   encapsulation for security reasons), this will influence delay
   performance.

   Fragmentation is a major issue for compostion accuracy, since all
   metrics require all fragments to arrive before proceeding, and
   fragmented complete path performance is likely to be different from
   performance with non-fragmented packets and composed metrics based on
   non-fragmented sub-path measurements.

4.1.10.  Application of Measurement Methodology

   The methodology:

   SHOULD use similar packets sent and collected separately in each sub-
   path.

   Allows a degree of flexibility regarding test stream generation
   (e.g., active or passive methods can produce an equivalent result,
   but the lack of control over the source, timing and correlation of
   passive measurements is much more challenging).

   Poisson and/or Periodic streams are RECOMMENDED.

   Applies to both Inter-domain and Intra-domain composition.

   SHOULD have synchronized measurement time intervals in all sub-paths,
   but largely overlapping intervals MAY suffice.

   REQUIRES assumption of sub-path independence w.r.t. the metric being
   defined/composed.

5.  One-way Delay Composed Metrics and Statistics

5.1.  Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream

   This metric is a necessary element of Delay Composition metrics, and
   its definition does not formally exist elsewhere in IPPM literature.

5.1.1.  Metric Parameters

   See the common parameters section above.

5.1.2.  Definition and Metric Units

   Using the parameters above, we obtain the value of Type-P-One-way-
   Delay singleton as per [RFC2679].

   For each packet [i] that has a finite One-way Delay (in other words,
   excluding packets which have undefined one-way delay):

   Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] =

   FiniteDelay[i] = TstampDst - TstampSrc

   The units of measure for this metric are time in seconds, expressed
   in sufficiently low resolution to convey meaningful quantitative
   information.  For example, resolution of microseconds is usually
   sufficient.

5.1.3.  Discussion and other details

   The "Type-P-Finite-One-way-Delay" metric permits calculation of the
   sample mean statistic.  This resolves the problem of including lost
   packets in the sample (whose delay is undefined), and the issue with
   the informal assignment of infinite delay to lost packets (practical
   systems can only assign some very large value).

   The Finite-One-way-Delay approach handles the problem of lost packets
   by reducing the event space.  We consider conditional statistics, and
   estimate the mean one-way delay conditioned on the event that all
   packets in the sample arrive at the destination (within the specified
   waiting time, Tmax).  This offers a way to make some valid statements
   about one-way delay, and at the same time avoiding events with
   undefined outcomes.  This approach is derived from the treatment of
   lost packets in [RFC3393], and is similar to [Y.1540] .

5.1.4.  Statistic:

   All statistics defined in [RFC2679] are applicable to the finite one-
   way delay,and additional metrics are possible, such as the mean (see
   below).

5.2.  Name: Type-P-Finite-Composite-One-way-Delay-Mean

   This section describes a statistic based on the Type-P-Finite-One-
   way-Delay-Poisson/Periodic-Stream metric.

5.2.1.  Metric Parameters

   See the common parameters section above.

5.2.2.  Definition and Metric Units of the Mean Statistic

   We define

   Type-P-Finite-One-way-Delay-Mean =
                                    N
                                   ---
                              1    \
                  MeanDelay = - *   >   (FiniteDelay [n])
                              N    /
                                   ---
                                  n = 1

   where all packets n= 1 through N have finite singleton delays.

   The units of measure for this metric are time in seconds, expressed
   in sufficiently fine resolution to convey meaningful quantitative
   information.  For example, resolution of microseconds is usually
   sufficient.

5.2.3.  Discussion and other details

   The Type-P-Finite-One-way-Delay-Mean metric requires the conditional
   delay distribution described in section 5.1.

5.2.4.  Statistic:

   This metric, a mean, does not require additional statistics.

5.2.5.  Composition Function: Sum of Means

   The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay,
   for the complete Source to Destination path can be calculated from
   sum of the Mean Delays of all its S constituent sub-paths.

   Then the

   Type-P-Finite-Composite-One-way-Delay-Mean =
                                     S
                                    ---
                                    \
                   CompMeanDelay =   >   (MeanDelay [s])
                                    /
                                    ---
                                   s = 1
   where sub-paths s = 1 to S are invloved in the complete path.

5.2.6.  Statement of Conjecture and Assumptions

   The mean of a sufficiently large stream of packets measured on each
   sub-path during the interval [T, Tf] will be representative of the
   ground truth mean of the delay distribution (and the distributions
   themselves are sufficiently independent), such that the means may be
   added to produce an estimate of the complete path mean delay.

   It is assumed that the one-way delay distributions of the sub-paths
   and the complete path are continuous.  The mean of bi-modal
   distributions have the unfortunate property that such a value may
   never occur.

5.2.7.  Justification of the Composition Function

   See the common section.

5.2.8.  Sources of Deviation from the Ground Truth

   See the common section.

5.2.9.  Specific cases where the conjecture might fail

   If any of the sub-path distributions are bimodal, then the measured
   means may not be stable, and in this case the mean will not be a
   particularly useful statistic when describing the delay distribution
   of the complete path.

   The mean may not be sufficiently robust statistic to produce a
   reliable estimate, or to be useful even if it can be measured.

   If a link contributing non-negligible delay is erroneously included
   or excluded, the composition will be in error.

5.2.10.  Application of Measurement Methodology

   The requirements of the common section apply here as well.

5.3.  Name: Type-P-Finite-Composite-One-way-Delay-Minimum

   This section describes is a statistic based on the Type-P-Finite-One-
   way-Delay-Poisson/Periodic-Stream metric, and the composed metric
   based on that statistic.

5.3.1.  Metric Parameters

   See the common parameters section above.

5.3.2.  Definition and Metric Units of the Minimum Statistic

   We define

   Type-P-Finite-One-way-Delay-Minimum =
               = MinDelay = (FiniteDelay [j])

               such that for some index, j, where 1<= j <= N
               FiniteDelay[j] <= FiniteDelay[n] for all n

   where all packets n = 1 through N have finite singleton delays.

   The units of measure for this metric are time in seconds, expressed
   in sufficiently fine resolution to convey meaningful quantitative
   information.  For example, resolution of microseconds is usually
   sufficient.

5.3.3.  Discussion and other details

   The Type-P-Finite-One-way-Delay-Minimum metric requires the
   conditional delay distribution described in section 5.1.3.

5.3.4.  Statistic:

   This metric, a minimum, does not require additional statistics.

5.3.5.  Composition Function: Sum of Minima

   The Type-P-Finite--Composite-One-way-Delay-Minimum, or CompMinDelay,
   for the complete Source to Destination path can be calculated from
   sum of the Minimum Delays of all its S constituent sub-paths.

   Then the

   Type-P-Finite-Composite-One-way-Delay-Minimum =
                                      S
                                     ---
                                     \
                    CompMinDelay =    >  (MinDelay [s])
                                     /
                                     ---
                                    s = 1

5.3.6.  Statement of Conjecture and Assumptions

   The minimum of a sufficiently large stream of packets measured on
   each sub-path during the interval [T, Tf] will be representative of
   the ground truth minimum of the delay distribution (and the
   distributions themselves are sufficiently independent), such that the
   minima may be added to produce an estimate of the complete path
   minimum delay.

   It is assumed that the one-way delay distributions of the sub-paths
   and the complete path are continuous.

5.3.7.  Justification of the Composition Function

   See the common section.

5.3.8.  Sources of Deviation from the Ground Truth

   See the common section.

5.3.9.  Specific cases where the conjecture might fail

   If the routing on any of the sub-paths is not stable, then the
   measured minimum may not be stable.  In this case the composite
   minimum would tend to produce an estimate for the complete path that
   may be too low for the current path.

5.3.10.  Application of Measurement Methodology

   The requirements of the common section apply here as well.

6.  Loss Metrics and Statistics

6.1.  Type-P-Composite-One-way-Packet-Loss-Empirical-Probability

6.1.1.  Metric Parameters:

   Same as section 4.1.1.

6.1.2.  Definition and Metric Units

   Using the parameters above, we obtain the value of Type-P-One-way-
   Packet-Loss singleton and stream as per [RFC2680].

   We obtain a sequence of pairs with elements as follows:

   o  TstampSrc, as above

   o  L, either zero or one, where L=1 indicates loss and L=0 indicates
      arrival at the destination within TstampSrc + Tmax.

6.1.3.  Discussion and other details

6.1.4.  Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability

   Given the stream parameter M, the number of packets sent, we can
   define the Empirical Probability of Loss Statistic (Ep), consistent
   with Average Loss in [RFC2680], as follows:

   Type-P-One-way-Packet-Loss-Empirical-Probability =
                                       M
                                      ---
                                 1    \
                            Ep = - *   >  (L[m])
                                 M    /
                                      ---
                                     m = 1

   where all packets m = 1 through M have a value for L.

6.1.5.  Composition Function: Composition of Empirical Probabilities

   The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or
   CompEp for the complete Source to Destination path can be calculated
   by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ...
   Epn) as

   Type-P-Composite-One-way-Packet-Loss-Empirical-Probability =
   CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - EpS)}

   If any Eps is undefined in a particular measurement interval,
   possibly because a measurement system failed to report a value, then
   any CompEp that uses sub-path s for that measurement interval is
   undefined.

6.1.6.  Statement of Conjecture and Assumptions

   The empirical probability of loss calculated on a sufficiently large
   stream of packets measured on each sub-path during the interval [T,
   Tf] will be representative of the ground truth empirical loss
   probability (and the probabilities themselves are sufficiently
   independent), such that the sub-path probabilities may be combined to
   produce an estimate of the complete path empirical loss probability.

6.1.7.  Justification of the Composition Function

   See the common section.

6.1.8.  Sources of Deviation from the Ground Truth

   See the common section.

6.1.9.  Specific cases where the conjecture might fail

   A concern for loss measurements combined in this way is that root
   causes may be correlated to some degree.

   For example, if the links of different networks follow the same
   physical route, then a single catastrophic event like a fire in a
   tunnel could cause an outage or congestion on remaining paths in
   multiple networks.  Here it is important to ensure that measurements
   before the event and after the event are not combined to estimate the
   composite performance.

   Or, when traffic volumes rise due to the rapid spread of an email-
   born worm, loss due to queue overflow in one network may help another
   network to carry its traffic without loss.

   others...

6.1.10.  Application of Measurement Methodology

   See the common section.

7.  Delay Variation Metrics and Statistics

7.1.  Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream

   This packet delay variation (PDV) metric is a necessary element of
   Composed Delay Variation metrics, and its definition does not
   formally exist elsewhere in IPPM literature.

7.1.1.  Metric Parameters:

   In addition to the parameters of section 4.1.1:

   o  TstampSrc[i], the wire time of packet[i] as measured at MP(Src)
      (measurement point at the source)

   o  TstampDst[i], the wire time of packet[i] as measured at MP(Dst),
      assigned to packets that arrive within a "reasonable" time.

   o  B, a packet length in bits

   o  F, a selection function unambiguously defining the packets from
      the stream that are selected for the packet-pair computation of
      this metric.  F(first packet), the first packet of the pair, MUST
      have a valid Type-P-Finite-One-way-Delay less than Tmax (in other
      words, excluding packets which have undefined one-way delay) and
      MUST have been transmitted during the interval T, Tf.  The second
      packet in the pair, F(second packet) MUST be the packet with the
      minimum valid value of Type-P-Finite-One-way-Delay for the stream,
      in addition to the criteria for F(first packet).  If multiple
      packets have equal minimum Type-P-Finite-One-way-Delay values,
      then the value for the earliest arriving packet SHOULD be used.

   o  MinDelay, the Type-P-Finite-One-way-Delay value for F(second
      packet) given above.

   o  N, the number of packets received at the Destination meeting the
      F(first packet) criteria.

7.1.2.  Definition and Metric Units

   Using the definition above in section 5.1.2, we obtain the value of
   Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[n], the singleton
   for each packet[i] in the stream (a.k.a.  FiniteDelay[i]).

   For each packet[n] that meets the F(first packet) criteria given
   above: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream[n] =

   PDV[n] = FiniteDelay[n] - MinDelay

   where PDV[i] is in units of time in seconds, expressed in
   sufficiently fine resolution to convey meaningful quantitative
   information.  For example, resolution of microseconds is usually
   sufficient.

7.1.3.  Discussion and other details

   This metric produces a sample of delay variation normalized to the
   minimum delay of the sample.  The resulting delay variation
   distribution is independent of the sending sequence (although
   specific FiniteDelay values within the distribution may be
   correlated, depending on various stream parameters such as packet
   spacing).  This metric is equivalent to the IP Packet Delay Variation
   parameter defined in [Y.1540].

7.1.4.  Statistics: Mean, Variance, Skewness, Quanitle

   We define the mean PDV as follows (where all packets n = 1 through N
   have a value for PDV[n]):

   Type-P-One-way-pdv-refmin-Mean = MeanPDV =
                                   N
                                  ---
                             1    \
                             - *   >   (PDV[n])
                             N    /
                                  ---
                                 n = 1

   We define the variance of PDV as follows:

   Type-P-One-way-pdv-refmin-Variance = VarPDV =
                               N
                              ---
                        1     \                      2
                     -------   >   (PDV[n] - MeanPDV)
                     (N - 1)  /
                              ---
                             n = 1

   We define the skewness of PDV as follows:

   Type-P-One-way-pdv-refmin-Skewness = SkewPDV =
                         N
                        ---                        3
                        \     /                  \
                         >   |  PDV[n]- MeanPDV  |
                        /     \                 /
                        ---
                       n = 1
                    -----------------------------------
                        /                         \
                       |                  ( 3/2 )  |
                        \ (N - 1) * VarPDV        /

   We define the Quantile of the IPDVRefMin sample as the value where
   the specified fraction of singletons is less than the given value.

7.1.5.  Composition Functions:

   This section gives two alternative composition functions.  The
   objective is to estimate a quantile of the complete path delay
   variation distribution.  The composed quantile will be estimated
   using information from the sub-path delay variation distributions.

7.1.5.1.  Approximate Convolution

   The Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream samples from
   each sub-path are summarized as a histogram with 1 ms bins
   representing the one-way delay distribution.

   From [Stats], the distribution of the sum of independent random
   variables can be derived using the relation:

   Type-P-Composite-One-way-pdv-refmin-quantile-a =
                          /  /
     P(X + Y + Z <= a) = |  | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz
                        /  /
                        z  y
   where X, Y, and Z are random variables representing the delay
   variation distributions of the sub-paths of the complete path (in
   this case, there are three sub-paths), and a is the quantile of
   interest.  Note dy and dz indicate partial integration here.This
   relation can be used to compose a quantile of interest for the
   complete path from the sub-path delay distributions.  The histograms
   with 1 ms bins are discrete approximations of the delay
   distributions.

7.1.5.2.  Normal Power Approximation

   Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source to
   Destination path can be calculated by combining statistics of all the
   constituent sub-paths in the process described in [Y.1541] clause 8
   and Appendix X.

7.1.6.  Statement of Conjecture and Assumptions

   The delay distribution of a sufficiently large stream of packets
   measured on each sub-path during the interval [T, Tf] will be
   sufficiently stationary and the sub-path distributions themselves are
   sufficiently independent, so that summary information describing the
   sub-path distributions can be combined to estimate the delay
   distribution of complete path.

   It is assumed that the one-way delay distributions of the sub-paths
   and the complete path are continuous.

7.1.7.  Justification of the Composition Function

   See the common section.

7.1.8.  Sources of Deviation from the Ground Truth

   In addition to the common deviations, a few additional sources exist
   here.  For one, very tight distributions with range on the order of a
   few milliseconds are not accurately represented by a histogram with 1
   ms bins.  This size was chosen assuming an implicit requirement on
   accuracy: errors of a few milliseconds are acceptable when assessing
   a composed distribution quantile.

   Also, summary statistics cannot describe the subtleties of an
   empirical distribution exactly, especially when the distribution is
   very different from a classical form.  Any procedure that uses these
   statistics alone may incur error.

7.1.9.  Specific cases where the conjecture might fail

   If the delay distributions of the sub-paths are somehow correlated,
   then neither of these composition functions will be reliable
   estimators of the complete path distribution.

   In practice, sub-path delay distributions with extreme outliers have
   increased the error of the composed metric estimate.

7.1.10.  Application of Measurement Methodology

   See the common section.

8.  Security Considerations

8.1.  Denial of Service Attacks

   This metric requires a stream of packets sent from one host (source)
   to another host (destination) through intervening networks.  This
   method could be abused for denial of service attacks directed at
   destination and/or the intervening network(s).

   Administrators of source, destination, and the intervening network(s)
   should establish bilateral or multi-lateral agreements regarding the
   timing, size, and frequency of collection of sample metrics.  Use of
   this method in excess of the terms agreed between the participants
   may be cause for immediate rejection or discard of packets or other
   escalation procedures defined between the affected parties.

8.2.  User Data Confidentiality

   Active use of this method generates packets for a sample, rather than
   taking samples based on user data, and does not threaten user data
   confidentiality.  Passive measurement must restrict attention to the
   headers of interest.  Since user payloads may be temporarily stored
   for length analysis, suitable precautions MUST be taken to keep this
   information safe and confidential.  In most cases, a hashing function
   will produce a value suitable for payload comparisons.

8.3.  Interference with the metrics

   It may be possible to identify that a certain packet or stream of
   packets is part of a sample.  With that knowledge at the destination
   and/or the intervening networks, it is possible to change the
   processing of the packets (e.g. increasing or decreasing delay) that
   may distort the measured performance.  It may also be possible to
   generate additional packets that appear to be part of the sample
   metric.  These additional packets are likely to perturb the results
   of the sample measurement.

   To discourage the kind of interference mentioned above, packet
   interference checks, such as cryptographic hash, may be used.

9.  IANA Considerations

   Metrics defined in this memo will be registered in the IANA IPPM
   METRICS REGISTRY as described in initial version of the registry
   [RFC4148].

10.  Acknowlegements

   A long time ago, in a galaxy far, far away (Minneapolis), Will Leland
   suggested the simple and elegant Type-P-Finite-One-way-Delay concept.
   Thanks Will.

11.  Issues (Open and Closed)

   >>>>>>>>>>>>Issue:

   Is Section 4.1.8.4 really describing a new error case, about
   Alternate Routing?  Or does Section 4.1.8.1 on sub-path differences
   cover it all?

   RESOLUTION: The section was re-worded in -10 version to make the
   topic, Absence of a real Route between the Src and Dst, more clear.

   >>>>>>>>>>>>
   >>>>>>>>>>>>Issue:

   What is the relationship between the decomposition and composition
   metrics?  Should we put both kinds in one draft to make up a
   framework?  The motivation of decomposition is as follows:

   The One-way measurement can provide result to show what the network
   performance between two end hosts is and whether it meets operator
   expectations or not.  It cannot provide further information to
   engineers where and how to improve the performance between the source
   and the destination.  For instance, if the network performance is not
   acceptable in terms of the One-way measurement, in which part of the
   network the engineers should put their efforts.  This question can to
   be answered by decompose the One-way measurement to sub-path
   measurement to investigate the performance of different part of the
   network.

   Editor's Questions for clarification: What additional information
   would be provided to the decomposition process, beyond the
   measurement of the complete path?

   Is the decomposition described above intended to estimate a metric
   for some/all disjoint sub-paths involved in the complete path?

   >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a separate memo

   >>>>>>>>>>>>>>>>>>>

   >>>>>>>>>>>>>>>>>>>Issue

   Section 7 defines a new type of metric, a "combination" of metrics
   for one-way delay and packet loss.  The purpose of this metric is to
   link these two primary metrics in a convenient way.

   Readers are asked to comment on the efficiency of the combination
   metric.

   >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as
   having "undefined" delay when the packet does not arrive within the
   waiting time Tmax, then this information is sufficient to determine
   the fraction of lost packets in the sample, and the additional loss
   indication of this combo is not needed.

   >>>>>>>>>>>>>>>>>>

   >>>>>>>>>>>>>>>>> Issue

   Can we introduce multicast metrics here, without causing too much
   confusion?  Should the multicast version of this draft wait until the
   Unicast concepts are stable (or maybe appear in a separate draft)?

   >>>>>>>>>>>>>>>>RESOLUTION: No and Yes.

12.  Acknowledgements

13.  References

13.1.  Normative References

   [I-D.ietf-ippm-framework-compagg]
              Morton, A., "Framework for Metric Composition",
              draft-ietf-ippm-framework-compagg-08 (work in progress),
              June 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [RFC4148]  Stephan, E., "IP Performance Metrics (IPPM) Metrics
              Registry", BCP 108, RFC 4148, August 2005.

   [RFC5835]  Morton, A. and S. Van den Berghe, "Framework for Metric
              Composition", RFC 5835, April 2010.

13.2.  Informative References

   [I-D.ietf-ippm-multimetrics]

   [RFC5644]  Stephan, E., Liang, L., and A. Morton, "IP Performance
              Metrics (IPPM) for spatial (IPPM): Spatial and multicast",
              draft-ietf-ippm-multimetrics-12 (work in progress),
              September Multicast", RFC 5644,
              October 2009.

   [Stats]    McGraw-Hill NY NY, "Introduction to the Theory of
              Statistics, 3rd Edition,",   1974.

   [Y.1540]   ITU-T Recommendation Y.1540, "Internet protocol data
              communication service - IP packet transfer and
              availability performance parameters", December  2002. November 2007.

   [Y.1541]   ITU-T Recommendation Y.1541, "Network Performance
              Objectives for IP-based Services", February  2006.

Index

   ?
      ???  14

Authors' Addresses

   Al Morton
   AT&T Labs
   200 Laurel Avenue South
   Middletown,, NJ  07748
   USA

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192
   Email: acmorton@att.com
   URI:   http://home.comcast.net/~acmacm/

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

   Phone:
   Fax:   +33 2 96 05 18 52
   Email: emile.stephan@orange-ftgroup.com
   URI: