draft-ietf-ippm-ipdv-05.txt | draft-ietf-ippm-ipdv-06.txt | |||
---|---|---|---|---|

Network Working Group C. Demichelis | Network Working Group C. Demichelis | |||

INTERNET-DRAFT CSELT | INTERNET-DRAFT CSELT | |||

Expiration Date: December 2000 P. Chimento | Expiration Date: August 2001 P. Chimento | |||

CTIT | Ericsson IPI | |||

July 2000 | February 2001 | |||

Instantaneous Packet Delay Variation Metric for IPPM | IP Packet Delay Variation Metric for IPPM | |||

<draft-ietf-ippm-ipdv-05.txt> | <draft-ietf-ippm-ipdv-06.txt> | |||

1. Status of this Memo | 1. Status of this Memo | |||

This document is an Internet-Draft and is in full conformance with | | This document is an Internet-Draft and is in full conformance with | |||

all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||

Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||

Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||

other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||

Drafts. | Drafts. | |||

Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||

and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||

time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||

material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||

The list of current Internet-Drafts can be accessed at | | The list of current Internet-Drafts can be accessed at | |||

http://www.ietf.org/ietf/1id-abstracts.txt | | http://www.ietf.org/ietf/1id-abstracts.txt | |||

The list of Internet-Draft shadow directories can be accessed at | | The list of Internet-Draft shadow directories can be accessed at | |||

http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||

This memo provides information for the Internet community. This memo | This memo provides information for the Internet community. This memo | |||

does not specify an Internet standard of any kind. Distribution of | does not specify an Internet standard of any kind. Distribution of | |||

this memo is unlimited. | this memo is unlimited. | |||

2. Abstract | 2. Abstract | |||

This memo refers to a metric for variation in delay of packets across | This memo refers to a metric for variation in delay of packets across | |||

Internet paths. The metric is based on statistics of the difference | Internet paths. The metric is based on the difference in the One-Way- | |||

in One-way-Delay of consecutive packets. This particular definition | Delay of selected packets. This difference in delay is called "IP | |||

of variation is called "Instantaneous Packet Delay Variation (ipdv)". | 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. In the second case it allows an evaluation of the | not synchronized. We discuss both in this draft. | |||

reciprocal skew. Measurements performed on both directions (Two-way | ||||

measurements) allow a better estimation of clock differences. The | ||||

precision that can be obtained is evaluated. | ||||

3. Introduction | 3. Introduction | |||

This memo is based on "A One-way-Delay metric for IPPM", RFC 2679 | | This memo is based on "A One-Way-Delay metric for IPPM", RFC 2679 | |||

[2]. Part of the text in this memo is taken directly from that | [2]. | |||

document. | ||||

This memo defines a metric for variation in delay of packets that > | Part of the text in this memo is taken directly from that document. | |||

flow from one host to another one through an IP path. This quantity > | ||||

is sometimes called "jitter". This term, however, causes confusion > | ||||

because it is used in different ways by different groups of people. | | ||||

"Jitter" commonly has two meanings: The first meaning is the | | ||||

variation of a signal with respect to some clock signal, where the | | ||||

arrival time of the signal is expected to coincide with the arrival | | ||||

of the clock signal. The second meaning has to do with the variation | | ||||

of a metric (e.g. delay) with respect to some reference metric (e.g. | | ||||

average delay or minimum delay). The form of "jitter" that we talk | | ||||

about here has to do almost exclusively with the second meaning, | | ||||

rather than the first. For more information see the section on the | | ||||

relationship with other standards. | ||||

3.1. Definition | This memo defines a metric for variation in delay of packets that | |||

flow from one host to another one through an IP path. This quantity | ||||

is sometimes called "jitter". This term, however, causes confusion | ||||

because it is used in different ways by different groups of people. | ||||

A definition of the Instantaneous Packet Delay Variation (ipdv) can | "Jitter" commonly has two meanings: The first meaning is the | |||

be given for a pair of packets or for a packet inside a stream of | variation of a signal with respect to some clock signal, where the | |||

packets. | arrival time of the signal is expected to coincide with the arrival | |||

of the clock signal. The second meaning has to do with the variation | ||||

of a metric (e.g. delay) with respect to some reference metric (e.g. | ||||

average delay or minimum delay). | ||||

For a pair of packets: | The first meaning is used with reference to synchronous signals and | |||

might be used to measure the quality of circuit emulation, for | ||||

example. There is also a metric called "wander" used in this context. | ||||

The second meaning is frequently used by computer scientists and | ||||

frequently (but not always) refers to variation in delay. | ||||

+ The ipdv of a pair of IP packets, that are transmitted from the | In this document we will avoid the term "jitter" whenever possible | |||

measurement point MP1 to the measurement point MP2, is the | and stick to delay variation which is more precise. | |||

difference between the One-way-Delay measured for the second | ||||

packet and the One-way-Delay measured for the first packet of the | ||||

pair. | ||||

For a stream of packets: | 3.1. Definition | |||

+ The Instantaneous Packet Delay Variation of an IP packet, inside a | A definition of the IP Packet Delay Variation (ipdv) can be given for | |||

stream of packets, going from the measurement point MP1 to the | packets inside a stream of packets. | |||

measurement point MP2, is the difference of the One-way-Delay of | ||||

that packet and the One-way-Delay of the preceding packet in the | The IP Packet Delay Variation (ipdv) of a pair of packets within a | |||

stream. | stream of packets is defined for a selected pair of packets in the | |||

stream going from measurement point MP1 to measurement point MP2 is | ||||

the difference between the one-way-delay of the first of the selected | ||||

packets and the one-way-delay of the second of the selected packets. | ||||

3.2. Motivation | 3.2. Motivation | |||

A number of services that can be supported by IP are sensitive to the | One important use of delay variation is the sizing of playout buffers | |||

regular delivery of packets and can be disturbed by instantaneous | for applications requiring the regular delivery of packets (for | |||

variations in delay, while they are not disturbed by slow variations, | example, voice or video playout). What is normally important in this | |||

that can last a relatively long time. A specific metric for quick | case is the maximum delay variation, which is used to size playout | |||

variations is therefore desirable. Metrics that can be derived from | buffers for such applications [6]. Other uses of a delay variation | |||

the analysis of statistics of ipdv can also be used, for example, for | | metric are, for example, to determine the dynamics of queues within a | |||

buffer dimensioning. The scope of this metric is to provide a way | network (or router) where the changes in delay variation can be | |||

for measurement of the quality delivered by a path. | linked to changes in the queue length process at a 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 | |||

differences and variations of the clocks of the two hosts. This | 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 | ||||

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

of the metric MUST include all the parameters associated with it so | ||||

that the conditions and meaning of the metric can be determined | ||||

exactly. We specifically do not specify particular values of the | ||||

metrics that IP networks must meet. | ||||

The flexibility of the metric can be viewed as a disadvantage but | ||||

there are some arguments for making it flexible. First, though there | ||||

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

experimentation. Secondly, there are different views in the community | ||||

of what precisely the definition should be (e.g. [7],[8],[9]). The | ||||

idea here is to parameterize the definition, rather than write a | ||||

different draft for each proposed definition. As long as all the | ||||

parameters are reported, it will be clear what is meant by a | ||||

particular use of ipdv. All the remarks in the draft hold, no matter | ||||

which parameters are chosen. | ||||

3.3. General Issues Regarding Time | 3.3. General Issues Regarding Time | |||

Everything contained in the Section 2.2. of [2] applies also in this | | Everything contained in the 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 few degrees. The total range of the | |||

drift is usually related to variations from 0 to 70 Celsius. These | drift is usually related to variations from 0 to 70 Celsius. These | |||

are important points for evaluation of precision of ipdv | are important points for evaluation of precision of ipdv | |||

measurements, as will be seen below. | measurements, as will be seen below. | |||

4. Structure of this memo | 4. A singleton definition of a One-way ipdv metric | |||

The metric will be defined as applicable to a stream of packets that | ||||

flow from a source host to a destination host (one-way ipdv). The | ||||

initial assumption is that source and destination hosts have | ||||

synchronized clocks. The definition of a singleton of one-way ipdv | ||||

metric is first considered, and then a definition of samples for ipdv | ||||

will be given. | ||||

Then the case of application to non-synchronized hosts will be | ||||

discussed, and the precision will be compared with the one of | ||||

synchronized clocks. | ||||

A bidirectional ipdv metric will be defined, as well as the > | ||||

methodology for error corrections. This will not be a two-way metric, > | ||||

but a "paired" one-way in opposite directions. | ||||

5. A singleton definition of a One-way ipdv metric | | The purpose of the singleton metric is to define what a single | |||

instance of an ipdv measurement is. Note that it can only be | ||||

statistically significant in combination with other instances. It is | ||||

not intended to be meaningful as a singleton, in the sense of being | ||||

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

5.1. Metric name | 4.1. Metric name | |||

Type-P-One-way-ipdv | Type-P-One-way-ipdv | |||

5.2. Metric parameters | 4.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. It is explicitly noted that also the difference T2-T1 | + T2, a time | |||

is a parameter of the measurement though this is already implicit, | ||||

since the times T1 and T2 exactly define the time conditions in | ||||

which the measurement takes place. | ||||

Note that the packet length is an implicit parameter of both the | | + L, a packet length in bits. The packets of a Type P packet stream | |||

Type-P-One-way-delay metric and the Type-P-One-way-ipdv metric, since | | from which the singleton ipdv metric is taken MUST all be of the | |||

this contributes to the overall one-way delay. We assume that the | | same length. | |||

packets sent for ipdv measurements are all of the same length. | ||||

5.3. Metric unit | + F, a selection function defining unambiguously the two packets | |||

from the stream selected for the metric. | ||||

+ I1,I2, times which mark that beginning and ending of the interval | ||||

in which the packet stream from which the singleton measurement is | ||||

taken occurs. | ||||

+ P, the specification of the packet type, over and above the source | ||||

and destination addresses | ||||

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

5.4. Definition | 4.4. Definition | |||

Type-P-One-way-ipdv is defined for two (consecutive) packets from Src | We are given a Type P packet stream and I1 and I2 such that the first | |||

to Dst, as the difference between the value of the Type-P-One-way- | Type P packet to pass measurement point MP2 after I1 is given index 0 | |||

delay from Src to Dst at T2 and the value of the Type-P-One-way-Delay | and the last Type P packet to pass measurement point MP2 before I2 is | |||

from Src to Dst at T1. T1 is the wire-time at which Scr sent the | given the highest index number. | |||

first bit of the first packet, and T2 is the wire-time at which Src | ||||

sent the first bit of the second packet. This metric is therefore | Type-P-One-way-ipdv is defined for two packets from Src to Dst | |||

ideally derived from the One-way-Delay metric. | 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 T1. T1 is the | ||||

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

packet. This metric is derived from the One-Way-Delay metric. | ||||

NOTE: The requirement of "consecutive" packets is not essential. The | ||||

measured value is anyway the difference in One-way-Delay at the times | ||||

T1 and T2, which is meaningful by itself, as long as the times T1 and | | ||||

T2 denote the wire times of the packets sent from Src to Dst. | T2 denote the wire times of the packets sent from Src to Dst. | |||

Therefore, for a real number ddT "The Type-P-one-way-ipdv from Src to | Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to | |||

Dst at T1, T2 is ddT" means that Src sent two consecutive packets, | Dst at T1, T2 is ddT" means that Src sent two packets, the first at | |||

the first at wire-time T1 (first bit), and the second at wire-time T2 | wire-time T1 (first bit), and the second at wire-time T2 (first bit) | |||

(first bit) and the packets were received by Dst at wire-time dT1+T1 | and the packets were received by Dst at wire-time dT1+T1 (last bit of | |||

(last bit of the first packet), and at wire-time dT2+T2 (last bit of | the first packet), and at wire-time dT2+T2 (last bit of the second | |||

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

5.5. Discussion | 4.5. Discussion | |||

Type-P-One-way-ipdv is a metric that makes use of the same | This metric definition depends on a stream of Type-P-One-Way-Delay | |||

measurement methods provided for delay metrics. | 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. | ||||

There must be a stream of at least two packets in order for a | ||||

singleton ipdv measurement to take place. The purpose of the | ||||

selection function is to specify exactly which two packets from 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 | ||||

Type P packets of the stream in the specified interval. Examples of a | ||||

selection function are: | ||||

+ Consecutive Type-P packets within the specified interval | ||||

+ Type-P packets with specified indices within the specified | ||||

interval | ||||

+ Type-P packets with the min and max one-way-delays within the | ||||

specified interval | ||||

+ Type-P packets with specified indices from the set of all defined | ||||

(i.e. non-infinite) one-way-delays Type-P packets within the | ||||

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 7 of this memo. It is pointed out that, if the | |||

relative clock conditions change in time, the accuracy of the | relative clock conditions change in time, the accuracy of the | |||

measurement will depend on the time interval T2-T1 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). | |||

+ 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. | |||

5.6. Methodologies | It is assumed that the Type-P packet stream is generated according to | |||

the Poisson sampling methodology described in [1]. | ||||

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). Generally, for a given Type-P, the methodology would | precedence). | |||

proceed as follows: | ||||

The measurement methodology described in this section asssumes the | ||||

measurement and determination of ipdv in real-time as part of an | ||||

active measurement. Note that this can equally well be done a | ||||

posteriori, i.e. after the one-way-delay measurement is completed. | ||||

Generally, for a given Type-P, the methodology would proceed as | ||||

follows: | ||||

+ The need of synchronized clocks for Src and Dst will be discussed | + The need of synchronized clocks for Src and Dst will be discussed | |||

later. Here a methodology is presented that is based on | later. Here a methodology is supposed that is based on | |||

synchronized clocks. | synchronized clocks. | |||

+ At the Src host, select Src and Dst IP addresses, and form two | + After time I1, start. At the Src host, select Src and Dst IP | |||

test packets of Type-P with these addresses. Any 'padding' portion | addresses, and form test packets of Type-P with these addresses | |||

of the packet needed only to make the test packet a given size | according to a given technique (e.g. the Poisson sampling | |||

should be filled with randomized bits to avoid a situation in | technique). Any 'padding' portion of the packet needed only to | |||

which the measured delay is lower than it would otherwise be due | make the test packet a given size should be filled with randomized | |||

to compression techniques along the path. | bits to avoid a situation in which the measured delay is lower | |||

than it would otherwise be due to compression techniques along the | ||||

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 timestamp in the first Type-P packet, | + At the Src host, place a timestamp in the Type-P packet, and send | |||

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

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

+ Record this first delay value. | + If the packet meets the selection function criterion for the first | |||

packet, record this first delay value. Otherwise, continue | ||||

generating the Type-P packet stream as above until the criterion | ||||

is met or I2, whichever comes first. | ||||

+ At the Src host, place a timestamp in the second Type-P packet, | + At the Src host, packets continue to be generated according to the | |||

and send it towards Dst. | given methodology. The Src host places a timestamp in the Type-P | |||

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

+ By subtracting the second value of One-way-Delay from the first | + If the packet meets the criterion for the second packet for the | |||

value the ipdv value of the pair of packets is obtained. | second packet, then by subtracting the second value of One-Way- | |||

Delay from the first value the ipdv value of the pair of packets | ||||

is obtained. Otherwise, packets continue to be generated until | ||||

the criterion for the 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. | |||

5.7. Errors and Uncertainties | 4.7. Errors and Uncertainties | |||

In the singleton metric of ipdv, factors that affect the measurement | In the singleton metric of ipdv, factors that affect the measurement | |||

are the same that can affect the One-way-Delay measurement, even if, | are the same as those affecting the One-Way-Delay measurement, even | |||

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 next | Each of these errors is discussed in more detail in the following | |||

paragraphs. | paragraphs. | |||

5.7.1. Errors/Uncertainties related to Clocks | 4.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 of 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 the time T1, at which the | errors that are supposed to change from time T1, at which the first | |||

first measurement is performed, to the time T2 at which the second | measurement is performed, to time T2 at which the second measurement | |||

measure ment is performed. Synchronization, skew, accuracy and | is performed. Synchronization, skew, accuracy and resolution are | |||

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

of skew are rather small over the time scales that we are > | It is the claim here (see remarks in section 3.3) that the effects | |||

discussing here, since temperature variations in a system tend to > | of skew are rather small over the time scales that we are | |||

be slow relative to packet inter-transmission times and the range > | discussing here, since temperature variations in a system tend to | |||

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

5.7.2. Errors/uncertainties related to Wire-time vs Host-time | 4.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. However, in most cases, the > | will be canceled while calculating ipdv. | |||

fixed and variable components are not known exactly. | ||||

6. Definitions for Samples of One-way ipdv | However, in most cases, the fixed and variable components are not | |||

known exactly. | ||||

Starting from the definition of the singleton metric of one-way ipdv, | | 5. Definitions for Samples of One-way ipdv | |||

we define a sample of such singletons. In the following, the two | | ||||

packets needed for a singleton measurement will be called a "pair". | | ||||

A stream of test packets is generated where the second packet of a | | The goal of the sample definition is to make it possible to compute | |||

pair is, at the same time, the first packet of the next pair. | | the statistics of sequences of ipdv measurements. The singleton | |||

definition is applied to a stream of test packets generated according | ||||

to a pseudo-random Poisson process with average arrival rate lambda. | ||||

If necessary, the interval in which the stream is generated can be | ||||

divided into sub-intervals on which the singleton definition of ipdv | ||||

can be applied. The result of this is a sequence of ipdv measurements | ||||

that can be analyzed by various statistical procedures. | ||||

+ Given particular binding of the parameters Src, Dst and Type-P, a | | Starting from the definition of the singleton metric of one-way ipdv, | |||

sample of values of parameter T1 is defined. To define the values | | we define a sample of such singletons. In the following, the two | |||

of T1, select a beginning time T0, a final time Tf, and an average | | packets needed for a singleton measurement will be called a "pair". | |||

rate lambda, then define a pseudo-random Poisson arrival process | | ||||

of rate lambda, whose values fall between T0 and Tf. The time | | ||||

interval between successive values of T1 will then average | | ||||

1/lambda. From the second value on, T1 value of the pair n | | ||||

coincides with T2 of the pair n-1, and the first packet of pair n | | ||||

coincides with the second packet of the pair n-1. | | ||||

6.1. Metric name | 5.1. Metric name | |||

Type-P-One-way-ipdv-stream | Type-P-One-way-ipdv-stream | |||

6.2. Parameters | 5.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 | |||

6.3. Metric Units: | + 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 | ||||

length. | ||||

A sequence of triads whose elements are: | + F, a selection function defining unambiguously the packets from | |||

the stream selected for the metric. | ||||

+ T, a time | + 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 | ||||

measurement is taken occurs. I(0) >= T0 and assuming that n is the | ||||

largest index, I(n) <= Tf. | ||||

+ Ti, a time interval. | + P, the specification of the packet type, over and above the source | |||

and destination addresses | ||||

5.3. Metric Units: | ||||

A sequence of triples whose elements are: | ||||

+ T1, T2,times | ||||

+ dT a real number or an undefined number of seconds | + dT a real number or an undefined number of seconds | |||

6.4. Definition | 5.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. Starting from time T0, at each pair of | equal to Tf are then selected for packet generation times. | |||

times T(i), T(i+1) of this process a value of Type-P-One-way-ipdv is | ||||

obtained. The value of the sample is the sequence made up of the | ||||

resulting <time, time interval, ipdv> triple, where the time interval | ||||

is given by T(i+1)-T(i). Each time T(i), excluding the first and the | ||||

last, is therefore at the same time the the second time of pair i and | ||||

the first time of pair i+1. The result is shown in figure 3 | ||||

|T(i-2) |T(i-1) |T(i) |T(i+1) | 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 | |||

pair i-1 pair i pair i+1 | 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 | ||||

of singleton samples for valid statistical estimates can be obtained. | ||||

Figure 3 | The triples defined above consist of the transmission times of the | |||

first and second packets of each singleton included in the sample, | ||||

and the ipdv in seconds. | ||||

6.5. Discussion | 5.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 will | |||

be needed to achieve the desired qualities. | 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. {Comment: there is, of course, | statistically as unbiased as possible. There is, of course, no claim | |||

no claim that real Internet traffic arrives according to a Poisson | that real Internet traffic arrives according to a Poisson arrival | |||

arrival process.} | process. | |||

6.6. Methodology | The sample metric can best be explained with a couple of examples: | |||

For the first example, assume that the selection function specifies | ||||

the "non-infinite" max and min one-way-delays over each sub-interval. | ||||

We can define contiguous sub-intervals of fixed specifiec length and | ||||

produce a sequence each of whose elements is the triple <transmission | ||||

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

second example is the selection function that specifies packets whose | ||||

indices (sequence numbers) are just the integers below a certain | ||||

bound. In this case, the sub-intervals are defined by the | ||||

transmission times of the generated packets and the sequence produced | ||||

is just <T(i), T(i+1), D(i)-D(i+1)> where D(i) denotes the one-way | ||||

delay of the ith packet of a stream. | ||||

This definition of the sample metric encompasses both the definition | ||||

proposed in [9] and the one proposed in [9]. | ||||

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

packets only the first received copy should be considered. If a | packets only the first received copy should be considered. | |||

packet is lost, two values of ipdv will be undefined, since each | ||||

packet is common to two pairs. | ||||

Steps for measurement can be the following: | Otherwise, the methodology is the same as for the singleton | |||

measurement, with the exception that the singleton measurement is | ||||

repeated a number of times. | ||||

+ Starting from a given time T, Src generates a test packet as for a | 5.7. Errors and uncertainties | |||

singleton metrics, inserts in the packet a sequence number and the | ||||

transmission time stamp Tx, then sorts the time Ti at which the | ||||

next packet has to be sent. | ||||

+ At time Ti, Src repeats the previous step, unless T(i) > Tf. | The same considerations apply that have been made about the singleton | |||

metric. Additional error can be introduced by the pseudo-random | ||||

Poisson process as discussed in [2]. Further considerations will be | ||||

given in section 7. | ||||

+ On reception of the first packet, or the first packet after a | 6. Statistics for One-way-ipdv | |||

sequence number error, Dst records sequence number and | ||||

transmission timestamp that are contained in the packet and the | ||||

reception time Rx as "old values". | ||||

+ On reception of the other packets Dst verifies the seuqence number | Some statistics are suggested which can provide useful information in | |||

and if it is correct, by using the "old values" and the newly | analyzing the behavior of the packets flowing from Src to Dst. The | |||

received ones, a value of ipdv is computed. Then Dst records the | statistics are assumed to be computed from an ipdv sample of | |||

new sequence number, transmit and receive timestamps as "old | reasonable size. | |||

values". | ||||

6.7. Errors and uncertainties | The purpose is not to define every possible statistic for ipdv, but | |||

ones which have been proposed or used. | ||||

The same considerations apply that have been made about the singleton > | 6.1. Lost Packets and ipdv statistics | |||

metric. Additional error can be introduced by the pseudo-random > | ||||

Poisson process as discussed in [2]. Further considerations will be > | ||||

given in section 7. | | ||||

6.8. Distribution of One-way-ipdv values | | The treatment of lost packets as having "infinite" or "undefined" | |||

delay complicates the derivation of statistics for ipdv. | ||||

Specifically, when packets in the measurement sequence are lost, | ||||

simple statistics such as sample mean cannot be computed. One | ||||

possible approach to handling this problem is to reduce the event | ||||

space by conditioning. That is, we consider conditional statistics; | ||||

namely we estimate the mean ipdv (or other derivative statistic) | ||||

conditioned on the event that selected packet pairs arrive at the | ||||

destination (within the given timeout). While this itself is not | ||||

without problems (what happens, for example, when every other packet | ||||

is lost), it offers a way to make some (valid) statements about ipdv, | ||||

at the same time avoiding events with undefined outcomes. | ||||

The one-way-ipdv values are limited by virtue of the fact that there | | In practical terms, what this means is throwing out the samples where | |||

are upper and lower bounds on the one-way-delay values. Specifically, | | one or both of the selected packets has an undefined delay. The | |||

one-way-delay is upper bounded by the value chosen as the maximum | | sample space is reduced (conditioned) and we can compute the usual | |||

beyond which a packet is counted as lost. It is lower bounded by | | statistics, understanding that formally they are conditional. | |||

propagation, transmission and nodal transit delays assuming that | | ||||

there are no queues or variable nodal delays in the path. Denote the | | ||||

upper bound of one-way-delay by U and the lower bound by L and we see | | ||||

that one-way-ipdv can only take on values in the (open) interval (L- | | ||||

U, U-L). | | ||||

In any finite interval, the one-way-delay can vary monotonically | | 6.2. Distribution of One-way-ipdv values | |||

(non-increasing or non-decreasing) or of course it can vary in both | | ||||

directions in the interval, within the limits of the half-open | | ||||

interval [L,U). Accordingly, within that interval, the one-way-ipdv | | ||||

values can be positive, negative, or a mixture (including 0). | | ||||

Since the range of values is limited, the one-way-ipdv cannot | | The one-way-ipdv values are limited by virtue of the fact that there | |||

increase or decrease indefinitely. Suppose, for example, that the | | are upper and lower bounds on the one-way-delay values. Specifically, | |||

ipdv has a positive 'run' (i.e. a long sequence of positive values). | | one-way-delay is upper bounded by the value chosen as the maximum | |||

At some point in this 'run', the positive values must approach 0 (or | | beyond which a packet is counted as lost. It is lower bounded by | |||

become negative) if the one-way-delay remains finite. Otherwise, the | | propagation, transmission and nodal transit delays assuming that | |||

one-way-delay bounds would be violated. If such a run were to | | there are no queues or variable nodal delays in the path. Denote the | |||

continue infinitely long, the sample mean (assuming no packets are | | upper bound of one-way-delay by U and the lower bound by L and we see | |||

lost) would approach 0 (because the one-way-ipdv values must approach | | that one-way-ipdv can only take on values in the (open) interval (L- | |||

0). Note, however, that this says nothing about the shape of the | | U, U-L). | |||

distribution, or whether it is symmetric. Note further that over | | ||||

significant intervals, depending on the width of the interval [L,U), | | In any finite interval, the one-way-delay can vary monotonically | |||

(non-increasing or non-decreasing) or of course it can vary in both | ||||

directions in the interval, within the limits of the half-open | ||||

interval [L,U). Accordingly, within that interval, the one-way-ipdv | ||||

values can be positive, negative, or a mixture (including 0). | ||||

Since the range of values is limited, the one-way-ipdv cannot | ||||

increase or decrease indefinitely. Suppose, for example, that the | ||||

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

become negative) if the one-way-delay remains finite. Otherwise, the | ||||

one-way-delay bounds would be violated. If such a run were to | ||||

continue infinitely long, the sample mean (assuming no packets are | ||||

lost) would approach 0 (because the one-way-ipdv values must approach | ||||

0). Note, however, that this says nothing about the shape of the | ||||

distribution, or whether it is symmetric. Note further that over | ||||

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

6.9. Some statistics for One-way-ipdv | There are basically two ways to represent the distribution of values | |||

of an ipdv sample: an empirical pdf and an empirical cdf. 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 | ||||

length and each bin contains the proportion of values falling between | ||||

the two limits of the bin. (Sometimes instead the number of values | ||||

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

sequence of values selected from the range of ipdv values. | ||||

Some statistics are suggested which can provide useful information in | | 6.3. Type-P-One-way-ipdv-percentile | |||

analyzing the behavior of the packets flowing from Src to Dst. The | | ||||

focus is on the instantaneous behavior of the connection. Other | | ||||

statistics can be defined if needed. | ||||

6.9.1. Type-P-One-way-ipdv-inverse-percentile | Given a Type-P One-Way-ipdv sample and a percent X between 0% and | |||

100%, the Xth percentile of all ipdv values in the sample. The 50th | ||||

percentile is the median. | ||||

Given a Type-P-One-way-ipdv-Stream and a time threshold, that can be | 6.4. Type-P-One-way-ipdv-inverse-percentile | |||

either positive or negative, the fraction of all the ipdv values in | ||||

the Stream less than or equal to the threshold, if the threshold is | ||||

positive, or greater or equal to the threshold if the threshold is | ||||

negative. | ||||

For many real-time services that require a regular delivery of the | Given a Type-P-One-way-ipdv sample and a given value Y, the percent | |||

packets, these statistics provide the number of packets exceeding a | of ipdv sample values less than or equal to Y. | |||

given limit. | ||||

6.9.2. Type-P-One-way-ipdv-jitter | | 6.5. Type-P-One-way-ipdv-jitter | |||

This metric is the same as the definition of "jitter" in [7], and is | | Although the use of the term "jitter" is deprecated, we use it here | |||

simply the absolute value of the Type-P-One-way-ipdv. | | following the authors in [7]. In that document, the selection | |||

function specifies that consecutive packets of the Type-P stream are | ||||

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

authors in [7] use the resulting sample to compare the behavior of | ||||

two different scheduling algorithms. | ||||

6.9.3. The treatment of lost packets as having "infinite" or > | 6.6. Type-P-One-way-peak-to-peak-ipdv | |||

"undefined" delay complicates the derivation of statistics for ipdv. > | ||||

Specifically, when packets in the measurement sequence are lost, > | In this case, the selection function used in collecting the Type-P- | |||

simple statistics such as sample mean cannot be computed. One > | One-Way-ipdv sample specifies that the first packet of each pair to | |||

possible approach to handling this problem is to reduce the event > | be the packet with the maximum Type-P-One-Way-Delay in each sub- | |||

space by conditioning. That is, we consider conditional statistics; > | interval and the second packet of each pair to be the packet with the | |||

namely we estimate the mean ipdv (or jitter or other derivative > | minimum Type-P-One-Way-Delay in each sub-interval. The resulting | |||

statistic) conditioned on the event that successive packet pairs > | sequence of values is the peak-to-peak delay variation in each sub- | |||

arrive at the destination (within the given timeout). While this > | interval of the measurement interval. | |||

itself is not without problems (what happens, for example, when every > | ||||

other packet is lost), it offers a way to make some (valid) > | ||||

statements about ipdv, at the same time avoiding events with > | ||||

undefined outcomes. We suggest that this be a topic for further > | ||||

study. | ||||

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 of having | |||

synchronized clocks at the source and destination. These | synchronized clocks at the source and destination. These | |||

considerations are given as a basis for discussion and they require | considerations are given as a basis for discussion and they require | |||

further investigation. > | further investigation. | |||

7.1. Effects of synchronization errors > | ||||

Clock errors can be generated by two processes: the relative 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 > | ||||

can vary between an upper and a lower bound. > | ||||

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

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

is letter O). > | ||||

Now suppose that the packets travel from source to destination 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 > | ||||

of the clocks. Suppose further that at the beginning of the > | ||||

measurement interval the ipdv value is calculated from a packet pair > | ||||

and at the end of the measurement interval another ipdv value is > | ||||

calculated from another packet pair. Assume that the time interval > | ||||

covered by the first measurement is t1 and that covered by the second > | ||||

measurement is t2. Then > | ||||

ipdv1 = s(0)*t1 + t1*(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 > | ||||

cases, it is claimed that the drift will be close to zero in which > | ||||

case the second (correction) term in the above equations disappears. > | ||||

Note that in the above discussion, other errors, including the > | ||||

differences between host time and wire time, and externally-caused > | ||||

clock discontinuities (e.g. clock corrections) were ignored. Under > | ||||

these assumptions the maximum clock errors will be due to the maximum > | ||||

relative skew acting on the largest interval between packets. > | ||||

7.2. Estimating the skew of unsynchronized clocks > | ||||

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

in calculating the value. If ti is the time between the ith and > | ||||

(i+1)st packet, then let Ti denote the sample mean time between > | ||||

packets and the average skew is s(Ti) = S * Ti. Note that E[Ti] > | ||||

should equal 1/lambda. In the event that the delays are constant, the > | ||||

skew parameter S can be estimated from the estimate Ti of the time > | ||||

between packets and the sample mean ipdv value. Under these > | ||||

assumptions, the ipdv values can be corrected by subtracting the > | ||||

estimated S * ti. > | ||||

We observe that the displacement due to the skew does not change the > | ||||

shape of the distribution, and, for example the Standard Deviation > | ||||

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

the measurement. The value of this distortion is limited to the > | ||||

effect of the total skew variation on the emission interval. > | ||||

8. Definition for a bidirectional ipdv metric | ||||

We now consider that the action of the skew on one direction is the | ||||

same, with opposite sign, of the action on the other direction. The | ||||

idea of performing at the same time two independent measurements in | ||||

the two directions is suggested by this fact. | ||||

If, after a long measurement, the variable conditions of the system | ||||

under test have reached the situation of a contribution close to zero | ||||

to the mean value of the ipdv distribution, it is expected that only | ||||

the action of the average skew has modified the measured mean value. | ||||

It is therefore expected that in one direction that value is equal | ||||

and opposite to the one measured in the other direction. | ||||

This fact offers the possibility of defining a theoretical reference | ||||

measurement duration in the following way: | ||||

The reference duration of a bidirectional ipdv measurement between an | ||||

host E and an host W is reached at time Tf such that for each time | ||||

T > Tf the expression ABS(E(ipdv E-W) - E(ipdv W-E))< epsilon, where | ||||

epsilon is what we can consider as zero, is always verified. This is | ||||

one, but not the only method for verifying that the mean ipdv value | ||||

has reached the value of the average relative skew. | ||||

At this point it is possible to evaluate the relative skew. This | ||||

will require the knowledge of the mean value of the intervals between | ||||

consecutive packets, that can be calculated over the transmitted | ||||

stream, by using the collected time stamps. | ||||

A bidirectional measurement can be defined not only as twin one-way | ||||

independent metrics that take place (nearly) at the same time, but | ||||

also as a two-way metric making use of packets looped back at one | ||||

end. This metric, that can be object of further study, would be | ||||

able to measure also the Round Trip Delay and its variations. | ||||

Problems will anyway arise on the characterization of emission | ||||

intervals in the backward direction. They would be produced by the | ||||

combination of the original Poisson arrival process and the effect of | ||||

ipdv on the forward direction. It has to be studied if this sequence | ||||

of intervals is still suitable for the measurement. also other | ||||

possibilities can be envisaged for obtaining a proper backward | ||||

sequence and still maintain the loopback concept. | ||||

9. Relationship to other standards | | ||||

The ITU definitions are based on delay variation as defined for ATM | | ||||

cells [5]. We will discuss these briefly first and then discuss the | | ||||

ITU's definition for IP packets [3]. | | ||||

9.1. 1-Point Cell Delay Variation | | ||||

The ITU looks at cell delay variation from two different points of | | ||||

view. The first, called 1-point cell delay variation, is essentially | | ||||

a measure of how a cell stream varies from a stated cell rate (e.g. | | ||||

the peak cell rate). The basic idea behind the measurement is as | | ||||

follows: The observer at the measurement point notes cell arrival | | ||||

times and clock ticks. The clock ticks at a constant rate, based on | | ||||

the peak cell rate for the cell stream. The difference between the | | ||||

cell arrival times and the clock ticks is the 1-point cell delay | | ||||

variation. If a cell arrives later than the clock tick, the clock | | ||||

"restarts" at the actual cell arrival time, and continues to tick at | | ||||

a constant rate from that point. | | ||||

The purpose of this measure is to identify what is called "cell | | ||||

clumping" and non-conforming cells. That is, to idenify cells that | | ||||

violate the leaky bucket parameters defined for that cell stream. | | ||||

That is why the clock skips when a cell is later than the normal | | ||||

inter-cell time defined by the peak cell rate. It is of much less | | ||||

interest when cells are late than when they arrive too close | | ||||

together. | | ||||

9.2. 2-Point Delay Variation, Cells and Packets | | ||||

2-Point cell delay variation, as defined in [5] is closer to what is | | ||||

defined here. The basic idea behind this metric is that two | | ||||

measurement points, whose clocks are synchronized, observe a cell | | ||||

stream and timestamp when each cell passes. The difference in the | | ||||

timestamps for a cell is essentially the one-way delay. There is also | | ||||

assumed to be a one-way cell delay for a reference cell which we will | | ||||

denote d0. The cell delay variation for the ith cell is then di-d0. | | ||||

Note that this is not an absolute value, but that the cell delay | | ||||

variation can be either positive or negative. [5] does not specify | | ||||

how to choose the reference cell delay. | | ||||

In [3] there is an informative appendix describing packet delay | | ||||

variation, which means that the material is not binding as a | | ||||

standard. The definitions are very similar to [5] with "packet" | | ||||

subsituting for "cell" in most places. One difference is that [3] | | ||||

offers two ways to define the reference packet (with the default | | ||||

being the first): | | ||||

+ Take the delay of the first packet of the sequence as the | | ||||

reference time. | | ||||

+ Take the average one-way packet delay as the reference time. | | 7.1. Effects of synchronization errors | |||

9.3. Discussion | | Clock errors can be generated by two processes: the relative 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 | ||||

can vary between an upper and a lower bound. | ||||

9.3.1. Differences | | 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 | ||||

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

is letter O). | ||||

Demichelis [4] points out a number of problems with the 2-point PDV | | Now suppose that the packets travel from source to destination in | |||

definition in [3]. First of all is the issue of choosing the | | constant time, in which case the ipdv is zero and the difference in | |||

reference delay time. If this is chosen arbitrarily, it becomes | | the timestamps of the two clocks is actually just the relative offset | |||

uncertain how to compare the measurements taken from two non- | | of the clocks. Suppose further that at the beginning of the | |||

overlapping periods. If it is chosen as an average, that can also be | | measurement interval the ipdv value is calculated from a packet pair | |||

a problem, because over long periods of time in a network, the | | and at the end of the measurement interval another ipdv value is | |||

average one-way delay can vary widely. A twenty-four hour average as | | calculated from another packet pair. Assume that the time interval | |||

the reference time can seriously overestimate the actual delay | | covered by the first measurement is t1 and that covered by the second | |||

variation at a given time of day because the night-time hours, when | | measurement is t2. Then | |||

the delay can be expected to approach the propagation and node time, | | ||||

is included in the average. On the other hand, there is no clear way | | ||||

to partition the time in order to find averages for certain periods | | ||||

of time and compute the delay variation with reference to these | | ||||

averages. | | ||||

Another problem pointed out in [4] is the fact that 2-point PDV | | ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T | |||

requires synchronized clocks, whereas in this document Demichelis | | ||||

shows that synchronized clocks are not absolutely necessary for ipdv. | | ||||

9.3.2. Relationship between the metrics | | ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T | |||

The ipdv metric described here and the 1-point cell delay variation | | assuming that the change is skew is linear in time. In most practical | |||

metric described in [5] do not really have much in common (see also | | cases, it is claimed that the drift will be close to zero in which | |||

[4]). 1-point delay variation is really intended to talk about the | | case the second (correction) term in the above equations disappears. | |||

relationship of cell arrival times to a given periodic event, and | | ||||

consequently is more closely related to the first definition of | | ||||

"jitter" given in Section 3 above. | | ||||

2-point delay variation (actually, the packet variant described in | | Note that in the above discussion, other errors, including the | |||

[3]) is related to ipdv, and this relationship can be made precise as | | differences between host time and wire time, and externally-caused | |||

follows: Suppose that an arbitrarily chosen packet is designated as | | clock discontinuities (e.g. clock corrections) were ignored. Under | |||

the reference packet for the 2-point measurement and also as the | | these assumptions the maximum clock errors will be due to the maximum | |||

start packet of the ipdv measurement. Denote this packet by p(0). | | relative skew acting on the largest interval between packets. | |||

Then given ipdv measurements for a series of packets, the 2-point | | ||||

delay variation for packet i is p(0) + the sum from k=1 to i of | | ||||

ipdv(k). | | ||||

Similarly, given a sequence of 2-point delay variation measurements | | 7.2. Estimating the skew of unsynchronized clocks | |||

we can derive the ipdv measurement as follows: Denote the 2-point | | ||||

delay variation measurement for packet i as v(i). Then the ipdv value | | ||||

for the pair of packets p(k-1), p(k) is simply v(k)-v(k-1) [6]. | | ||||

9.3.3. Summary | | 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 | ||||

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

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

of the time between packets and the sample mean ipdv value. Under | ||||

these assumptions, the ipdv values can be corrected by subtracting | ||||

the estimated S * ti. | ||||

As described above, there are a number of disadvantages of the | | We observe that the displacement due to the skew does not change the | |||

2-point packet delay variation approach. Further, the ipdv approach | | shape of the distribution, and, for example the Standard Deviation | |||

described here is general enough to provide the same information as | | remains the same. What introduces a distortion is the effect of the | |||

the 2-point packet delay variation measurements. Because of this, and | | drift, also when the mean value of this effect is zero at the end of | |||

because of the (possibly) looser clock synchronization requirements | | the measurement. The value of this distortion is limited to the | |||

of ipdv, we recommend the one-way-ipdv approach for the delay | | effect of the total skew variation on the emission interval. | |||

variation measurement. | | ||||

10. 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]. The packets contain no user information, and so | |||

privacy of user data is not a concern. It is still possible that | | privacy of user data is not a concern. It is still possible that | |||

there could be an attempt at a denial of service attack by sending | | there could be an attempt at a denial of service attack by sending | |||

many measurement packets into the network; there could also be | | many measurement packets into the network; there could also be | |||

attempts to disrupt measurements by diverting packets or corrupting | | attempts to disrupt measurements by diverting packets or corrupting | |||

them. | | them. | |||

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 | | selected carefully in order to avoid interfering with normal traffic | |||

in the network. Such measurements should also be authorized and | | in the network. Such measurements should also be authorized and | |||

authenticated in some way so that attacks can be identified and | | authenticated in some way so that attacks can be identified and | |||

intercepted. | | intercepted. | |||

11. Acknowledgements | | 9. Acknowledgements | |||

Thanks to Matt Zekauskas from Advanced and Ruediger Geib from | | This major revision of the draft resulted from e-mail discussions | |||

Deutsche Telekom for discussions relating to the contents of this | | with and suggestions from Mike Pierce, Ruediger Geib, Glenn | |||

revised draft. For this additional revision, discussions by e-mail > | Grotefeld, and Al Morton. For previous revisions of this document, | |||

with Andy Scherrer were very helpful. | discussions with Ruediger Geib, Matt Zekaukas and Andy Scherer were | |||

very helpful. | ||||

12. 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 | |||

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

[3] ITU-T Recommendation I.380 "Internet Protocol Data | [3] ITU-T Recommendation Y.1540 (formerly numbered I.380) | |||

Communication Service - IP Packet Transfer and Availability | "Internet Protocol Data Communication Service - IP Packet | |||

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" March 1999 | ITU-T and IETF Draft Definitions" November 2000 (in the IPPM | |||

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

Performance" | Performance" | |||

[6] e-mail exchanges with Ruediger Geib | [6] S. Keshav - "An Engineering Approach to Computer Networking", | |||

Addison-Wesley 1997, ISBN 0-201-63442-2 | ||||

[7] V. Jacobson, K. Nichols, K. Poduri - "An expedited forwarding | [7] V. Jacobson, K. Nichols, K. Poduri - "An expedited forwarding | |||

PHB", RFC 2598, June 1999 | PHB", RFC 2598, June 1999 | |||

13. Authors' Addresses | [8] ITU-T Draft Recommendation Y.1541 - "Internet Protocol | |||

Communication Service - IP Performance and Availability | ||||

Objectives and Allocations", April 2000 | ||||

[9] Demichelis, Carlo - "Improvement of the Instantaneous Packet | ||||

Delay Variation (IPDV) Concept and Applications", World | ||||

Telecommunications Congress 2000, 7-12 May 2000 | ||||

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@ctit.utwente.nl> | Philip Chimento <chimento@torrentnet.com> | |||

CTIT - Centre for Telematics and Information Technology | Ericsson IPI | |||

University of Twente | 7301 Calhoun Place | |||

Postbox 217 | Rockville, Maryland | |||

7500 AE Enschede | 20855 | |||

The Netherlands | USA | |||

Phone +31 53 489 4331 | Phone +1-240-314-3597 | |||

FAX +31 53 489 4524 | ||||

Expiration date: December 2000 | Expiration date: August 2001 | |||

End of changes. | ||||

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