draft-ietf-ippm-ipdv-08.txt   draft-ietf-ippm-ipdv-09.txt 
Network Working Group C. Demichelis Network Working Group C. Demichelis
INTERNET-DRAFT CSELT INTERNET-DRAFT CSELT
Expiration Date: May 2002 P. Chimento Expiration Date: October 2002 P. Chimento
Ericsson IPI Ericsson IPI
November 2001 April 2002
IP Packet Delay Variation Metric for IPPM IP Packet Delay Variation Metric for IPPM
<draft-ietf-ippm-ipdv-08.txt> <draft-ietf-ippm-ipdv-09.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 RFC 2026. all provisions of Section 10 of RFC 2026.
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 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 RFC 2119 [10].
Although RFC 2119 was written with protocols in mind, the key words | Although RFC 2119 was written with protocols in mind, the key words
are used in this document for similar reasons. They are used to | are used in this document for similar reasons. They are used to
ensure the results of measurements from two different implementations | ensure the results of measurements from two different implementations
are comparable and to note instances where an implementation could | are comparable and to note instances where an implementation could
perturb the network. | perturb the network.
The structure of the memo is as follows: | The structure of the memo is as follows:
+ A 'singleton' anlaytic 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, as '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 3.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 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. | stream going from measurement 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 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 play-out
for applications requiring the regular delivery of packets (for buffers for applications requiring the regular delivery of packets
example, voice or video playout). What is normally important in this (for example, voice or video play-out). What is normally important in
case is the maximum delay variation, which is used to size playout this case is the maximum delay variation, which is used to size play-
buffers for such applications [6]. Other uses of a delay variation out buffers for such applications [6]. Other uses of a delay
metric are, for example, to determine the dynamics of queues within a variation metric are, for example, to determine the dynamics of
network (or router) where the changes in delay variation can be queues within a network (or router) where the changes in delay
linked to changes in the queue length process at a given link or a variation can be linked to changes in the queue length process at 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 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. Since the metric does not represent a value judgement (i.e. exactly. Since the metric does not represent a value judgment (i.e.
define "good" and "bad"), ee 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 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
skipping to change at page 6, line 29 skipping to change at page 6, line 36
+ 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 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 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.
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 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
skipping to change at page 8, line 37 skipping to change at page 8, line 43
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
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,
the packet size is a parameter of the measurement and must be
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. reassembly 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 draft 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]. The reason for Poisson sampling is that it ensures an unbiased
and uniformly distributed sampling of times between I1 and I2. | and uniformly distributed sampling of times between I1 and I2.
However, alternate sampling methodologies are possible. For example, | However, alternate sampling methodologies are possible. For example,
continuous sampling of a constant bit rate stream (i.e. periodic | continuous sampling of a constant bit rate stream (i.e. periodic
packet transmission) is a possibility. However, in this case, one | 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 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 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
skipping to change at page 10, line 11 skipping to change at page 10, line 24
+ 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, 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 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
skipping to change at page 13, line 46 skipping to change at page 14, line 21
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 specifiec 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 [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 16, line 31 skipping to change at page 17, line 5
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 | 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 | 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). 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.
7. Discussion of clock synchronization 7. Discussion of clock synchronization
This section gives some considerations about the need of having This section gives some considerations about the need for having
synchronized clocks at the source and destination. These synchronized clocks at the source and destination, although in the
considerations are given as a basis for discussion and they require case of unsynchronized clocks, data from the measurements themselves
further investigation. can be used to correct error. These considerations are given as a
basis for discussion and they require further investigation.
7.1. Effects of synchronization errors 7.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 (that
is letter O). 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 timestamps of the two clocks is actually just the relative offset the time stamps of the two clocks is actually just the relative
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 covered by the second
measurement is t2. Then 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
skipping to change at page 18, line 27 skipping to change at page 18, line 43
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 8. 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]. The packets contain no user information, and so way-delay metric [2], and thus they inherit the security
privacy of user data is not a concern. It is still possible that considerations of that document. The reader should consult [2] for a
there could be an attempt at a denial of service attack by sending more detailed treatment of security considerations. Nevertheless,
many measurement packets into the network; there could also be there are a few things to highlight.
attempts to disrupt measurements by diverting packets or corrupting
them. 8.1. Denial of service
It is still possible that there could be an attempt at a denial of
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
selected carefully in order to avoid interfering with normal traffic carefully selected in order to avoid interfering with normal traffic.
in the network. Such measurements should also be authorized and
authenticated in some way so that attacks can be identified and
intercepted.
9. Acknowledgements 8.2. Privacy/Confidentiality
This major revision of the draft resulted from e-mail discussions The packets contain no user information, and so privacy of user data
with and suggestions from Mike Pierce, Ruediger Geib, Glenn is not a concern.
Grotefeld, and Al Morton. For previous revisions of this document,
discussions with Ruediger Geib, Matt Zekauskas and Andy Scherer were 8.3. Integrity
very helpful.
There could also be attempts to disrupt measurements by diverting
packets or corrupting them. To ensure that test packets are valid and
have not be altered during transit, packet authentication and
integrity checks may be used.
9. Acknowledgments
Thanks to Merike Kaeo, Al Morton and Henk Uiterwaal for catching
mistakes and for clarifying re-wordings for this final draft.
A previous major revision of the draft resulted from e-mail
discussions with and suggestions from Mike Pierce, Ruediger Geib,
Glenn Grotefeld, and Al Morton. For previous revisions of this
document, discussions with Ruediger Geib, Matt Zekauskas and Andy
Scherer were very helpful.
10. References 10. References
[1] V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP [1] V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP
Performance Metrics", RFC 2330 Feb. 1998 Performance Metrics", RFC 2330 Feb. 1998 (Normative)
[2] G.Almes, S.Kalidindi - "A One-Way-Delay Metric for IPPM", RFC [2] G.Almes, S.Kalidindi - "A One-Way-Delay Metric for IPPM", RFC
2679, September 1999 2679, September 1999 (Normative)
[3] ITU-T Recommendation Y.1540 (formerly numbered I.380) [3] ITU-T Recommendation Y.1540 (formerly numbered I.380)
"Internet Protocol Data Communication Service - IP Packet "Internet Protocol Data Communication Service - IP Packet
Transfer and Availability Performance Parameters", February 1999 Transfer and Availability Performance Parameters", February 1999
[4] Demichelis, Carlo - "Packet Delay Variation Comparison between [4] 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 [5] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer
skipping to change at page 19, line 37 skipping to change at page 20, line 24
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 | [10] Bradner, Scott - "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997 | requirement levels", RFC 2119, March 1997
[11] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson - "RTP: A | [11] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson - "RTP: A
transport protocol for real-time applications", RFC 1889, | transport protocol for real-time applications", RFC 1889,
January 1996 | 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
skipping to change at page 20, line 14 skipping to change at page 21, line 4
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: May 2002 Expiration date: October 2002
 End of changes. 

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