Spatial Composition of Metrics
draftietfippmspatialcomposition16
The information below is for an old version of the document that is already published as an RFC.
Document  Type 
This is an older version of an InternetDraft that was ultimately published as RFC 6049.



Authors  Al Morton , Emile Stephan  
Last updated  20151014 (Latest revision 20100814)  
RFC stream  Internet Engineering Task Force (IETF)  
Intended RFC status  Proposed Standard  
Formats  
Reviews  
Additional resources  Mailing list discussion  
Stream  WG state  (None)  
Document shepherd  (None)  
IESG  IESG state  Became RFC 6049 (Proposed Standard)  
Action Holders 
(None)


Consensus boilerplate  Unknown  
Telechat date  (None)  
Responsible AD  Lars Eggert  
Send notices to  (None) 
draftietfippmspatialcomposition16
Network Working Group A. Morton InternetDraft AT&T Labs Intended status: Standards Track E. Stephan Expires: February 14, 2011 France Telecom Division R&D August 13, 2010 Spatial Composition of Metrics draftietfippmspatialcomposition16 Abstract This memo utilizes IP Performance Metrics that are applicable to both complete paths and subpaths, and defines relationships to compose a complete path metric from the subpath 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 InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79. InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current Internet Drafts is at http://datatracker.ietf.org/drafts/current/. InternetDrafts 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 InternetDrafts as reference material or to cite them other than as "work in progress." This InternetDraft will expire on February 14, 2011. Copyright Notice Morton & Stephan Expires February 14, 2011 [Page 1] InternetDraft Spatial Composition August 2010 Copyright (c) 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/licenseinfo) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. Morton & Stephan Expires February 14, 2011 [Page 2] InternetDraft Spatial Composition August 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Scope and Application . . . . . . . . . . . . . . . . . . . . 6 2.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Application . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Incomplete Information . . . . . . . . . . . . . . . . . . 7 3. Common Specifications for Composed Metrics . . . . . . . . . . 7 3.1. Name: TypeP . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 8 3.1.2. Definition and Metric Units . . . . . . . . . . . . . 9 3.1.3. Discussion and other details . . . . . . . . . . . . . 9 3.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 9 3.1.5. Composition Function . . . . . . . . . . . . . . . . . 9 3.1.6. Statement of Conjecture and Assumptions . . . . . . . 9 3.1.7. Justification of the Composition Function . . . . . . 9 3.1.8. Sources of Deviation from the Ground Truth . . . . . . 10 3.1.9. Specific cases where the conjecture might fail . . . . 11 3.1.10. Application of Measurement Methodology . . . . . . . . 11 4. Oneway Delay Composed Metrics and Statistics . . . . . . . . 12 4.1. Name: TypePFiniteOnewayDelay<Sample>Stream . . . . 12 4.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 12 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 12 4.1.3. Discussion and other details . . . . . . . . . . . . . 12 4.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Name: TypePFiniteCompositeOnewayDelayMean . . . . . 13 4.2.1. Metric Parameters . . . . . . . . . . . . . . . . . . 13 4.2.2. Definition and Metric Units of the Mean Statistic . . 13 4.2.3. Discussion and other details . . . . . . . . . . . . . 14 4.2.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 14 4.2.5. Composition Function: Sum of Means . . . . . . . . . . 14 4.2.6. Statement of Conjecture and Assumptions . . . . . . . 14 4.2.7. Justification of the Composition Function . . . . . . 14 4.2.8. Sources of Deviation from the Ground Truth . . . . . . 14 4.2.9. Specific cases where the conjecture might fail . . . . 15 4.2.10. Application of Measurement Methodology . . . . . . . . 15 4.3. Name: TypePFiniteCompositeOnewayDelayMinimum . . . 15 4.3.1. Metric Parameters . . . . . . . . . . . . . . . . . . 15 4.3.2. Definition and Metric Units of the Minimum Statistic . . . . . . . . . . . . . . . . . . . . . . 15 4.3.3. Discussion and other details . . . . . . . . . . . . . 16 4.3.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 16 4.3.5. Composition Function: Sum of Minima . . . . . . . . . 16 4.3.6. Statement of Conjecture and Assumptions . . . . . . . 16 4.3.7. Justification of the Composition Function . . . . . . 16 4.3.8. Sources of Deviation from the Ground Truth . . . . . . 16 4.3.9. Specific cases where the conjecture might fail . . . . 17 Morton & Stephan Expires February 14, 2011 [Page 3] InternetDraft Spatial Composition August 2010 4.3.10. Application of Measurement Methodology . . . . . . . . 17 5. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 17 5.1. TypePCompositeOnewayPacketLossEmpiricalProbability 17 5.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 17 5.1.2. Definition and Metric Units . . . . . . . . . . . . . 17 5.1.3. Discussion and other details . . . . . . . . . . . . . 17 5.1.4. Statistic: TypePOnewayPacketLossEmpiricalProbability . . . 17 5.1.5. Composition Function: Composition of Empirical Probabilities . . . . . . . . . . . . . . . . . . . . 18 5.1.6. Statement of Conjecture and Assumptions . . . . . . . 18 5.1.7. Justification of the Composition Function . . . . . . 18 5.1.8. Sources of Deviation from the Ground Truth . . . . . . 18 5.1.9. Specific cases where the conjecture might fail . . . . 18 5.1.10. Application of Measurement Methodology . . . . . . . . 19 6. Delay Variation Metrics and Statistics . . . . . . . . . . . . 19 6.1. Name: TypePOnewaypdvrefmin<Sample>Stream . . . . . 19 6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 19 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 20 6.1.3. Discussion and other details . . . . . . . . . . . . . 20 6.1.4. Statistics: Mean, Variance, Skewness, Quantile . . . . 20 6.1.5. Composition Functions: . . . . . . . . . . . . . . . . 21 6.1.6. Statement of Conjecture and Assumptions . . . . . . . 22 6.1.7. Justification of the Composition Function . . . . . . 23 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 23 6.1.9. Specific cases where the conjecture might fail . . . . 23 6.1.10. Application of Measurement Methodology . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 23 7.2. User Data Confidentiality . . . . . . . . . . . . . . . . 24 7.3. Interference with the metrics . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. Contributors and Acknowledgements . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Morton & Stephan Expires February 14, 2011 [Page 4] InternetDraft Spatial Composition August 2010 1. Introduction The IP Performance Metrics (IPPM) framework [RFC2330] describes two forms of metric composition, spatial and temporal. The composition framework [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 subpaths. The main purpose of this memo is to define the deterministic functions that yield the complete path metrics using metrics of the subpaths. 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 Aframe 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 Interdomain path without direct measurement, and the performance estimate of the complete path is related to the measured results for various subpaths instead. Approximate functions between the subpath 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 subpath would sum to produce an accurate estimate of a delay singleton for the complete path Morton & Stephan Expires February 14, 2011 [Page 5] InternetDraft Spatial Composition August 2010 (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. 1.1. Motivation Oneway metrics defined in other RFCs (such as [RFC2679] and [RFC2680]) all assume that the measurement can be practically carried out between the source and the destination of interest. Sometimes there are reasons that the measurement cannot 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 subpath measurements. This means each domain performs the Oneway 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 subpath Oneway metric results to estimate the complete path Oneway measurement metric with some degree of accuracy. 2. Scope and Application 2.1. Scope of work For the primary IPPM metrics of Loss [RFC2680], Delay [RFC2679], and Delay Variation [RFC3393], this memo gives a set of metrics that can be composed from the same or similar subpath metrics. This means that the composition function may utilize: o the same metric for each subpath; o multiple metrics for each subpath (possibly one that is the same as the complete path metric); o a single subpath metric that is different from the complete path metric; o different measurement techniques like active [RFC2330], [RFC3432] and passive [RFC5474]. We note a possibility: Using a complete path metric and all but one subpath metric to infer the performance of the missing subpath, especially when the "last" subpath metric is missing. However, such decomposition calculations, and the corresponding set of issues they Morton & Stephan Expires February 14, 2011 [Page 6] InternetDraft Spatial Composition August 2010 raise, are beyond the scope of this memo. 2.2. Application The composition framework [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 subpaths, or may use similar packets sent and collected separately in each subpath. 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 Interdomain composition. Requires synchronized measurement start and stop times in all sub paths, or largely overlapping, or no timing requirements. Requires assumption of subpath independence w.r.t. the metric being defined/composed, or other assumptions. Has known sources of inaccuracy/error, and identifies the sources. 2.3. Incomplete Information In practice, when measurements cannot be initiated on a subpath (and perhaps the measurement system gives up during the test interval), then there will not be a value for the subpath 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 subpath results are undefined, then the composed metric SHOULD also be recorded as undefined. 3. 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 Morton & Stephan Expires February 14, 2011 [Page 7] InternetDraft Spatial Composition August 2010 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 subpaths 3.1. Name: TypeP All metrics use the TypeP convention as described in [RFC2330]. The rest of the name is unique to each metric. 3.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 interpacket 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) Morton & Stephan Expires February 14, 2011 [Page 8] InternetDraft Spatial Composition August 2010 o S, the number of subpaths involved in the complete SrcDst path o TypeP, as defined in [RFC2330], which includes any field that may affect a packet's treatment as it traverses the network In metric names, the term <Sample> is intended to be replaced by the name of the method used to define a sample of values of parameter TstampSrc. This can be done in several ways, including: 1. Poisson: a pseudorandom Poisson process of rate lambda, whose values fall between T and Tf. The time interval between successive values of TstampSrc will then average 1/lambda, as per [RFC2330]. 2. Periodic: a periodic stream process with pseudorandom start time T0 between T and dT, and nominal interpacket interval incT, as per [RFC3432]. 3.1.2. Definition and Metric Units This section is unique for every metric. 3.1.3. Discussion and other details This section is unique for every metric. 3.1.4. Statistic: This section is unique for every metric. 3.1.5. Composition Function This section is unique for every metric. 3.1.6. Statement of Conjecture and Assumptions This section is unique for each metric. The term "ground truth" frequently used in these sections and it is defined in section 4.7 of [RFC5835]. 3.1.7. Justification of the Composition Function It is sometimes impractical to conduct active measurements between every SrcDst 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 Morton & Stephan Expires February 14, 2011 [Page 9] InternetDraft Spatial Composition August 2010 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 lowspeed access link may be understood wellenough 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 reusing measurements where they are applicable, rather than launching new measurements for every possible sourcedestination pair. 3.1.8. Sources of Deviation from the Ground Truth 3.1.8.1. Subpath List Differs from Complete Path The measurement packets, each having source and destination addresses intended for collection at edges of the subpath, 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 MultiPath and parallel (or bundled) links. Therefore, the performance estimated from the composition of subpath measurements may differ from the performance experienced by packets on the complete path. Multiple measurements employing sufficient subpath address pairs might produce bounds on the extent of this error. We also note the possibility of rerouting during a measurement interval, as it may affect the correspondence between packets traversing the complete path and the subpaths that were "involved" prior to the reroute. 3.1.8.2. Subpath 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 subpath metrics SHOULD be minimized as a source of error. 3.1.8.3. Subpaths Have Incomplete Coverage Measurements of subpath 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 Morton & Stephan Expires February 14, 2011 [Page 10] InternetDraft Spatial Composition August 2010 conducted. In this example, test packets on the previous subpath are received just before the exchange point and test packets on the next subpath are injected just after the same exchange point. Clearly, the set of subpath measurements SHOULD cover all critical network elements in the complete path. 3.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 subpaths therefore differs from the complete path. Consequently, spatial composition may produce finite estimation of a ground truth metric (see section 4.7 of [RFC5835]) between a source and a destination, even when the route between them is undefined. 3.1.9. Specific cases where the conjecture might fail This section is unique for most metrics (see the metricspecific sections). For delayrelated metrics, Oneway 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 on route (due to encapsulation), this can influence delay performance. However, the main error source may be the additional processing associated with encapsulation and encryption/decryption if not experienced or accounted for in subpath measurements. Fragmentation is a major issue for composition accuracy, since all metrics require all fragments to arrive before proceeding, and fragmented complete path performance is likely to be different from performance with nonfragmented packets and composed metrics based on nonfragmented subpath measurements. Highly manipulated routing can cause measurement error if not expected and compensated. For example, policybased MPLS routing could modify the class of service for the subpaths and complete path. 3.1.10. Application of Measurement Methodology The methodology: SHOULD use similar packets sent and collected separately in each sub path, where "similar" in this case means that the TypeP contains as many equal attributes as possible, while recognizing that there will be differences. Note that TypeP includes stream characteristics (e.g., Poisson, Periodic). Morton & Stephan Expires February 14, 2011 [Page 11] InternetDraft Spatial Composition August 2010 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 Interdomain and Intradomain composition. SHOULD have synchronized measurement time intervals in all subpaths, but largely overlapping intervals MAY suffice. Assumption of subpath independence w.r.t. the metric being defined/ composed is REQUIRED. 4. Oneway Delay Composed Metrics and Statistics 4.1. Name: TypePFiniteOnewayDelay<Sample>Stream This metric is a necessary element of Delay Composition metrics, and its definition does not formally exist elsewhere in IPPM literature. 4.1.1. Metric Parameters See the common parameters section above. 4.1.2. Definition and Metric Units Using the parameters above, we obtain the value of TypePOneway Delay singleton as per [RFC2679]. For each packet [i] that has a finite Oneway Delay (in other words, excluding packets which have undefined oneway delay): TypePFiniteOnewayDelay<Sample>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. 4.1.3. Discussion and other details The "TypePFiniteOnewayDelay" metric permits calculation of the sample mean statistic. This resolves the problem of including lost Morton & Stephan Expires February 14, 2011 [Page 12] InternetDraft Spatial Composition August 2010 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 FiniteOnewayDelay approach handles the problem of lost packets by reducing the event space. We consider conditional statistics, and estimate the mean oneway 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 oneway 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] . 4.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). 4.2. Name: TypePFiniteCompositeOnewayDelayMean This section describes a statistic based on the TypePFiniteOne wayDelay<Sample>Stream metric. 4.2.1. Metric Parameters See the common parameters section above. 4.2.2. Definition and Metric Units of the Mean Statistic We define TypePFiniteOnewayDelayMean = 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. Morton & Stephan Expires February 14, 2011 [Page 13] InternetDraft Spatial Composition August 2010 4.2.3. Discussion and other details The TypePFiniteOnewayDelayMean metric requires the conditional delay distribution described in section 5.1. 4.2.4. Statistic: This metric, a mean, does not require additional statistics. 4.2.5. Composition Function: Sum of Means The TypePFiniteCompositeOnewayDelayMean, or CompMeanDelay, for the complete Source to Destination path can be calculated from sum of the Mean Delays of all its S constituent subpaths. Then the TypePFiniteCompositeOnewayDelayMean = S  \ = CompMeanDelay = > (MeanDelay [s]) /  s = 1 where subpaths s = 1 to S are involved in the complete path. 4.2.6. Statement of Conjecture and Assumptions The mean of a sufficiently large stream of packets measured on each subpath 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 oneway delay distributions of the subpaths and the complete path are continuous. The mean of multimodal distributions have the unfortunate property that such a value may never occur. 4.2.7. Justification of the Composition Function See the common section. 4.2.8. Sources of Deviation from the Ground Truth See the common section. Morton & Stephan Expires February 14, 2011 [Page 14] InternetDraft Spatial Composition August 2010 4.2.9. Specific cases where the conjecture might fail If any of the subpath distributions are multimodal, 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 a sufficiently robust statistic to produce a reliable estimate, or to be useful even if it can be measured. If a link contributing nonnegligible delay is erroneously included or excluded, the composition will be in error. 4.2.10. Application of Measurement Methodology The requirements of the common section apply here as well. 4.3. Name: TypePFiniteCompositeOnewayDelayMinimum This section describes is a statistic based on the TypePFiniteOne wayDelay<Sample>Stream metric, and the composed metric based on that statistic. 4.3.1. Metric Parameters See the common parameters section above. 4.3.2. Definition and Metric Units of the Minimum Statistic We define TypePFiniteOnewayDelayMinimum = = 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. Morton & Stephan Expires February 14, 2011 [Page 15] InternetDraft Spatial Composition August 2010 4.3.3. Discussion and other details The TypePFiniteOnewayDelayMinimum metric requires the conditional delay distribution described in section 5.1.3. 4.3.4. Statistic: This metric, a minimum, does not require additional statistics. 4.3.5. Composition Function: Sum of Minima The TypePFiniteCompositeOnewayDelayMinimum, or CompMinDelay, for the complete Source to Destination path can be calculated from sum of the Minimum Delays of all its S constituent subpaths. Then the TypePFiniteCompositeOnewayDelayMinimum = S  \ = CompMinDelay = > (MinDelay [s]) /  s = 1 4.3.6. Statement of Conjecture and Assumptions The minimum of a sufficiently large stream of packets measured on each subpath 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 oneway delay distributions of the subpaths and the complete path are continuous. 4.3.7. Justification of the Composition Function See the common section. 4.3.8. Sources of Deviation from the Ground Truth See the common section. Morton & Stephan Expires February 14, 2011 [Page 16] InternetDraft Spatial Composition August 2010 4.3.9. Specific cases where the conjecture might fail If the routing on any of the subpaths 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. 4.3.10. Application of Measurement Methodology The requirements of the common section apply here as well. 5. Loss Metrics and Statistics 5.1. TypePCompositeOnewayPacketLossEmpiricalProbability 5.1.1. Metric Parameters: Same as section 4.1.1. 5.1.2. Definition and Metric Units Using the parameters above, we obtain the value of TypePOneway PacketLoss 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. 5.1.3. Discussion and other details None. 5.1.4. Statistic: TypePOnewayPacketLossEmpiricalProbability 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: Morton & Stephan Expires February 14, 2011 [Page 17] InternetDraft Spatial Composition August 2010 TypePOnewayPacketLossEmpiricalProbability = M  1 \ = Ep =  * > (L[m]) M /  m = 1 where all packets m = 1 through M have a value for L. 5.1.5. Composition Function: Composition of Empirical Probabilities The TypePOnewayCompositePacketLossEmpiricalProbability, or CompEp for the complete Source to Destination path can be calculated by combining Ep of all its constituent subpaths (Ep1, Ep2, Ep3, ... Epn) as TypePCompositeOnewayPacketLossEmpiricalProbability = = 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 subpath s for that measurement interval is undefined. 5.1.6. Statement of Conjecture and Assumptions The empirical probability of loss calculated on a sufficiently large stream of packets measured on each subpath 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 subpath probabilities may be combined to produce an estimate of the complete path empirical loss probability. 5.1.7. Justification of the Composition Function See the common section. 5.1.8. Sources of Deviation from the Ground Truth See the common section. 5.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. Morton & Stephan Expires February 14, 2011 [Page 18] InternetDraft Spatial Composition August 2010 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 borne worm, loss due to queue overflow in one network may help another network to carry its traffic without loss. 5.1.10. Application of Measurement Methodology See the common section. 6. Delay Variation Metrics and Statistics 6.1. Name: TypePOnewaypdvrefmin<Sample>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 (with the exception of [RFC5481] . 6.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 packetpair computation of this metric. F(current packet), the first packet of the pair, MUST have a valid TypePFiniteOnewayDelay less than Tmax (in other words, excluding packets which have undefined oneway delay) and MUST have been transmitted during the interval T, Tf. The second packet in the pair, F(min_delay packet) MUST be the packet with the minimum valid value of TypePFiniteOnewayDelay for the stream, in addition to the criteria for F(current packet). If multiple packets have equal minimum TypePFiniteOnewayDelay values, then the value for the earliest arriving packet SHOULD be Morton & Stephan Expires February 14, 2011 [Page 19] InternetDraft Spatial Composition August 2010 used. o MinDelay, the TypePFiniteOnewayDelay value for F(min_delay packet) given above. o N, the number of packets received at the Destination meeting the F(current packet) criteria. 6.1.2. Definition and Metric Units Using the definition above in section 5.1.2, we obtain the value of TypePFiniteOnewayDelay<Sample>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: TypePOnewaypdvrefmin<Sample>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. 6.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]. 6.1.4. Statistics: Mean, Variance, Skewness, Quantile We define the mean PDV as follows (where all packets n = 1 through N have a value for PDV[n]): Morton & Stephan Expires February 14, 2011 [Page 20] InternetDraft Spatial Composition August 2010 TypePOnewaypdvrefminMean = MeanPDV = N  1 \  * > (PDV[n]) N /  n = 1 We define the variance of PDV as follows: TypePOnewaypdvrefminVariance = VarPDV = N  1 \ 2  > (PDV[n]  MeanPDV) (N  1) /  n = 1 We define the skewness of PDV as follows: TypePOnewaypdvrefminSkewness = SkewPDV = N  3 \ / \ >  PDV[n] MeanPDV  / \ /  n = 1  / \  ( 3/2 )  \ (N  1) * VarPDV / (see Appendix X of [Y.1541] for additional background information). We define the Quantile of the PDVRefMin sample as the value where the specified fraction of singletons is less than the given value. 6.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 subpath delay variation distributions. Morton & Stephan Expires February 14, 2011 [Page 21] InternetDraft Spatial Composition August 2010 6.1.5.1. Approximate Convolution The TypePFiniteOnewayDelay<Sample>Stream samples from each subpath are summarized as a histogram with 1 ms bins representing the oneway delay distribution. From [Stats], the distribution of the sum of independent random variables can be derived using the relation: TypePCompositeOnewaypdvrefminquantilea = . . / / P(X + Y + Z <= a) =   P(X <= ayz) * P(Y = y) * P(Z = z) dy dz / / ` ` z y Note that dy and dz indicate partial integration above, and that y and z are the integration variables. Also, the probablility of an outcome is indicated by the symbol P(outcome). where X, Y, and Z are random variables representing the delay variation distributions of the subpaths of the complete path (in this case, there are three subpaths), and a is the quantile of interest. This relation can be used to compose a quantile of interest for the complete path from the subpath delay distributions. The histograms with 1 ms bins are discrete approximations of the delay distributions. 6.1.5.2. Normal Power Approximation TypePOnewayCompositepdvrefminNPA for the complete Source to Destination path can be calculated by combining statistics of all the constituent subpaths in the process described in [Y.1541] clause 8 and Appendix X. 6.1.6. Statement of Conjecture and Assumptions The delay distribution of a sufficiently large stream of packets measured on each subpath during the interval [T, Tf] will be sufficiently stationary and the subpath distributions themselves are sufficiently independent, so that summary information describing the subpath distributions can be combined to estimate the delay distribution of complete path. It is assumed that the oneway delay distributions of the subpaths Morton & Stephan Expires February 14, 2011 [Page 22] InternetDraft Spatial Composition August 2010 and the complete path are continuous. 6.1.7. Justification of the Composition Function See the common section. 6.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. 6.1.9. Specific cases where the conjecture might fail If the delay distributions of the subpaths are somehow correlated, then neither of these composition functions will be reliable estimators of the complete path distribution. In practice, subpath delay distributions with extreme outliers have increased the error of the composed metric estimate. 6.1.10. Application of Measurement Methodology See the common section. 7. Security Considerations 7.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 the destination and/or the intervening network(s). Administrators of source, destination, and the intervening network(s) should establish bilateral or multilateral 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 Morton & Stephan Expires February 14, 2011 [Page 23] InternetDraft Spatial Composition August 2010 escalation procedures defined between the affected parties. 7.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. 7.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. 8. IANA Considerations Metrics defined in IETF are typically registered in the IANA IPPM METRICS REGISTRY as described in initial version of the registry [RFC4148]. IANA is asked to register the following metrics in the IANAIPPM METRICSREGISTRYMIB: ietfFiniteOneWayDelayStream OBJECTIDENTITY STATUS current DESCRIPTION "TypePFiniteOnewayDelayStream" REFERENCE "Reference "RFCyyyy, section 4.1."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfFiniteOneWayDelayMean OBJECTIDENTITY Morton & Stephan Expires February 14, 2011 [Page 24] InternetDraft Spatial Composition August 2010 STATUS current DESCRIPTION "TypePFiniteOnewayDelayMean" REFERENCE "Reference "RFCyyyy, section 4.2."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfCompositeOneWayDelayMean OBJECTIDENTITY STATUS current DESCRIPTION "TypePFiniteCompositeOnewayDelayMean" REFERENCE "Reference "RFCyyyy, section 4.2.5."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfFiniteOneWayDelayMinimum OBJECTIDENTITY STATUS current DESCRIPTION "TypePFiniteOnewayDelayMinimum" REFERENCE "Reference "RFCyyyy, section 4.3.2."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfCompositeOneWayDelayMinimum OBJECTIDENTITY STATUS current DESCRIPTION "TypePFiniteCompositeOnewayDelayMinimum" REFERENCE "Reference "RFCyyyy, section 4.3."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfOneWayPktLossEmpiricProb OBJECTIDENTITY STATUS current Morton & Stephan Expires February 14, 2011 [Page 25] InternetDraft Spatial Composition August 2010 DESCRIPTION "TypePOnewayPacketLossEmpiricalProbability" REFERENCE "Reference "RFCyyyy, section 5.1.4"  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfCompositeOneWayPktLossEmpiricProb OBJECTIDENTITY STATUS current DESCRIPTION "TypePCompositeOnewayPacketLossEmpiricalProbability" REFERENCE "Reference "RFCyyyy, section 5.1."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfOneWayPdvRefminStream OBJECTIDENTITY STATUS current DESCRIPTION "TypePOnewaypdvrefminStream" REFERENCE "Reference "RFCyyyy, section 6.1."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfOneWayPdvRefminMean OBJECTIDENTITY STATUS current DESCRIPTION "TypePOnewaypdvrefminMean" REFERENCE "Reference "RFCyyyy, section 6.1.4."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfOneWayPdvRefminVariance OBJECTIDENTITY STATUS current DESCRIPTION "TypePOnewaypdvrefminVariance" REFERENCE Morton & Stephan Expires February 14, 2011 [Page 26] InternetDraft Spatial Composition August 2010 "Reference "RFCyyyy, section 6.1.4."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfOneWayPdvRefminSkewness OBJECTIDENTITY STATUS current DESCRIPTION "TypePOnewaypdvrefminSkewness" REFERENCE "Reference "RFCyyyy, section 6.1.4."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfCompositeOneWayPdvRefminQtil OBJECTIDENTITY STATUS current DESCRIPTION "TypePCompositeOnewaypdvrefminquantilea" REFERENCE "Reference "RFCyyyy, section 6.1.5.1."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn ietfCompositeOneWayPdvRefminNPA OBJECTIDENTITY STATUS current DESCRIPTION "TypePOnewayCompositepdvrefminNPA" REFERENCE "Reference "RFCyyyy, section 6.1.5.2."  RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { ianaIppmMetrics nn }  IANA assigns nn 9. Contributors and Acknowledgements The following people have contributed useful ideas, suggestions, or the text of sections that have been incorporated into this memo: Morton & Stephan Expires February 14, 2011 [Page 27] InternetDraft Spatial Composition August 2010  Phil Chimento <vze275m9@verizon.net>  Reza Fardid <RFardid@cariden.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> A long time ago, in a galaxy far, far away (Minneapolis), Will Leland suggested the simple and elegant TypePFiniteOnewayDelay concept. Thanks Will. Yaakov Stein and Donald McLachlan also provided useful comments along the way. 10. References 10.1. Normative References [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 Oneway Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A Oneway 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. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005. Morton & Stephan Expires February 14, 2011 [Page 28] InternetDraft Spatial Composition August 2010 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010. 10.2. Informative References [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009. [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009. [Stats] McGrawHill NY NY, "Introduction to the Theory of Statistics, 3rd Edition,", 1974. [Y.1540] ITUT Recommendation Y.1540, "Internet protocol data communication service  IP packet transfer and availability performance parameters", November 2007. [Y.1541] ITUT Recommendation Y.1541, "Network Performance Objectives for IPbased 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/ Morton & Stephan Expires February 14, 2011 [Page 29] InternetDraft Spatial Composition August 2010 Emile Stephan France Telecom Division R&D 2 avenue Pierre Marzin Lannion, F22307 France Phone: Fax: +33 2 96 05 18 52 Email: emile.stephan@orangeftgroup.com URI: Morton & Stephan Expires February 14, 2011 [Page 30]