draft-ietf-ippm-ipdv-07.txt   draft-ietf-ippm-ipdv-08.txt 
Network Working Group C. Demichelis Network Working Group C. Demichelis
INTERNET-DRAFT CSELT INTERNET-DRAFT CSELT
Expiration Date: August 2001 P. Chimento Expiration Date: May 2002 P. Chimento
Ericsson IPI Ericsson IPI
February 2001 November 2001
IP Packet Delay Variation Metric for IPPM IP Packet Delay Variation Metric for IPPM
<draft-ietf-ippm-ipdv-07.txt> <draft-ietf-ippm-ipdv-08.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Internet paths. The metric is based on the difference in the One-Way- Internet paths. The metric is based on the difference in the One-Way-
Delay of selected packets. This difference in delay is called "IP Delay of selected packets. This difference in delay is called "IP
Packet Delay variation." Packet Delay variation."
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 draft.
3. Introduction 3. Introduction
This memo is based on "A One-Way-Delay metric for IPPM", RFC 2679 This memo defines a metric for the variation in delay of packets that |
[2]. 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 |
this memo is taken directly from that document; the reader is assumed |
to be familiar with that document. |
Part of the text in this memo is taken directly from that document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this |
document are to be interpreted as described in RFC 2119 [10]. |
Although RFC 2119 was written with protocols in mind, the key words |
are used in this document for similar reasons. They are used to |
ensure the results of measurements from two different implementations |
are comparable and to note instances where an implementation could |
perturb the network. |
This memo defines a metric for variation in delay of packets that The structure of the memo is as follows: |
flow from one host to another one through an IP path. This quantity
is sometimes called "jitter". This term, however, causes confusion
because it is used in different ways by different groups of people.
"Jitter" commonly has two meanings: The first meaning is the + A 'singleton' anlaytic metric, called Type-P-One-way-ipdv, will be |
variation of a signal with respect to some clock signal, where the introduced to define a single instance of an ipdv measurement. |
arrival time of the signal is expected to coincide with the arrival
of the clock signal. 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 minimum delay).
The first meaning is used with reference to synchronous signals and + Using this singleton metric, as 'sample', called Type-P-one-way- |
might be used to measure the quality of circuit emulation, for ipdv-Poisson-stream, will be introduced to make it possible to |
example. There is also a metric called "wander" used in this context. compute the statistics of sequences of ipdv measurements. |
The second meaning is frequently used by computer scientists and
frequently (but not always) refers to variation in delay. + Using this sample, several 'statistics' of the sample will be |
defined and discussed. |
3.1. Terminology
The variation in packet delay is sometimes called "jitter". This
term, however, causes confusion because it is used in different ways
by different groups of people.
"Jitter" commonly has two meanings: The first meaning is 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 |
of the clock signal. This meaning is used with reference to |
synchronous signals and might be used to measure the quality of |
circuit emulation, for example. There is also a metric called |
"wander" used in this context. |
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 |
minimum delay). This meaning is frequently used by computer |
scientists and frequently (but not always) refers to variation in |
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.1. Definition 3.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 IP Packet Delay Variation (ipdv) of a pair of packets within a
stream of packets is defined for a selected pair of packets in the stream of packets is defined for a selected pair of packets in the
stream going from measurement point MP1 to measurement point MP2 is stream going from measurement point MP1 to measurement point MP2. |
the difference between the one-way-delay of the first of the selected The ipdv is the difference between the one-way-delay of the selected |
packets and the one-way-delay of the second of the selected packets. packets.
3.2. Motivation 3.3. Motivation
One important use of delay variation is the sizing of playout buffers One important use of delay variation is the sizing of playout buffers
for applications requiring the regular delivery of packets (for for applications requiring the regular delivery of packets (for
example, voice or video playout). What is normally important in this example, voice or video playout). What is normally important in this
case is the maximum delay variation, which is used to size playout case is the maximum delay variation, which is used to size playout
buffers for such applications [6]. Other uses of a delay variation buffers for such applications [6]. Other uses of a delay variation
metric are, for example, to determine the dynamics of queues within a metric are, for example, to determine the dynamics of queues within a
network (or router) where the changes in delay variation can be network (or router) where the changes in delay variation can be
linked to changes in the queue length process at a given link or a linked to changes in the queue length process at a given link or a
combination of links. 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
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 report
of the metric MUST include all the parameters associated with it so of the metric MUST include all the parameters associated with it so
that the conditions and meaning of the metric can be determined that the conditions and meaning of the metric can be determined
exactly. We specifically do not specify particular values of the exactly. Since the metric does not represent a value judgement (i.e.
metrics that IP networks must meet. define "good" and "bad"), ee specifically do not specify particular
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 community
of what precisely the definition should be (e.g. [7],[8],[9]). The of what precisely the definition should be (e.g. [7],[8],[9]). The
idea here is to parameterize the definition, rather than write a idea here is to parameterize the definition, rather than write a
different draft for each proposed definition. As long as all the different draft for each proposed definition. As long as all the
parameters are reported, it will be clear what is meant by a parameters are reported, it will be clear what is meant by a
particular use of ipdv. All the remarks in the draft hold, no matter particular use of ipdv. All the remarks in the draft hold, no matter
which parameters are chosen. which parameters are chosen.
3.3. General Issues Regarding Time 3.4. General Issues Regarding Time
Everything contained in the 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:
skipping to change at page 6, line 12 skipping to change at page 6, line 29
+ 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 4.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 4.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 MP2 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 MP2 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 of the type-P-One-Way-Delay from Src to Dst at T1. T1 is the value of the type-P-One-Way-Delay from Src to Dst at T1. T1 is the
wire-time at which Scr sent the first bit of the first packet, and T2 wire-time at which Scr sent the first bit of the first packet, and T2
is the wire-time at which Src sent the first bit of the second is the wire-time at which Src sent the first bit of the second
packet. This metric is derived from the One-Way-Delay metric. packet. This metric is derived from the One-Way-Delay metric. |
T2 denote the wire times of the packets sent from Src to Dst.
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 |
P(k) are selected. |
I1 P(i) P(j) P(k) I2 |
MP1 |
|----------------------------------------------------------------| |
|\ |\ |\ |
| \ | \ | \ |
| \ | \ | \ |
| \ | \ | \ |
|dTi \ |dTj \ |dTk \ |
|<--->v |<--->v |<--->v |
MP2 |
|----------------------------------------------------------------| |
I1 P(i) P(j) P(k) I2 |
Figure 1: Illustration of the definition |
Then ddT = dTk - dTi as defined above.
4.5. Discussion 4.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
skipping to change at page 8, line 5 skipping to change at page 8, line 45
precedence or with RSVP). precedence or with RSVP).
+ 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. reassembly does not occur, then the packet will be deemed lost.
It is assumed that the Type-P packet stream is generated according to In this draft it is assumed that the Type-P packet stream is |
the Poisson sampling methodology described in [1]. generated according to the Poisson sampling methodology described in |
[1]. The reason for Poisson sampling is that it ensures an unbiased |
and uniformly distributed sampling of times between I1 and I2. |
However, 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 |
periodic samples.
4.6. Methodologies 4.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 asssumes the The measurement methodology described in this section asssumes 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: follows: Note that this methodology is based on synchronized clocks.
The need for synchronized clocks for Src and Dst will be discussed
+ The need of synchronized clocks for Src and Dst will be discussed later.
later. Here a methodology is supposed that is based on
synchronized clocks.
+ After time I1, start. 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.
skipping to change at page 9, line 10 skipping to change at page 10, line 11
+ 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 timestamp in the Type-P given methodology. The Src host places a timestamp 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
timestamp as soon as possible upon the receipt of the packet. By timestamp as soon as possible upon the receipt of the packet. By
subtracting the two timestamps, an estimate of One-Way-Delay can subtracting the two timestamps, an estimate of One-Way-Delay can
be computed. be computed.
+ If the packet meets the criterion for the second packet for the + If the packet meets the criterion for the second packet, then by |
second packet, then by subtracting the second value of One-Way- subtracting the first value of One-Way-Delay from the second value |
Delay from the first value the ipdv value of the pair of packets the ipdv value of the pair of packets is obtained. Otherwise,
is obtained. Otherwise, packets continue to be generated until packets continue to be generated until the criterion for the
the criterion for the second packet is fulfilled or I2, whichever second packet is fulfilled or I2, whichever comes first.
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 4.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.
skipping to change at page 13, line 7 skipping to change at page 14, line 7
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 specifiec length and We can define contiguous sub-intervals of fixed specifiec 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)-D(i+1)> 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 [8] and the one proposed in [9].
5.6. Methodology 5.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, in order to recognize the pairs of test
packets, they should be marked with a sequence number. For duplicated packets, they should be marked with a sequence number. For duplicated
skipping to change at page 15, line 31 skipping to change at page 16, line 31
6.5. Type-P-One-way-ipdv-jitter 6.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 [7]. 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 [7] 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 |
given in RFC 1889 [11]. The selection function there is implicitly |
consecutive packet pairs, and the "jitter estimate" is computed by |
taking the absolute values of the ipdv sequence (as defined in this |
draft) 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).
6.6. Type-P-One-way-peak-to-peak-ipdv 6.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 sub-
interval and the second packet of each pair to be the packet with the interval and the second packet of each pair to be the packet with the
minimum Type-P-One-Way-Delay in each sub-interval. The resulting 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 sub-
interval of the measurement interval. interval of the measurement interval.
skipping to change at page 18, line 37 skipping to change at page 19, line 37
PHB", RFC 2598, June 1999 PHB", RFC 2598, June 1999
[8] ITU-T Draft Recommendation Y.1541 - "Internet Protocol [8] 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 [9] 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 |
transport protocol for real-time applications", RFC 1889, |
January 1996 |
11. Authors' Addresses 11. Authors' Addresses
Carlo Demichelis <carlo.demichelis@cselt.it> Carlo Demichelis <carlo.demichelis@cselt.it>
CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A
Via G. Reiss Romoli 274 Via G. Reiss Romoli 274
10148 - TORINO 10148 - TORINO
Italy Italy
Phone +39 11 228 5057 Phone +39 11 228 5057
Fax. +39 11 228 5069 Fax. +39 11 228 5069
Philip Chimento <chimento@torrentnet.com> Philip Chimento <chimento@torrentnet.com>
Ericsson IPI Ericsson IPI
7301 Calhoun Place 7301 Calhoun Place
Rockville, Maryland Rockville, Maryland
20855 20855
USA USA
Phone +1-240-314-3597 Phone +1-240-314-3597
Expiration date: August 2001 Expiration date: May 2002
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/