idnits 2.17.1 draft-morton-ippm-delay-var-as-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 799. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- The document date (October 15, 2006) is 6396 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2680' is defined on line 695, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) == Outdated reference: A later version (-09) exists of draft-ietf-ippm-framework-compagg-01 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Informational October 15, 2006 5 Expires: April 18, 2007 7 Packet Delay Variation Applicability Statement 8 draft-morton-ippm-delay-var-as-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 18, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Many definitions of packet delay variation exist, and two different 42 formulations have come into wide use in the context of active 43 measurements. This memo examines a range of circumstances for active 44 measurements and their uses, and recommends which of these two forms 45 is best matched to the conditions and task. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Uses of Delay Variation Metrics . . . . . . . . . . . . . . . 4 58 3.1. Determining De-jitter Buffer Size . . . . . . . . . . . . 4 59 3.2. Inferring Queue Occupation on a Path . . . . . . . . . . . 5 60 3.3. Spatial Composition . . . . . . . . . . . . . . . . . . . 5 61 3.4. Challenging Circumstances . . . . . . . . . . . . . . . . 5 62 3.5. . . . . . . . . . . . . . . . . . . . 6 63 4. Formulations of IPDV and PDV . . . . . . . . . . . . . . . . . 6 64 4.1. IPDV: Inter-Packet Delay Variation . . . . . . . . . . . . 6 65 4.2. PDV: Packet Delay Variation . . . . . . . . . . . . . . . 6 66 4.3. Examples and Initial Comparisons . . . . . . . . . . . . . 6 67 5. Earlier Comparisons . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Demichelis' Comparison . . . . . . . . . . . . . . . . . . 7 69 5.2. Ciavattone et al. . . . . . . . . . . . . . . . . . . . . 8 70 5.3. IPPM List Discussion from 2001 . . . . . . . . . . . . . . 8 71 5.4. Y.1540 Appendix II . . . . . . . . . . . . . . . . . . . . 9 72 6. Additional Properties and Comparisons . . . . . . . . . . . . 9 73 6.1. Jitter in RTCP Reports . . . . . . . . . . . . . . . . . . 9 74 6.2. Path Changes . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.2.1. Lossless Path Change . . . . . . . . . . . . . . . . . 10 76 6.2.2. Path Change with Loss . . . . . . . . . . . . . . . . 11 77 6.3. Measurement Clock Issues . . . . . . . . . . . . . . . . . 11 78 6.4. Reporting a Single Number . . . . . . . . . . . . . . . . 12 79 6.5. MAPDV2 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Applicability of the Delay Variation Forms with Tasks . . . . 13 81 7.1. Challenging Circumstances . . . . . . . . . . . . . . . . 13 82 7.2. Spatial Composition . . . . . . . . . . . . . . . . . . . 13 83 7.3. Inferring Queue Occupancy . . . . . . . . . . . . . . . . 14 84 7.4. Determining De-jitter Buffer Size . . . . . . . . . . . . 14 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 Intellectual Property and Copyright Statements . . . . . . . . . . 18 94 1. Introduction 96 There are many ways to formulate delay variation metrics for packet 97 networks. The IETF itself has several specifications for delay 98 variation, sometimes called jitter, and these have achieved wide 99 adoption. The International Telecommunication Union - 100 Telecommunication Standardization Sector has also recommended several 101 delay variation metrics (called parameters in their terminology), and 102 some of these are widely cited and used. 104 Most (if not all) delay variation metrics are derived metrics, in 105 that their definitions rely on another fundamental metric. In this 106 case, the fundamental metric is one-way delay, and variation is 107 assessed by computing the difference between two individual one-way 108 delay measurements, or a pair of singletons. One of the delay 109 singletons is taken as a reference value, and the result is the 110 variation with respect to the reference. The variation is usually 111 summarized for all packets in a stream (or sample) using statistics. 113 Two main formulations of delay variation are preferred (according to 114 [Krzanowski]): 116 1. Inter-Packet Delay Variation, IPDV, where the reference is the 117 previous packet in the stream (according to sending sequence), 118 and the reference changes for each packet in the stream. 119 Properties of variation and packet sequence are captured in this 120 formulation. 122 2. Packet Delay Variation, PDV, where a single reference is chosen 123 from the stream based on specific criteria, and the reference is 124 fixed once selected. The most common criterion for the reference 125 is the packet with the minimum delay in the sample. 127 Each of these metric formulations has certain advantages and 128 disadvantages that make them more suitable for one circumstance and 129 less so for another. This memo examines a range of circumstances for 130 active measurements of delay variation and their uses, and recommends 131 the form that is best matched to the conditions and task. 133 It is important to note that the authors of relevant standards for 134 delay variation recognized there are many different users with 135 varying needs, and allowed sufficient flexibility to formulate 136 several metrics with different properties. Therefore, the comparison 137 is not so much between standards bodies or their specifications as it 138 is between specific formulations of delay variation. For instance, 139 both Inter-Packet Delay Variation and Packet Delay Variation can be 140 assessed using options of [RFC3393], especially the packet selection 141 function. 143 The IPPM framework [RFC2330] and other RFCs describing IPPM metrics 144 provide a background for this memo, especially for terms such as 145 singleton, sample, and statistic. 147 2. Purpose and Scope 149 The purpose of this memo is to compare two forms of delay variation, 150 so that it will be evident which of the two is better suited for each 151 of many possible uses and their related circumstances. 153 The scope of this memo is limited to the two forms of delay variation 154 briefly described above (Inter-Packet Delay Variation and Packet 155 Delay Variation), circumstances related to active measurement, and 156 uses that are deemed relevant and worthy of inclusion here through 157 IPPM Working Group consensus. 159 The scope excludes assessment of delay variation for packets with 160 undefined delay. The is accomplished by conditioning the delay 161 distribution on arrival within a reasonable time based on an 162 understanding of the path under test and packet lifetimes. This is 163 consistent with [RFC3393], where the Type-P-One-way-ipdv is undefined 164 when the destination fails to receive one or both packets in the 165 selected pair. Furthermore, it is consistent with application 166 performance analysis to consider only arriving packets, because a 167 finite waiting time-out is a feature of many protocols. 169 3. Uses of Delay Variation Metrics 171 This section presents a set of tasks that call for delay variation 172 measurements and their possible circumstances. It answers the 173 question, "How will the results be used?" for the delay variation 174 metric. 176 3.1. Determining De-jitter Buffer Size 178 Most Isochronous applications (a.k.a. real-time applications) employ 179 a buffer to smooth out delay variation encountered on the path from 180 source to destination. The buffer must be big enough to accommodate 181 (most of) the expected variation, or packet loss will result. 182 However, if the buffer is too large, then some of the desired 183 spontaneity of communication will be lost and conversational dynamics 184 will be affected. Therefore, application designers need to know the 185 extent of delay variation they must accommodate, whether they are 186 designing fixed or adaptive buffer systems. 188 Network service providers also attempt to constrain delay variation 189 to ensure the quality of real-time applications, and monitor this 190 metric (possibly to compare with a numerical objective or Service 191 Level Agreement). 193 3.2. Inferring Queue Occupation on a Path 195 As packets travel along the path from source to destination, they 196 pass through a series of router queues. Many of the sources of delay 197 along the path are constant, but the latency encountered in each 198 queue varies, depending on the number of packets in the queue when a 199 particular packet arrives. If one assumes that at least one of the 200 packets in a test stream encounters virtually empty queues all along 201 the path (and the path is stable), then the additional delay observed 202 on other packets can be attributed to the time spent in one or more 203 queues. Otherwise, the delay variation observed is the variation in 204 queue time experienced by the test stream. 206 3.3. Spatial Composition 208 In Spatial Composition, the tasks are similar to those described 209 above, but with the additional complexity of a multiple network path 210 where several sub-paths are measured separately, and no source to 211 destination measurements are available. In this case, the source to 212 destination performance must be estimated, using Composed Metrics as 213 described in [I-D.ietf-ippm-framework-compagg] 215 3.4. Challenging Circumstances 217 Any of the tasks above are made more "interesting" when certain 218 circumstances are present. Among these are: 220 1. Low cost or low complexity measurement systems. These systems 221 may be embedded in communication devices that do not have access 222 to high stability clocks, and time errors will almost certainly 223 be present. These devices may not have sufficient memory to 224 store all singletons for later processing. 226 2. Extremely dynamic network conditions. When there is little or no 227 stability in the network under test, then the devices that 228 attempt to characterize the network are equally stressed, 229 especially if the results displayed are used to make inferences 230 which may not be valid. Frequent path changes and prolonged 231 congestion with substantial packet loss clearly make delay 232 variation measurements challenging. 234 3.5. 236 4. Formulations of IPDV and PDV 238 This section presents the formulations of IPDV and PDV, and provides 239 some illustrative examples. We use the basic singleton definition in 240 [RFC3393] (which itself is based on [RFC2679]): 242 "Type-P-One-way-ipdv is defined for two packets from Src to Dst 243 selected by the selection function F, as the difference between the 244 value of the Type-P-One-way-delay from Src to Dst at T2 and the value 245 of the Type-P-One-Way-Delay from Src to Dst at T1." 247 4.1. IPDV: Inter-Packet Delay Variation 249 An example selection function given in [RFC3393] is "Consecutive 250 Type-P packets within the specified interval." This is exactly the 251 function needed for IPDV. The reference packet in the pair is always 252 the previous packet in the sending sequence. 254 If we have packets in a stream consecutively numbered i = 1,2,3,... 255 falling within the test interval, then IPDV(i) = D(i)-D(i-1) where 256 D(i) denotes the one-way-delay of the ith packet of a stream. 258 4.2. PDV: Packet Delay Variation 260 The Selection Function for PDV requires two specific roles for the 261 packets in the pair. The first packet is any Type-P packet within 262 the specified interval. The second, or reference packet is the 263 Type-P packet within the specified interval with the minimum one-way- 264 delay. 266 Therefore, PDV(i) = D(i)-D(min) (using the nomenclature introduced in 267 the IPDV section). 269 4.3. Examples and Initial Comparisons 271 This section will discuss the examples in slides 2 and 3 of 273 http://www3.ietf.org/proceedings/06mar/slides/ippm-4.pdf 275 5. Earlier Comparisons 277 This section summarizes previous work to compare these two forms of 278 delay variation. 280 5.1. Demichelis' Comparison 282 In [Demichelis], Demichelis compared the early draft versions of the 283 two forms we consider here. Although the IPDV form would eventually 284 be standardized under the IETF IPPM effort, the ITU-T work cited here 285 was significantly modified based on further study and analysis. 286 Demichelis considered the possibilities of using the delay of the 287 first packet in the stream and the mean delay of the stream as the 288 PDV reference packet. Neither of these alternative references were 289 used in practice, and they are now depreciated in favor of the 290 minimum delay of the stream [Y.1540] . 292 Active measurements of a transcontinental path (Torino to Tokyo) 293 provided the data for the comparison. The Poisson test stream had 294 0.764 second average inter-packet interval, with more than 58 295 thousand packets over 13.5 hours. Among Demichelis' observations 296 about IPDV are the following: 298 1. IPDV is a measure of the network's ability to preserve the 299 spacing between packets. 301 2. The distribution of IPDV is usually symmetrical about the origin, 302 having a balance of negative and positive values (for the most 303 part). The mean is usually zero, unless some long-term delay 304 trend is present. 306 3. IPDV distinguishes quick delay variations (on the order of the 307 interval between packets) from longer term variations. 309 4. IPDV places reduced demands on the stability and skew of 310 measurement clocks. 312 He also notes these features of PDV: 314 1. PDV does not distinguish quick variation from variation over the 315 complete test interval. 317 2. The location of the distribution is very sensitive to the delay 318 of the first packet, if this packet is used as the reference. 320 3. The shape of the PDV distribution is identical to the delay 321 distribution, but shifted by the reference delay. 323 4. Use of a common reference over long measurement intervals can 324 indicate more PDV than would be experienced by streams that 325 support shorter interval sessions. 327 5. PDV characterizes the range of queue occupancies along the 328 measurement path (assuming the path is fixed), but the range says 329 nothing about how the variation took place. 331 The summary metrics used in this comparison were the number of values 332 exceeding a +/-50ms range around the mean, the Inverse Percentiles, 333 and the Inter-Quartile Range. 335 5.2. Ciavattone et al. 337 In [Cia03], the authors compared IPDV and PDV (referred to as delta) 338 using a periodic packet stream conforming to [RFC3432] with inter- 339 packet interval of 20 ms. 341 One of the comparisons between IPDV and PDV involves a laboratory 342 set-up where a queue was temporarily congested by a competing packet 343 burst. The additional queuing delay was 85ms to 95ms, much larger 344 than the inter-packet interval. The first packet in the stream that 345 follows the competing burst spends the longest time enqueued, and 346 others experience less and less queuing time until the queue is 347 drained. 349 The authors observed that PDV reflects the additional queuing time of 350 the packets affected by the burst, with values of 85, 65, 45, 25, and 351 5ms. Also, it is easy to determine (by looking at the PDV range) 352 that a de-jitter buffer of 90 ms would have been sufficient to 353 accommodate the delay variation. 355 The distribution of IPDV values in the congested queue example are 356 very different: 85, -20, -20, -20, -20, -5ms. Only the positive 357 excursion of IPDV gives an indication of the de-jitter buffer size 358 needed. Although the variation exceeds the inter-packet interval, 359 the extent of negative IPDV values is limited by that sending 360 interval. This preference for information from the positive IPDV 361 values has prompted some to ignore the negative values, or to take 362 the absolute value of each IPDV measurement (sacrificing key 363 properties of IPDV in the process, such as its ability to distinguish 364 delay trends). 366 Elsewhere, the authors considered the range as a summary statistic 367 for IPDV, and the 99.9%-ile minus the minimum delay as a summary 368 statistic for delay variation, or PDV. 370 5.3. IPPM List Discussion from 2001 372 Summary To Be Provided. But to indicate one of the key points: 374 IPDV values can be viewed as the adjustments that an adaptive de- 375 jitter buffer would make, IF it could make adjustments on a packet- 376 by-packet basis. However, adaptive de-jitter buffers don't make 377 adjustments so frequently, so in this respect IPDV provides "too much 378 information". 380 5.4. Y.1540 Appendix II 382 This Appendix compares IPDV, PDV (referred to as 2-point PDV), and 383 1-point packet delay variation (which assume a periodic stream and 384 assesses variation against an ideal arrival schedule constructed at 385 the single measurement point). 387 6. Additional Properties and Comparisons 389 This section treats some of the earlier comparison areas in more 390 detail, and introduces new areas for comparison. 392 6.1. Jitter in RTCP Reports 394 [RFC3550] gives the calculation of the inter-arrival Jitter field for 395 the RTCP report, with a sample implementation in an Appendix. 397 The RTCP Jitter value can be calculated using IPDV singletons. If 398 there is packet reordering, as defined in [I-D.ietf-ippm-reordering], 399 then estimates of Jitter based on IPDV may vary slightly, because 400 [RFC3550] specifies the use of receive packet order. 402 Just as there is no simple way to convert PDV singletons to IPDV 403 singletons without returning to the original sample of delay 404 singletons, there is no clear relationship between PDV and [RFC3550] 405 Jitter. 407 6.2. Path Changes 409 Sometimes the path characteristics change during a measurement 410 interval. The change may be due to link or router failure, 411 administrative changes prior to maintenance (e.g., link cost change), 412 or re-optimization of routing using new information. All these 413 causes are usually infrequent, and network providers take appropriate 414 measures to ensure this. Automatic restoration to a back-up path is 415 seen as a desirable feature of IP networks. 417 Path changes are usually accompanied by a persistent increase or 418 decrease in one-way-delay. [Cia03] gives one such example. We 419 assume that a restoration path either accepts a stream of packets, or 420 is not used for that particular stream (e.g., no multipath for 421 flows). 423 In any case, a change in the TTL (or Hop Limit) of the received 424 packets indicates that the path is no longer the same. Transient 425 packet reordering may also be observed with path changes, due to use 426 of non-optimal routing while updates propagate through the network 427 (see [Casner] and [Cia03] ) 429 Many, if not all, packet streams experience packet loss in 430 conjunction with a path change. However, it is certainly possible 431 that the active measurement stream does not experience loss. This 432 may be due to use of a long inter-packet sending interval with 433 respect to the restoration time, and this becomes more likely as 434 "fast restoration" techniques see wider deployment. 436 Thus, there are two main cases to consider, path changes accompanied 437 by loss, and those that are lossless from the point of view of the 438 active measurement stream. 440 6.2.1. Lossless Path Change 442 In the lossless case, a path change will typically affect only two 443 IPDV singletons. However, if the change in delay is negative and 444 larger than the inter-packet sending interval, then more than two 445 IPDV singletons may be affected because packet reordering is also 446 likely to occur. 448 The use of the new path and its delay variation can be quantified by 449 treating the PDV distribution as bi-modal, and characterizing each 450 mode separately. This would involve declaring a new path within the 451 sample, and using a new local minimum delay as the PDV reference 452 delay for the sub-sample (or time interval) where the new path is 453 present. 455 The process of detecting a bi-modal delay distribution is made 456 difficult if the typical delay variation is larger than the delay 457 change associated with the new path. However, information on TTL (or 458 Hop Limit) change or the presence of transient reordering can assist 459 in an automated decision. 461 The effect of path changes may also be reduced by making PDV 462 measurements over short intervals (minutes, as opposed to hours). 463 This way, a path change will affect one sample and its PDV values. 464 Assuming that the mean or median one-way-delay changes appreciably on 465 the new path, then subsequent measurements can confirm a path change, 466 and trigger special processing on the interval containing a path 467 change and the affected PDV result. 469 6.2.2. Path Change with Loss 471 If the path change is accompanied by loss, such that the are no 472 consecutive packet pairs that span the change, then no IPDV 473 singletons will reflect the change. This may or may not be 474 desirable, depending on the ultimate use of the delay variation 475 measurement. 477 PDV will again produce a bimodal distribution. But here, the 478 decision process to define sub-intervals associated with each path is 479 further assisted by the presence of loss, in addition to TTL, 480 reordering information, and use of short measurement intervals 481 consistent with the duration of user sessions. It is reasonable to 482 assume that at least loss and delay will be measured simultaneously 483 with PDV or IPDV. 485 6.3. Measurement Clock Issues 487 As mentioned above, [Demichelis] observed that PDV places greater 488 demands on clock synchronization than for IPDV. This observation 489 deserves more discussion. Synchronization errors have two 490 components: time of day errors and clock frequency errors (resulting 491 in skew). 493 Both IPDV and PDV are sensitive to time-of-day errors when attempting 494 to align measurement intervals at the source and destination. Gross 495 mis-alignment of the measurement intervals can lead to lost packets, 496 for example if the receiver is not ready when the first test packet 497 arrives. However, both IPDV and PDV assess time differences, so the 498 error present in two one-way-delay singletons will cancel as long as 499 it is constant. 501 Skew is a measure of the change in clock time over an interval w.r.t. 502 a reference clock. Both IPDV and PDV are affected by skew, but the 503 error sensitivity in IPDV singletons is less because the intervals 504 between consecutive packets are rather small, especially when 505 compared to the overall measurement interval. Since PDV computes the 506 difference between a single reference delay (the sample minimum) and 507 all other delays in the measurement interval, the constraint on skew 508 error is greater to attain the same accuracy as IPDV. Again, use of 509 short PDV measurement intervals (on the order of minutes, not hours) 510 provides some relief from the effects of skew error. 512 If skew is present in a sample of one-way-delays, its symptom is 513 typically a linear growth or decline over all the one-way-delay 514 values. As a practical matter, if the same slope appears 515 consistently in the measurements, then it may be possible to fit the 516 slope and compensate for the skew in the one-way-delay measurements, 517 thereby avoiding the issue in the PDV calculations that follow. See 518 [RFC3393] for additional information on compensating for skew. 520 6.4. Reporting a Single Number 522 Despite the risk of over-summarization, measurements must often be 523 displayed for easy consumption. If the right summary report is 524 prepared, then the "dashboard" view correctly indicates whether there 525 is something different and worth investigating further, or that the 526 status has not changed. The dashboard model restricts every 527 instrument display to a single number. The packet network dashboard 528 could have different instruments for loss, delay, delay variation, 529 reordering, etc., and each must be summarized as a single number for 530 each measurement interval. 532 The simplicity of the PDV distribution lends itself to this 533 summarization process (including use of the median or mean). 534 [Y.1541] introduced the notion of a pseudo-range when setting an 535 objective for the 99.9%-ile of PDV. The conventional range (max-min) 536 was avoided for several reasons, including stability of the maximum 537 delay. The 99.9%-ile of PDV is helpful to performance planners 538 (seeking to meet some user-to-user objective for delay) and in design 539 of de-jitter buffer sizes, even those with adaptive capabilities. 541 IPDV does not lend itself to summarization so easily. The mean IPDV 542 is typically zero. As the IPDV distribution may have two tails 543 (positive and negative) the range or pseudo-range would not match the 544 needed de-jitter buffer size. Additional complexity may be 545 introduced when the variation exceeds the inter-packet sending 546 interval, as discussed above. Should the Inter-Quartile Range be 547 used? Should the singletons beyond some threshold be counted (e.g., 548 mean +/- 50ms)? A strong rationale for one of these summary 549 statistics has yet to emerge. 551 6.5. MAPDV2 553 MAPDV2 stands for Mean Absolute Packet Delay Variation (version) 2, 554 and is specified in [G.1020]. The MAPDV2 algorithm computes a 555 smoothed running estimate of the mean delay using the one-way delays 556 of 16 previous packets. It compares the current one-way-delay to the 557 estimated mean, separately computes the means of positive and 558 negative deviations, and sums these deviation means to produce 559 MAPVDV2. In effect, there is a MAPDV2 singleton for every arriving 560 packet, so further summarization is usually warranted. 562 Neither IPDV or PDV assists in the computation of MAPDV2. 564 7. Applicability of the Delay Variation Forms with Tasks 566 Based on the comparisons of IPDV and PDV presented above, this 567 section matches the attributes of each form with the tasks described 568 in section 3. We discuss the more general circumstances first. 570 Note: the conclusions of this section should be regarded as 571 preliminary, pending discussion and further development by the IPPM 572 WG. 574 7.1. Challenging Circumstances 576 When appreciable skew is present between measurement system clocks, 577 then IPDV has a clear advantage, since that PDV would require 578 processing over the entire sample to remove the skew error. Neither 579 form of delay variation is more suited than the other to on-the-fly 580 summarization without memory, and this is one of the reasons that 581 [RFC3550] RTCP Jitter and MAPDV2 in [G.1020] have attained deployment 582 in low-cost systems. 584 If the network under test exhibits frequent path changes, on the 585 order of several new routes per minute, then IPDV appears to isolate 586 the delay variation on each path from the transient effect of path 587 change (especially if there is packet loss at the time of path 588 change). It is possible to make meaningful PDV measurements when 589 paths are unstable, but great importance would be placed on the 590 algorithms that infer path change and attempt to divide the sample on 591 path change boundaries. 593 If the network under test exhibits frequent loss, then PDV may 594 produce a larger set of singletons for the sample than IPDV. This is 595 due to IPDV requiring consecutive packet arrivals to assess delay 596 variation, compared to PDV where any packet arrival is useful. The 597 worst case is when no consecutive packets arrive, and the entire IPDV 598 sample would be undefined. PDV would successfully produce a sample 599 based on the arriving packets. 601 Note that delay variation may not be the top concern under these 602 unstable and un-reliable circumstances, as this author has pointed- 603 out many times in discussion. 605 7.2. Spatial Composition 607 ITU-T Recommendation [Y.1541] gives a provisional method to compose a 608 PDV metric using PDV measurement results from two or more sub-paths. 610 PDV has a clear advantage at this time, since there is no known 611 method to compose an IPDV metric. In addition, IPDV results depend 612 greatly on the exact sequence of packets and may not lend themselves 613 easily to the composition problem. 615 7.3. Inferring Queue Occupancy 617 The PDV distribution is anchored at the minimum delay observed in the 618 measurement interval. When the sample minimum coincides with the 619 true minimum delay of the path, then the PDV distribution is 620 equivalent to the queuing time distribution experienced by the test 621 stream. If the minimum delay is not the true minimum, then the PDV 622 distribution captures the variation in queuing time and some 623 additional amount of queuing time is experienced, but unknown. One 624 can summarize the PDV distribution with the mean, median, and other 625 statistics. 627 IPDV can capture the difference in queuing time from one packet to 628 the next, but this is a different distribution from the queue 629 occupancy revealed by PDV. 631 7.4. Determining De-jitter Buffer Size 633 This task is complimentary to the problem of inferring queue 634 occupancy through measurement. Again, use of the sample minimum as 635 the reference delay for PDV yields a distribution that is very 636 relevant to de-jitter buffer size. This is because the minimum delay 637 is an alignment point for the smoothing operation of de-jitter 638 buffers. A de-jitter buffer that is ideally aligned with the delay 639 variation adds zero buffer time to packets with the longest 640 accommodated network delay (any packets with longer delays are 641 discarded). Thus, a packet experiencing minimum network delay should 642 be aligned to wait the maximum length of the de-jitter buffer. With 643 this alignment, the stream is smoothed with no unnecessary delay 644 added. [G.1020] illustrates the ideal relationship between network 645 delay variation and buffer time. 647 The PDV distribution is also useful for this task, but different 648 statistics are preferred. The range (max-min) or the 99.9%-ile of 649 PDV (pseudo-range) are closely related to the buffer size needed to 650 accommodate the observed network delay variation. 652 In some cases, the positive excursions of IPDV may help to 653 approximate the de-jitter buffer size, but there is no guarantee that 654 a good buffer estimate will emerge, especially when the delay varies 655 as a positive trend over several test packets. 657 8. IANA Considerations 659 This document makes no request of IANA. 661 Note to RFC Editor: this section may be removed on publication as an 662 RFC. 664 9. Security Considerations 666 The security considerations that apply to any active measurement of 667 live networks are relevant here as well. See [RFC4656] 669 10. Acknowledgements 671 The author would like to thank Phil Chimento for his suggestion to 672 employ the convention of conditional distributions for Delay to deal 673 with packet loss, and his encouragement to "write the memo" after 674 hearing the talk. 676 11. References 678 11.1. Normative References 680 [I-D.ietf-ippm-reordering] 681 Morton, A., "Packet Reordering Metric for IPPM", 682 draft-ietf-ippm-reordering-13 (work in progress), 683 May 2006. 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 688 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 689 "Framework for IP Performance Metrics", RFC 2330, 690 May 1998. 692 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 693 Delay Metric for IPPM", RFC 2679, September 1999. 695 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 696 Packet Loss Metric for IPPM", RFC 2680, September 1999. 698 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 699 Metric for IP Performance Metrics (IPPM)", RFC 3393, 700 November 2002. 702 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 703 performance measurement with periodic streams", RFC 3432, 704 November 2002. 706 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 707 Zekauskas, "A One-way Active Measurement Protocol 708 (OWAMP)", RFC 4656, September 2006. 710 11.2. Informative References 712 [Casner] "A Fine-Grained View of High Performance Networking, NANOG 713 22 Conf.; http://www.nanog.org/mtg-0105/agenda.html", May 714 20-22 2001. 716 [Cia03] "Standardized Active Measurements on a Tier 1 IP Backbone, 717 IEEE Communications Mag., pp 90-97.", June 2003. 719 [Demichelis] 720 http://www.advanced.org/ippm/archive.3/att-0075/ 721 01-pap02.doc, "Packet Delay Variation Comparison between 722 ITU-T and IETF Draft Definitions", November 2000. 724 [G.1020] ITU-T Recommendation G.1020, ""Performance parameter 725 definitions for the quality of speech and other voiceband 726 applications utilizing IP networks"", 2006. 728 [I-D.ietf-ippm-framework-compagg] 729 Morton, A. and S. Berghe, "Framework for Metric 730 Composition", draft-ietf-ippm-framework-compagg-01 (work 731 in progress), June 2006. 733 [Krzanowski] 734 Presentation at IPPM, IETF-64, "Jitter Definitions: What 735 is What?", November 2005. 737 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 738 Jacobson, "RTP: A Transport Protocol for Real-Time 739 Applications", STD 64, RFC 3550, July 2003. 741 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 742 communication service - IP packet transfer and 743 availability performance parameters", December 2002. 745 [Y.1541] ITU-T Recommendation Y.1540, "Network Performance 746 Objectives for IP-Based Services", February 2006. 748 Author's Address 750 Al Morton 751 AT&T Labs 752 200 Laurel Avenue South 753 Middletown,, NJ 07748 754 USA 756 Phone: +1 732 420 1571 757 Fax: +1 732 368 1192 758 Email: acmorton@att.com 759 URI: http://home.comcast.net/~acmacm/ 761 Full Copyright Statement 763 Copyright (C) The Internet Society (2006). 765 This document is subject to the rights, licenses and restrictions 766 contained in BCP 78, and except as set forth therein, the authors 767 retain all their rights. 769 This document and the information contained herein are provided on an 770 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 771 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 772 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 773 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 774 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 775 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 777 Intellectual Property 779 The IETF takes no position regarding the validity or scope of any 780 Intellectual Property Rights or other rights that might be claimed to 781 pertain to the implementation or use of the technology described in 782 this document or the extent to which any license under such rights 783 might or might not be available; nor does it represent that it has 784 made any independent effort to identify any such rights. Information 785 on the procedures with respect to rights in RFC documents can be 786 found in BCP 78 and BCP 79. 788 Copies of IPR disclosures made to the IETF Secretariat and any 789 assurances of licenses to be made available, or the result of an 790 attempt made to obtain a general license or permission for the use of 791 such proprietary rights by implementers or users of this 792 specification can be obtained from the IETF on-line IPR repository at 793 http://www.ietf.org/ipr. 795 The IETF invites any interested party to bring to its attention any 796 copyrights, patents or patent applications, or other proprietary 797 rights that may cover technology that may be required to implement 798 this standard. Please address the information to the IETF at 799 ietf-ipr@ietf.org. 801 Acknowledgment 803 Funding for the RFC Editor function is provided by the IETF 804 Administrative Support Activity (IASA).