idnits 2.17.1 draft-ietf-ippm-ipdv-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 272 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 284 has weird spacing: '... in the first...' == Line 323 has weird spacing: '...f these error...' == Line 346 has weird spacing: '... to the subtr...' == Line 384 has weird spacing: '...nerated where...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Ti' on line 611 ** Downref: Normative reference to an Informational RFC: RFC 2330 (ref. '1') ** Obsolete normative reference: RFC 2679 (ref. '2') (Obsoleted by RFC 7679) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2598 (ref. '7') (Obsoleted by RFC 3246) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Demichelis 2 INTERNET-DRAFT CSELT 3 Expiration Date: December 1999 P. Chimento 4 CTIT 5 October 1999 7 Instantaneous Packet Delay Variation Metric for IPPM 8 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with | 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at | 26 http://www.ietf.org/ietf/1id-abstracts.txt | 28 The list of Internet-Draft shadow directories can be accessed at | 29 http://www.ietf.org/shadow.html 31 This memo provides information for the Internet community. This memo 32 does not specify an Internet standard of any kind. Distribution of 33 this memo is unlimited. 35 2. Abstract 37 This memo refers to a metric for variation in delay of packets across 38 Internet paths. The metric is based on statistics of the difference 39 in One-Way-Delay of consecutive packets. This particular definition 40 of variation is called "Instantaneous Packet Delay Variation (ipdv)". 42 The metric is valid for measurements between two hosts both in the 43 case that they have synchronized clocks and in the case that they are 44 not synchronized. In the second case it allows an evaluation of the 45 reciprocal skew. Measurements performed on both directions (Two-way 46 measurements) allow a better estimation of clock differences. The 47 precision that can be obtained is evaluated. 49 3. Introduction 51 This memo is based on "A One-Way-Delay metric for IPPM", RFC 2679 | 52 [2]. Part of the text in this memo is taken directly from that 53 document. 55 This memo defines a metric for variation in delay of packets that > 56 flow from one host to another one through an IP path. This quantity > 57 is sometimes called "jitter". This term, however, causes confusion > 58 because it is used in different ways by different groups of people. | 59 "Jitter" commonly has two meanings: The first meaning is the | 60 variation of a signal with respect to some clock signal, where the | 61 arrival time of the signal is expected to coincide with the arrival | 62 of the clock signal. The second meaning has to do with the variation | 63 of a metric (e.g. delay) with respect to some reference metric (e.g. | 64 average delay or minimum delay). The form of "jitter" that we talk | 65 about here has to do almost exclusively with the second meaning, | 66 rather than the first. For more information see the section on the | 67 relationship with other standards. 69 3.1. Definition 71 A definition of the Instantaneous Packet Delay Variation (ipdv) can 72 be given for a pair of packets or for a packet inside a stream of 73 packets. 75 For a pair of packets: 77 + The ipdv of a pair of IP packets, that are transmitted from the 78 measurement point MP1 to the measurement point MP2, is the 79 difference between the One-Way-Delay measured for the second 80 packet and the One-Way-Delay measured for the first packet of the 81 pair. 83 For a stream of packets: 85 + The Instantaneous Packet Delay Variation of an IP packet, inside a 86 stream of packets, going from the measurement point MP1 to the 87 measurement point MP2, is the difference of the One-Way-Delay of 88 that packet and the One-Way-Delay of the preceding packet in the 89 stream. 91 3.2. Motivation 93 A number of services that can be supported by IP are sensitive to the 94 regular delivery of packets and can be disturbed by instantaneous 95 variations in delay, while they are not disturbed by slow variations, 96 that can last a relatively long time. A specific metric for quick 97 variations is therefore desirable. Metrics that can be derived from 98 the analysis of statistics of ipdv can also be used, for example, for | 99 buffer dimensioning. The scope of this metric is to provide a way 100 for measurement of the quality delivered by a path. 102 In addition, this type of metric is particularly robust with respect 103 differences and variations of the clocks of the two hosts. This 104 allows the use of the metric even if the two hosts that support the 105 measurement points are not synchronized. In the latter case 106 indications of reciprocal skew of the clocks can be derived from the 107 measurement and corrections are possible. The related precision is 108 often comparable with the one that can be achieved with synchronized 109 clocks, being of the same order of magnitude of synchronization 110 errors. This will be discussed below. 112 3.3. General Issues Regarding Time 114 Everything contained in the Section 2.2. of [2] applies also in this | 115 case. 117 To summarize: As in [1] we define "skew" as the first derivative of > 118 the offset of a clock with respect to "true time" and define "drift" > 119 as the second derivative of the offset of a clock with respect to > 120 "true time". > 122 From there, we can construct "relative skew" and "relative drift" for > 123 two clocks C1 and C2 with respect to one another. These are natural > 124 extensions of the basic framework definitions of these quantities: > 126 + Relative offset = difference in clock times > 128 + Relative skew = first derivative of the difference in clock times > 130 + Relative drift = second derivative of the difference in clock > 131 times > 133 NOTE: The drift of a clock, as it is above defined over a long period 134 must have an average value that tends to zero while the period 135 becomes large since the frequency of the clock has a finite (and 136 small) range. In order to underline the order of magnitude of this 137 effect,it is considered that the maximum range of drift for 138 commercial crystals is about 50 part per million (ppm). Since it is 139 mainly connected with variations in operating temperature (from 0 to 140 70 degrees Celsius), it is expected that a host will have a nearly 141 constant temperature during its operation period, and variations in 142 temperature, even if quick, could be less than one Celsius per 143 second, and range in the order of few degrees. The total range of the 144 drift is usually related to variations from 0 to 70 Celsius. These 145 are important points for evaluation of precision of ipdv 146 measurements, as will be seen below. 148 4. Structure of this memo 150 The metric will be defined as applicable to a stream of packets that 151 flow from a source host to a destination host (one-way ipdv). The 152 initial assumption is that source and destination hosts have 153 synchronized clocks. The definition of a singleton of one-way ipdv 154 metric is first considered, and then a definition of samples for ipdv 155 will be given. 157 Then the case of application to non-synchronized hosts will be 158 discussed, and the precision will be compared with the one of 159 synchronized clocks. 161 A bidirectional ipdv metric will be defined, as well as the > 162 methodology for error corrections. This will not be a two-way metric, > 163 but a "paired" one-way in opposite directions. 165 5. A singleton definition of a One-way ipdv metric | 167 This definition makes use of the corresponding definition of type-P- 168 One-Way-Delay metric [2]. This section makes use of those parts of 169 the One-Way-Delay Draft that directly apply to the One-Way-ipdv 170 metric, or makes direct references to that Draft. 172 5.1. Metric name 174 Type-P-One-way-ipdv 176 5.2. Metric parameters 178 + Src, the IP address of a host 180 + Dst, the IP address of a host 182 + T1, a time 184 + T2, a time. It is explicitly noted that also the difference T2-T1 185 is a parameter of the measurement though this is already implicit, 186 since the times T1 and T2 exactly define the time conditions in 187 which the measurement takes place. 189 Note that the packet length is an implicit parameter of both the | 190 Type-P-One-way-delay metric and the Type-P-One-way-ipdv metric, since | 191 this contributes to the overall one-way delay. We assume that the | 192 packets sent for ipdv measurements are all of the same length. 194 5.3. Metric unit 196 The value of a Type-P-One-way-ipdv is either a real number of seconds 197 (positive, zero or negative) or an undefined number of seconds. 199 5.4. Definition 201 Type-P-One-way-ipdv is defined for two (consecutive) packets from Src 202 to Dst, as the difference between the value of the type-P-One-way- 203 delay from Src to Dst at T2 and the value of the type-P-One-Way-Delay 204 from Src to Dst at T1. T1 is the wire-time at which Scr sent the 205 first bit of the first packet, and T2 is the wire-time at which Src 206 sent the first bit of the second packet. This metric is therefore 207 ideally derived from the One-Way-Delay metric. 209 NOTE: The requirement of "consecutive" packets is not essential. The 210 measured value is anyway the difference in One-Way-Delay at the times 211 T1 and T2, which is meaningful by itself, as long as the times T1 and | 212 T2 denote the wire times of the packets sent from Src to Dst. 214 Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to 215 Dst at T1, T2 is ddT" means that Src sent two consecutive packets, 216 the first at wire-time T1 (first bit), and the second at wire-time T2 217 (first bit) and the packets were received by Dst at wire-time dT1+T1 218 (last bit of the first packet), and at wire-time dT2+T2 (last bit of 219 the second packet), and that dT2-dT1=ddT. 221 "The type-P-one-way-ipdv from Src to Dst at T1,T2 is undefined" means 222 that Src sent the first bit of a packet at T1 and the first bit of a 223 second packet at T2 and that Dst did not receive one or both packets. 225 5.5. Discussion 227 Type-P-One-way-ipdv is a metric that makes use of the same 228 measurement methods provided for delay metrics. 230 The following practical issues have to be considered: 232 + Being a differential measurement, this metric is less sensitive to 233 clock synchronization problems. This issue will be more carefully 234 examined in section 7 of this memo. It is pointed out that, if the 235 relative clock conditions change in time, the accuracy of the 236 measurement will depend on the time interval T2-T1 and the 237 magnitude of possible errors will be discussed below. 239 + A given methodology will have to include a way to determine 240 whether a delay value is infinite or whether it is merely very 241 large (and the packet is yet to arrive at Dst). As noted by 242 Mahdavi and Paxson, simple upper bounds (such as the 255 seconds 243 theoretical upper bound on the lifetimes of IP packets [Postel: 244 RFC 791]) could be used, but good engineering, including an 245 understanding of packet lifetimes, will be needed in practice. 246 {Comment: Note that, for many applications of these metrics, the 247 harm in treating a large delay as infinite might be zero or very 248 small. A TCP data packet, for example, that arrives only after 249 several multiples of the RTT may as well have been lost.} 251 + As with other 'type-P' metrics, the value of the metric may depend 252 on such properties of the packet as protocol,(UDP or TCP) port 253 number, size, and arrangement for special treatment (as with IP 254 precedence or with RSVP). 256 + If the packet is duplicated along the path (or paths!) so that 257 multiple non-corrupt copies arrive at the destination, then the 258 packet is counted as received, and the first copy to arrive 259 determines the packet's One-Way-Delay. 261 + If the packet is fragmented and if, for whatever reason, 262 reassembly does not occur, then the packet will be deemed lost. 264 5.6. Methodologies 266 As with other Type-P-* metrics, the detailed methodology will depend 267 on the Type-P (e.g., protocol number, UDP/TCP port number, size, 268 precedence). Generally, for a given Type-P, the methodology would 269 proceed as follows: 271 + The need of synchronized clocks for Src and Dst will be discussed 272 later. Here a methodology is supposed that is based on 273 synchronized clocks. 275 + At the Src host, select Src and Dst IP addresses, and form two 276 test packets of Type-P with these addresses. Any 'padding' portion 277 of the packet needed only to make the test packet a given size 278 should be filled with randomized bits to avoid a situation in 279 which the measured delay is lower than it would otherwise be due 280 to compression techniques along the path. 282 + At the Dst host, arrange to receive the packets. 284 + At the Src host, place a timestamp in the first Type-P packet, 285 and send it towards Dst. 287 + If the packet arrives within a reasonable period of time, take a 288 timestamp as soon as possible upon the receipt of the packet. By 289 subtracting the two timestamps, an estimate of One-Way-Delay can 290 be computed. 292 + Record this first delay value. 294 + At the Src host, place a timestamp in the second Type-P packet, 295 and send it towards Dst. 297 + If the packet arrives within a reasonable period of time, take a 298 timestamp as soon as possible upon the receipt of the packet. By 299 subtracting the two timestamps, an estimate of One-Way-Delay can 300 be computed. 302 + By subtracting the second value of One-Way-Delay from the first 303 value the ipdv value of the pair of packets is obtained. 305 + If one or both packets fail to arrive within a reasonable period 306 of time, the ipdv is taken to be undefined. 308 5.7. Errors and Uncertainties 310 In the singleton metric of ipdv, factors that affect the measurement 311 are the same that can affect the One-Way-Delay measurement, even if, 312 in this case, the influence is different. 314 The Framework document [1] provides general guidance on this point, 315 but we note here the following specifics related to delay metrics: 317 + Errors/uncertainties due to uncertainties in the clocks of the Src 318 and Dst hosts. 320 + Errors/uncertainties due to the difference between 'wire time' and 321 'host time'. 323 Each of these errors is discussed in more detail in the next 324 paragraphs. 326 5.7.1. Errors/Uncertainties related to Clocks 328 If, as a first approximation, the error that affects the first 329 measurement of One-Way-Delay were the same of the one affecting the 330 second measurement, they will cancel each other when calculating 331 ipdv. The residual error related to clocks is the difference of the 332 errors that are supposed to change from the time T1, at which the 333 first measurement is performed, to the time T2 at which the second 334 measure ment is performed. Synchronization, skew, accuracy and 335 resolution are here considered with the following notes: 337 + Errors in synchronization between source and destination clocks 338 contribute to errors in both of the delay measurements required 339 for calculating ipdv. 341 + The effect of drift and skew errors on ipdv measurements can be > 342 quantified as follows: Suppose that the skew and drift functions > 343 are known. Assume first that the skew function is linear in time. > 344 Clock offset if then also a function of time and the error evolves > 345 as e(t) = K*t + O, where K is a constant and O is the offset at > 346 time 0. In this case, the error added to the subtraction two > 347 different time stamps (t2 > t1) is e(t2)-e(t1) = K*(t2 - t1) which > 348 will be added to the time difference (t2 - t1). If the drift > 349 cannot be ignored, but we assume that the drift is a linear > 350 function of time, then the skew is given by s(t) = M*(t**2) + N*t > 351 + S0, where M and N are constants and S0 is the skew at time 0. > 352 The error added by the variable skew/drift process in this case > 353 becomes e(t) = O + s(t) and the error added to the difference in > 354 time stamps is e(t2)-e(t1) = N*(t2-t1) + M*{(t2-t1)**2}. > 355 It is the claim here (see remarks in section 3.3) that the effects > 356 of skew are rather small over the time scales that we are > 357 discussing here, since temperature variations in a system tend to > 358 be slow relative to packet inter-transmission times and the range > 359 of drift is so small. 361 + As far as accuracy and resolution are concerned, what is noted in 362 the one-way-delay document [2] in section 3.7.1, applies also in 363 this case, with the further consideration, about resolution, that 364 in this case the uncertainty introduced is two times the one of a 365 single delay measurement. Errors introduced by these effects are 366 often larger than the ones introduced by the drift. 368 5.7.2. Errors/uncertainties related to Wire-time vs Host-time 370 The content of sec. 3.7.2 of [2] applies also in this case, with the 371 following further consideration: The difference between Host-time and 372 Wire-time can be in general decomposed into two components, of which 373 one is constant and the other is variable. Only the variable 374 components will produce measurement errors, while the constant one 375 will be canceled while calculating ipdv. However, in most cases, the > 376 fixed and variable components are not known exactly. 378 6. Definitions for Samples of One-way ipdv 380 Starting from the definition of the singleton metric of one-way ipdv, | 381 we define a sample of such singletons. In the following, the two | 382 packets needed for a singleton measurement will be called a "pair". | 384 A stream of test packets is generated where the second packet of a | 385 pair is, at the same time, the first packet of the next pair. | 387 + Given particular binding of the parameters Src, Dst and Type-P, a | 388 sample of values of parameter T1 is defined. To define the values | 389 of T1, select a beginning time T0, a final time Tf, and an average | 390 rate lambda, then define a pseudo-random Poisson arrival process | 391 of rate lambda, whose values fall between T0 and Tf. The time | 392 interval between successive values of T1 will then average | 393 1/lambda. From the second value on, T1 value of the pair n | 394 coincides with T2 of the pair n-1, and the first packet of pair n | 395 coincides with the second packet of the pair n-1. | 397 6.1. Metric name 399 Type-P-One-way-ipdv-stream 401 6.2. Parameters 403 + Src, the IP address of a host 405 + Dst, the IP address of a host 407 + T0, a time 409 + Tf, a time 411 + lambda, a rate in reciprocal seconds 413 6.3. Metric Units: 415 A sequence of triads whose elements are: 417 + T, a time 419 + Ti, a time interval. 421 + dT a real number or an undefined number of seconds 423 6.4. Definition 425 A pseudo-random Poisson process is defined such that it begins at or 426 before T0, with average arrival rate lambda, and ends at or after Tf. 427 Those time values T(i) greater than or equal to T0 and less than or 428 equal to Tf are then selected. Starting from time T0, at each pair of 429 times T(i), T(i+1) of this process a value of Type-P-One-way-ipdv is 430 obtained. The value of the sample is the sequence made up of the 431 resulting triple, where the time interval 432 is given by T(i+1)-T(i). Each time T(i), excluding the first and the 433 last, is therefore at the same time the the second time of pair i and 434 the first time of pair i+1. The result is shown in figure 3 436 |T(i-2) |T(i-1) |T(i) |T(i+1) 437 _____|__________|___________________|__________|________ 438 pair i-1 pair i pair i+1 440 Figure 3 442 6.5. Discussion 444 Note first that, since a pseudo-random number sequence is employed, 445 the sequence of times, and hence the value of the sample, is not 446 fully specified. Pseudo-random number generators of good quality will 447 be needed to achieve the desired qualities. 449 The sample is defined in terms of a Poisson process both to avoid the 450 effects of self-synchronization and also capture a sample that is 451 statistically as unbiased as possible. {Comment: there is, of course, 452 no claim that real Internet traffic arrives according to a Poisson 453 arrival process.} 455 6.6. Methodology 457 Since packets can be lost or duplicated or can arrive in a different 458 order than the order sent, in order to recognize the pairs of test 459 packets, they should be marked with a sequence number. For duplicated 460 packets only the first received copy should be considered. If a 461 packet is lost, two values of ipdv will be undefined, since each 462 packet is common to two pairs. 464 Steps for measurement can be the following: 466 + Starting from a given time T, Src generates a test packet as for a 467 singleton metrics, inserts in the packet a sequence number and the 468 transmission time stamp Tx, then sorts the time Ti at which the 469 next packet has to be sent. 471 + At time Ti, Src repeats the previous step, unless T(i) > Tf. 473 + On reception of the first packet, or the first packet after a 474 sequence number error, Dst records sequence number and 475 transmission timestamp that are contained in the packet and the 476 reception time Rx as "old values". 478 + On reception of the other packets Dst verifies the seuqence number 479 and if it is correct, by using the "old values" and the newly 480 received ones, a value of ipdv is computed. Then Dst records the 481 new sequence number, transmit and receive timestamps as "old 482 values". 484 6.7. Errors and uncertainties 486 The same considerations apply that have been made about the singleton > 487 metric. Additional error can be introduced by the pseudo-random > 488 Poisson process as discussed in [2]. Further considerations will be > 489 given in section 7. | 491 6.8. Distribution of One-way-ipdv values | 493 The one-way-ipdv values are limited by virtue of the fact that there | 494 are upper and lower bounds on the one-way-delay values. Specifically, | 495 one-way-delay is upper bounded by the value chosen as the maximum | 496 beyond which a packet is counted as lost. It is lower bounded by | 497 propagation, transmission and nodal transit delays assuming that | 498 there are no queues or variable nodal delays in the path. Denote the | 499 upper bound of one-way-delay by U and the lower bound by L and we see | 500 that one-way-ipdv can only take on values in the (open) interval (L- | 501 U, U-L). | 503 In any finite interval, the one-way-delay can vary monotonically | 504 (non-increasing or non-decreasing) or of course it can vary in both | 505 directions in the interval, within the limits of the half-open | 506 interval [L,U). Accordingly, within that interval, the one-way-ipdv | 507 values can be positive, negative, or a mixture (including 0). | 509 Since the range of values is limited, the one-way-ipdv cannot | 510 increase or decrease indefinitely. Suppose, for example, that the | 511 ipdv has a positive 'run' (i.e. a long sequence of positive values). | 512 At some point in this 'run', the positive values must approach 0 (or | 513 become negative) if the one-way-delay remains finite. Otherwise, the | 514 one-way-delay bounds would be violated. If such a run were to | 515 continue infinitely long, the sample mean (assuming no packets are | 516 lost) would approach 0 (because the one-way-ipdv values must approach | 517 0). Note, however, that this says nothing about the shape of the | 518 distribution, or whether it is symmetric. Note further that over | 519 significant intervals, depending on the width of the interval [L,U), | 520 that the sample mean one-way-ipdv could be positive, negative or 0. 522 6.9. Some statistics for One-way-ipdv 524 Some statistics are suggested which can provide useful information in | 525 analyzing the behavior of the packets flowing from Src to Dst. The | 526 focus is on the instantaneous behavior of the connection. Other | 527 statistics can be defined if needed. 529 6.9.1. Type-P-One-way-ipdv-inverse-percentile 531 Given a Type-P-One-way-ipdv-Stream and a time threshold, that can be 532 either positive or negative, the fraction of all the ipdv values in 533 the Stream less than or equal to the threshold, if the threshold is 534 positive, or greater or equal to the threshold if the threshold is 535 negative. 537 For many real-time services that require a regular delivery of the 538 packets, these statistics provide the number of packets exceeding a 539 given limit. 541 6.9.2. Type-P-One-way-ipdv-jitter | 543 This metric is the same as the definition of "jitter" in [7], and is | 544 simply the absolute value of the Type-P-One-way-ipdv. | 546 6.9.3. The treatment of lost packets as having "infinite" or > 547 "undefined" delay complicates the derivation of statistics for ipdv. > 548 Specifically, when packets in the measurement sequence are lost, > 549 simple statistics such as sample mean cannot be computed. One > 550 possible approach to handling this problem is to reduce the event > 551 space by conditioning. That is, we consider conditional statistics; > 552 namely we estimate the mean ipdv (or jitter or other derivative > 553 statistic) conditioned on the event that successive packet pairs > 554 arrive at the destination (within the given timeout). While this > 555 itself is not without problems (what happens, for example, when every > 556 other packet is lost), it offers a way to make some (valid) > 557 statements about ipdv, at the same time avoiding events with > 558 undefined outcomes. We suggest that this be a topic for further > 559 study. 561 7. Discussion of clock synchronization 563 This section gives some considerations about the need of having 564 synchronized clocks at the source and destination. These 565 considerations are given as a basis for discussion and they require 566 further investigation. > 568 7.1. Effects of synchronization errors > 570 Clock errors can be generated by two processes: the relative drift > 571 and the relative skew of two given clocks. We should note that drift > 572 is physically limited and so the total relative skew of two clocks > 573 can vary between an upper and a lower bound. > 575 Suppose then that we have a measurement between two systems such that > 576 the clocks in the source and destination systems have at time 0 a > 577 relative skew of s(0) and after a measurement interval T have skew > 578 s(T). We assume that the two clocks have an initial offset of O (that > 579 is letter O). > 581 Now suppose that the packets travel from source to destination in > 582 constant time, in which case the ipdv is zero and the difference in > 583 the timestamps of the two clocks is actually just the relative offset > 584 of the clocks. Suppose further that at the beginning of the > 585 measurement interval the ipdv value is calculated from a packet pair > 586 and at the end of the measurement interval another ipdv value is > 587 calculated from another packet pair. Assume that the time interval > 588 covered by the first measurement is t1 and that covered by the second > 589 measurement is t2. Then > 591 ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T > 593 ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T > 595 assuming that the change is skew is linear in time. In most practical > 596 cases, it is claimed that the drift will be close to zero in which > 597 case the second (correction) term in the above equations disappears. > 599 Note that in the above discussion, other errors, including the > 600 differences between host time and wire time, and externally-caused > 601 clock discontinuities (e.g. clock corrections) were ignored. Under > 602 these assumptions the maximum clock errors will be due to the maximum > 603 relative skew acting on the largest interval between packets. > 605 7.2. Estimating the skew of unsynchronized clocks > 607 If the skew is linear (that is, if s(t) = S * t for constant S), the > 608 error in ipdv values will depend on the time between the packets used > 609 in calculating the value. If ti is the time between the ith and > 610 (i+1)st packet, then let Ti denote the sample mean time between > 611 packets and the average skew is s(Ti) = S * Ti. Note that E[Ti] > 612 should equal 1/lambda. In the event that the delays are constant, the > 613 skew parameter S can be estimated from the estimate Ti of the time > 614 between packets and the sample mean ipdv value. Under these > 615 assumptions, the ipdv values can be corrected by subtracting the > 616 estimated S * ti. > 618 We observe that the displacement due to the skew does not change the > 619 shape of the distribution, and, for example the Standard Deviation > 620 remains the same. What introduces a distortion is the effect of the > 621 drift, also when the mean value of this effect is zero at the end of > 622 the measurement. The value of this distortion is limited to the > 623 effect of the total skew variation on the emission interval. > 625 8. Definition for a bidirectional ipdv metric 627 We now consider that the action of the skew on one direction is the 628 same, with opposite sign, of the action on the other direction. The 629 idea of performing at the same time two independent measurements in 630 the two directions is suggested by this fact. 632 If, after a long measurement, the variable conditions of the system 633 under test have reached the situation of a contribution close to zero 634 to the mean value of the ipdv distribution, it is expected that only 635 the action of the average skew has modified the measured mean value. 636 It is therefore expected that in one direction that value is equal 637 and opposite to the one measured in the other direction. 639 This fact offers the possibility of defining a theoretical reference 640 measurement duration in the following way: 642 The reference duration of a bidirectional ipdv measurement between an 643 host E and an host W is reached at time Tf such that for each time T 644 > Tf the expression ABS(E(ipdv E-W) - E(ipdv W-E))< epsilon, where 645 epsilon is what we can consider as zero, is always verified. This is 646 one, but not the only method for verifying that the mean ipdv value 647 has reached the value of the average relative skew. 649 At this point it is possible to evaluate the relative skew. This 650 will require the knowledge of the mean value of the intervals between 651 consecutive packets, that can be calculated over the transmitted 652 stream, by using the collected time stamps. 654 A bidirectional measurement can be defined not only as twin one-way 655 independent metrics that take place (nearly) at the same time, but 656 also as a two-way metric making use of packets looped back at one 657 end. This metric, that can be object of further study/Draft, would be 658 able to measure also the Round Trip Delay and its variations. 659 Problems will anyway arise on the characterization of emission 660 intervals in the backward direction. They would be produced by the 661 combination of the original Poisson arrival process and the effect of 662 ipdv on the forward direction. It has to be studied if this sequence 663 of intervals is still suitable for the measurement. also other 664 possibilities can be envisaged for obtaining a proper backward 665 sequence and still maintain the loopback concept. 667 9. Relationship to other standards | 669 The ITU definitions are based on delay variation as defined for ATM | 670 cells [5]. We will discuss these briefly first and then discuss the | 671 ITU's definition for IP packets [3]. | 673 9.1. 1-Point Cell Delay Variation | 675 The ITU looks at cell delay variation from two different points of | 676 view. The first, called 1-point cell delay variation, is essentially | 677 a measure of how a cell stream varies from a stated cell rate (e.g. | 678 the peak cell rate). The basic idea behind the measurement is as | 679 follows: The observer at the measurement point notes cell arrival | 680 times and clock ticks. The clock ticks at a constant rate, based on | 681 the peak cell rate for the cell stream. The difference between the | 682 cell arrival times and the clock ticks is the 1-point cell delay | 683 variation. If a cell arrives later than the clock tick, the clock | 684 "restarts" at the actual cell arrival time, and continues to tick at | 685 a constant rate from that point. | 687 The purpose of this measure is to identify what is called "cell | 688 clumping" and non-conforming cells. That is, to idenify cells that | 689 violate the leaky bucket parameters defined for that cell stream. | 690 That is why the clock skips when a cell is later than the normal | 691 inter-cell time defined by the peak cell rate. It is of much less | 692 interest when cells are late than when they arrive too close | 693 together. | 695 9.2. 2-Point Delay Variation, Cells and Packets | 697 2-Point cell delay variation, as defined in [5] is closer to what is | 698 defined here. The basic idea behind this metric is that two | 699 measurement points, whose clocks are synchronized, observe a cell | 700 stream and timestamp when each cell passes. The difference in the | 701 timestamps for a cell is essentially the one-way delay. There is also | 702 assumed to be a one-way cell delay for a reference cell which we will | 703 denote d0. The cell delay variation for the ith cell is then di-d0. | 704 Note that this is not an absolute value, but that the cell delay | 705 variation can be either positive or negative. [5] does not specify | 706 how to choose the reference cell delay. | 708 In [3] there is an informative appendix describing packet delay | 709 variation, which means that the material is not binding as a | 710 standard. The definitions are very similar to [5] with "packet" | 711 subsituting for "cell" in most places. One difference is that [3] | 712 offers two ways to define the reference packet (with the default | 713 being the first): | 715 + Take the delay of the first packet of the sequence as the | 716 reference time. | 718 + Take the average one-way packet delay as the reference time. | 720 9.3. Discussion | 722 9.3.1. Differences | 724 Demichelis [4] points out a number of problems with the 2-point PDV | 725 definition in [3]. First of all is the issue of choosing the | 726 reference delay time. If this is chosen arbitrarily, it becomes | 727 uncertain how to compare the measurements taken from two non- | 728 overlapping periods. If it is chosen as an average, that can also be | 729 a problem, because over long periods of time in a network, the | 730 average one-way delay can vary widely. A twenty-four hour average as | 731 the reference time can seriously overestimate the actual delay | 732 variation at a given time of day because the night-time hours, when | 733 the delay can be expected to approach the propagation and node time, | 734 is included in the average. On the other hand, there is no clear way | 735 to partition the time in order to find averages for certain periods | 736 of time and compute the delay variation with reference to these | 737 averages. | 739 Another problem pointed out in [4] is the fact that 2-point PDV | 740 requires synchronized clocks, whereas in this document Demichelis | 741 shows that synchronized clocks are not absolutely necessary for ipdv. | 743 9.3.2. Relationship between the metrics | 745 The ipdv metric described here and the 1-point cell delay variation | 746 metric described in [5] do not really have much in common (see also | 747 [4]). 1-point delay variation is really intended to talk about the | 748 relationship of cell arrival times to a given periodic event, and | 749 consequently is more closely related to the first definition of | 750 "jitter" given in Section 3 above. | 752 2-point delay variation (actually, the packet variant described in | 753 [3]) is related to ipdv, and this relationship can be made precise as | 754 follows: Suppose that an arbitrarily chosen packet is designated as | 755 the reference packet for the 2-point measurement and also as the | 756 start packet of the ipdv measurement. Denote this packet by p(0). | 757 Then given ipdv measurements for a series of packets, the 2-point | 758 delay variation for packet i is p(0) + the sum from k=1 to i of | 759 ipdv(k). | 761 Similarly, given a sequence of 2-point delay variation measurements | 762 we can derive the ipdv measurement as follows: Denote the 2-point | 763 delay variation measurement for packet i as v(i). Then the ipdv value | 764 for the pair of packets p(k-1), p(k) is simply v(k)-v(k-1) [6]. | 766 9.3.3. Summary | 768 As described above, there are a number of disadvantages of the | 769 2-point packet delay variation approach. Further, the ipdv approach | 770 described here is general enough to provide the same information as | 771 the 2-point packet delay variation measurements. Because of this, and | 772 because of the (possibly) looser clock synchronization requirements | 773 of ipdv, we recommend the one-way-ipdv approach for the delay | 774 variation measurement. | 776 10. Security Considerations | 778 The one-way-ipdv metric has the same security properties as the one- | 779 way-delay metric [2]. The packets contain no user information, and so | 780 privacy of user data is not a concern. It is still possible that | 781 there could be an attempt at a denial of service attack by sending | 782 many measurement packets into the network; there could also be | 783 attempts to disrupt measurements by diverting packets or corrupting | 784 them. | 786 In general, legitimate measurements must have their parameters | 787 selected carefully in order to avoid interfering with normal traffic | 788 in the network. Such measurements should also be authorized and | 789 authenticated in some way so that attacks can be identified and | 790 intercepted. | 792 11. Acknowledgements | 794 Thanks to Matt Zekauskas from Advanced and Ruediger Geib from | 795 Deutsche Telekom for discussions relating to the contents of this | 796 revised draft. For this additional revision, discussions by e-mail > 797 with Andy Scherrer were very helpful. 799 12. References 800 [1] V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP 801 Performance Metrics", RFC 2330 Feb. 1998 803 [2] G.Almes, S.Kalidindi - "A One-Way-Delay Metric for IPPM", RFC 804 2679, September 1999 806 [3] ITU-T Recommendation I.380 "Internet Protocol Data 807 Communication Service - IP Packet Transfer and Availability 808 Performance Parameters", February 1999 810 [4] Demichelis, Carlo - "Packet Delay Variation Comparison between 811 ITU-T and IETF Draft Definitions" March 1999 813 [5] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer 814 Performance" 816 [6] e-mail exchanges with Ruediger Geib 818 [7] V. Jacobson, K. Nichols, K. Poduri - "An expedited forwarding 819 PHB", RFC 2598, June 1999 821 13. Authors' Addresses 823 Carlo Demichelis 824 CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A 825 Via G. Reiss Romoli 274 826 10148 - TORINO 827 Italy 828 Phone +39 11 228 5057 829 Fax. +39 11 228 5069 830 Philip Chimento 831 CTIT - Centre for Telematics and Information Technology 832 University of Twente 833 Postbox 217 834 7500 AE Enschede 835 The Netherlands 836 Phone +31 53 489 4331 837 FAX +31 53 489 4524 839 Expiration date: April 2000