RFC 3393

IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)

📅 published November 2002, from ietf

RFC 3393 Title Check 🎀

okay bestie, RFC 3393 is giving full metrics-nerd main character energy 💅 Its title is "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)" 💖 It was written by C. Demichelis (Telecomitalia Lab) and P. Chimento (Ericsson IPI) 🫶 It's a Standards Track doc dated November 2002 🌸 and its header doesn't list any RFCs it obsoletes or updates ✨ This is part 1 of 4, so hold tight 🧚

Status of This Memo ✨

ok so this doc is an Internet standards track protocol for the Internet community 🦋 It's asking for discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2002). All Rights Reserved. 🔒

Abstract 🎀

this doc is about a metric for how much the delay of packets varies as they cross Internet paths 🛣️ The metric is based on the difference in the One-Way-Delay of selected packets 💅 That difference is called "IP Packet Delay Variation (ipdv)" ✨

it's valid for measurements between two hosts whether their clocks are synchronized or not 🕰️ we talk about both cases in this document 🫶

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 flowing from one host to another through an IP path 🛤️ It's based on "A One-Way-Delay metric for IPPM", RFC 2679 [2], and part of the text here is taken directly from that doc 📖 so the reader is assumed to already know that one 🤓

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3] 🔑 BCP 14 / RFC 2119 was written with protocols in mind, but these key words get used here for similar reasons 💅 They make sure results from two different implementations can be compared, and they point out where an implementation could perturb the network 🫧

the structure of the memo goes like this:

  • a 'singleton' analytic metric, called Type-P-One-way-ipdv, gets introduced to define a single instance of an ipdv measurement 🧚
  • using that singleton metric, a 'sample', called Type-P-one-way-ipdv-Poisson-stream, gets introduced so we can compute stats for sequences of ipdv measurements 📊
  • using that sample, several 'statistics' of the sample get defined and discussed 💜

1.1. Terminology 💬

the variation in packet delay is sometimes called "jitter" 🙃 but this term causes confusion because different groups of people use it in different ways 😭

"Jitter" commonly has two meanings 🌈 The first is the variation of a signal with respect to some clock signal, where the arrival time of the signal is expected to line up with the arrival of the clock signal 🕰️ That meaning is used for synchronous signals and might be used to measure the quality of circuit emulation, for example 🔌 There's also a metric called "wander" used in this context 🎀

The second meaning is about the variation of a metric (e.g., delay) with respect to some reference metric (e.g., average delay or minimum delay) 📉 Computer scientists use this one a lot, and it frequently (but not always) refers to variation in delay 💻

in this document we avoid the term "jitter" whenever possible and stick with delay variation, which is more precise 💖

1.2. Definition 🧁

ipdv can be defined for packets inside a stream of packets 🌊

The ipdv of a pair of packets within a stream of packets is defined for a selected pair of packets in the stream going from measurement point MP1 to measurement point MP2 🎯

The ipdv is the difference between the one-way-delay of the selected packets ✨

1.3. Motivation 💅

one big use of delay variation is sizing play-out buffers for apps that need regular delivery of packets, like voice or video play-out 🎧🎬 In that case, what usually matters is the maximum delay variation, which is used to size play-out buffers for such apps [7] 📏 Delay variation metrics also help figure out the dynamics of queues inside a network (or router), since changes in delay variation can be linked to changes in the queue length process at a given link or a combo of links 🚦

this type of metric is also super robust when the clocks of the two hosts differ or vary 🕰️ That means you can use it even if the two hosts supporting the measurement points aren't synchronized 🫶 In that case, indications of reciprocal skew of the clocks can be derived from the measurement, and corrections are possible 🔧 The related precision is often comparable to what you get with synchronized clocks, being the same order of magnitude as synchronization errors 🎀 We'll discuss this below 👀

The scope of this document is to provide a way to measure the ipdv delivered on a path 🛣️ The goal is a metric that can be parameterized so it works for lots of different 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 🔥 Since the metric is not a value judgment (it doesn't define "good" and "bad"), we specifically do not specify particular values of the metrics that IP networks must meet 🙅‍♀️

the flexibility of the metric can be seen as a disadvantage, but there are some arguments for making it flexible 🤔 First, even though there are some uses of ipdv mentioned above, the uses of ipdv are still to some degree a research topic, so some room should be left for experimentation 🧪 Second, the community has different views on what precisely the definition should be (e.g., [8],[9],[10]) 💭 The idea here is to parameterize the definition, rather than write a different document for each proposed definition 📝 As long as all the parameters are reported, it'll be clear what is meant by a particular use of ipdv 💖 All the remarks in the document hold, no matter which parameters are chosen 🫶

1.4. General Issues Regarding Time ⏰

everything contained in Section 2.2. of [2] applies to this case too 💅

to summarize: as in [1], we define "skew" as the first derivative of the offset of a clock with respect to "true time", and "drift" as the second derivative of the offset of a clock with respect to "true time" 📐

From there, we can build "relative skew" and "relative drift" for two clocks C1 and C2 with respect to one another 👯 These are natural extensions of the basic framework definitions of these quantities 🌸

  • relative offset = difference in clock times 🕰️
  • relative skew = first derivative of the difference in clock times 📈
  • relative drift = second derivative of the difference in clock times 📉
NOTE: The drift of a clock, as defined above over a long 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 small) range 🧠 To underline how small this effect is, the maximum range of drift for commercial crystals is about 50 parts per million (ppm) 🔬 Drift is mainly connected with variations in operating temperature (from 0 to 70 degrees Celsius) 🌡️ A host is expected to have a nearly constant temperature during its operation period, and temperature variations, even quick ones, could be less than one Celsius per second and range in the order of a few degrees 🔥 The total range of the drift is usually related to variations from 0 to 70 Celsius 💀 These are important points for evaluating the precision of ipdv measurements, as we'll see below 🫧

2. A singleton definition of a One-way-ipdv metric ✨

okay so the singleton metric is basically defining what ONE instance of an ipdv measurement is 🫶 ngl it can only be statistically significant when you pair it with other instances, so it's not meant to tell you anything on its own. like, one data point is not the whole story bestie 💅

this definition borrows from the type-P-One-Way-Delay metric [2] 🦋 and this section only uses the parts of the One-Way-Delay Draft that directly apply to One-Way-ipdv, or that make direct references to that Draft 🌸

2.1. Metric name

Type-P-One-way-ipdv 💖

2.2. Metric parameters

the parameters are giving full checklist energy ✨

  • Src, the IP address of a host
  • Dst, the IP address of a host
  • T1, a time
  • T2, a time
  • 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 same length. 🎀
  • F, a selection function defining unambiguously the two packets from the stream selected for the metric.
  • I1,I2, times which mark the 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 🧚

2.3. Metric unit

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 🔥

2.4. Definition

okay this part is the main character moment 👑 we're given a Type P packet stream and I1 and I2, and the first Type P packet to pass measurement point MP1 after I1 gets index 0, while the last Type P packet to pass MP1 before I2 gets the highest index number 🦋

Type-P-One-way-ipdv is defined for two packets from Src to Dst picked by the selection function F. it's 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 💜

so 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 went out at wire-time T1 (first bit) and the second at wire-time T2 (first bit). 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 packet), and dT2-dT1=ddT. literally just math but make it cute 🍓

"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 second packet at T2, and Dst did not receive one or both packets 💀

Figure 1 shows this definition. suppose packets P(i) and P(k) get selected 👀

  I1  P(i)       P(j)                  P(k)                     I2

MP1 |--------------------------------------------------------------|
        |\        |\                    |\
        | \       | \                   | \
        |  \      |  \                  |  \
        |   \     |   \                 |   \
        |dTi \    |dTj \                |dTk \
        |<--->v   |<--->v               |<--->v

MP2 |--------------------------------------------------------------|

 I1          P(i)       P(j)                 P(k)               I2

                  Figure 1: Illustration of the definition

so then ddT = dTk - dTi, as defined above ✨

2.5. Discussion

this metric depends on a stream of Type-P-One-Way-Delay packets that have been measured 🫶 in general that 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 for a singleton ipdv measurement to take place. the selection function's whole job is to say exactly which two packets from the stream get used for the singleton measurement. heads up, 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 🌈

  • Being a differential measurement, this metric is less sensitive to clock synchronization problems. This issue will be more carefully examined in section 5 of this memo. It is pointed out that, if the relative clock conditions change in time, the accuracy of the measurement will depend on the time interval I2-I1, and the magnitude of possible errors will be discussed below. 🧚
  • A given methodology will have to include a way to determine 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 Mahdavi and Paxson, simple upper bounds (such as the 255 seconds theoretical upper bound on the lifetimes of IP packets [Postel: RFC 791]) could be used, but good engineering, including an understanding of packet lifetimes, will be needed in practice. Comment: Note that, for many applications of these metrics, the harm in treating a large delay as infinite might be zero or very small. A TCP data packet, for example, that arrives only after several multiples of the RTT may as well have been lost. 😭
  • 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 number, size, and arrangement for special treatment (as with IP precedence or with RSVP). 🍓
  • ddT is derived from the start of the first bit out from a packet sent out by Src to the reception of the last bit received by Dst. Delay is correlated to the size of the packet. For this reason, the packet size is a parameter of the measurement and must be reported along with the measurement. ✨
  • If the packet is duplicated along the path (or paths!) so that multiple non-corrupt copies arrive at the destination, then the packet is counted as received, and the first copy to arrive determines the packet's One-Way-Delay. 🦋
  • If the packet is fragmented and, for whatever reason, re-assembly does not occur, then the packet will be deemed lost. 💀

in this document it is assumed that the Type-P packet stream is generated according to the Poisson sampling methodology described in [1] 🌸

the reason for Poisson sampling is that it ensures an unbiased and uniformly distributed sampling of times between I1 and I2. alternate sampling methodologies are possible though. for example, continuous sampling of a constant bit rate stream (i.e., periodic packet transmission) is a possibility. however, in this case, one must be sure to avoid any "aliasing" effects that may occur with periodic samples. 🎀

2.6. Methodologies

as with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence) 💅

the measurement methodology described in this section assumes 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 go like this. note that this methodology is based on synchronized clocks. the need for synchronized clocks for Src and Dst will be discussed later 🔥

  • Start after time I1. At the Src host, select Src and Dst IP addresses, and form test packets of Type-P with these addresses according to a given technique (e.g., the Poisson sampling technique). Any 'padding' portion of the packet needed only to make the test packet a given size should be filled with randomized 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 Src host, place a time stamp in the Type-P packet, and send it towards Dst.
  • 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 subtracting the two time stamps, an estimate of One-Way-Delay can be computed.
  • 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, packets continue to be generated according to the given methodology. The Src host places a time stamp in the Type-P packet, and send it towards Dst.
  • 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 subtracting the two time stamps, an estimate of One-Way-Delay can be computed.
  • If the packet meets the criterion for the second packet, then by subtracting the first value of One-Way-Delay from the second 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 of time, the ipdv is taken to be undefined. 💀

2.7. Errors and Uncertainties

in the singleton metric of ipdv, the factors that affect the measurement are the same as those affecting the One-Way-Delay measurement, even if, in this case, the influence is different 🌸

the Framework document [1] gives general guidance on this point, but here are the specifics related to delay metrics 🎀

  • Errors/uncertainties due to uncertainties in the clocks of the Src and Dst hosts.
  • Errors/uncertainties due to the difference between 'wire time' and 'host time'.

each of these errors gets a closer look in the following paragraphs 🦋

okay so, if the error hitting the first One-Way-Delay measurement is roughly the same as the error hitting the second one, they just cancel each other out when we calculate ipdv 🫶. The leftover clock error is the difference between the errors that are supposed to change from time T1, when the first measurement happens, to time T2, when the second one happens. Synchronization, skew, accuracy and resolution all get these notes:

  • Errors in synchronization between source and destination clocks contribute to errors in both of the delay measurements required for calculating ipdv 🕰️
  • The effect of drift and skew errors on ipdv measurements can be quantified like this 📐 Suppose the skew and drift functions are known. First, assume the skew function is linear in time. Then the clock offset is 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 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 gets added to the time difference (t2 - t1). If the drift can't be ignored, but we assume the drift is a linear 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. 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 time stamps is e(t2)-e(t1) = N*(t2-t1) + M*{(t2-t1)**2}.

It's the claim here (see remarks in section 1.3) that the effects of skew are pretty small over the time scales we're discussing, since temperature changes in a system tend to be slow compared to packet inter-transmission times, and the range of drift is so tiny 🌡️🙈

  • As far as accuracy and resolution go, what the one-way-delay document [2] says in section 3.7.1 applies here too 📚 With one extra twist about resolution: in this case the uncertainty introduced is two times the one from a single delay measurement. Errors from these effects are often bigger than the ones introduced by drift 😭

The content of sec. 3.7.2 of [2] applies here as well, with one more thing to know 👀 The difference between Host-time and Wire-time can generally be broken into two components: one is constant and the other is variable. Only the variable components will produce measurement errors, while the constant one gets canceled out when we calculate ipdv.

Lowkey though, in most cases the fixed and variable components aren't known exactly 💀

3. Definitions for Samples of One-way-ipdv 🎀

The whole point of the sample definition is to make it possible to compute the statistics of sequences of ipdv measurements 📊 The singleton definition gets applied to a stream of test packets generated according to a pseudo-random Poisson process with average arrival rate lambda. If needed, the interval where the stream is generated can be split into sub-intervals, and the singleton definition of ipdv can be applied to each one. The result is a sequence of ipdv measurements that can be analyzed with all kinds of statistical procedures 💅

Starting from the singleton metric of one-way-ipdv, we define a sample made up of those singletons. From here on, the two packets needed for a singleton measurement are called a "pair" 👯‍♀️

3.1. Metric name

Type-P-One-way-ipdv-Poisson-stream

3.2. Parameters

  • Src, the IP address of a host 🖥️
  • Dst, the IP address of a host 🖥️
  • T0, a time ⏰
  • Tf, a time ⏰
  • lambda, a rate in reciprocal seconds
  • 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 📏
  • F, a selection function defining unambiguously the packets from the stream selected for the metric 🎯
  • 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 n is the largest index, I(n) <= Tf 🧩
  • P, the specification of the packet type, over and above the source and destination addresses 🎁

3.3. Metric Units:

A sequence of triples whose elements are:

  • T1, T2,times
  • dT, a real number or an undefined number of seconds ⏱️

3.4. Definition

A pseudo-random Poisson process is defined so that it begins at or before T0, with average arrival rate lambda, and ends at or after Tf. Those time values T(i) that are greater than or equal to T0 and less than or equal to Tf are then selected as packet generation times 🌸

Each packet falling within one of the sub-intervals I(i), I(i+1) gets tested to see whether it meets the criteria of the selection function F as the first or second packet of a pair needed to compute ipdv 🔍 The sub-intervals can be defined so that a sufficient number of singleton samples for valid statistical estimates can be obtained ✨

The triples defined above consist of the transmission times of the first and second packets of each singleton included in the sample, plus the ipdv in seconds 💖

3.5. Discussion

Note first that, since a pseudo-random number sequence is used, the sequence of times, and therefore the value of the sample, is not fully specified 🎲 Pseudo-random number generators of good quality will be needed to achieve the desired qualities 🧠

The sample is defined in terms of a Poisson process both to avoid the effects of self-synchronization and to capture a sample that is statistically as unbiased as possible 🦄 Of course, there's no claim that real Internet traffic arrives according to a Poisson arrival process. Not me saying the internet is Poisson 💀

The sample metric is best explained with a couple of examples 🍓 For the first one, assume 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, specified length and produce a sequence where each element is the triple <transmission time of the max delay packet, transmission time of the min delay packet, D(max)-D(min)>, collected for each sub-interval. A second example is a 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+1)-D(i)>, where D(i) denotes the one-way-delay of the ith packet of a stream 🧚

This definition of the sample metric covers both the definition proposed in [9] and the one proposed in [10] 🌈

3.6. Methodology

Since packets can be lost or duplicated, or can arrive in a different order than the order sent, the pairs of test packets should be marked with a sequence number 🔢 For duplicated packets, only the first received copy should be considered 🙅‍♀️

Otherwise, the methodology is the same as for the singleton measurement, except that the singleton measurement is repeated a number of times 🔁

3.7. Errors and uncertainties

The same considerations apply that were made about the singleton metric 🫶 Additional error can be introduced by the pseudo-random Poisson process, as discussed in [2]. More considerations will be given in section 5 🔜

4. Statistics for One-way-ipdv 💅

Some statistics are suggested that can provide useful information when analyzing the behavior of the packets flowing from Src to Dst 📈 The statistics are assumed to be computed from an ipdv sample of reasonable size.

The purpose isn't to define every possible statistic for ipdv, just the ones that have been proposed or used 🎀

4.1. Lost Packets and ipdv statistics

Treating lost packets as having "infinite" or "undefined" delay really complicates deriving statistics for ipdv 😩 Specifically, when packets in the measurement sequence are lost, simple statistics like the sample mean can't be computed. One possible approach is to reduce the event space by conditioning. That means we consider conditional statistics: we estimate the mean ipdv (or another derivative statistic) conditioned on the event that the selected packet pairs arrive at the destination within the given timeout. This isn't without problems. For example, what happens when every other packet is lost? Still, it offers a way to make some valid statements about ipdv, while avoiding events with undefined outcomes 🧁

In practical terms, this means throwing out the samples where one or both of the selected packets has an undefined delay. The sample space gets reduced (conditioned), and we can compute the usual statistics, understanding that formally they are conditional 💜

4.2. Distribution of One-way-ipdv values

The one-way-ipdv values are limited because there are upper and lower bounds on the one-way-delay values 🚧 Specifically, one-way-delay is bounded above by the value chosen as the maximum beyond which a packet is counted as lost. It's bounded below by propagation, transmission and nodal transit delays, assuming 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) 🦋

Within any finite interval, the one-way-delay can vary monotonically (non-increasing or non-decreasing), or of course it can vary in both directions within 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 can't 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's symmetric. Note further that over significant intervals, depending on the width of the interval [L,U), the sample mean one-way-ipdv could be positive, negative or 0 🤯

There are basically two ways to represent the distribution of values in 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 in 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 the number of values falling between the two limits is used instead.) 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 🌸

4.3. Type-P-One-way-ipdv-percentile 💖

okay so you give it a Type-P One-Way-ipdv sample and a percent X between 0% and 100%, and you get the Xth percentile of all the ipdv values in that sample 📊 the 50th percentile is the median, so if you want the middle value, that's your girl ✨

4.4. Type-P-One-way-ipdv-inverse-percentile 🦋

this one flips it. you give it a Type-P-One-way-ipdv sample and a value Y, and you get back the percent of ipdv sample values that are less than or equal to Y. basically the inverse of the last one, and it's giving very "how many of these are at or under this number" 🧮

4.5. Type-P-One-way-ipdv-jitter 🎀

ok so the word "jitter" is deprecated, but we're still using it here bc the authors in [8] did 🫶 in that doc, the selection function says consecutive packets of the Type-P stream get picked as the packet pairs for ipdv computation. then they take the absolute value of the ipdv values in the sample. the authors in [8] use that sample to compare how two different scheduling algorithms behave 🔥

there's also a related (but not identical) way to estimate jitter, and it's in RFC 1889 [11] 🌸 the selection function there is implicitly consecutive packet pairs, and the "jitter estimate" comes from taking the absolute values of the ipdv sequence (as defined in this document) and running them through an exponential filter with parameter 1/16 to generate the estimate. written out it's j_new = 15/16* j_old + 1/16*j_new 🧚

4.6. Type-P-One-way-peak-to-peak-ipdv 👑

this one is kind of dramatic 😭 the selection function used when collecting the Type-P-One-Way-ipdv sample says the first packet of each pair is the packet with the maximum Type-P-One-Way-Delay in each subinterval, and the second packet of each pair is the packet with 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 subinterval of the measurement interval. main character energy, honestly 💅

5. Discussion of clock synchronization ⏰

this section is a little bit of "let's talk about it" 💬 it gives some considerations about why you might need synchronized clocks at the source and destination. even if the clocks aren't synchronized, the measurements themselves can be used to correct the error 🫶 these considerations are a basis for discussion, and they still need further investigation.

5.1. Effects of synchronization errors 🌈

ok so clock errors can come from two processes: the relative drift and the relative skew of two given clocks. drift is physically limited, so the total relative skew of two clocks can vary between an upper and a lower bound 🧠

say we have a measurement between two systems, and the clocks in the source and destination have a relative skew of s(0) at time 0 and s(T) after a measurement interval T. we assume the two clocks start with an initial offset of O (that is letter O, yes it's giving confusing but it's the letter) 🙈

now suppose the packets travel from source to destination in constant time. then the ipdv is zero, and the difference in the time stamps of the two clocks is literally just the relative offset of the clocks ✨ suppose also that at the start of the measurement interval, an ipdv value is calculated from a packet pair, and at the end, another ipdv value is calculated from another packet pair. the time interval covered by the first measurement is t1, and the time interval covered by the second is t2. then:

ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T

ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T

this assumes the change in skew is linear in time. in most practical cases the drift is claimed to be close to zero, so the second (correction) term in the above equations disappears 😌

also, in the discussion above, other errors were ignored, including the differences between host time and wire time, and externally-caused clock discontinuities (e.g., clock corrections) 🙃 under these assumptions, the maximum clock errors come from the maximum relative skew acting on the largest interval between packets. bestie, that's the big one to remember 💀

5.2. Estimating the skew of unsynchronized clocks 🍓

if the skew is linear (so s(t) = S * t for constant S), the error in ipdv values depends on the time between the packets used to calculate the value. if ti is the time between the packet pair, then Ti is the sample mean time between packets, and the average skew is s(Ti) = S * Ti. when 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 🧮

here's the tea: the displacement from the skew doesn't change the shape of the distribution, so the Standard Deviation stays the same, for example 🫧 what actually causes distortion is the effect of the drift, even when the mean of this effect is zero at the end of the measurement. the size of that distortion is limited to the effect of the total skew variation on the emission interval 🌸

6. Security Considerations 🔐

ok this is the serious part, so listen up 🫶 the one-way-ipdv metric has the same security properties as the one-way-delay metric [2], so it inherits the security considerations of that document. the reader should check out [2] for a more detailed treatment. still, there are a few things to highlight 👀

6.1. Denial of service 🚨

it's still possible for someone to try a denial of service attack by sending a bunch of measurement packets into the network 😱 in general, legitimate measurements need their parameters carefully selected so they don't interfere with normal traffic. don't be that person 🙅‍♀️

6.2. Privacy/Confidentiality 🔒

the packets contain no user information, so privacy of user data is not a concern ✨ literally a win 🎀

6.3. Integrity 🛡️

there could also be attempts to disrupt measurements by diverting packets or corrupting them 😤 to make sure test packets are valid and haven't been altered in transit, packet authentication and integrity checks may be used.

7. Acknowledgments 🫶

huge thanks to Merike Kaeo, Al Morton and Henk Uiterwaal for catching mistakes and clarifying the rewordings for this final document 💜

an earlier major revision came out of e-mail discussions with and suggestions from Mike Pierce, Ruediger Geib, Glenn Grotefeld, and Al Morton 📧 for previous revisions, discussions with Ruediger Geib, Matt Zekauskas and Andy Scherer were super helpful 🌟

8. References 📚

8.1 Normative References

[1] Paxon, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, February 1998.

[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 mail archives).

[6] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer Performance".

[7] S. Keshav - "An Engineering Approach to Computer Networking", Addison-Wesley 1997, ISBN 0-201-63442-2.

[8] Jacobson, V., Nichols, K. and Poduri, K. "An Expedited Forwarding PHB", RFC 2598, June 1999.

[9] ITU-T Draft Recommendation Y.1541 - "Internet Protocol Communication Service - IP Performance and Availability Objectives and Allocations", April 2000.

[10] Demichelis, Carlo - "Improvement of the Instantaneous Packet Delay Variation (IPDV) Concept and Applications", World Telecommunications Congress 2000, 7-12 May 2000.

[11] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A transport protocol for real-time applications", RFC 1889, January 1996.

9. Authors' Addresses 🌷

Carlo Demichelis
Telecomitalia Lab S.p.A
Via G. Reiss Romoli 274
10148 - TORINO
Italy

Phone: +39 11 228 5057
Fax:   +39 11 228 5069
EMail: carlo.demichelis@tilab.com
Philip Chimento
Ericsson IPI
7301 Calhoun Place
Rockville, Maryland 20855
USA

Phone: +1-240-314-3597
EMail: chimento@torrentnet.com

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, as long as 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. ✨🎀

📦 where this page comes from