draft-ietf-ippm-ipdv-09.txt   rfc3393.txt 
Network Working Group C. Demichelis Network Working Group C. Demichelis
INTERNET-DRAFT CSELT Request for Comments: 3393 Telecomitalia Lab
Expiration Date: October 2002 P. Chimento Category: Standards Track P. Chimento
Ericsson IPI Ericsson IPI
April 2002 November 2002
IP Packet Delay Variation Metric for IPPM
<draft-ietf-ippm-ipdv-09.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering IP Packet Delay Variation Metric
Task Force (IETF), its areas, and its working groups. Note that for IP Performance Metrics (IPPM)
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of this Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/1id-abstracts.txt Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft shadow directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
This memo provides information for the Internet community. This memo Copyright (C) The Internet Society (2002). All Rights Reserved.
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
2. Abstract Abstract
This memo refers to a metric for variation in delay of packets across This document refers to a metric for variation in delay of packets
Internet paths. The metric is based on the difference in the One-Way- across Internet paths. The metric is based on the difference in the
Delay of selected packets. This difference in delay is called "IP One-Way-Delay of selected packets. This difference in delay is
Packet Delay variation." called "IP Packet Delay Variation (ipdv)".
The metric is valid for measurements between two hosts both in the The metric is valid for measurements between two hosts both in the
case that they have synchronized clocks and in the case that they are case that they have synchronized clocks and in the case that they are
not synchronized. We discuss both in this draft. not synchronized. We discuss both in this document.
3. Introduction Table of Contents
1 Introduction..................................................... 2
1.1 Terminology.................................................. 3
1.2 Definition................................................... 3
1.3 Motivation................................................... 4
1.4 General Issues Regarding Time................................ 5
2 A singleton definition of a One-way-ipdv metric.................. 5
2.1 Metric name.................................................. 6
2.2 Metric parameters............................................ 6
2.3 Metric unit.................................................. 6
2.4 Definition................................................... 6
2.5 Discussion................................................... 7
2.6 Methodologies................................................ 9
2.7 Errors and Uncertainties.....................................10
2.7.1 Errors/Uncertainties related to Clocks.................11
2.7.2 Errors/uncertainties related to Wire-time vs Host-time.12
3 Definitions for Samples of One-way-ipdv..........................12
3.1 Metric name..................................................12
3.2 Parameters...................................................12
3.3 Metric Units.................................................13
3.4 Definition...................................................13
3.5 Discussion...................................................13
3.6 Methodology..................................................14
3.7 Errors and uncertainties.....................................14
4 Statistics for One-way-ipdv......................................14
4.1 Lost Packets and ipdv statistics.............................15
4.2 Distribution of One-way-ipdv values..........................15
4.3 Type-P-One-way-ipdv-percentile...............................16
4.4 Type-P-One-way-ipdv-inverse-percentile.......................16
4.5 Type-P-One-way-ipdv-jitter...................................16
4.6 Type-P-One-way-peak-to-peak-ipdv.............................16
5 Discussion of clock synchronization..............................17
5.1 Effects of synchronization errors............................17
5.2 Estimating the skew of unsynchronized clocks.................18
6 Security Considerations..........................................18
6.1 Denial of service............................................18
6.2 Privacy/Confidentiality......................................18
6.3 Integrity....................................................19
7 Acknowledgments..................................................19
8 References.......................................................19
8.1 Normative References........................................19
8.2 Informational References....................................19
9 Authors' Addresses...............................................20
10 Full Copyright Statement........................................21
1. Introduction
This memo defines a metric for the variation in delay of packets that This memo defines a metric for the variation in delay of packets that
flow from one host to another through an IP path. It is based on "A flow from one host to another through an IP path. It is based on "A
One-Way-Delay metric for IPPM", RFC 2679 [2] and part of the text in One-Way-Delay metric for IPPM", RFC 2679 [2] and part of the text in
this memo is taken directly from that document; the reader is assumed this memo is taken directly from that document; the reader is assumed
to be familiar with that document. to be familiar with that document.
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 [10]. document are to be interpreted as described in BCP 14, RFC 2119 [3].
Although RFC 2119 was written with protocols in mind, the key words Although BCP 14, RFC 2119 was written with protocols in mind, the key
are used in this document for similar reasons. They are used to words are used in this document for similar reasons. They are used
ensure the results of measurements from two different implementations to ensure the results of measurements from two different
are comparable and to note instances where an implementation could implementations are comparable and to note instances where an
perturb the network. implementation could perturb the network.
The structure of the memo is as follows: The structure of the memo is as follows:
+ A 'singleton' analytic metric, called Type-P-One-way-ipdv, will be + A 'singleton' analytic metric, called Type-P-One-way-ipdv, will be
introduced to define a single instance of an ipdv measurement. introduced to define a single instance of an ipdv measurement.
+ Using this singleton metric, as 'sample', called Type-P-one-way- + Using this singleton metric, a 'sample', called Type-P-one-way-
ipdv-Poisson-stream, will be introduced to make it possible to ipdv-Poisson-stream, will be introduced to make it possible to
compute the statistics of sequences of ipdv measurements. compute the statistics of sequences of ipdv measurements.
+ Using this sample, several 'statistics' of the sample will be + Using this sample, several 'statistics' of the sample will be
defined and discussed. defined and discussed
3.1. Terminology 1.1. Terminology
The variation in packet delay is sometimes called "jitter". This The variation in packet delay is sometimes called "jitter". This
term, however, causes confusion because it is used in different ways term, however, causes confusion because it is used in different ways
by different groups of people. by different groups of people.
"Jitter" commonly has two meanings: The first meaning is the "Jitter" commonly has two meanings: The first meaning is the
variation of a signal with respect to some clock signal, where the variation of a signal with respect to some clock signal, where the
arrival time of the signal is expected to coincide with the arrival arrival time of the signal is expected to coincide with the arrival
of the clock signal. This meaning is used with reference to of the clock signal. This meaning is used with reference to
synchronous signals and might be used to measure the quality of synchronous signals and might be used to measure the quality of
circuit emulation, for example. There is also a metric called circuit emulation, for example. There is also a metric called
"wander" used in this context. "wander" used in this context.
The second meaning has to do with the variation of a metric (e.g. The second meaning has to do with the variation of a metric (e.g.,
delay) with respect to some reference metric (e.g. average delay or delay) with respect to some reference metric (e.g., average delay or
minimum delay). This meaning is frequently used by computer minimum delay). This meaning is frequently used by computer
scientists and frequently (but not always) refers to variation in scientists and frequently (but not always) refers to variation in
delay. delay.
In this document we will avoid the term "jitter" whenever possible In this document we will avoid the term "jitter" whenever possible
and stick to delay variation which is more precise. and stick to delay variation which is more precise.
3.2. Definition 1.2. Definition
A definition of the IP Packet Delay Variation (ipdv) can be given for A definition of the IP Packet Delay Variation (ipdv) can be given for
packets inside a stream of packets. packets inside a stream of packets.
The IP Packet Delay Variation (ipdv) of a pair of packets within a The ipdv of a pair of packets within a stream of packets is defined
stream of packets is defined for a selected pair of packets in the for a selected pair of packets in the stream going from measurement
stream going from measurement point MP1 to measurement point MP2. point MP1 to measurement point MP2.
The ipdv is the difference between the one-way-delay of the selected The ipdv is the difference between the one-way-delay of the selected
packets. packets.
3.3. Motivation 1.3. Motivation
One important use of delay variation is the sizing of play-out One important use of delay variation is the sizing of play-out
buffers for applications requiring the regular delivery of packets buffers for applications requiring the regular delivery of packets
(for example, voice or video play-out). What is normally important in (for example, voice or video play-out). What is normally important
this case is the maximum delay variation, which is used to size play- in this case is the maximum delay variation, which is used to size
out buffers for such applications [6]. Other uses of a delay play-out buffers for such applications [7]. Other uses of a delay
variation metric are, for example, to determine the dynamics of variation metric are, for example, to determine the dynamics of
queues within a network (or router) where the changes in delay queues within a network (or router) where the changes in delay
variation can be linked to changes in the queue length process at a variation can be linked to changes in the queue length process at a
given link or a combination of links. given link or a combination of links.
In addition, this type of metric is particularly robust with respect In addition, this type of metric is particularly robust with respect
to differences and variations of the clocks of the two hosts. This to differences and variations of the clocks of the two hosts. This
allows the use of the metric even if the two hosts that support the allows the use of the metric even if the two hosts that support the
measurement points are not synchronized. In the latter case measurement points are not synchronized. In the latter case
indications of reciprocal skew of the clocks can be derived from the indications of reciprocal skew of the clocks can be derived from the
measurement and corrections are possible. The related precision is measurement and corrections are possible. The related precision is
often comparable with the one that can be achieved with synchronized often comparable with the one that can be achieved with synchronized
clocks, being of the same order of magnitude of synchronization clocks, being of the same order of magnitude of synchronization
errors. This will be discussed below. errors. This will be discussed below.
The scope of this document is to provide a way to measure the ipdv The scope of this document is to provide a way to measure the ipdv
delivered on a path. Our goal is to provide a metric which can be delivered on a path. Our goal is to provide a metric which can be
parameterized so that it can be used for various purposes. Any report parameterized so that it can be used for various purposes. Any
of the metric MUST include all the parameters associated with it so report of the metric MUST include all the parameters associated with
that the conditions and meaning of the metric can be determined it so that the conditions and meaning of the metric can be determined
exactly. Since the metric does not represent a value judgment (i.e. exactly. Since the metric does not represent a value judgment (i.e.,
define "good" and "bad"), we specifically do not specify particular define "good" and "bad"), we specifically do not specify particular
values of the metrics that IP networks must meet. values of the metrics that IP networks must meet.
The flexibility of the metric can be viewed as a disadvantage but The flexibility of the metric can be viewed as a disadvantage but
there are some arguments for making it flexible. First, though there there are some arguments for making it flexible. First, though there
are some uses of ipdv mentioned above, to some degree the uses of are some uses of ipdv mentioned above, to some degree the uses of
ipdv are still a research topic and some room should be left for ipdv are still a research topic and some room should be left for
experimentation. Secondly, there are different views in the community experimentation. Secondly, there are different views in the
of what precisely the definition should be (e.g. [7],[8],[9]). The community of what precisely the definition should be (e.g.,
idea here is to parameterize the definition, rather than write a [8],[9],[10]). The idea here is to parameterize the definition,
different draft for each proposed definition. As long as all the rather than write a different document for each proposed definition.
parameters are reported, it will be clear what is meant by a As long as all the parameters are reported, it will be clear what is
particular use of ipdv. All the remarks in the draft hold, no matter meant by a particular use of ipdv. All the remarks in the document
which parameters are chosen. hold, no matter which parameters are chosen.
3.4. General Issues Regarding Time 1.4. General Issues Regarding Time
Everything contained in Section 2.2. of [2] applies also in this Everything contained in Section 2.2. of [2] applies also in this
case. case.
To summarize: As in [1] we define "skew" as the first derivative of To summarize: As in [1] we define "skew" as the first derivative of
the offset of a clock with respect to "true time" and define "drift" the offset of a clock with respect to "true time" and define "drift"
as the second derivative of the offset of a clock with respect to as the second derivative of the offset of a clock with respect to
"true time". "true time".
From there, we can construct "relative skew" and "relative drift" for From there, we can construct "relative skew" and "relative drift" for
two clocks C1 and C2 with respect to one another. These are natural two clocks C1 and C2 with respect to one another. These are natural
extensions of the basic framework definitions of these quantities: extensions of the basic framework definitions of these quantities:
+ Relative offset = difference in clock times + Relative offset = difference in clock times
+ Relative skew = first derivative of the difference in clock times + Relative skew = first derivative of the difference in clock times
+ Relative drift = second derivative of the difference in clock + Relative drift = second derivative of the difference in clock
times times
NOTE: The drift of a clock, as it is above defined over a long period NOTE: The drift of a clock, as it is above defined over a long period
must have an average value that tends to zero while the period must have an average value that tends to zero while the period
becomes large since the frequency of the clock has a finite (and becomes large since the frequency of the clock has a finite (and
small) range. In order to underline the order of magnitude of this small) range. In order to underline the order of magnitude of this
effect,it is considered that the maximum range of drift for effect,it is considered that the maximum range of drift for
commercial crystals is about 50 part per million (ppm). Since it is commercial crystals is about 50 part per million (ppm). Since it is
mainly connected with variations in operating temperature (from 0 to mainly connected with variations in operating temperature (from 0 to
70 degrees Celsius), it is expected that a host will have a nearly 70 degrees Celsius), it is expected that a host will have a nearly
constant temperature during its operation period, and variations in constant temperature during its operation period, and variations in
temperature, even if quick, could be less than one Celsius per temperature, even if quick, could be less than one Celsius per
second, and range in the order of few degrees. The total range of the second, and range in the order of a few degrees. The total range of
drift is usually related to variations from 0 to 70 Celsius. These the drift is usually related to variations from 0 to 70 Celsius.
are important points for evaluation of precision of ipdv These are important points for evaluation of precision of ipdv
measurements, as will be seen below. measurements, as will be seen below.
4. A singleton definition of a One-way ipdv metric 2. A singleton definition of a One-way-ipdv metric
The purpose of the singleton metric is to define what a single The purpose of the singleton metric is to define what a single
instance of an ipdv measurement is. Note that it can only be instance of an ipdv measurement is. Note that it can only be
statistically significant in combination with other instances. It is statistically significant in combination with other instances. It is
not intended to be meaningful as a singleton, in the sense of being not intended to be meaningful as a singleton, in the sense of being
able to draw inferences from it. able to draw inferences from it.
This definition makes use of the corresponding definition of type-P- This definition makes use of the corresponding definition of type-P-
One-Way-Delay metric [2]. This section makes use of those parts of One-Way-Delay metric [2]. This section makes use of those parts of
the One-Way-Delay Draft that directly apply to the One-Way-ipdv the One-Way-Delay Draft that directly apply to the One-Way-ipdv
metric, or makes direct references to that Draft. metric, or makes direct references to that Draft.
4.1. Metric name 2.1. Metric name
Type-P-One-way-ipdv Type-P-One-way-ipdv
4.2. Metric parameters 2.2. Metric parameters
+ Src, the IP address of a host + Src, the IP address of a host
+ Dst, the IP address of a host + Dst, the IP address of a host
+ T1, a time + T1, a time
+ T2, a time + T2, a time
+ L, a packet length in bits. The packets of a Type P packet stream + L, a packet length in bits. The packets of a Type P packet stream
from which the singleton ipdv metric is taken MUST all be of the from which the singleton ipdv metric is taken MUST all be of the
same length. same length.
+ F, a selection function defining unambiguously the two packets + F, a selection function defining unambiguously the two packets
from the stream selected for the metric. from the stream selected for the metric.
+ I1,I2, times which mark that beginning and ending of the interval + I1,I2, times which mark that beginning and ending of the interval
in which the packet stream from which the singleton measurement is in which the packet stream from which the singleton measurement is
taken occurs. taken occurs.
+ P, the specification of the packet type, over and above the source + P, the specification of the packet type, over and above the source
and destination addresses and destination addresses
4.3. Metric unit 2.3. Metric unit
The value of a Type-P-One-way-ipdv is either a real number of seconds The value of a Type-P-One-way-ipdv is either a real number of seconds
(positive, zero or negative) or an undefined number of seconds. (positive, zero or negative) or an undefined number of seconds.
4.4. Definition 2.4. Definition
We are given a Type P packet stream and I1 and I2 such that the first We are given a Type P packet stream and I1 and I2 such that the first
Type P packet to pass measurement point MP1 after I1 is given index 0 Type P packet to pass measurement point MP1 after I1 is given index 0
and the last Type P packet to pass measurement point MP1 before I2 is and the last Type P packet to pass measurement point MP1 before I2 is
given the highest index number. given the highest index number.
Type-P-One-way-ipdv is defined for two packets from Src to Dst Type-P-One-way-ipdv is defined for two packets from Src to Dst
selected by the selection function F, as the difference between the selected by the selection function F, as the difference between the
value of the type-P-One-way- delay from Src to Dst at T2 and the value of the type-P-One-way-delay from Src to Dst at T2 and the value
value of the type-P-One-Way-Delay from Src to Dst at T1. T1 is the of the type-P-One-Way-Delay from Src to Dst at T1. T1 is the wire-
wire-time at which Scr sent the first bit of the first packet, and T2 time at which Scr sent the first bit of the first packet, and T2 is
is the wire-time at which Src sent the first bit of the second the wire-time at which Src sent the first bit of the second packet.
packet. This metric is derived from the One-Way-Delay metric. This metric is derived from the One-Way-Delay metric.
Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to
Dst at T1, T2 is ddT" means that Src sent two packets, the first at Dst at T1, T2 is ddT" means that Src sent two packets, the first at
wire-time T1 (first bit), and the second at wire-time T2 (first bit) wire-time T1 (first bit), and the second at wire-time T2 (first bit)
and the packets were received by Dst at wire-time dT1+T1 (last bit of and the packets were received by Dst at wire-time dT1+T1 (last bit of
the first packet), and at wire-time dT2+T2 (last bit of the second the first packet), and at wire-time dT2+T2 (last bit of the second
packet), and that dT2-dT1=ddT. packet), and that dT2-dT1=ddT.
"The type-P-one-way-ipdv from Src to Dst at T1,T2 is undefined" means "The type-P-one-way-ipdv from Src to Dst at T1,T2 is undefined" means
that Src sent the first bit of a packet at T1 and the first bit of a that Src sent the first bit of a packet at T1 and the first bit of a
second packet at T2 and that Dst did not receive one or both packets. second packet at T2 and that Dst did not receive one or both packets.
Figure 1 illustrates this definition. Suppose that packets P(i) and Figure 1 illustrates this definition. Suppose that packets P(i) and
P(k) are selected. P(k) are selected.
I1 P(i) P(j) P(k) I2 I1 P(i) P(j) P(k) I2
MP1 MP1 |--------------------------------------------------------------|
|----------------------------------------------------------------|
|\ |\ |\ |\ |\ |\
| \ | \ | \ | \ | \ | \
| \ | \ | \ | \ | \ | \
| \ | \ | \ | \ | \ | \
|dTi \ |dTj \ |dTk \ |dTi \ |dTj \ |dTk \
|<--->v |<--->v |<--->v |<--->v |<--->v |<--->v
MP2 MP2 |--------------------------------------------------------------|
|----------------------------------------------------------------|
I1 P(i) P(j) P(k) I2 I1 P(i) P(j) P(k) I2
Figure 1: Illustration of the definition Figure 1: Illustration of the definition
Then ddT = dTk - dTi as defined above. Then ddT = dTk - dTi as defined above.
4.5. Discussion 2.5. Discussion
This metric definition depends on a stream of Type-P-One-Way-Delay This metric definition depends on a stream of Type-P-One-Way-Delay
packets that have been measured. In general this can be a stream of packets that have been measured. In general this can be a stream of
two or more packets, delimited by the interval endpoints I1 and I2. two or more packets, delimited by the interval endpoints I1 and I2.
There must be a stream of at least two packets in order for a There must be a stream of at least two packets in order for a
singleton ipdv measurement to take place. The purpose of the singleton ipdv measurement to take place. The purpose of the
selection function is to specify exactly which two packets from the selection function is to specify exactly which two packets from the
stream are to be used for the singleton measurement. Note that the stream are to be used for the singleton measurement. Note that the
selection function may involve observing the one-way-delay of all the selection function may involve observing the one-way-delay of all the
Type P packets of the stream in the specified interval. Examples of a Type P packets of the stream in the specified interval. Examples of
selection function are: a selection function are:
+ Consecutive Type-P packets within the specified interval + Consecutive Type-P packets within the specified interval
+ Type-P packets with specified indices within the specified + Type-P packets with specified indices within the specified
interval interval
+ Type-P packets with the min and max one-way-delays within the + Type-P packets with the min and max one-way-delays within the
specified interval specified interval
+ Type-P packets with specified indices from the set of all defined + Type-P packets with specified indices from the set of all defined
(i.e. non-infinite) one-way-delays Type-P packets within the (i.e., non-infinite) one-way-delays Type-P packets within the
specified interval. specified interval.
The following practical issues have to be considered: The following practical issues have to be considered:
+ Being a differential measurement, this metric is less sensitive to + Being a differential measurement, this metric is less sensitive to
clock synchronization problems. This issue will be more carefully clock synchronization problems. This issue will be more carefully
examined in section 7 of this memo. It is pointed out that, if the examined in section 5 of this memo. It is pointed out that, if
relative clock conditions change in time, the accuracy of the the relative clock conditions change in time, the accuracy of the
measurement will depend on the time interval I2-I1 and the measurement will depend on the time interval I2-I1 and the
magnitude of possible errors will be discussed below. magnitude of possible errors will be discussed below.
+ A given methodology will have to include a way to determine + A given methodology will have to include a way to determine
whether a delay value is infinite or whether it is merely very whether a delay value is infinite or whether it is merely very
large (and the packet is yet to arrive at Dst). As noted by large (and the packet is yet to arrive at Dst). As noted by
Mahdavi and Paxson, simple upper bounds (such as the 255 seconds Mahdavi and Paxson, simple upper bounds (such as the 255 seconds
theoretical upper bound on the lifetimes of IP packets [Postel: theoretical upper bound on the lifetimes of IP packets [Postel:
RFC 791]) could be used, but good engineering, including an RFC 791]) could be used, but good engineering, including an
understanding of packet lifetimes, will be needed in practice. understanding of packet lifetimes, will be needed in practice.
Comment: Note that, for many applications of these metrics, the Comment: Note that, for many applications of these metrics, the
harm in treating a large delay as infinite might be zero or very harm in treating a large delay as infinite might be zero or very
small. A TCP data packet, for example, that arrives only after small. A TCP data packet, for example, that arrives only after
several multiples of the RTT may as well have been lost. several multiples of the RTT may as well have been lost.
+ As with other 'type-P' metrics, the value of the metric may depend + As with other 'type-P' metrics, the value of the metric may depend
on such properties of the packet as protocol,(UDP or TCP) port on such properties of the packet as protocol,(UDP or TCP) port
number, size, and arrangement for special treatment (as with IP number, size, and arrangement for special treatment (as with IP
precedence or with RSVP). precedence or with RSVP).
+ ddT is derived from the start of the first bit out from a packet + ddT is derived from the start of the first bit out from a packet
sent out by Src to the reception of the last bit received by Dst. sent out by Src to the reception of the last bit received by Dst.
Delay is correlated to the size of the packet. For this reason, Delay is correlated to the size of the packet. For this reason,
the packet size is a parameter of the measurement and must be the packet size is a parameter of the measurement and must be
reported along with the measurement. reported along with the measurement.
+ If the packet is duplicated along the path (or paths!) so that + If the packet is duplicated along the path (or paths!) so that
multiple non-corrupt copies arrive at the destination, then the multiple non-corrupt copies arrive at the destination, then the
packet is counted as received, and the first copy to arrive packet is counted as received, and the first copy to arrive
determines the packet's One-Way-Delay. determines the packet's One-Way-Delay.
+ If the packet is fragmented and if, for whatever reason, + If the packet is fragmented and if, for whatever reason,
reassembly does not occur, then the packet will be deemed lost. re-assembly does not occur, then the packet will be deemed lost.
In this draft it is assumed that the Type-P packet stream is In this document it is assumed that the Type-P packet stream is
generated according to the Poisson sampling methodology described in generated according to the Poisson sampling methodology described in
[1]. The reason for Poisson sampling is that it ensures an unbiased [1].
and uniformly distributed sampling of times between I1 and I2.
However, alternate sampling methodologies are possible. For example, The reason for Poisson sampling is that it ensures an unbiased and
continuous sampling of a constant bit rate stream (i.e. periodic uniformly distributed sampling of times between I1 and I2. However,
packet transmission) is a possibility. However, in this case, one alternate sampling methodologies are possible. For example,
continuous sampling of a constant bit rate stream (i.e., periodic
packet transmission) is a possibility. However, in this case, one
must be sure to avoid any "aliasing" effects that may occur with must be sure to avoid any "aliasing" effects that may occur with
periodic samples. periodic samples.
4.6. Methodologies 2.6. Methodologies
As with other Type-P-* metrics, the detailed methodology will depend As with other Type-P-* metrics, the detailed methodology will depend
on the Type-P (e.g., protocol number, UDP/TCP port number, size, on the Type-P (e.g., protocol number, UDP/TCP port number, size,
precedence). precedence).
The measurement methodology described in this section assumes the The measurement methodology described in this section assumes the
measurement and determination of ipdv in real-time as part of an measurement and determination of ipdv in real-time as part of an
active measurement. Note that this can equally well be done a active measurement. Note that this can equally well be done a
posteriori, i.e. after the one-way-delay measurement is completed. posteriori, i.e., after the one-way-delay measurement is completed.
Generally, for a given Type-P, the methodology would proceed as Generally, for a given Type-P, the methodology would proceed as
follows: Note that this methodology is based on synchronized clocks. follows: Note that this methodology is based on synchronized clocks.
The need for synchronized clocks for Src and Dst will be discussed The need for synchronized clocks for Src and Dst will be discussed
later. later.
+ Start after time I1. At the Src host, select Src and Dst IP + Start after time I1. At the Src host, select Src and Dst IP
addresses, and form test packets of Type-P with these addresses addresses, and form test packets of Type-P with these addresses
according to a given technique (e.g. the Poisson sampling according to a given technique (e.g., the Poisson sampling
technique). Any 'padding' portion of the packet needed only to technique). Any 'padding' portion of the packet needed only to
make the test packet a given size should be filled with randomized make the test packet a given size should be filled with randomized
bits to avoid a situation in which the measured delay is lower bits to avoid a situation in which the measured delay is lower
than it would otherwise be due to compression techniques along the than it would otherwise be due to compression techniques along the
path. path.
+ At the Dst host, arrange to receive the packets. + At the Dst host, arrange to receive the packets.
+ At the Src host, place a time stamp in the Type-P packet, and send + At the Src host, place a time stamp in the Type-P packet, and send
it towards Dst. it towards Dst.
+ If the packet arrives within a reasonable period of time, take a + If the packet arrives within a reasonable period of time, take a
time stamp as soon as possible upon the receipt of the packet. By time stamp as soon as possible upon the receipt of the packet. By
subtracting the two time stamps, an estimate of One-Way-Delay can subtracting the two time stamps, an estimate of One-Way-Delay can
be computed. be computed.
+ If the packet meets the selection function criterion for the first + If the packet meets the selection function criterion for the first
packet, record this first delay value. Otherwise, continue packet, record this first delay value. Otherwise, continue
generating the Type-P packet stream as above until the criterion generating the Type-P packet stream as above until the criterion
is met or I2, whichever comes first. is met or I2, whichever comes first.
+ At the Src host, packets continue to be generated according to the + At the Src host, packets continue to be generated according to the
given methodology. The Src host places a time stamp in the Type-P given methodology. The Src host places a time stamp in the Type-P
packet, and send it towards Dst. packet, and send it towards Dst.
+ If the packet arrives within a reasonable period of time, take a + If the packet arrives within a reasonable period of time, take a
time stamp as soon as possible upon the receipt of the packet. By time stamp as soon as possible upon the receipt of the packet. By
subtracting the two time stamps, an estimate of One-Way-Delay can subtracting the two time stamps, an estimate of One-Way-Delay can
be computed. be computed.
+ If the packet meets the criterion for the second packet, then by + If the packet meets the criterion for the second packet, then by
subtracting the first value of One-Way-Delay from the second value subtracting the first value of One-Way-Delay from the second value
the ipdv value of the pair of packets is obtained. Otherwise, the ipdv value of the pair of packets is obtained. Otherwise,
packets continue to be generated until the criterion for the packets continue to be generated until the criterion for the
second packet is fulfilled or I2, whichever comes first. second packet is fulfilled or I2, whichever comes first.
+ If one or both packets fail to arrive within a reasonable period + If one or both packets fail to arrive within a reasonable period
of time, the ipdv is taken to be undefined. of time, the ipdv is taken to be undefined.
4.7. Errors and Uncertainties 2.7. Errors and Uncertainties
In the singleton metric of ipdv, factors that affect the measurement In the singleton metric of ipdv, factors that affect the measurement
are the same as those affecting the One-Way-Delay measurement, even are the same as those affecting the One-Way-Delay measurement, even
if, in this case, the influence is different. if, in this case, the influence is different.
The Framework document [1] provides general guidance on this point, The Framework document [1] provides general guidance on this point,
but we note here the following specifics related to delay metrics: but we note here the following specifics related to delay metrics:
+ Errors/uncertainties due to uncertainties in the clocks of the Src + Errors/uncertainties due to uncertainties in the clocks of the Src
and Dst hosts. and Dst hosts.
+ Errors/uncertainties due to the difference between 'wire time' and + Errors/uncertainties due to the difference between 'wire time' and
'host time'. 'host time'.
Each of these errors is discussed in more detail in the following Each of these errors is discussed in more detail in the following
paragraphs. paragraphs.
4.7.1. Errors/Uncertainties related to Clocks 2.7.1. Errors/Uncertainties related to Clocks
If, as a first approximation, the error that affects the first If, as a first approximation, the error that affects the first
measurement of One-Way-Delay were the same as the one affecting the measurement of One-Way-Delay were the same as the one affecting the
second measurement, they will cancel each other when calculating second measurement, they will cancel each other when calculating
ipdv. The residual error related to clocks is the difference of the ipdv. The residual error related to clocks is the difference of the
errors that are supposed to change from time T1, at which the first errors that are supposed to change from time T1, at which the first
measurement is performed, to time T2 at which the second measurement measurement is performed, to time T2 at which the second measurement
is performed. Synchronization, skew, accuracy and resolution are is performed. Synchronization, skew, accuracy and resolution are
here considered with the following notes: here considered with the following notes:
+ Errors in synchronization between source and destination clocks + Errors in synchronization between source and destination clocks
contribute to errors in both of the delay measurements required contribute to errors in both of the delay measurements required
for calculating ipdv. for calculating ipdv.
+ The effect of drift and skew errors on ipdv measurements can be + The effect of drift and skew errors on ipdv measurements can be
quantified as follows: Suppose that the skew and drift functions quantified as follows: Suppose that the skew and drift functions
are known. Assume first that the skew function is linear in time. are known. Assume first that the skew function is linear in time.
Clock offset if then also a function of time and the error evolves Clock offset is then also a function of time and the error evolves
as e(t) = K*t + O, where K is a constant and O is the offset at as e(t) = K*t + O, where K is a constant and O is the offset at
time 0. In this case, the error added to the subtraction two time 0. In this case, the error added to the subtraction of two
different time stamps (t2 > t1) is e(t2)-e(t1) = K*(t2 - t1) which different time stamps (t2 > t1) is e(t2)-e(t1) = K*(t2 - t1) which
will be added to the time difference (t2 - t1). If the drift will be added to the time difference (t2 - t1). If the drift
cannot be ignored, but we assume that the drift is a linear cannot be ignored, but we assume that the drift is a linear
function of time, then the skew is given by s(t) = M*(t**2) + N*t function of time, then the skew is given by s(t) = M*(t**2) + N*t
+ S0, where M and N are constants and S0 is the skew at time 0. + S0, where M and N are constants and S0 is the skew at time 0.
The error added by the variable skew/drift process in this case The error added by the variable skew/drift process in this case
becomes e(t) = O + s(t) and the error added to the difference in becomes e(t) = O + s(t) and the error added to the difference in
time stamps is e(t2)-e(t1) = N*(t2-t1) + M*{(t2-t1)**2}. time stamps is e(t2)-e(t1) = N*(t2-t1) + M*{(t2-t1)**2}.
It is the claim here (see remarks in section 3.3) that the effects It is the claim here (see remarks in section 1.3) that the effects
of skew are rather small over the time scales that we are of skew are rather small over the time scales that we are
discussing here, since temperature variations in a system tend to discussing here, since temperature variations in a system tend to
be slow relative to packet inter-transmission times and the range be slow relative to packet inter-transmission times and the range
of drift is so small. of drift is so small.
+ As far as accuracy and resolution are concerned, what is noted in + As far as accuracy and resolution are concerned, what is noted in
the one-way-delay document [2] in section 3.7.1, applies also in the one-way-delay document [2] in section 3.7.1, applies also in
this case, with the further consideration, about resolution, that this case, with the further consideration, about resolution, that
in this case the uncertainty introduced is two times the one of a in this case the uncertainty introduced is two times the one of a
single delay measurement. Errors introduced by these effects are single delay measurement. Errors introduced by these effects are
often larger than the ones introduced by the drift. often larger than the ones introduced by the drift.
4.7.2. Errors/uncertainties related to Wire-time vs Host-time 2.7.2. Errors/uncertainties related to Wire-time vs Host-time
The content of sec. 3.7.2 of [2] applies also in this case, with the The content of sec. 3.7.2 of [2] applies also in this case, with the
following further consideration: The difference between Host-time and following further consideration: The difference between Host-time and
Wire-time can be in general decomposed into two components, of which Wire-time can be in general decomposed into two components, of which
one is constant and the other is variable. Only the variable one is constant and the other is variable. Only the variable
components will produce measurement errors, while the constant one components will produce measurement errors, while the constant one
will be canceled while calculating ipdv. will be canceled while calculating ipdv.
However, in most cases, the fixed and variable components are not However, in most cases, the fixed and variable components are not
known exactly. known exactly.
5. Definitions for Samples of One-way ipdv 3. Definitions for Samples of One-way-ipdv
The goal of the sample definition is to make it possible to compute The goal of the sample definition is to make it possible to compute
the statistics of sequences of ipdv measurements. The singleton the statistics of sequences of ipdv measurements. The singleton
definition is applied to a stream of test packets generated according definition is applied to a stream of test packets generated according
to a pseudo-random Poisson process with average arrival rate lambda. to a pseudo-random Poisson process with average arrival rate lambda.
If necessary, the interval in which the stream is generated can be If necessary, the interval in which the stream is generated can be
divided into sub-intervals on which the singleton definition of ipdv divided into sub-intervals on which the singleton definition of ipdv
can be applied. The result of this is a sequence of ipdv measurements can be applied. The result of this is a sequence of ipdv
that can be analyzed by various statistical procedures. measurements that can be analyzed by various statistical procedures.
Starting from the definition of the singleton metric of one-way ipdv, Starting from the definition of the singleton metric of one-way-ipdv,
we define a sample of such singletons. In the following, the two we define a sample of such singletons. In the following, the two
packets needed for a singleton measurement will be called a "pair". packets needed for a singleton measurement will be called a "pair".
5.1. Metric name 3.1. Metric name
Type-P-One-way-ipdv-Poisson-stream Type-P-One-way-ipdv-Poisson-stream
5.2. Parameters 3.2. Parameters
+ Src, the IP address of a host + Src, the IP address of a host
+ Dst, the IP address of a host + Dst, the IP address of a host
+ T0, a time + T0, a time
+ Tf, a time + Tf, a time
+ lambda, a rate in reciprocal seconds + lambda, a rate in reciprocal seconds
+ L, a packet length in bits. The packets of a Type P packet stream
+ L, a packet length in bits. The packets of a Type P packet stream
from which the sample ipdv metric is taken MUST all be of the same from which the sample ipdv metric is taken MUST all be of the same
length. length.
+ F, a selection function defining unambiguously the packets from + F, a selection function defining unambiguously the packets from
the stream selected for the metric. the stream selected for the metric.
+ I(i),I(i+1), i >=0, pairs of times which mark the beginning and + I(i),I(i+1), i >=0, pairs of times which mark the beginning and
ending of the intervals in which the packet stream from which the ending of the intervals in which the packet stream from which the
measurement is taken occurs. I(0) >= T0 and assuming that n is the measurement is taken occurs. I(0) >= T0 and assuming that n is
largest index, I(n) <= Tf. the largest index, I(n) <= Tf.
+ P, the specification of the packet type, over and above the source + P, the specification of the packet type, over and above the source
and destination addresses and destination addresses
5.3. Metric Units: 3.3. Metric Units:
A sequence of triples whose elements are: A sequence of triples whose elements are:
+ T1, T2,times + T1, T2,times
+ dT a real number or an undefined number of seconds + dT a real number or an undefined number of seconds
5.4. Definition 3.4. Definition
A pseudo-random Poisson process is defined such that it begins at or A pseudo-random Poisson process is defined such that it begins at or
before T0, with average arrival rate lambda, and ends at or after Tf. before T0, with average arrival rate lambda, and ends at or after Tf.
Those time values T(i) greater than or equal to T0 and less than or Those time values T(i) greater than or equal to T0 and less than or
equal to Tf are then selected for packet generation times. equal to Tf are then selected for packet generation times.
Each packet falling within one of the sub-intervals I(i), I(i+1) is Each packet falling within one of the sub-intervals I(i), I(i+1) is
tested to determine whether it meets the criteria of the selection tested to determine whether it meets the criteria of the selection
function F as the first or second of a packet pair needed to compute function F as the first or second of a packet pair needed to compute
ipdv. The sub-intervals can be defined such that a sufficient number ipdv. The sub-intervals can be defined such that a sufficient number
of singleton samples for valid statistical estimates can be obtained. of singleton samples for valid statistical estimates can be obtained.
The triples defined above consist of the transmission times of the The triples defined above consist of the transmission times of the
first and second packets of each singleton included in the sample, first and second packets of each singleton included in the sample,
and the ipdv in seconds. and the ipdv in seconds.
5.5. Discussion 3.5. Discussion
Note first that, since a pseudo-random number sequence is employed, Note first that, since a pseudo-random number sequence is employed,
the sequence of times, and hence the value of the sample, is not the sequence of times, and hence the value of the sample, is not
fully specified. Pseudo-random number generators of good quality will fully specified. Pseudo-random number generators of good quality
be needed to achieve the desired qualities. will be needed to achieve the desired qualities.
The sample is defined in terms of a Poisson process both to avoid the The sample is defined in terms of a Poisson process both to avoid the
effects of self-synchronization and also capture a sample that is effects of self-synchronization and also capture a sample that is
statistically as unbiased as possible. There is, of course, no claim statistically as unbiased as possible. There is, of course, no claim
that real Internet traffic arrives according to a Poisson arrival that real Internet traffic arrives according to a Poisson arrival
process. process.
The sample metric can best be explained with a couple of examples: The sample metric can best be explained with a couple of examples:
For the first example, assume that the selection function specifies For the first example, assume that the selection function specifies
the "non-infinite" max and min one-way-delays over each sub-interval. the "non-infinite" max and min one-way-delays over each sub-interval.
We can define contiguous sub-intervals of fixed specified length and We can define contiguous sub-intervals of fixed specified length and
produce a sequence each of whose elements is the triple <transmission produce a sequence each of whose elements is the triple <transmission
time of the max delay packet, transmission time of the min delay time of the max delay packet, transmission time of the min delay
packet, D(max)-D(min)> which is collected for each sub-interval. A packet, D(max)-D(min)> which is collected for each sub-interval. A
second example is the selection function that specifies packets whose second example is the selection function that specifies packets whose
indices (sequence numbers) are just the integers below a certain indices (sequence numbers) are just the integers below a certain
bound. In this case, the sub-intervals are defined by the bound. In this case, the sub-intervals are defined by the
transmission times of the generated packets and the sequence produced transmission times of the generated packets and the sequence produced
is just <T(i), T(i+1), D(i+1)-D(i)> where D(i) denotes the one-way is just <T(i), T(i+1), D(i+1)-D(i)> where D(i) denotes the one-way-
delay of the ith packet of a stream. delay of the ith packet of a stream.
This definition of the sample metric encompasses both the definition This definition of the sample metric encompasses both the definition
proposed in [8] and the one proposed in [9]. proposed in [9] and the one proposed in [10].
5.6. Methodology 3.6. Methodology
Since packets can be lost or duplicated or can arrive in a different Since packets can be lost or duplicated or can arrive in a different
order than the order sent, in order to recognize the pairs of test order than the order sent, the pairs of test packets should be marked
packets, they should be marked with a sequence number. For duplicated with a sequence number. For duplicated packets only the first
packets only the first received copy should be considered. received copy should be considered.
Otherwise, the methodology is the same as for the singleton Otherwise, the methodology is the same as for the singleton
measurement, with the exception that the singleton measurement is measurement, with the exception that the singleton measurement is
repeated a number of times. repeated a number of times.
5.7. Errors and uncertainties 3.7. Errors and uncertainties
The same considerations apply that have been made about the singleton The same considerations apply that have been made about the singleton
metric. Additional error can be introduced by the pseudo-random metric. Additional error can be introduced by the pseudo-random
Poisson process as discussed in [2]. Further considerations will be Poisson process as discussed in [2]. Further considerations will be
given in section 7. given in section 5.
6. Statistics for One-way-ipdv 4. Statistics for One-way-ipdv
Some statistics are suggested which can provide useful information in Some statistics are suggested which can provide useful information in
analyzing the behavior of the packets flowing from Src to Dst. The analyzing the behavior of the packets flowing from Src to Dst. The
statistics are assumed to be computed from an ipdv sample of statistics are assumed to be computed from an ipdv sample of
reasonable size. reasonable size.
The purpose is not to define every possible statistic for ipdv, but The purpose is not to define every possible statistic for ipdv, but
ones which have been proposed or used. ones which have been proposed or used.
6.1. Lost Packets and ipdv statistics 4.1. Lost Packets and ipdv statistics
The treatment of lost packets as having "infinite" or "undefined" The treatment of lost packets as having "infinite" or "undefined"
delay complicates the derivation of statistics for ipdv. delay complicates the derivation of statistics for ipdv.
Specifically, when packets in the measurement sequence are lost, Specifically, when packets in the measurement sequence are lost,
simple statistics such as sample mean cannot be computed. One simple statistics such as sample mean cannot be computed. One
possible approach to handling this problem is to reduce the event possible approach to handling this problem is to reduce the event
space by conditioning. That is, we consider conditional statistics; space by conditioning. That is, we consider conditional statistics;
namely we estimate the mean ipdv (or other derivative statistic) namely we estimate the mean ipdv (or other derivative statistic)
conditioned on the event that selected packet pairs arrive at the conditioned on the event that selected packet pairs arrive at the
destination (within the given timeout). While this itself is not destination (within the given timeout). While this itself is not
without problems (what happens, for example, when every other packet without problems (what happens, for example, when every other packet
is lost), it offers a way to make some (valid) statements about ipdv, is lost), it offers a way to make some (valid) statements about ipdv,
at the same time avoiding events with undefined outcomes. at the same time avoiding events with undefined outcomes.
In practical terms, what this means is throwing out the samples where In practical terms, what this means is throwing out the samples where
one or both of the selected packets has an undefined delay. The one or both of the selected packets has an undefined delay. The
sample space is reduced (conditioned) and we can compute the usual sample space is reduced (conditioned) and we can compute the usual
statistics, understanding that formally they are conditional. statistics, understanding that formally they are conditional.
6.2. Distribution of One-way-ipdv values 4.2. Distribution of One-way-ipdv values
The one-way-ipdv values are limited by virtue of the fact that there The one-way-ipdv values are limited by virtue of the fact that there
are upper and lower bounds on the one-way-delay values. Specifically, are upper and lower bounds on the one-way-delay values.
one-way-delay is upper bounded by the value chosen as the maximum Specifically, one-way-delay is upper bounded by the value chosen as
beyond which a packet is counted as lost. It is lower bounded by the maximum beyond which a packet is counted as lost. It is lower
propagation, transmission and nodal transit delays assuming that bounded by propagation, transmission and nodal transit delays
there are no queues or variable nodal delays in the path. Denote the assuming that there are no queues or variable nodal delays in the
upper bound of one-way-delay by U and the lower bound by L and we see path. Denote the upper bound of one-way-delay by U and the lower
that one-way-ipdv can only take on values in the (open) interval (L- bound by L and we see that one-way-ipdv can only take on values in
U, U-L). the (open) interval (L-U, U-L).
In any finite interval, the one-way-delay can vary monotonically In any finite interval, the one-way-delay can vary monotonically
(non-increasing or non-decreasing) or of course it can vary in both (non-increasing or non-decreasing) or of course it can vary in both
directions in the interval, within the limits of the half-open directions in the interval, within the limits of the half-open
interval [L,U). Accordingly, within that interval, the one-way-ipdv interval [L,U). Accordingly, within that interval, the one-way-ipdv
values can be positive, negative, or a mixture (including 0). values can be positive, negative, or a mixture (including 0).
Since the range of values is limited, the one-way-ipdv cannot Since the range of values is limited, the one-way-ipdv cannot
increase or decrease indefinitely. Suppose, for example, that the increase or decrease indefinitely. Suppose, for example, that the
ipdv has a positive 'run' (i.e. a long sequence of positive values). ipdv has a positive 'run' (i.e., a long sequence of positive values).
At some point in this 'run', the positive values must approach 0 (or At some point in this 'run', the positive values must approach 0 (or
become negative) if the one-way-delay remains finite. Otherwise, the become negative) if the one-way-delay remains finite. Otherwise, the
one-way-delay bounds would be violated. If such a run were to one-way-delay bounds would be violated. If such a run were to
continue infinitely long, the sample mean (assuming no packets are continue infinitely long, the sample mean (assuming no packets are
lost) would approach 0 (because the one-way-ipdv values must approach lost) would approach 0 (because the one-way-ipdv values must approach
0). Note, however, that this says nothing about the shape of the 0). Note, however, that this says nothing about the shape of the
distribution, or whether it is symmetric. Note further that over distribution, or whether it is symmetric. Note further that over
significant intervals, depending on the width of the interval [L,U), significant intervals, depending on the width of the interval [L,U),
that the sample mean one-way-ipdv could be positive, negative or 0. that the sample mean one-way-ipdv could be positive, negative or 0.
There are basically two ways to represent the distribution of values There are basically two ways to represent the distribution of values
of an ipdv sample: an empirical pdf and an empirical cdf. The of an ipdv sample: an empirical pdf and an empirical cdf. The
empirical pdf is most often represented as a histogram where the empirical pdf is most often represented as a histogram where the
range of values of an ipdv sample is divided into bins of a given range of values of an ipdv sample is divided into bins of a given
length and each bin contains the proportion of values falling between length and each bin contains the proportion of values falling between
the two limits of the bin. (Sometimes instead the number of values the two limits of the bin. (Sometimes instead the number of values
falling between the two limits is used). The empirical cdf is simply falling between the two limits is used). The empirical cdf is simply
the proportion of ipdv sample values less than a given value, for a the proportion of ipdv sample values less than a given value, for a
sequence of values selected from the range of ipdv values. sequence of values selected from the range of ipdv values.
6.3. Type-P-One-way-ipdv-percentile 4.3. Type-P-One-way-ipdv-percentile
Given a Type-P One-Way-ipdv sample and a percent X between 0% and Given a Type-P One-Way-ipdv sample and a given percent X between 0%
100%, the Xth percentile of all ipdv values in the sample. The 50th and 100%. The Xth percentile of all ipdv values is in the sample.
percentile is the median. Therefore, then 50th percentile is the median.
6.4. Type-P-One-way-ipdv-inverse-percentile 4.4. Type-P-One-way-ipdv-inverse-percentile
Given a Type-P-One-way-ipdv sample and a given value Y, the percent Given a Type-P-One-way-ipdv sample and a given value Y, the percent
of ipdv sample values less than or equal to Y. of ipdv sample values less than or equal to Y.
6.5. Type-P-One-way-ipdv-jitter 4.5. Type-P-One-way-ipdv-jitter
Although the use of the term "jitter" is deprecated, we use it here Although the use of the term "jitter" is deprecated, we use it here
following the authors in [7]. In that document, the selection following the authors in [8]. In that document, the selection
function specifies that consecutive packets of the Type-P stream are function specifies that consecutive packets of the Type-P stream are
to be selected for the packet pairs used in ipdv computation. They to be selected for the packet pairs used in ipdv computation. They
then take the absolute value of the ipdv values in the sample. The then take the absolute value of the ipdv values in the sample. The
authors in [7] use the resulting sample to compare the behavior of authors in [8] use the resulting sample to compare the behavior of
two different scheduling algorithms. two different scheduling algorithms.
An alternate, but related, way of computing an estimate of jitter is An alternate, but related, way of computing an estimate of jitter is
given in RFC 1889 [11]. The selection function there is implicitly given in RFC 1889 [11]. The selection function there is implicitly
consecutive packet pairs, and the "jitter estimate" is computed by consecutive packet pairs, and the "jitter estimate" is computed by
taking the absolute values of the ipdv sequence (as defined in this taking the absolute values of the ipdv sequence (as defined in this
draft) and applying an exponential filter with parameter 1/16 to document) and applying an exponential filter with parameter 1/16 to
generate the estimate (i.e. j_new = 15/16* j_old + 1/16*j_new). generate the estimate (i.e., j_new = 15/16* j_old + 1/16*j_new).
6.6. Type-P-One-way-peak-to-peak-ipdv 4.6. Type-P-One-way-peak-to-peak-ipdv
In this case, the selection function used in collecting the Type-P- In this case, the selection function used in collecting the Type-P-
One-Way-ipdv sample specifies that the first packet of each pair to One-Way-ipdv sample specifies that the first packet of each pair to
be the packet with the maximum Type-P-One-Way-Delay in each sub- be the packet with the maximum Type-P-One-Way-Delay in each
interval and the second packet of each pair to be the packet with the subinterval and the second packet of each pair to be the packet with
minimum Type-P-One-Way-Delay in each sub-interval. The resulting the minimum Type-P-One-Way-Delay in each sub-interval. The resulting
sequence of values is the peak-to-peak delay variation in each sub- sequence of values is the peak-to-peak delay variation in each
interval of the measurement interval. subinterval of the measurement interval.
7. Discussion of clock synchronization 5. Discussion of clock synchronization
This section gives some considerations about the need for having This section gives some considerations about the need for having
synchronized clocks at the source and destination, although in the synchronized clocks at the source and destination, although in the
case of unsynchronized clocks, data from the measurements themselves case of unsynchronized clocks, data from the measurements themselves
can be used to correct error. These considerations are given as a can be used to correct error. These considerations are given as a
basis for discussion and they require further investigation. basis for discussion and they require further investigation.
7.1. Effects of synchronization errors 5.1. Effects of synchronization errors
Clock errors can be generated by two processes: the relative drift Clock errors can be generated by two processes: the relative drift
and the relative skew of two given clocks. We should note that drift and the relative skew of two given clocks. We should note that drift
is physically limited and so the total relative skew of two clocks is physically limited and so the total relative skew of two clocks
can vary between an upper and a lower bound. can vary between an upper and a lower bound.
Suppose then that we have a measurement between two systems such that Suppose then that we have a measurement between two systems such that
the clocks in the source and destination systems have at time 0 a the clocks in the source and destination systems have at time 0 a
relative skew of s(0) and after a measurement interval T have skew relative skew of s(0) and after a measurement interval T have skew
s(T). We assume that the two clocks have an initial offset of O (that s(T). We assume that the two clocks have an initial offset of O
is letter O). (that is letter O).
Now suppose that the packets travel from source to destination in Now suppose that the packets travel from source to destination in
constant time, in which case the ipdv is zero and the difference in constant time, in which case the ipdv is zero and the difference in
the time stamps of the two clocks is actually just the relative the time stamps of the two clocks is actually just the relative
offset of the clocks. Suppose further that at the beginning of the offset of the clocks. Suppose further that at the beginning of the
measurement interval the ipdv value is calculated from a packet pair measurement interval the ipdv value is calculated from a packet pair
and at the end of the measurement interval another ipdv value is and at the end of the measurement interval another ipdv value is
calculated from another packet pair. Assume that the time interval calculated from another packet pair. Assume that the time interval
covered by the first measurement is t1 and that covered by the second covered by the first measurement is t1 and that the time interval
measurement is t2. Then covered by the second measurement is t2. Then
ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T
ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T
assuming that the change is skew is linear in time. In most practical assuming that the change in skew is linear in time. In most
cases, it is claimed that the drift will be close to zero in which practical cases, it is claimed that the drift will be close to zero
case the second (correction) term in the above equations disappears. in which case the second (correction) term in the above equations
disappears.
Note that in the above discussion, other errors, including the Note that in the above discussion, other errors, including the
differences between host time and wire time, and externally-caused differences between host time and wire time, and externally-caused
clock discontinuities (e.g. clock corrections) were ignored. Under clock discontinuities (e.g., clock corrections) were ignored. Under
these assumptions the maximum clock errors will be due to the maximum these assumptions the maximum clock errors will be due to the maximum
relative skew acting on the largest interval between packets. relative skew acting on the largest interval between packets.
7.2. Estimating the skew of unsynchronized clocks 5.2. Estimating the skew of unsynchronized clocks
If the skew is linear (that is, if s(t) = S * t for constant S), the If the skew is linear (that is, if s(t) = S * t for constant S), the
error in ipdv values will depend on the time between the packets used error in ipdv values will depend on the time between the packets used
in calculating the value. If ti is the time between the packet pair, in calculating the value. If ti is the time between the packet pair,
then let Ti denote the sample mean time between packets and the then let Ti denote the sample mean time between packets and the
average skew is s(Ti) = S * Ti. In the event that the delays are average skew is s(Ti) = S * Ti. In the event that the delays are
constant, the skew parameter S can be estimated from the estimate Ti constant, the skew parameter S can be estimated from the estimate Ti
of the time between packets and the sample mean ipdv value. Under of the time between packets and the sample mean ipdv value. Under
these assumptions, the ipdv values can be corrected by subtracting these assumptions, the ipdv values can be corrected by subtracting
the estimated S * ti. the estimated S * ti.
We observe that the displacement due to the skew does not change the We observe that the displacement due to the skew does not change the
shape of the distribution, and, for example the Standard Deviation shape of the distribution, and, for example the Standard Deviation
remains the same. What introduces a distortion is the effect of the remains the same. What introduces a distortion is the effect of the
drift, also when the mean value of this effect is zero at the end of drift, also when the mean value of this effect is zero at the end of
the measurement. The value of this distortion is limited to the the measurement. The value of this distortion is limited to the
effect of the total skew variation on the emission interval. effect of the total skew variation on the emission interval.
8. Security Considerations 6. Security Considerations
The one-way-ipdv metric has the same security properties as the one- The one-way-ipdv metric has the same security properties as the one-
way-delay metric [2], and thus they inherit the security way-delay metric [2], and thus they inherit the security
considerations of that document. The reader should consult [2] for a considerations of that document. The reader should consult [2] for a
more detailed treatment of security considerations. Nevertheless, more detailed treatment of security considerations. Nevertheless,
there are a few things to highlight. there are a few things to highlight.
8.1. Denial of service 6.1. Denial of service
It is still possible that there could be an attempt at a denial of It is still possible that there could be an attempt at a denial of
service attack by sending many measurement packets into the network. service attack by sending many measurement packets into the network.
In general, legitimate measurements must have their parameters In general, legitimate measurements must have their parameters
carefully selected in order to avoid interfering with normal traffic. carefully selected in order to avoid interfering with normal traffic.
8.2. Privacy/Confidentiality 6.2. Privacy/Confidentiality
The packets contain no user information, and so privacy of user data The packets contain no user information, and so privacy of user data
is not a concern. is not a concern.
8.3. Integrity 6.3. Integrity
There could also be attempts to disrupt measurements by diverting There could also be attempts to disrupt measurements by diverting
packets or corrupting them. To ensure that test packets are valid and packets or corrupting them. To ensure that test packets are valid
have not be altered during transit, packet authentication and and have not been altered during transit, packet authentication and
integrity checks may be used. integrity checks may be used.
9. Acknowledgments 7. Acknowledgments
Thanks to Merike Kaeo, Al Morton and Henk Uiterwaal for catching Thanks to Merike Kaeo, Al Morton and Henk Uiterwaal for catching
mistakes and for clarifying re-wordings for this final draft. mistakes and for clarifying re-wordings for this final document.
A previous major revision of the draft resulted from e-mail A previous major revision of the document resulted from e-mail
discussions with and suggestions from Mike Pierce, Ruediger Geib, discussions with and suggestions from Mike Pierce, Ruediger Geib,
Glenn Grotefeld, and Al Morton. For previous revisions of this Glenn Grotefeld, and Al Morton. For previous revisions of this
document, discussions with Ruediger Geib, Matt Zekauskas and Andy document, discussions with Ruediger Geib, Matt Zekauskas and Andy
Scherer were very helpful. Scherer were very helpful.
10. References 8. References
[1] V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP
Performance Metrics", RFC 2330 Feb. 1998 (Normative)
[2] G.Almes, S.Kalidindi - "A One-Way-Delay Metric for IPPM", RFC 8.1 Normative References
2679, September 1999 (Normative)
[3] ITU-T Recommendation Y.1540 (formerly numbered I.380) [1] Paxon, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
"Internet Protocol Data Communication Service - IP Packet IP Performance Metrics", RFC 2330, February 1998.
Transfer and Availability Performance Parameters", February 1999
[4] Demichelis, Carlo - "Packet Delay Variation Comparison between [2] Almes, G. and S. Kalidindisu, "A One-Way-Delay Metric for IPPM",
RFC 2679, September 1999.
[3] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
8.2 Informational References
[4] ITU-T Recommendation Y.1540 (formerly numbered I.380) "Internet
Protocol Data Communication Service - IP Packet Transfer and
Availability Performance Parameters", February 1999.
[5] Demichelis, Carlo - "Packet Delay Variation Comparison between
ITU-T and IETF Draft Definitions" November 2000 (in the IPPM ITU-T and IETF Draft Definitions" November 2000 (in the IPPM
mail archives) mail archives).
[5] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer [6] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer
Performance" Performance".
[6] S. Keshav - "An Engineering Approach to Computer Networking", [7] S. Keshav - "An Engineering Approach to Computer Networking",
Addison-Wesley 1997, ISBN 0-201-63442-2 Addison-Wesley 1997, ISBN 0-201-63442-2.
[7] V. Jacobson, K. Nichols, K. Poduri - "An expedited forwarding [8] Jacobson, V., Nichols, K. and Poduri, K. "An Expedited
PHB", RFC 2598, June 1999 Forwarding PHB", RFC 2598, June 1999.
[8] ITU-T Draft Recommendation Y.1541 - "Internet Protocol [9] ITU-T Draft Recommendation Y.1541 - "Internet Protocol
Communication Service - IP Performance and Availability Communication Service - IP Performance and Availability
Objectives and Allocations", April 2000 Objectives and Allocations", April 2000.
[9] Demichelis, Carlo - "Improvement of the Instantaneous Packet [10] Demichelis, Carlo - "Improvement of the Instantaneous Packet
Delay Variation (IPDV) Concept and Applications", World Delay Variation (IPDV) Concept and Applications", World
Telecommunications Congress 2000, 7-12 May 2000 Telecommunications Congress 2000, 7-12 May 2000.
[10] Bradner, Scott - "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997
[11] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson - "RTP: A [11] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
transport protocol for real-time applications", RFC 1889, "RTP: A transport protocol for real-time applications", RFC
January 1996 1889, January 1996.
11. Authors' Addresses 9. Authors' Addresses
Carlo Demichelis <carlo.demichelis@cselt.it> Carlo Demichelis
CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A Telecomitalia Lab S.p.A
Via G. Reiss Romoli 274 Via G. Reiss Romoli 274
10148 - TORINO 10148 - TORINO
Italy Italy
Phone +39 11 228 5057
Fax. +39 11 228 5069 Phone: +39 11 228 5057
Philip Chimento <chimento@torrentnet.com> Fax: +39 11 228 5069
EMail: carlo.demichelis@tilab.com
Philip Chimento
Ericsson IPI Ericsson IPI
7301 Calhoun Place 7301 Calhoun Place
Rockville, Maryland Rockville, Maryland 20855
20855
USA USA
Phone +1-240-314-3597
Expiration date: October 2002 Phone: +1-240-314-3597
EMail: chimento@torrentnet.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 171 change blocks. 
281 lines changed or deleted 322 lines changed or added

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