 1/draftietfippmspatialcomposition15.txt 20100814 22:12:10.000000000 +0200
+++ 2/draftietfippmspatialcomposition16.txt 20100814 22:12:10.000000000 +0200
@@ 1,19 +1,19 @@
Network Working Group A. Morton
InternetDraft AT&T Labs
Intended status: Standards Track E. Stephan
Expires: January 3, 2011 France Telecom Division R&D
 July 2, 2010
+Expires: February 14, 2011 France Telecom Division R&D
+ August 13, 2010
Spatial Composition of Metrics
 draftietfippmspatialcomposition15
+ 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
@@ 36,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 January 3, 2011.
+ This InternetDraft will expire on February 14, 2011.
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
@@ 85,85 +85,84 @@
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:
 TypePFiniteOnewayDelayPoisson/PeriodicStream . . . 12
+ 4.1. Name: TypePFiniteOnewayDelayStream . . . . 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 . . . . . . . . . . . . . 13
 4.2.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 13
 4.2.5. Composition Function: Sum of Means . . . . . . . . . . 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 . . . . 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 . . . . . . . . . . . . . 15
 4.3.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 15
 4.3.5. Composition Function: Sum of Minima . . . . . . . . . 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 . . . . 16
 4.3.10. Application of Measurement Methodology . . . . . . . . 16
 5. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 16
 5.1. TypePCompositeOnewayPacketLossEmpiricalProbability 16
+ 4.3.9. Specific cases where the conjecture might fail . . . . 17
+ 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 . . . . . . . . . . . . . . . . . . . . 17
+ 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 . . . . . . . . 18
 6. Delay Variation Metrics and Statistics . . . . . . . . . . . . 18
 6.1. Name: TypePOnewaypdvrefminPoisson/PeriodicStream . 18
+ 5.1.10. Application of Measurement Methodology . . . . . . . . 19
+ 6. Delay Variation Metrics and Statistics . . . . . . . . . . . . 19
+ 6.1. Name: TypePOnewaypdvrefminStream . . . . . 19
6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 19
 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 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 . . . . . . 22
 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 22
 6.1.9. Specific cases where the conjecture might fail . . . . 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 . . . . . . . . . . . . . . . . 23
 7.3. Interference with the metrics . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
 10.2. Informative References . . . . . . . . . . . . . . . . . . 28
 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
+ Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
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.
@@ 266,22 +265,22 @@
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 time intervals in all subpaths, or
 largely overlapping, or no timing requirements.
+ 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),
@@ 348,39 +347,54 @@
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 the network
+ In metric names, the term 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.
+ 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
of the network. For example, it may not be possible to collect the
@@ 436,22 +450,22 @@
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 between a source and a destination, even when the
 route between them is undefined.
+ 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,
@@ 490,38 +504,38 @@
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: TypePFiniteOnewayDelayPoisson/PeriodicStream
+4.1. Name: TypePFiniteOnewayDelayStream
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):
 TypePFiniteOnewayDelayPoisson/PeriodicStream[i] =
+ TypePFiniteOnewayDelayStream[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
@@ 542,35 +556,35 @@
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
 wayDelayPoisson/PeriodicStream metric.
+ wayDelayStream 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])
+ = 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.
@@ 579,31 +593,31 @@
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.
+ 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])
+ = 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
@@ 636,22 +650,22 @@
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
 wayDelayPoisson/PeriodicStream metric, and the composed metric
 based on that statistic.
+ wayDelayStream 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 =
@@ 671,30 +685,31 @@
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,
+ 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])
+ = 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
@@ 737,46 +753,48 @@
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:
TypePOnewayPacketLossEmpiricalProbability =
M

1 \
 Ep =  * > (L[m])
+ = 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)}
+ = 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,
@@ 808,25 +826,26 @@
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: TypePOnewaypdvrefminPoisson/PeriodicStream
+6.1. Name: TypePOnewaypdvrefminStream
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.
+ 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.
@@ 848,25 +867,25 @@
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
 TypePFiniteOnewayDelayPoisson/PeriodicStream[n], the singleton
 for each packet[i] in the stream (a.k.a. FiniteDelay[i]).
+ TypePFiniteOnewayDelayStream[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] =
+ above: TypePOnewaypdvrefminStream[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
@@ 911,49 +930,59 @@
\ / \
>  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.
6.1.5.1. Approximate Convolution
 The TypePFiniteOnewayDelayPoisson/PeriodicStream samples from
 each subpath are summarized as a histogram with 1 ms bins
 representing the oneway delay distribution.
+ The TypePFiniteOnewayDelayStream 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. Note dy and dz indicate partial integration here.This
 relation can be used to compose a quantile of interest for the
+ 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.
@@ 1014,21 +1043,21 @@
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
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
+ 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
@@ 1048,143 +1077,141 @@
[RFC4148].
IANA is asked to register the following metrics in the IANAIPPM
METRICSREGISTRYMIB:
ietfFiniteOneWayDelayStream OBJECTIDENTITY
STATUS current
DESCRIPTION
"TypePFiniteOnewayDelayStream"
REFERENCE
 "Reference "RFCyyyy, section 5.1."
+ "Reference "RFCyyyy, section 4.1."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
::= { ianaIppmMetrics nn }  IANA assigns nn
ietfFiniteOneWayDelayMean OBJECTIDENTITY
STATUS current
DESCRIPTION
"TypePFiniteOnewayDelayMean"
REFERENCE
 "Reference "RFCyyyy, section 5.2."
+ "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 5.2.5."
+ "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 5.3.2."
+ "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 5.3.5."
+ "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
DESCRIPTION
"TypePOnewayPacketLossEmpiricalProbability"
REFERENCE
 "Reference "RFCyyyy, section 6.1.4."
+ "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 6.1.5."
+ "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 7.1."
+ "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 7.1.4."
+ "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
 "Reference "RFCyyyy, section 7.1.4."
+ "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 7.1.4."
+ "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 7.1.5.1."
+ "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 7.1.5.2."
+ "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:
 Phil Chimento
@@ 1236,23 +1263,22 @@
[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.
 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance
 Metrics (IPPM): Spatial and Multicast", RFC 5644,
 October 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.