draft-ietf-ippm-delay-var-as-01.txt   draft-ietf-ippm-delay-var-as-02.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational B. Claise Intended status: Informational B. Claise
Expires: January 14, 2009 Cisco Systems, Inc. Expires: July 12, 2009 Cisco Systems, Inc.
July 13, 2008 January 8, 2009
Packet Delay Variation Applicability Statement Packet Delay Variation Applicability Statement
draft-ietf-ippm-delay-var-as-01 draft-ietf-ippm-delay-var-as-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2009. This Internet-Draft will expire on July 12, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
Packet delay variation metrics appear in many different standards Packet delay variation metrics appear in many different standards
documents. The metric definition in RFC 3393 has considerable documents. The metric definition in RFC 3393 has considerable
flexibility, and it allows multiple formulations of delay variation flexibility, and it allows multiple formulations of delay variation
through the specification of different packet selection functions. through the specification of different packet selection functions.
Although flexibility provides wide coverage and room for new ideas, Although flexibility provides wide coverage and room for new ideas,
it can make comparisons of independent implementations more it can make comparisons of independent implementations more
skipping to change at page 2, line 14 skipping to change at page 3, line 7
best matched to particular conditions and tasks. best matched to particular conditions and tasks.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background Literature in IPPM and Elsewhere . . . . . . . 5 1.1. Background Literature in IPPM and Elsewhere . . . . . . . 6
1.2. Organization of the Memo . . . . . . . . . . . . . . . . . 6 1.2. Organization of the Memo . . . . . . . . . . . . . . . . . 7
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 6 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 7
3. Brief Descriptions of Delay Variation Uses . . . . . . . . . . 7 3. Brief Descriptions of Delay Variation Uses . . . . . . . . . . 8
3.1. Inferring Queue Occupation on a Path . . . . . . . . . . . 7 3.1. Inferring Queue Occupation on a Path . . . . . . . . . . . 8
3.2. Determining De-jitter Buffer Size . . . . . . . . . . . . 8 3.2. Determining De-jitter Buffer Size . . . . . . . . . . . . 9
3.3. Spatial Composition . . . . . . . . . . . . . . . . . . . 9 3.3. Spatial Composition . . . . . . . . . . . . . . . . . . . 10
3.4. Service Level Comparison . . . . . . . . . . . . . . . . . 9 3.4. Service Level Comparison . . . . . . . . . . . . . . . . . 11
3.5. Application-Layer FEC Design . . . . . . . . . . . . . . . 10 3.5. Application-Layer FEC Design . . . . . . . . . . . . . . . 11
4. Formulations of IPDV and PDV . . . . . . . . . . . . . . . . . 10 4. Formulations of IPDV and PDV . . . . . . . . . . . . . . . . . 11
4.1. IPDV: Inter-Packet Delay Variation . . . . . . . . . . . . 10 4.1. IPDV: Inter-Packet Delay Variation . . . . . . . . . . . . 11
4.2. PDV: Packet Delay Variation . . . . . . . . . . . . . . . 11 4.2. PDV: Packet Delay Variation . . . . . . . . . . . . . . . 12
4.3. A "Point" about Measurement Points . . . . . . . . . . . . 11 4.3. A "Point" about Measurement Points . . . . . . . . . . . . 12
4.4. Examples and Initial Comparisons . . . . . . . . . . . . . 12 4.4. Examples and Initial Comparisons . . . . . . . . . . . . . 13
5. Survey of Earlier Comparisons . . . . . . . . . . . . . . . . 13 5. Survey of Earlier Comparisons . . . . . . . . . . . . . . . . 14
5.1. Demichelis' Comparison . . . . . . . . . . . . . . . . . . 13 5.1. Demichelis' Comparison . . . . . . . . . . . . . . . . . . 14
5.2. Ciavattone et al. . . . . . . . . . . . . . . . . . . . . 14 5.2. Ciavattone et al. . . . . . . . . . . . . . . . . . . . . 15
5.3. IPPM List Discussion from 2000 . . . . . . . . . . . . . . 15 5.3. IPPM List Discussion from 2000 . . . . . . . . . . . . . . 16
5.4. Y.1540 Appendix II . . . . . . . . . . . . . . . . . . . . 17 5.4. Y.1540 Appendix II . . . . . . . . . . . . . . . . . . . . 18
5.5. Clark's ITU-T SG 12 Contribution . . . . . . . . . . . . . 17 5.5. Clark's ITU-T SG 12 Contribution . . . . . . . . . . . . . 18
6. Additional Properties and Comparisons . . . . . . . . . . . . 17 6. Additional Properties and Comparisons . . . . . . . . . . . . 18
6.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Path Changes . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Path Changes . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.1. Lossless Path Change . . . . . . . . . . . . . . . . . 19 6.2.1. Lossless Path Change . . . . . . . . . . . . . . . . . 20
6.2.2. Path Change with Loss . . . . . . . . . . . . . . . . 20 6.2.2. Path Change with Loss . . . . . . . . . . . . . . . . 21
6.3. Clock Stability and Error . . . . . . . . . . . . . . . . 21 6.3. Clock Stability and Error . . . . . . . . . . . . . . . . 22
6.4. Spatial Composition . . . . . . . . . . . . . . . . . . . 23 6.4. Spatial Composition . . . . . . . . . . . . . . . . . . . 24
6.5. Reporting a Single Number (SLA) . . . . . . . . . . . . . 23 6.5. Reporting a Single Number (SLA) . . . . . . . . . . . . . 24
6.6. Jitter in RTCP Reports . . . . . . . . . . . . . . . . . . 24 6.6. Jitter in RTCP Reports . . . . . . . . . . . . . . . . . . 25
6.7. MAPDV2 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.7. MAPDV2 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.8. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 25 6.8. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 26
7. Applicability of the Delay Variation Forms and 7. Applicability of the Delay Variation Forms and
Recommendations . . . . . . . . . . . . . . . . . . . . . . . 26 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1.1. Inferring Queue Occupancy . . . . . . . . . . . . . . 26 7.1.1. Inferring Queue Occupancy . . . . . . . . . . . . . . 27
7.1.2. Determining De-jitter Buffer Size (and FEC Design) . . 26 7.1.2. Determining De-jitter Buffer Size (and FEC Design) . . 27
7.1.3. Spatial Composition . . . . . . . . . . . . . . . . . 27 7.1.3. Spatial Composition . . . . . . . . . . . . . . . . . 28
7.1.4. Service Level Specification: Reporting a Single 7.1.4. Service Level Specification: Reporting a Single
Number . . . . . . . . . . . . . . . . . . . . . . . . 27 Number . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. Challenging Circumstances . . . . . . . . . . . . . . . . 27 7.2. Challenging Circumstances . . . . . . . . . . . . . . . . 28
7.2.1. Clock and Storage Issues . . . . . . . . . . . . . . . 27 7.2.1. Clock and Storage Issues . . . . . . . . . . . . . . . 28
7.2.2. Frequent Path Changes . . . . . . . . . . . . . . . . 28 7.2.2. Frequent Path Changes . . . . . . . . . . . . . . . . 29
7.2.3. Frequent Loss . . . . . . . . . . . . . . . . . . . . 28 7.2.3. Frequent Loss . . . . . . . . . . . . . . . . . . . . 29
7.2.4. Load Balancing . . . . . . . . . . . . . . . . . . . . 28 7.2.4. Load Balancing . . . . . . . . . . . . . . . . . . . . 29
7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Measurement Considerations . . . . . . . . . . . . . . . . . . 29 8. Measurement Considerations . . . . . . . . . . . . . . . . . . 30
8.1. Measurement Stream Characteristics . . . . . . . . . . . . 30 8.1. Measurement Stream Characteristics . . . . . . . . . . . . 31
8.2. Measurement Devices . . . . . . . . . . . . . . . . . . . 31 8.2. Measurement Devices . . . . . . . . . . . . . . . . . . . 32
8.3. Units of Measurement . . . . . . . . . . . . . . . . . . . 31 8.3. Units of Measurement . . . . . . . . . . . . . . . . . . . 32
8.4. Test Duration . . . . . . . . . . . . . . . . . . . . . . 32 8.4. Test Duration . . . . . . . . . . . . . . . . . . . . . . 33
8.5. Clock Sync Options . . . . . . . . . . . . . . . . . . . . 32 8.5. Clock Sync Options . . . . . . . . . . . . . . . . . . . . 33
8.6. Distinguishing Long Delay from Loss . . . . . . . . . . . 32 8.6. Distinguishing Long Delay from Loss . . . . . . . . . . . 33
8.7. Accounting for Packet Reordering . . . . . . . . . . . . . 33 8.7. Accounting for Packet Reordering . . . . . . . . . . . . . 34
8.8. Results Representation and Reporting . . . . . . . . . . . 33 8.8. Results Representation and Reporting . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
12. Appendix on Calculating the D(min) in PDV . . . . . . . . . . 34 12. Appendix on Calculating the D(min) in PDV . . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.1. Normative References . . . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36
13.2. Informative References . . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39
1. Introduction 1. Introduction
There are many ways to formulate packet delay variation metrics for There are many ways to formulate packet delay variation metrics for
the Internet and other packet-based networks. The IETF itself has the Internet and other packet-based networks. The IETF itself has
several specifications for delay variation [RFC3393], sometimes several specifications for delay variation [RFC3393], sometimes
called jitter [RFC3550] or even inter-arrival jitter [RFC3550], and called jitter [RFC3550] or even inter-arrival jitter [RFC3550], and
these have achieved wide adoption. The International these have achieved wide adoption. The International
Telecommunication Union - Telecommunication Standardization Sector Telecommunication Union - Telecommunication Standardization Sector
(ITU-T) has also recommended several delay variation metrics (called (ITU-T) has also recommended several delay variation metrics (called
skipping to change at page 4, line 50 skipping to change at page 5, line 50
The industry has predominantly implemented two specific formulations The industry has predominantly implemented two specific formulations
of delay variation (for one survey of the situation, of delay variation (for one survey of the situation,
see[Krzanowski]): see[Krzanowski]):
1. Inter-Packet Delay Variation, IPDV, where the reference is the 1. Inter-Packet Delay Variation, IPDV, where the reference is the
previous packet in the stream (according to sending sequence), previous packet in the stream (according to sending sequence),
and the reference changes for each packet in the stream. and the reference changes for each packet in the stream.
Properties of variation are coupled with packet sequence in this Properties of variation are coupled with packet sequence in this
formulation. This form was called Instantaneous Packet Delay formulation. This form was called Instantaneous Packet Delay
Variation in early IETF contributions. Variation in early IETF contributions, and is similar to the
packet spacing difference metric used for interarrival jitter
calculations in [RFC3550].
2. Packet Delay Variation, PDV, where a single reference is chosen 2. Packet Delay Variation, PDV, where a single reference is chosen
from the stream based on specific criteria. The most common from the stream based on specific criteria. The most common
criterion for the reference is the packet with the minimum delay criterion for the reference is the packet with the minimum delay
in the sample. This term derives its name from a similar in the sample. This term derives its name from a similar
definition for Cell Delay Variation, an ATM performance metric. definition for Cell Delay Variation, an ATM performance metric
[I.356].
It is important to note that the authors of relevant standards for It is important to note that the authors of relevant standards for
delay variation recognized there are many different users with delay variation recognized there are many different users with
varying needs, and allowed sufficient flexibility to formulate varying needs, and allowed sufficient flexibility to formulate
several metrics with different properties. Therefore, the comparison several metrics with different properties. Therefore, the comparison
is not so much between standards bodies or their specifications as it is not so much between standards bodies or their specifications as it
is between specific formulations of delay variation. Both Inter- is between specific formulations of delay variation. Both Inter-
Packet Delay Variation and Packet Delay Variation are compliant with Packet Delay Variation and Packet Delay Variation are compliant with
[RFC3393], because different packet selection functions will produce [RFC3393], because different packet selection functions will produce
either form. either form.
skipping to change at page 5, line 37 skipping to change at page 6, line 38
the published specifications of other relevant standards the published specifications of other relevant standards
organizations. organizations.
The IPPM framework [RFC2330] provides a background for this memo and The IPPM framework [RFC2330] provides a background for this memo and
other IPPM RFCs. Key terms such as singleton, sample, and statistic other IPPM RFCs. Key terms such as singleton, sample, and statistic
are defined there, along with methods of collecting samples (Poisson are defined there, along with methods of collecting samples (Poisson
streams), time related issues, and the "packet of Type-P" convention. streams), time related issues, and the "packet of Type-P" convention.
There are two fundamental and related metrics that can be applied to There are two fundamental and related metrics that can be applied to
every packet transfer attempt: one-way loss [RFC2680] and one-way every packet transfer attempt: one-way loss [RFC2680] and one-way
delay [RFC2679]. Lost and delayed packets are separated by a waiting delay [RFC2679]. The metrics use a waiting time threshold to
time threshold. Packets that arrive at the measurement destination distinguish between lost and delayed packets. Packets that arrive at
within their waiting time have finite delay and are not lost. the measurement destination within their waiting time have finite
Otherwise, packets are designated lost and their delay is undefined. delay and are not lost. Otherwise, packets are designated lost and
Guidance on setting the waiting time threshold may be found in their delay is undefined. Guidance on setting the waiting time
[RFC2680] and [I-D.morton-ippm-reporting-metrics]. threshold may be found in [RFC2680] and
[I-D.morton-ippm-reporting-metrics].
Another fundamental metric is packet reordering as specified in Another fundamental metric is packet reordering as specified in
[RFC4737]. The reordering metric was defined to be "orthogonal" to [RFC4737]. The reordering metric was defined to be "orthogonal" to
packet loss. In other words, the gap in a packet sequence caused by packet loss. In other words, the gap in a packet sequence caused by
loss does not result in reordered packets, but a re-arrangement of loss does not result in reordered packets, but a re-arrangement of
packet arrivals from their sending order constitutes reordering. packet arrivals from their sending order constitutes reordering.
Derived metrics are based on the fundamental metrics. The metric of Derived metrics are based on the fundamental metrics. The metric of
primary interest here is delay variation [RFC3393], a metric which is primary interest here is delay variation [RFC3393], a metric which is
derived from one-way delay [RFC2680]. Another derived metric is the derived from one-way delay [RFC2680]. Another derived metric is the
skipping to change at page 9, line 20 skipping to change at page 10, line 20
instead of the maximum. instead of the maximum.
Note that B_max - B_min = range(B) is the range of buffering times Note that B_max - B_min = range(B) is the range of buffering times
needed to compensate for delay variation. The actual size of the needed to compensate for delay variation. The actual size of the
buffer may be larger (where B_min > 0) or smaller than range(B). buffer may be larger (where B_min > 0) or smaller than range(B).
There must be a process to align the de-jitter buffer time with There must be a process to align the de-jitter buffer time with
packet transit delay. This is a process to identify the packets with packet transit delay. This is a process to identify the packets with
minimum delay and schedule their play-out time so that they spend the minimum delay and schedule their play-out time so that they spend the
maximum time in the buffer. The error in the alignment process can maximum time in the buffer. The error in the alignment process can
be accounted for by a factor, A. In the equation below, the range of be accounted for by a variable, A. In the equation below, the range
buffering times *available* to the packet stream, range(b), depends of buffering times *available* to the packet stream, range(b),
on buffer alignment with the actual arrival times of D_min and D_max. depends on buffer alignment with the actual arrival times of D_min
and D_max.
range(b) = b_max - b_min = D_max - D_min + A range(b) = b_max - b_min = D_max - D_min + A
where variable b represents the *available* buffer in a system with a
specific alignment, A, and b_max and b_min represent the limits of
the available buffer.
When A is positive, the de-jitter buffer applies more delay than When A is positive, the de-jitter buffer applies more delay than
necessary (where Constant = D_max+b_min+A represents one possible necessary (where Constant = D_max+b_min+A represents one possible
alignment). When A is negative, there is insufficient buffer time alignment). When A is negative, there is insufficient buffer time
available to compensate for range(D) because of mis-alignment. available to compensate for range(D) because of mis-alignment.
Packets with D_min may be arriving too early and encountering a full Packets with D_min may be arriving too early and encountering a full
buffer, or packets with D_max may be arriving too late, and in either buffer, or packets with D_max may be arriving too late, and in either
case the packets would be discarded. case the packets would be discarded.
In summary, the range of transit delay variation is a critical factor In summary, the range of transit delay variation is a critical factor
in the determination of de-jitter buffer size. in the determination of de-jitter buffer size.
skipping to change at page 11, line 10 skipping to change at page 12, line 15
IPDV(2) = D(2) - D(1) = (R2-T2) - (R1-T1) = (R2-R1) - (T2-T1) IPDV(2) = D(2) - D(1) = (R2-T2) - (R1-T1) = (R2-R1) - (T2-T1)
An example selection function given in [RFC3393] is "Consecutive An example selection function given in [RFC3393] is "Consecutive
Type-P packets within the specified interval." This is exactly the Type-P packets within the specified interval." This is exactly the
function needed for IPDV. The reference packet in the pair is always function needed for IPDV. The reference packet in the pair is always
the previous packet in the sending sequence. the previous packet in the sending sequence.
Note that IPDV can take on positive and negative values (and zero). Note that IPDV can take on positive and negative values (and zero).
One way to analyze the IPDV results is to concentrate on the positive One way to analyze the IPDV results is to concentrate on the positive
excursions. However, approach has limitations that are discussed in excursions. However, this approach has limitations that are
more detail below (see section 5.3). discussed in more detail below (see section 5.3).
The mean of all IPDV(i) for a stream is usually zero. However, a The mean of all IPDV(i) for a stream is usually zero. However, a
slow delay change over the life of the stream, or a frequency error slow delay change over the life of the stream, or a frequency error
between the measurement system clocks, can result in a non-zero mean. between the measurement system clocks, can result in a non-zero mean.
4.2. PDV: Packet Delay Variation 4.2. PDV: Packet Delay Variation
The name Packet Delay Variation is used in [Y.1540] and its The name Packet Delay Variation is used in [Y.1540] and its
predecessors, and refers to a performance parameter equivalent to the predecessors, and refers to a performance parameter equivalent to the
metric described below. metric described below.
skipping to change at page 20, line 32 skipping to change at page 21, line 32
Alternatively, if the path change is detected, by monitoring the test Alternatively, if the path change is detected, by monitoring the test
packets TTL or Hop Limit, or monitoring the change in the IGP link- packets TTL or Hop Limit, or monitoring the change in the IGP link-
state database, the results of measurement before and after the path state database, the results of measurement before and after the path
change could be kept separated, presenting two different change could be kept separated, presenting two different
distributions. This avoids the difficult task of determining the distributions. This avoids the difficult task of determining the
different modes of a multi-modal distribution. different modes of a multi-modal distribution.
6.2.2. Path Change with Loss 6.2.2. Path Change with Loss
If the path change is accompanied by loss, such that the are no If the path change is accompanied by loss, such that there are no
consecutive packet pairs that span the change, then no IPDV consecutive packet pairs that span the change, then no IPDV
singletons will reflect the change. This may or may not be singletons will reflect the change. This may or may not be
desirable, depending on the ultimate use of the delay variation desirable, depending on the ultimate use of the delay variation
measurement. Figure 6, in which L means Lost and U means undefined, measurement. Figure 6, in which L means Lost and U means undefined,
illustrates this case. illustrates this case.
Packet # 1 2 3 4 5 6 7 8 9 Packet # 1 2 3 4 5 6 7 8 9
Lost L L Lost L L
------------------------------------ ------------------------------------
Delay, ms 3 4 3 3 U U 8 9 8 Delay, ms 3 4 3 3 U U 8 9 8
skipping to change at page 29, line 14 skipping to change at page 30, line 14
+---------------+----------------------+----------------------------+ +---------------+----------------------+----------------------------+
| Comparison | PDV | IPDV | | Comparison | PDV | IPDV |
| Area | | | | Area | | |
+---------------+----------------------+----------------------------+ +---------------+----------------------+----------------------------+
| Challenging | Less sensitive to | Preferred when path | | Challenging | Less sensitive to | Preferred when path |
| Circumstances | packet loss, and | changes are frequent or | | Circumstances | packet loss, and | changes are frequent or |
| | simplifies analysis | when measurement clocks | | | simplifies analysis | when measurement clocks |
| | when load balancing | exhibit some skew | | | when load balancing | exhibit some skew |
| | or multiple paths | | | | or multiple paths | |
| | are present | | | | are present | |
|---------------|----------------------|----------------------------|
| Spatial | All validated | Has sensitivity to | | Spatial | All validated | Has sensitivity to |
| Composition | methods use this | sequence and spacing | | Composition | methods use this | sequence and spacing |
| of DV metric | form | changes, which tends to | | of DV metric | form | changes, which tends to |
| | | break the requirement for | | | | break the requirement for |
| | | independent distributions | | | | independent distributions |
| | | between path segments | | | | between path segments |
|---------------|----------------------|----------------------------|
| Determine | "Pseudo-range" | No reliable relationship, | | Determine | "Pseudo-range" | No reliable relationship, |
| De-Jitter | reveals this | but some heuristics | | De-Jitter | reveals this | but some heuristics |
| Buffer Size | property by | | | Buffer Size | property by | |
| Required | anchoring the | | | Required | anchoring the | |
| | distribution at the | | | | distribution at the | |
| | minimum delay | | | | minimum delay | |
|---------------|----------------------|----------------------------|
| Estimate of | Distribution has | No reliable relationship | | Estimate of | Distribution has | No reliable relationship |
| Queuing Time | one-to-one | | | Queuing Time | one-to-one | |
| and Variation | relationship on a | | | and Variation | relationship on a | |
| | stable path, | | | | stable path, | |
| | especially when | | | | especially when | |
| | sample min = true | | | | sample min = true | |
| | min | | | | min | |
|---------------|----------------------|----------------------------|
| Specification | One constraint | Distribution is two-sided, | | Specification | One constraint | Distribution is two-sided, |
| Simplicity: | needed for | usually has zero mean, and | | Simplicity: | needed for | usually has zero mean, and |
| Single Number | single-sided | no universal summary | | Single Number | single-sided | no universal summary |
| SLS | distribution, and | statistic that relates to | | SLA | distribution, and | statistic that relates to |
| | easily related to | a physical quantity | | | easily related to | a physical quantity |
| | quantities above | | | | quantities above | |
+---------------+----------------------+----------------------------+ +---------------+----------------------+----------------------------+
Summary of Comparisons Summary of Comparisons
8. Measurement Considerations 8. Measurement Considerations
This section discusses the practical aspects of delay variation This section discusses the practical aspects of delay variation
measurement, with special attention to the two formulations compared measurement, with special attention to the two formulations compared
skipping to change at page 34, line 15 skipping to change at page 35, line 15
9. IANA Considerations 9. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
10. Security Considerations 10. Security Considerations
The security considerations that apply to any active measurement of The security considerations that apply to any active measurement of
live networks are relevant here as well. See [RFC4656] live networks are relevant here as well. See the security
considerations sections in [RFC2330], [RFC2679], [RFC3393],
[RFC3432], and[RFC4656].
Security considerations do not contribute to the selection of PDV or
IPDV forms of delay variation.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Phil Chimento for his suggestion to The authors would like to thank Phil Chimento for his suggestion to
employ the convention of conditional distributions for Delay to deal employ the convention of conditional distributions of Delay to deal
with packet loss, and his encouragement to "write the memo" after with packet loss, and his encouragement to "write the memo" after
hearing "the talk" on this topic at IETF-65. We also acknowledge hearing "the talk" on this topic at IETF-65. We also acknowledge
constructive comments from Alan Clark, Loki Jorgenson, Carsten constructive comments from Alan Clark, Loki Jorgenson, Carsten
Schmoll, and Robert Holley. Schmoll, and Robert Holley.
12. Appendix on Calculating the D(min) in PDV 12. Appendix on Calculating the D(min) in PDV
Practitioners have raised questions several questions that this Practitioners have raised questions several questions that this
section intends to answer: section intends to answer:
skipping to change at page 36, line 38 skipping to change at page 37, line 42
[G.1020] ITU-T Recommendation G.1020, ""Performance parameter [G.1020] ITU-T Recommendation G.1020, ""Performance parameter
definitions for the quality of speech and other voiceband definitions for the quality of speech and other voiceband
applications utilizing IP networks"", 2006. applications utilizing IP networks"", 2006.
[G.1050] ITU-T Recommendation G.1050, ""Network model for [G.1050] ITU-T Recommendation G.1050, ""Network model for
evaluating multimedia transmission performance over evaluating multimedia transmission performance over
Internet Protocol"", November 2005. Internet Protocol"", November 2005.
[I-D.ietf-ippm-framework-compagg] [I-D.ietf-ippm-framework-compagg]
Morton, A., "Framework for Metric Composition", Morton, A., "Framework for Metric Composition",
draft-ietf-ippm-framework-compagg-06 (work in progress), draft-ietf-ippm-framework-compagg-07 (work in progress),
February 2008. October 2008.
[I-D.ietf-ippm-spatial-composition] [I-D.ietf-ippm-spatial-composition]
Morton, A. and E. Stephan, "Spatial Composition of Morton, A. and E. Stephan, "Spatial Composition of
Metrics", draft-ietf-ippm-spatial-composition-06 (work in Metrics", draft-ietf-ippm-spatial-composition-07 (work in
progress), February 2008. progress), July 2008.
[I-D.morton-ippm-reporting-metrics] [I-D.morton-ippm-reporting-metrics]
Morton, A., Ramachandran, G., and G. Maguluri, "Reporting Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
Metrics: Different Points of View", Metrics: Different Points of View",
draft-morton-ippm-reporting-metrics-05 (work in progress), draft-morton-ippm-reporting-metrics-06 (work in progress),
May 2008. January 2009.
[I.356] ITU-T Recommendation Y.1540, "B-ISDN ATM layer cell
transfer performance", March 2000.
[Krzanowski] [Krzanowski]
Presentation at IPPM, IETF-64, "Jitter Definitions: What Presentation at IPPM, IETF-64, "Jitter Definitions: What
is What?", November 2005. is What?", November 2005.
[Li.Mills] [Li.Mills]
Li, Quong. and David. Mills, ""The Implications of Short- Li, Quong. and David. Mills, ""The Implications of Short-
Range Dependency on Delay Variation Measurement", Second Range Dependency on Delay Variation Measurement", Second
IEEE Symposium on Network Computing and Applications", IEEE Symposium on Network Computing and Applications",
2003. 2003.
skipping to change at page 37, line 30 skipping to change at page 38, line 37
[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
Metrics", RFC 3357, August 2002. Metrics", RFC 3357, August 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data
communication service - IP packet transfer and communication service - IP packet transfer and
availability performance parameters", December 2002. availability performance parameters", November 2007.
[Y.1541] ITU-T Recommendation Y.1540, "Network Performance [Y.1541] ITU-T Recommendation Y.1541, "Network Performance
Objectives for IP-Based Services", February 2006. Objectives for IP-Based Services", February 2006.
[Zhang.Duff] [Zhang.Duff]
Zhang, Yin., Duffield, Nick., Paxson, Vern., and Scott. Zhang, Yin., Duffield, Nick., Paxson, Vern., and Scott.
Shenker, ""On the Constancy of Internet Path Properties", Shenker, ""On the Constancy of Internet Path Properties",
Proceedings of ACM SIGCOMM Internet Measurement Proceedings of ACM SIGCOMM Internet Measurement
Workshop,", November 2001. Workshop,", November 2001.
Authors' Addresses Authors' Addresses
skipping to change at page 39, line 4 skipping to change at line 1735
Benoit Claise Benoit Claise
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6a b1 De Kleetlaan 6a b1
Diegem, 1831 Diegem, 1831
Belgium Belgium
Phone: +32 2 704 5622 Phone: +32 2 704 5622
Fax: Fax:
Email: bclaise@cisco.com Email: bclaise@cisco.com
URI: URI:
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 27 change blocks. 
95 lines changed or deleted 125 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/