idnits 2.17.1 draft-morton-ippm-delay-var-as-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1138. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1162. 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 IETF Trust 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 (March 4, 2007) is 6255 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ippm-reordering' is defined on line 1017, 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-02 == Outdated reference: A later version (-07) exists of draft-morton-ippm-reporting-metrics-01 Summary: 3 errors (**), 0 flaws (~~), 5 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 B. Claise 5 Expires: September 5, 2007 Cisco Systems, Inc. 6 March 4, 2007 8 Packet Delay Variation Applicability Statement 9 draft-morton-ippm-delay-var-as-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 5, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Packet delay variation metrics appear in many different standards 43 documents. The metric definition in RFC 3393 has considerable 44 flexibility, and it allows multiple formulations of delay variation 45 through the specification of different packet selection functions. 47 Although flexibility provides wide coverage and room for new ideas, 48 it can make comparisons of independent implementations more 49 difficult. Two different formulations of delay variation have come 50 into wide use in the context of active measurements. This memo 51 examines a range of circumstances for active measurements of delay 52 variation and their uses, and recommends which of the two forms is 53 best matched to particular conditions and tasks. 55 Requirements Language 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [RFC2119]. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Background Literature in IPPM and Elsewhere . . . . . . . 5 65 1.2. Organization of the Memo . . . . . . . . . . . . . . . . . 6 66 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Brief Descriptions of Delay Variation Uses . . . . . . . . . . 7 68 3.1. Inferring Queue Occupation on a Path . . . . . . . . . . . 7 69 3.2. Determining De-jitter Buffer Size . . . . . . . . . . . . 7 70 3.3. Spatial Composition . . . . . . . . . . . . . . . . . . . 7 71 3.4. Service Level Comparison . . . . . . . . . . . . . . . . . 8 72 3.5. . . . . . . . . . . . . . . . . . . . 8 73 4. Formulations of IPDV and PDV . . . . . . . . . . . . . . . . . 8 74 4.1. IPDV: Inter-Packet Delay Variation . . . . . . . . . . . . 8 75 4.2. PDV: Packet Delay Variation . . . . . . . . . . . . . . . 9 76 4.3. Examples and Initial Comparisons . . . . . . . . . . . . . 9 77 5. Survey of Earlier Comparisons . . . . . . . . . . . . . . . . 9 78 5.1. Demichelis' Comparison . . . . . . . . . . . . . . . . . . 9 79 5.2. Ciavattone et al. . . . . . . . . . . . . . . . . . . . . 10 80 5.3. IPPM List Discussion from 2000 . . . . . . . . . . . . . . 11 81 5.4. Y.1540 Appendix II . . . . . . . . . . . . . . . . . . . . 12 82 6. Additional Properties and Comparisons . . . . . . . . . . . . 12 83 6.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 13 84 6.2. Path Changes . . . . . . . . . . . . . . . . . . . . . . . 13 85 6.2.1. Lossless Path Change . . . . . . . . . . . . . . . . . 14 86 6.2.2. Path Change with Loss . . . . . . . . . . . . . . . . 15 87 6.3. Clock Stability and Error . . . . . . . . . . . . . . . . 16 88 6.4. Spatial Composition . . . . . . . . . . . . . . . . . . . 17 89 6.5. Reporting a Single Number . . . . . . . . . . . . . . . . 17 90 6.6. Jitter in RTCP Reports . . . . . . . . . . . . . . . . . . 18 91 6.7. MAPDV2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 6.8. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 18 93 7. Applicability of the Delay Variation Forms and 94 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18 95 7.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 7.1.1. Inferring Queue Occupancy . . . . . . . . . . . . . . 19 97 7.1.2. Determining De-jitter Buffer Size . . . . . . . . . . 19 98 7.1.3. Spatial Composition . . . . . . . . . . . . . . . . . 20 99 7.2. Challenging Circumstances . . . . . . . . . . . . . . . . 20 100 7.2.1. Clock Issues . . . . . . . . . . . . . . . . . . . . . 20 101 7.2.2. Frequent Path Changes . . . . . . . . . . . . . . . . 20 102 7.2.3. Frequent Loss . . . . . . . . . . . . . . . . . . . . 20 103 7.2.4. Load Balancing . . . . . . . . . . . . . . . . . . . . 20 104 8. Measurement Considerations for Vendors, Testers, and Users . . 21 105 8.1. Measurement Stream Characteristics . . . . . . . . . . . . 21 106 8.2. Measurement Units . . . . . . . . . . . . . . . . . . . . 21 107 8.3. Test Duration . . . . . . . . . . . . . . . . . . . . . . 21 108 8.4. Clock Sync Options . . . . . . . . . . . . . . . . . . . . 21 109 8.5. Distinguishing Long Delay from Loss . . . . . . . . . . . 21 110 8.6. Accounting for Packet Reordering . . . . . . . . . . . . . 21 111 8.7. Results Representation and Reporting . . . . . . . . . . . 21 112 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 113 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 114 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 115 12. Appendix on Reducing Delay Variation in Networks . . . . . . . 22 116 13. Appendix on Calculating the D(min) in PDV . . . . . . . . . . 22 117 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 118 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 119 14.2. Informative References . . . . . . . . . . . . . . . . . . 23 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 121 Intellectual Property and Copyright Statements . . . . . . . . . . 26 123 1. Introduction 125 There are many ways to formulate packet delay variation metrics for 126 the Internet and other packet-based networks. The IETF itself has 127 several specifications for delay variation [RFC3393], sometimes 128 called jitter [RFC3550] or even interarrival jitter [RFC3550], and 129 these have achieved wide adoption. The International 130 Telecommunication Union - Telecommunication Standardization Sector 131 (ITU-T) has also recommended several delay variation metrics (called 132 parameters in their terminology) [Y.1540] [G.1020], and some of these 133 are widely cited and used. Most of the standards above specify more 134 than one way to quantify delay variation, so one can conclude that 135 standardization efforts have tended to be inclusive rather than 136 selective. 138 This memo uses the term "delay variation" for metrics that quantify a 139 path's ability to transfer packets with consistent delay. [RFC3393] 140 and [Y.1540] both prefer this term. Some refer to this phenomenon as 141 "jitter" (and the buffers that attempt to smooth the variations as 142 de-jitter buffers). Applications of the term "jitter" are much 143 broader than packet transfer performance, with "unwanted signal 144 variation" as a general definition. "Jitter" has been used to 145 describe frequency or phase variations, such as data stream rate 146 variations or carrier signal phase noise. The phrase "delay 147 variation" is almost self-defining and more precise, so it is 148 preferred in this memo. 150 Most (if not all) delay variation metrics are derived metrics, in 151 that their definitions rely on another fundamental metric. In this 152 case, the fundamental metric is one-way delay, and variation is 153 assessed by computing the difference between two individual one-way 154 delay measurements, or a pair of singletons. One of the delay 155 singletons is taken as a reference, and the result is the variation 156 with respect to the reference. The variation is usually summarized 157 for all packets in a stream using statistics. 159 The industry has predominantly implemented two specific formulations 160 of delay variation (for one survey of the situation, 161 see[Krzanowski]): 163 1. Inter-Packet Delay Variation, IPDV, where the reference is the 164 previous packet in the stream (according to sending sequence), 165 and the reference changes for each packet in the stream. 166 Properties of variation are coupled with packet sequence in this 167 formulation. This form was called Instantaneous Packet Delay 168 Variation in early contributions. 170 2. Packet Delay Variation, PDV, where a single reference is chosen 171 from the stream based on specific criteria, and the reference is 172 fixed once selected. The most common criterion for the reference 173 is the packet with the minimum delay in the sample. This term 174 derives its name from a similar definition for Cell Delay 175 Variation, an ATM performance metric. 177 It is important to note that the authors of relevant standards for 178 delay variation recognized there are many different users with 179 varying needs, and allowed sufficient flexibility to formulate 180 several metrics with different properties. Therefore, the comparison 181 is not so much between standards bodies or their specifications as it 182 is between specific formulations of delay variation. Both Inter- 183 Packet Delay Variation and Packet Delay Variation are compliant with 184 [RFC3393], because different packet selection functions will produce 185 either form. 187 1.1. Background Literature in IPPM and Elsewhere 189 With more people joining the measurement community every day, it is 190 possible this document is the first RFC from the IP Performance 191 Metrics (IPPM) Working Group that the reader has consulted. This 192 section provides a brief roadmap and background on the IPPM 193 literature, and the published specifications of other relevant 194 standards organizations. 196 The IPPM framework [RFC2330] provides a background for this memo and 197 other IPPM RFCs. Key terms such as singleton, sample, and statistic 198 are defined there, along with methods of collecting samples (Poisson 199 streams), time related issues, and the "packet of Type-P" convention. 201 There are two fundamental and related metrics that can be applied to 202 every packet transfer attempt: one-way loss [RFC2680] and one-way 203 delay [RFC2679]. Lost and delayed packets are separated by a waiting 204 time threshold. Packets that arrive at the measurement destination 205 within their waiting time have finite delay and are not lost. 206 Otherwise, packets are designated lost and their delay is undefined. 207 Guidance on setting the waiting time threshold may be found in 208 [RFC2680] and [I-D.morton-ippm-reporting-metrics]. 210 Another fundamental metric is packet reordering as specified in 211 [RFC4737]. The reordering metric was defined to be "orthogonal" to 212 packet loss. In other words, the gap in a packet sequence caused by 213 loss does not result in reordered packets, but a re-arrangement of 214 packet arrivals from their sending order constitutes reordering. 216 Derived metrics are based on the fundamental metrics. The derived 217 metric of primary interest here is delay variation [RFC3393], a 218 metric which is derived from one-way delay [RFC2680]. Another 219 derived metric is the loss patterns metric [RFC3357], which is 220 derived from loss. 222 In the ITU-T, the framework, fundamental metrics and derived metrics 223 for IP performance are all specified in Recommendation Y.1540 224 [Y.1540]. 226 1.2. Organization of the Memo 228 The Purpose and Scope follows in Section 2. We then give a summary 229 of the main tasks for delay variation metrics in section 3. Section 230 4 defines the two primary forms of delay variation, and section 5 231 presents summaries of four earlier comparisons. Section 6 adds new 232 comparisons to the analysis, and section 7 reviews the applicability 233 and recommendations for each form of delay variation. Section 8 then 234 looks at many important delay variation measurement considerations. 235 Following IANA and Security Considerations, there two Appendices. 236 One presents guidance on reducing delay variation in networks, and 237 the other calculation of the minimum delay for the PDV form. 239 2. Purpose and Scope 241 The IPDV and PDV formulations have certain features that make them 242 more suitable for one circumstance and less so for another. The 243 purpose of this memo is to compare two forms of delay variation, so 244 that it will be evident which of the two is better suited for each of 245 many possible uses and their related circumstances. 247 The scope of this memo is limited to the two forms of delay variation 248 briefly described above (Inter-Packet Delay Variation and Packet 249 Delay Variation), circumstances related to active measurement, and 250 uses that are deemed relevant and worthy of inclusion here through 251 IPPM Working Group consensus. 253 The scope excludes assessment of delay variation for packets with 254 undefined delay. This is accomplished by conditioning the delay 255 distribution on arrival within a reasonable waiting time based on an 256 understanding of the path under test and packet lifetimes. The 257 waiting time is sometimes called the loss threshold [RFC2680]: if a 258 packet arrives beyond this threshold, it may as well have been lost 259 because it is no longer useful. This is consistent with [RFC3393], 260 where the Type-P-One-way-ipdv is undefined when the destination fails 261 to receive one or both packets in the selected pair. Furthermore, it 262 is consistent with application performance analysis to consider only 263 arriving packets, because a finite waiting time-out is a feature of 264 many protocols. 266 3. Brief Descriptions of Delay Variation Uses 268 This section presents a set of tasks that call for delay variation 269 measurements. Here, the memo provides several answers to the 270 question, "How will the results be used?" for the delay variation 271 metric. 273 3.1. Inferring Queue Occupation on a Path 275 As packets travel along the path from source to destination, they 276 pass through many network elements, including a series of router 277 queues. Some types of the delay sources along the path are constant, 278 such as links between two locations. But the latency encountered in 279 each queue varies, depending on the number of packets in the queue 280 when a particular packet arrives. If one assumes that at least one 281 of the packets in a test stream encounters virtually empty queues all 282 along the path (and the path is stable), then the additional delay 283 observed on other packets can be attributed to the time spent in one 284 or more queues. Otherwise, the delay variation observed is the 285 variation in queue time experienced by the test stream. 287 3.2. Determining De-jitter Buffer Size 289 Note - while this memo and other IPPM literature prefer the term 290 delay variation, the terms "jitter buffer" and the more accurate "de- 291 jitter buffer" are widely adopted names for a component of packet 292 communication systems, and they will be used here to designate that 293 system component. 295 Most Isochronous applications (a.k.a. real-time applications) employ 296 a buffer to smooth out delay variation encountered on the path from 297 source to destination. The buffer must be big enough to accommodate 298 (most of) the expected variation, or packet loss will result. 299 However, if the buffer is too large, then some of the desired 300 spontaneity of communication will be lost and conversational dynamics 301 will be affected. Therefore, application designers need to know the 302 extent of delay variation they must accommodate, whether they are 303 designing fixed or adaptive buffer systems. 305 Network service providers also attempt to constrain delay variation 306 to ensure the quality of real-time applications, and monitor this 307 metric (possibly to compare with a numerical objective or Service 308 Level Agreement). 310 3.3. Spatial Composition 312 In Spatial Composition, the tasks are similar to those described 313 above, but with the additional complexity of a multiple network path 314 where several sub-paths are measured separately, and no source to 315 destination measurements are available. In this case, the source to 316 destination performance must be estimated, using Composed Metrics as 317 described in [I-D.ietf-ippm-framework-compagg] and [Y.1541]. Note 318 that determining the composite delay variation is not trivial: simply 319 summing the sub-path variations is not accurate. 321 3.4. Service Level Comparison 323 IP performance measurements are often used as the basis for 324 agreements (or contracts) between service providers and their 325 customers. The measurement results must compare favorably with the 326 performance levels specified in the agreement. 328 Packet delay variation is usually one of the metrics specified in 329 these agreements. In principle, any formulation could be specified 330 in the Service Level Agreement (SLA). However, the SLA is most 331 useful when the measured quantities can be related to ways in which 332 the communication service will be utilized by the customer, and this 333 can usually be derived from one of the tasks described above. 335 3.5. 337 4. Formulations of IPDV and PDV 339 This section presents the formulations of IPDV and PDV, and provides 340 some illustrative examples. We use the basic singleton definition in 341 [RFC3393] (which itself is based on [RFC2679]): 343 "Type-P-One-way-ipdv is defined for two packets from Src to Dst 344 selected by the selection function F, as the difference between the 345 value of the Type-P-One-way-delay from Src to Dst at T2 and the value 346 of the Type-P-One-Way-Delay from Src to Dst at T1." 348 4.1. IPDV: Inter-Packet Delay Variation 350 If we have packets in a stream consecutively numbered i = 1,2,3,... 351 falling within the test interval, then IPDV(i) = D(i)-D(i-1) where 352 D(i) denotes the one-way-delay of the ith packet of a stream. 354 An example selection function given in [RFC3393] is "Consecutive 355 Type-P packets within the specified interval." This is exactly the 356 function needed for IPDV. The reference packet in the pair is always 357 the previous packet in the sending sequence. 359 Note that IPDV can take on positive and negative values (and zero), 360 although one of the useful ways to analyze the results is to 361 concentrate on the positive excursions. This is discussed in more 362 detail below. 364 4.2. PDV: Packet Delay Variation 366 The name Packet Delay Variation is used in [Y.1540] and its 367 predecessors, and refers to a performance parameter equivalent to the 368 metric described below. 370 The Selection Function for PDV requires two specific roles for the 371 packets in the pair. The first packet is any Type-P packet within 372 the specified interval. The second, or reference packet is the 373 Type-P packet within the specified interval with the minimum one-way- 374 delay. 376 Therefore, PDV(i) = D(i)-D(min) (using the nomenclature introduced in 377 the IPDV section). D(min) is the delay of the packet with the lowest 378 value for delay (minimum) over the current test interval. Values of 379 PDV may be zero or positive, and quantiles of the PDV distribution 380 are direct indications of delay variation. 382 4.3. Examples and Initial Comparisons 384 This section will discuss the examples in slides 2 and 3 of 386 http://www3.ietf.org/proceedings/06mar/slides/ippm-4.pdf 388 5. Survey of Earlier Comparisons 390 This section summarizes previous work to compare these two forms of 391 delay variation. 393 5.1. Demichelis' Comparison 395 In [Demichelis], Demichelis compared the early draft versions of two 396 forms of delay variation. Although the IPDV form would eventually 397 see widespread use, the ITU-T work-in-progress he cited did not 398 utilize the same reference packets as PDV. Demichelis compared IPDV 399 with the alternatives of using the delay of the first packet in the 400 stream and the mean delay of the stream as the PDV reference packet. 401 Neither of these alternative references were used in practice, and 402 they are now deprecated in favor of the minimum delay of the stream 403 [Y.1540]. 405 Active measurements of a transcontinental path (Torino to Tokyo) 406 provided the data for the comparison. The Poisson test stream had 407 0.764 second average inter-packet interval, with more than 58 408 thousand packets over 13.5 hours. Among Demichelis' observations 409 about IPDV are the following: 411 1. IPDV is a measure of the network's ability to preserve the 412 spacing between packets. 414 2. The distribution of IPDV is usually symmetrical about the origin, 415 having a balance of negative and positive values (for the most 416 part). The mean is usually zero, unless some long-term delay 417 trend is present. 419 3. IPDV distinguishes quick delay variations (on the order of the 420 interval between packets) from longer term variations. 422 4. IPDV places reduced demands on the stability and skew of 423 measurement clocks. 425 He also notes these features of PDV: 427 1. PDV does not distinguish quick variation from variation over the 428 complete test interval. 430 2. The location of the distribution is very sensitive to the delay 431 of the first packet, IF this packet is used as the reference. 432 This would be a new formulation that differs from the PDV 433 definition in this memo (PDV references the packet with minimum 434 delay, so it does not have this drawback). 436 3. The shape of the PDV distribution is identical to the delay 437 distribution, but shifted by the reference delay. 439 4. Use of a common reference over measurement intervals that are 440 longer than a typical session length may indicate more PDV than 441 would be experienced by streams that support such sessions. 443 5. PDV characterizes the range of queue occupancies along the 444 measurement path (assuming the path is fixed), but the range says 445 nothing about how the variation took place. 447 The summary metrics used in this comparison were the number of values 448 exceeding a +/-50ms range around the mean, the Inverse Percentiles, 449 and the Inter-Quartile Range. 451 5.2. Ciavattone et al. 453 In [Cia03], the authors compared IPDV and PDV (referred to as delta) 454 using a periodic packet stream conforming to [RFC3432] with inter- 455 packet interval of 20 ms. 457 One of the comparisons between IPDV and PDV involves a laboratory 458 set-up where a queue was temporarily congested by a competing packet 459 burst. The additional queuing delay was 85ms to 95ms, much larger 460 than the inter-packet interval. The first packet in the stream that 461 follows the competing burst spends the longest time enqueued, and 462 others experience less and less queuing time until the queue is 463 drained. 465 The authors observed that PDV reflects the additional queuing time of 466 the packets affected by the burst, with values of 85, 65, 45, 25, and 467 5ms. Also, it is easy to determine (by looking at the PDV range) 468 that a de-jitter buffer of 90 ms would have been sufficient to 469 accommodate the delay variation. 471 The distribution of IPDV values in the congested queue example are 472 very different: 85, -20, -20, -20, -20, -5ms. Only the positive 473 excursion of IPDV gives an indication of the de-jitter buffer size 474 needed. Although the variation exceeds the inter-packet interval, 475 the extent of negative IPDV values is limited by that sending 476 interval. This preference for information from the positive IPDV 477 values has prompted some to ignore the negative values, or to take 478 the absolute value of each IPDV measurement (sacrificing key 479 properties of IPDV in the process, such as its ability to distinguish 480 delay trends). 482 Elsewhere, the authors considered the range as a summary statistic 483 for IPDV, and the 99.9%-ile minus the minimum delay as a summary 484 statistic for delay variation, or PDV. 486 5.3. IPPM List Discussion from 2000 488 Summary To Be Provided. But to indicate one of the key points: 490 Mike Pierce made many comments in the context of the 05 version of 491 the draft. One of his main points was that a delay histogram is a 492 useful approach to quantifying variation. Another was the that the 493 time duration of evaluation is a critical aspect. 495 Carlo Demichelis then mailed his comparison paper to the IPPM list, 496 [Demichelis] as discussed in more detail above. 498 Ruediger Geib observed that both IPDV and the delay histogram (PDV) 499 are useful, and suggested that they might be applied to different 500 variation time scales. He pointed out that loss has a significant 501 effect on IPDV, and encouraged that the loss information be retained 502 in the arrival sequence. 504 Several example delay variation scenarios were discussed, including: 506 Packet # 1 2 3 4 5 6 7 8 9 10 11 507 ------------------------------------------------------- 508 Ex. A 509 Lost 511 Delay, ms 100 110 120 130 140 150 140 130 120 110 100 513 IPDV U 10 10 10 10 10 -10 -10 -10 -10 -10 515 PDV 0 10 20 30 40 50 40 30 20 10 0 517 ------------------------------------------------------- 518 Ex. B 519 Lost L 521 Delay, ms 100 110 150 U 120 100 110 150 130 120 100 523 IPDV U 10 40 U U -10 10 40 -20 -10 -20 525 PDV 0 10 50 U 20 0 10 50 30 20 0 527 Figure 1: Delay Examples 529 Clearly, the range of PDV values is 50 ms in both cases above, while 530 the IPDV range tends to minimize the smooth variation in Example A 531 (20 ms), and responds to the faster variations in Example B (60 ms). 533 IPDV values can be viewed as the adjustments that an adaptive de- 534 jitter buffer would make, IF it could make adjustments on a packet- 535 by-packet basis. However, adaptive de-jitter buffers don't make 536 adjustments so frequently. How can this detailed information be 537 used? 539 5.4. Y.1540 Appendix II 541 This Appendix compares IPDV, PDV (referred to as 2-point PDV), and 542 1-point packet delay variation (which assume a periodic stream and 543 assesses variation against an ideal arrival schedule constructed at 544 the single measurement point). 546 6. Additional Properties and Comparisons 548 This section treats some of the earlier comparison areas in more 549 detail, and introduces new areas for comparison. 551 6.1. Packet Loss 553 The measurement packet loss is of great influence for the delay 554 variation results, as displayed in the figure 2 and 3 (L means Lost 555 and U means undefined). Figure 3 shows that in the extreme case of 556 every other packet loss, the IPDV doesn't produce any results, while 557 the PDV produces results for all arriving packets. 559 Packet # 1 2 3 4 5 6 7 8 9 10 560 Lost L L L L L 561 --------------------------------------- 562 Delay, ms 3 U 5 U 4 U 3 U 4 U 564 IPDV U U U U U U U U U U 566 PDV 0 U 2 U 1 U 0 U 1 U 568 Figure 2: Path Loss Every Other Packet 570 In case of a burst of packet loss, as displayed in figure 3, both the 571 IPDV and PDV produces some results. Note that the PDV. 573 Packet # 1 2 3 4 5 6 7 8 9 10 574 Lost L L L L L 575 --------------------------------------- 576 Delay, ms 3 4 U U U U U 5 4 3 578 IPDV U 1 U U U U U U -1 -1 580 PDV 0 1 U U U U U 2 1 0 582 Figure 3: Burst of Packet Loss 584 In conclusion, the PDV results are affected by the packet loss ratio. 585 While the IPDV results are affected by the packet loss ratio, they 586 are also affected by the packet loss distribution. Indeed, in the 587 extreme case of every other packet loss, the IPDV doesn't provide any 588 results. 590 6.2. Path Changes 592 When there is little or no stability in the network under test, then 593 the devices that attempt to characterize the network are equally 594 stressed, especially if the results displayed are used to make 595 inferences which may not be valid. 597 Sometimes the path characteristics change during a measurement 598 interval. The change may be due to link or router failure, 599 administrative changes prior to maintenance (e.g., link cost change), 600 or re-optimization of routing using new information. All these 601 causes are usually infrequent, and network providers take appropriate 602 measures to ensure this. Automatic restoration to a back-up path is 603 seen as a desirable feature of IP networks. 605 Frequent path changes and prolonged congestion with substantial 606 packet loss clearly make delay variation measurements challenging. 607 Path changes are usually accompanied by a sudden, persistent increase 608 or decrease in one-way-delay. [Cia03] gives one such example. We 609 assume that a restoration path either accepts a stream of packets, or 610 is not used for that particular stream (e.g., no multi-path for 611 flows). 613 In any case, a change in the TTL (or Hop Limit) of the received 614 packets indicates that the path is no longer the same. Transient 615 packet reordering may also be observed with path changes, due to use 616 of non-optimal routing while updates propagate through the network 617 (see [Casner] and [Cia03] ) 619 Many, if not all, packet streams experience packet loss in 620 conjunction with a path change. However, it is certainly possible 621 that the active measurement stream does not experience loss. This 622 may be due to use of a long inter-packet sending interval with 623 respect to the restoration time, and this becomes more likely as 624 "fast restoration" techniques see wider deployment (e.g., [RFC4090]. 626 Thus, there are two main cases to consider, path changes accompanied 627 by loss, and those that are lossless from the point of view of the 628 active measurement stream. The subsections below examine each of 629 these cases. 631 6.2.1. Lossless Path Change 633 In the lossless case, a path change will typically affect only two 634 IPDV singletons. However, if the change in delay is negative and 635 larger than the inter-packet sending interval, then more than two 636 IPDV singletons may be affected because packet reordering is also 637 likely to occur. 639 The use of the new path and its delay variation can be quantified by 640 treating the PDV distribution as bi-modal, and characterizing each 641 mode separately. This would involve declaring a new path within the 642 sample, and using a new local minimum delay as the PDV reference 643 delay for the sub-sample (or time interval) where the new path is 644 present. 646 The process of detecting a bi-modal delay distribution is made 647 difficult if the typical delay variation is larger than the delay 648 change associated with the new path. However, information on TTL (or 649 Hop Limit) change or the presence of transient reordering can assist 650 in an automated decision. 652 The effect of path changes may also be reduced by making PDV 653 measurements over short intervals (minutes, as opposed to hours). 654 This way, a path change will affect one sample and its PDV values. 655 Assuming that the mean or median one-way-delay changes appreciably on 656 the new path, then subsequent measurements can confirm a path change, 657 and trigger special processing on the interval containing a path 658 change and the affected PDV result. 660 Alternatively, if the path change is detected, by monitoring the test 661 packets TTL or Hop Limit, or monitoring the change in the IGP link- 662 state database, the results of measurement before and after the path 663 change could be kept separated, presenting two different 664 distributions. This avoids the difficult task of determining the 665 different modes of a multi-modal distribution. 667 6.2.2. Path Change with Loss 669 If the path change is accompanied by loss, such that the are no 670 consecutive packet pairs that span the change, then no IPDV 671 singletons will reflect the change. This may or may not be 672 desirable, depending on the ultimate use of the delay variation 673 measurement. The Figure 3, in which L means Lost and U means 674 undefined, illustrates this case. 676 Packet # 1 2 3 4 5 6 7 8 9 677 Lost L L 678 ------------------------------------ 679 Delay, ms 3 4 3 3 U U 8 9 8 681 IPDV U 1 -1 0 U U U 1 -1 683 PDV 0 1 0 0 U U 5 6 5 685 Figure 4: Path Change with Loss 687 PDV will again produce a bimodal distribution. But here, the 688 decision process to define sub-intervals associated with each path is 689 further assisted by the presence of loss, in addition to TTL, 690 reordering information, and use of short measurement intervals 691 consistent with the duration of user sessions. It is reasonable to 692 assume that at least loss and delay will be measured simultaneously 693 with PDV and/or IPDV. 695 6.3. Clock Stability and Error 697 Low cost or low complexity measurement systems may be embedded in 698 communication devices that do not have access to high stability 699 clocks, and time errors will almost certainly be present. However, 700 larger time-related errors may offer an acceptable trade-off for 701 monitoring performance over a large population (the accuracy needed 702 to detect problems may be much less than required for a scientific 703 study). 705 As mentioned above, [Demichelis] observed that PDV places greater 706 demands on clock synchronization than for IPDV. This observation 707 deserves more discussion. Synchronization errors have two 708 components: time of day errors and clock frequency errors (resulting 709 in skew). 711 Both IPDV and PDV are sensitive to time-of-day errors when attempting 712 to align measurement intervals at the source and destination. Gross 713 mis-alignment of the measurement intervals can lead to lost packets, 714 for example if the receiver is not ready when the first test packet 715 arrives. However, both IPDV and PDV assess delay differences, so the 716 error present in two one-way-delay singletons will cancel as long as 717 it is constant. So, NTP or GPS synchronization is not required to 718 correct the time-of-day error in case the delay variation 719 measurement, while it is required for the one-way delay measurement. 721 Skew is a measure of the change in clock time over an interval w.r.t. 722 a reference clock. Both IPDV and PDV are affected by skew, but the 723 error sensitivity in IPDV singletons is less because the intervals 724 between consecutive packets are rather small, especially when 725 compared to the overall measurement interval. Since PDV computes the 726 difference between a single reference delay (the sample minimum) and 727 all other delays in the measurement interval, the constraint on skew 728 error is greater to attain the same accuracy as IPDV. Again, use of 729 short PDV measurement intervals (on the order of minutes, not hours) 730 provides some relief from the effects of skew error. 732 If skew is present in a sample of one-way-delays, its symptom is 733 typically a linear growth or decline over all the one-way-delay 734 values. As a practical matter, if the same slope appears 735 consistently in the measurements, then it may be possible to fit the 736 slope and compensate for the skew in the one-way-delay measurements, 737 thereby avoiding the issue in the PDV calculations that follow. See 738 [RFC3393] for additional information on compensating for skew. 740 There is a third factor related to clock error and stability: this is 741 the presence of a clock synchronization protocol (e.g., NTP) and the 742 time adjustment operations that result. When a small time error is 743 detected (typically on the order of a few milliseconds), the host 744 clock frequency is continuously adjusted to reduce the time error. 745 If these adjustments take place during a measurement interval, they 746 may appear as delay variation when none was present, and therefore 747 are a source of error. 749 6.4. Spatial Composition 751 ITU-T Recommendation [Y.1541] gives a provisional method to compose a 752 PDV metric using PDV measurement results from two or more sub-paths. 754 PDV has a clear advantage at this time, since there is no known 755 method to compose an IPDV metric. In addition, IPDV results depend 756 greatly on the exact sequence of packets and may not lend themselves 757 easily to the composition problem. 759 6.5. Reporting a Single Number 761 Despite the risk of over-summarization, measurements must often be 762 displayed for easy consumption. If the right summary report is 763 prepared, then the "dashboard" view correctly indicates whether there 764 is something different and worth investigating further, or that the 765 status has not changed. The dashboard model restricts every 766 instrument display to a single number. The packet network dashboard 767 could have different instruments for loss, delay, delay variation, 768 reordering, etc., and each must be summarized as a single number for 769 each measurement interval. 771 The simplicity of the PDV distribution lends itself to this 772 summarization process (including use of the median or mean). 773 [Y.1541] introduced the notion of a pseudo-range when setting an 774 objective for the 99.9%-ile of PDV. The conventional range (max-min) 775 was avoided for several reasons, including stability of the maximum 776 delay. The 99.9%-ile of PDV is helpful to performance planners 777 (seeking to meet some user-to-user objective for delay) and in design 778 of de-jitter buffer sizes, even those with adaptive capabilities. 780 IPDV does not lend itself to summarization so easily. The mean IPDV 781 is typically zero. As the IPDV distribution may have two tails 782 (positive and negative) the range or pseudo-range would not match the 783 needed de-jitter buffer size. Additional complexity may be 784 introduced when the variation exceeds the inter-packet sending 785 interval, as discussed above. Should the Inter-Quartile Range be 786 used? Should the singletons beyond some threshold be counted (e.g., 787 mean +/- 50ms)? A strong rationale for one of these summary 788 statistics has yet to emerge. 790 6.6. Jitter in RTCP Reports 792 [RFC3550] gives the calculation of the inter-arrival Jitter field for 793 the RTCP report, with a sample implementation in an Appendix. 795 The RTCP Jitter value can be calculated using IPDV singletons. If 796 there is packet reordering, as defined in [RFC4737], then estimates 797 of Jitter based on IPDV may vary slightly, because [RFC3550] 798 specifies the use of receive packet order. 800 Just as there is no simple way to convert PDV singletons to IPDV 801 singletons without returning to the original sample of delay 802 singletons, there is no clear relationship between PDV and [RFC3550] 803 Jitter. 805 6.7. MAPDV2 807 MAPDV2 stands for Mean Absolute Packet Delay Variation (version) 2, 808 and is specified in [G.1020]. The MAPDV2 algorithm computes a 809 smoothed running estimate of the mean delay using the one-way delays 810 of 16 previous packets. It compares the current one-way-delay to the 811 estimated mean, separately computes the means of positive and 812 negative deviations, and sums these deviation means to produce 813 MAPVDV2. In effect, there is a MAPDV2 singleton for every arriving 814 packet, so further summarization is usually warranted. 816 Neither IPDV or PDV forms assist in the computation of MAPDV2. 818 6.8. Load Balancing 820 TO DO: What if there is load-balancing in an ISP network? Load- 821 balancing is based on the IGP metrics, while the delay depends on the 822 path. So, we could have a multi-modal distribution, if we send test 823 packets with different characteristics such as IP addresses/ports. 825 Should the delay singletons using multiple addresses/ports be 826 combined in the same sample? 828 The PDV form makes the identification of multiple modes possible. 829 Should we characterize each mode separately? This question also 830 applies to the Path Change case. 832 7. Applicability of the Delay Variation Forms and Recommendations 834 Based on the comparisons of IPDV and PDV presented above, this 835 section matches the attributes of each form with the tasks described 836 earlier. We discuss the more general circumstances first. 838 Note: the conclusions of this section should be regarded as 839 preliminary, pending discussion and further development by the IPPM 840 WG. 842 7.1. Uses 844 7.1.1. Inferring Queue Occupancy 846 The PDV distribution is anchored at the minimum delay observed in the 847 measurement interval. When the sample minimum coincides with the 848 true minimum delay of the path, then the PDV distribution is 849 equivalent to the queuing time distribution experienced by the test 850 stream. If the minimum delay is not the true minimum, then the PDV 851 distribution captures the variation in queuing time and some 852 additional amount of queuing time is experienced, but unknown. One 853 can summarize the PDV distribution with the mean, median, and other 854 statistics. 856 IPDV can capture the difference in queuing time from one packet to 857 the next, but this is a different distribution from the queue 858 occupancy revealed by PDV. 860 7.1.2. Determining De-jitter Buffer Size 862 This task is complimentary to the problem of inferring queue 863 occupancy through measurement. Again, use of the sample minimum as 864 the reference delay for PDV yields a distribution that is very 865 relevant to de-jitter buffer size. This is because the minimum delay 866 is an alignment point for the smoothing operation of de-jitter 867 buffers. A de-jitter buffer that is ideally aligned with the delay 868 variation adds zero buffer time to packets with the longest 869 accommodated network delay (any packets with longer delays are 870 discarded). Thus, a packet experiencing minimum network delay should 871 be aligned to wait the maximum length of the de-jitter buffer. With 872 this alignment, the stream is smoothed with no unnecessary delay 873 added. [G.1020] illustrates the ideal relationship between network 874 delay variation and buffer time. 876 The PDV distribution is also useful for this task, but different 877 statistics are preferred. The range (max-min) or the 99.9%-ile of 878 PDV (pseudo-range) are closely related to the buffer size needed to 879 accommodate the observed network delay variation. 881 In some cases, the positive excursions (or series of positive 882 excursions) of IPDV may help to approximate the de-jitter buffer 883 size, but there is no guarantee that a good buffer estimate will 884 emerge, especially when the delay varies as a positive trend over 885 several test packets. 887 7.1.3. Spatial Composition 889 PDV has a clear advantage at this time, since there is no known 890 method to compose an IPDV metric. 892 7.2. Challenging Circumstances 894 Note that measurement of delay variation may not be the primary 895 concern under unstable and unreliable circumstances. 897 7.2.1. Clock Issues 899 When appreciable skew is present between measurement system clocks, 900 then IPDV has a clear advantage because PDV would require processing 901 over the entire sample to remove the skew error. Neither form of 902 delay variation is more suited than the other to on-the-fly 903 summarization without memory, and this may be one of the reasons that 904 [RFC3550] RTCP Jitter and MAPDV2 in [G.1020] have attained deployment 905 in low-cost systems. 907 7.2.2. Frequent Path Changes 909 If the network under test exhibits frequent path changes, on the 910 order of several new routes per minute, then IPDV appears to isolate 911 the delay variation on each path from the transient effect of path 912 change (especially if there is packet loss at the time of path 913 change). It is possible to make meaningful PDV measurements when 914 paths are unstable, but great importance would be placed on the 915 algorithms that infer path change and attempt to divide the sample on 916 path change boundaries. 918 7.2.3. Frequent Loss 920 If the network under test exhibits frequent loss, then PDV may 921 produce a larger set of singletons for the sample than IPDV. This is 922 due to IPDV requiring consecutive packet arrivals to assess delay 923 variation, compared to PDV where any packet arrival is useful. The 924 worst case is when no consecutive packets arrive, and the entire IPDV 925 sample would be undefined. PDV would successfully produce a sample 926 based on the arriving packets. 928 7.2.4. Load Balancing 930 TO DO: this section will give the brief conclusions of the discussion 931 and analysis in section 6. 933 8. Measurement Considerations for Vendors, Testers, and Users 935 TO DO: 937 8.1. Measurement Stream Characteristics 939 8.2. Measurement Units 941 TO DO: Al, you mentioned somewhere above: "These devices may not have 942 sufficient memory to store all singletons for later processing." And 943 also an important conclusion: "Just as there is no simple way to 944 convert PDV singletons to IPDV singletons without returning to the 945 original sample of delay singletons" I'm thinking we should develop 946 around that: 948 - Do we want to get IPDV and DV? 950 - Do we want to reconstruct the IPDV and DV later on, with a 951 different interval? 953 + a reference to the appendix where we would describe: 955 - how is this D(min) calculated? Is it DV(99%) as mentioned by Roman 956 in http://www3.ietf.org/proceedings/05nov/slides/ippm-3.pdf? 958 - do we need to keep all the values from the interval, then take the 959 minimum? Or do we keep the minimum from previous intervals? 961 8.3. Test Duration 963 8.4. Clock Sync Options 965 8.5. Distinguishing Long Delay from Loss 967 Setting the max waiting time threshold... 969 8.6. Accounting for Packet Reordering 971 8.7. Results Representation and Reporting 973 9. IANA Considerations 975 This document makes no request of IANA. 977 Note to RFC Editor: this section may be removed on publication as an 978 RFC. 980 10. Security Considerations 982 The security considerations that apply to any active measurement of 983 live networks are relevant here as well. See [RFC4656] 985 11. Acknowledgements 987 The author would like to thank Phil Chimento for his suggestion to 988 employ the convention of conditional distributions for Delay to deal 989 with packet loss, and his encouragement to "write the memo" after 990 hearing the talk on this topic at IETF-65. 992 12. Appendix on Reducing Delay Variation in Networks 994 This text is both preliminary and generic but we want to explain the 995 basic troubleshooting. 997 If there is a DV problem, it may be because: 999 1. there is congestion. Find where the bottleneck is, and increase 1000 the buffer Alternatively, increase the bandwidth Alternatively, 1001 remove some applications from that class of service 1003 2. there is a variability of the traffic Discover that traffic, then 1004 change/apply QoS (for example, rate-limiting) 1006 13. Appendix on Calculating the D(min) in PDV 1008 - how is this D(min) calculated? Is it DV(99%) as mentioned by Roman 1009 in http://www3.ietf.org/proceedings/05nov/slides/ippm-3.pdf? - do we 1010 need to keep all the values from the interval, then take the minimum? 1011 Or do we keep the minimum from previous intervals? 1013 14. References 1015 14.1. Normative References 1017 [I-D.ietf-ippm-reordering] 1018 Morton, A., "Packet Reordering Metric for IPPM", 1019 draft-ietf-ippm-reordering-13 (work in progress), 1020 May 2006. 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, March 1997. 1025 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1026 "Framework for IP Performance Metrics", RFC 2330, 1027 May 1998. 1029 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1030 Delay Metric for IPPM", RFC 2679, September 1999. 1032 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1033 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1035 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1036 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1037 November 2002. 1039 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1040 performance measurement with periodic streams", RFC 3432, 1041 November 2002. 1043 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1044 Jacobson, "RTP: A Transport Protocol for Real-Time 1045 Applications", STD 64, RFC 3550, July 2003. 1047 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1048 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1049 May 2005. 1051 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1052 Zekauskas, "A One-way Active Measurement Protocol 1053 (OWAMP)", RFC 4656, September 2006. 1055 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1056 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 1057 November 2006. 1059 14.2. Informative References 1061 [Casner] "A Fine-Grained View of High Performance Networking, NANOG 1062 22 Conf.; http://www.nanog.org/mtg-0105/agenda.html", May 1063 20-22 2001. 1065 [Cia03] "Standardized Active Measurements on a Tier 1 IP Backbone, 1066 IEEE Communications Mag., pp 90-97.", June 2003. 1068 [Demichelis] 1069 http://www.advanced.org/ippm/archive.3/att-0075/ 1070 01-pap02.doc, "Packet Delay Variation Comparison between 1071 ITU-T and IETF Draft Definitions", November 2000. 1073 [G.1020] ITU-T Recommendation G.1020, ""Performance parameter 1074 definitions for the quality of speech and other voiceband 1075 applications utilizing IP networks"", 2006. 1077 [I-D.ietf-ippm-framework-compagg] 1078 Morton, A. and S. Berghe, "Framework for Metric 1079 Composition", draft-ietf-ippm-framework-compagg-02 (work 1080 in progress), October 2006. 1082 [I-D.morton-ippm-reporting-metrics] 1083 Morton, A., "Reporting Metrics: Different Points of View", 1084 draft-morton-ippm-reporting-metrics-01 (work in progress), 1085 October 2006. 1087 [Krzanowski] 1088 Presentation at IPPM, IETF-64, "Jitter Definitions: What 1089 is What?", November 2005. 1091 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 1092 Metrics", RFC 3357, August 2002. 1094 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1095 communication service - IP packet transfer and 1096 availability performance parameters", December 2002. 1098 [Y.1541] ITU-T Recommendation Y.1540, "Network Performance 1099 Objectives for IP-Based Services", February 2006. 1101 Authors' Addresses 1103 Al Morton 1104 AT&T Labs 1105 200 Laurel Avenue South 1106 Middletown,, NJ 07748 1107 USA 1109 Phone: +1 732 420 1571 1110 Fax: +1 732 368 1192 1111 Email: acmorton@att.com 1112 URI: http://home.comcast.net/~acmacm/ 1113 Benoit Claise 1114 Cisco Systems, Inc. 1115 De Kleetlaan 6a b1 1116 Diegem, 1831 1117 Belgium 1119 Phone: +32 2 704 5622 1120 Fax: 1121 Email: bclaise@cisco.com 1122 URI: 1124 Full Copyright Statement 1126 Copyright (C) The IETF Trust (2007). 1128 This document is subject to the rights, licenses and restrictions 1129 contained in BCP 78, and except as set forth therein, the authors 1130 retain all their rights. 1132 This document and the information contained herein are provided on an 1133 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1134 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1135 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1136 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1137 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1138 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1140 Intellectual Property 1142 The IETF takes no position regarding the validity or scope of any 1143 Intellectual Property Rights or other rights that might be claimed to 1144 pertain to the implementation or use of the technology described in 1145 this document or the extent to which any license under such rights 1146 might or might not be available; nor does it represent that it has 1147 made any independent effort to identify any such rights. Information 1148 on the procedures with respect to rights in RFC documents can be 1149 found in BCP 78 and BCP 79. 1151 Copies of IPR disclosures made to the IETF Secretariat and any 1152 assurances of licenses to be made available, or the result of an 1153 attempt made to obtain a general license or permission for the use of 1154 such proprietary rights by implementers or users of this 1155 specification can be obtained from the IETF on-line IPR repository at 1156 http://www.ietf.org/ipr. 1158 The IETF invites any interested party to bring to its attention any 1159 copyrights, patents or patent applications, or other proprietary 1160 rights that may cover technology that may be required to implement 1161 this standard. Please address the information to the IETF at 1162 ietf-ipr@ietf.org. 1164 Acknowledgment 1166 Funding for the RFC Editor function is provided by the IETF 1167 Administrative Support Activity (IASA).