 1/draftietfippmspatialcomposition11.txt 20100531 15:12:58.000000000 +0200
+++ 2/draftietfippmspatialcomposition12.txt 20100531 15:12:58.000000000 +0200
@@ 1,29 +1,30 @@
Network Working Group A. Morton
InternetDraft AT&T Labs
Intended status: Standards Track E. Stephan
Expires: October 16, 2010 France Telecom Division R&D
 April 14, 2010
+Expires: December 1, 2010 France Telecom Division R&D
+ May 30, 2010
Spatial Composition of Metrics
 draftietfippmspatialcomposition11
+ draftietfippmspatialcomposition12
Abstract
 This memo utilizes IPPM 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.
+ 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".
@@ 35,21 +36,21 @@
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 October 16, 2010.
+ This InternetDraft will expire on December 1, 2010.
Copyright Notice
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
@@ 83,64 +84,64 @@
4.1. Name: TypeP . . . . . . . . . . . . . . . . . . . . . . . 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
+ 4.1.10. Application of Measurement Methodology . . . . . . . . 12
5. Oneway Delay Composed Metrics and Statistics . . . . . . . . 12
5.1. Name:
TypePFiniteOnewayDelayPoisson/PeriodicStream . . . 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.3. Discussion and other details . . . . . . . . . . . . . 13
5.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Name: TypePFiniteCompositeOnewayDelayMean . . . . . 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.7. Justification of the Composition Function . . . . . . 15
+ 5.2.8. Sources of Deviation from the Ground Truth . . . . . . 15
5.2.9. Specific cases where the conjecture might fail . . . . 15
5.2.10. Application of Measurement Methodology . . . . . . . . 15
5.3. Name: TypePFiniteCompositeOnewayDelayMinimum . . . 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.7. Justification of the Composition Function . . . . . . 17
+ 5.3.8. Sources of Deviation from the Ground Truth . . . . . . 17
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. TypePCompositeOnewayPacketLossEmpiricalProbability 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:
 TypePOnewayPacketLossEmpiricalProbability . . . 17
+ TypePOnewayPacketLossEmpiricalProbability . . . 18
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.8. Sources of Deviation from the Ground Truth . . . . . . 19
+ 6.1.9. Specific cases where the conjecture might fail . . . . 19
6.1.10. Application of Measurement Methodology . . . . . . . . 19
7. Delay Variation Metrics and Statistics . . . . . . . . . . . . 19
7.1. Name: TypePOnewaypdvrefminPoisson/PeriodicStream . 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
@@ 150,21 +151,21 @@
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
+ 13.2. Informative References . . . . . . . . . . . . . . . . . . 27
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
@@ 229,21 +230,21 @@
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
Oneway 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
+ destination of 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 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
@@ 258,23 +259,22 @@
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 and passive
 (recognizing that PSAMP WG will define capabilities to sample
 packets to support measurement).
+ 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
raise, are beyond the scope of this memo.
3.2. Application
The new composition framework [RFC5835] requires the specification of
@@ 337,22 +337,22 @@
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 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),
@@ 363,20 +363,23 @@
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 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 network
+
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:
@@ 461,36 +464,46 @@
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 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 (due to
 encapsulation for security reasons), this will influence delay
 performance.
+ 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 compostion accuracy, since all
+ 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.
+
4.1.10. Application of Measurement Methodology
The methodology:
SHOULD use similar packets sent and collected separately in each sub
 path.
+ 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).
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.
@@ 598,49 +609,49 @@
Then the
TypePFiniteCompositeOnewayDelayMean =
S

\
CompMeanDelay = > (MeanDelay [s])
/

s = 1
 where subpaths s = 1 to S are invloved in the complete path.
+ where subpaths s = 1 to S are involved in the complete path.
5.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 bimodal
+ and the complete path are continuous. The mean of multimodal
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 subpath 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.
+ 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 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.
5.2.10. Application of Measurement Methodology
The requirements of the common section apply here as well.
@@ 809,22 +818,20 @@
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: TypePOnewaypdvrefminPoisson/PeriodicStream
This packet delay variation (PDV) metric is a necessary element of
Composed Delay Variation metrics, and its definition does not
@@ 837,35 +844,36 @@
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(first 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(second packet) MUST be the packet with the
 minimum valid value of TypePFiniteOnewayDelay for the stream,
 in addition to the criteria for F(first packet). If multiple
 packets have equal minimum TypePFiniteOnewayDelay values,
 then the value for the earliest arriving packet SHOULD be used.
+ 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
+ used.
 o MinDelay, the TypePFiniteOnewayDelay value for F(second
+ 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(first packet) criteria.
+ F(current packet) criteria.
7.1.2. Definition and Metric Units
Using the definition above in section 5.1.2, we obtain the value of
TypePFiniteOnewayDelayPoisson/PeriodicStream[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: TypePOnewaypdvrefminPoisson/PeriodicStream[n] =
@@ 919,22 +927,22 @@
\ / \
>  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.
+ We define the Quantile of the PDVRefMin 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 subpath delay variation distributions.
7.1.5.1. Approximate Convolution
@@ 1054,32 +1062,37 @@
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 TypePFiniteOnewayDelay concept.
Thanks Will.
+ Yaakov Stein and Donald McLachlan also provided useful comments along
+ the way.
+
11. Issues (Open and Closed)
+ This section to be removed at publication.
+
>>>>>>>>>>>>Issue:
Is Section 4.1.8.4 really describing a new error case, about
Alternate Routing? Or does Section 4.1.8.1 on subpath differences
cover it all?

RESOLUTION: The section was reworded 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 Oneway 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
@@ 1142,23 +1155,31 @@
[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.
+ [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.
+
[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric
Composition", RFC 5835, April 2010.
13.2. Informative References
[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance
Metrics (IPPM): Spatial and Multicast", RFC 5644,
October 2009.
[Stats] McGrawHill NY NY, "Introduction to the Theory of