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/ |