idnits 2.17.1 draft-ietf-ippm-reordering-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 16 looks like a reference -- Missing reference section? '2' on line 50 looks like a reference -- Missing reference section? '3' on line 584 looks like a reference -- Missing reference section? '4' on line 71 looks like a reference -- Missing reference section? '5' on line 72 looks like a reference -- Missing reference section? '6' on line 327 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 0 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Performance Metrics Working Group A.Morton 2 Internet Draft L.Ciavattone 3 Document: G.Ramachandran 4 Category: Standards Track AT&T Labs 5 S.Shalunov 6 Internet2 7 J.Perser 8 Spirent 10 Reordering Metric for IPPM 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 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. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or made obsolete by other 22 documents at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1. Abstract 33 This memo defines a simple metric to determine if a network has 34 maintained packet order. It provides motivations for the new metric, 35 suggests a metric definition, and discusses the issues associated 36 with measurement. The memo includes sample metrics to quantify the 37 extent of reordering in several useful dimensions. Some examples of 38 evaluation using the various sample metrics are included. 40 2. Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [2]. 45 Although RFC 2119 was written with protocols in mind, the key words 46 are used in this document for similar reasons. They are used to 47 ensure the results of measurements from two different 48 implementations are comparable, and to note instances when an 49 implementation could perturb the network. 51 3. Introduction 53 Ordered delivery is a property of successful packet transfer 54 attempts, where the packet sequence ascends for each arriving packet 55 and there are no backward steps. 57 An explicit sequence number, such as the sending time of each packet 58 or an incrementing message number carried in each packet establishes 59 the Source Sequence. 61 The presence of reordering at the Destination is based on arrival 62 order. 64 This metric classifies arriving packets with sequence numbers 65 smaller than their predecessors as out-of-order, or reordered. For 66 example, if arriving packets are numbered 1,2,4,5,3, then packet 3 67 is reordered. This is equivalent to Paxon's reordering definition in 68 [3], where "late" packets were declared reordered. The alternative 69 is to emphasize "premature" packets instead (4 and 5 in the 70 example). The metric's construction is very similar to the sequence 71 space validation for received segments in RFC793 [4]. Earlier work 72 to define ordered delivery includes [5], and more ???. 74 3.1 Motivation 76 A reordering metric is relevant for most applications, especially 77 when assessing network support for Real-Time media streams. The 78 extent of reordering may be sufficient to cause a received packet to 79 be discarded by functions above the IP layer. 81 Packet order is not expected to change during transfer, but several 82 specific path characteristics can cause their order to change. 84 Examples are: 85 * When two paths, one with slightly longer transfer time, support a 86 single packet stream or flow, then packets traversing the longer 87 path may arrive out-of-order. Multiple paths may be used to 88 achieve load balancing, or may arise from route instability. 89 * To increase capacity, a network device designed with multiple 90 processors serving a single port may reorder as a byproduct. 91 * A layer 2 retransmission protocol that compensates for an error- 92 prone link may cause packet reordering. 93 * If for any reason, the packets in a buffer are not serviced in the 94 order of their arrival, their order will change. 95 * If packets in a flow are assigned to multiple buffers (following 96 evaluation of traffic characteristics, for example), and the 97 buffers have different occupations and/or service rates, then 98 order will likely change. 100 The ability to restore order at the destination will likely have 101 finite limits. Practical hosts have receiver buffers with finite 102 size in terms of packets, bytes, or time (such as de-jitter 103 buffers). Once the initial determination of reordering is made, it 104 is useful to quantify the extent of reordering, or lateness, in all 105 meaningful dimensions. 107 3.2 Goals and Objectives 109 The definitions below intend to satisfy the goals of: 110 1. Determining whether or not packet order is maintained. 111 2. Quantifying the extent (achieving this second goal requires 112 assumptions of upper layer functions and capabilities to 113 restore order, and therefore several solutions). 115 Reordering Metrics MUST: 117 + be relevant to one or more known applications 118 + be computable "on the fly" 119 + work with Poisson and Periodic test streams 120 + work even if the stream has duplicate or lost packets 122 Reordering Metrics SHOULD: 124 + have concatenating results for segments measured separately 125 + have simplicity for easy consumption and understanding 126 + have relevance to TCP performance 127 + have relevance to Real-time application performance 129 4. An Ordered Arrival Singleton Metric 131 The IPPM framework RFC 2330 [3] gives the definitions of singletons, 132 samples, and statistics. 134 The evaluation of packet order requires several supporting concepts. 135 The first is an incrementing sequence number applied to packets at 136 the source (decrementing sequences can be accommodated, and sequence 137 roll-over is treated later). The source order may established by a 138 simple message number, a byte stream number, or it may be the actual 139 time when each packet departs from the Src. 141 The second supporting concept is a stored value which is the "next 142 expected" packet number. Under normal conditions, the value of Next 143 Expected (NextExp) is the sequence number of the previous packet 144 (plus 1 for message numbering). In byte stream numbering, NextExp 145 is a value 1 byte greater than the last in-order packet sequence 146 number + payload. If Src time is used as the sequence number, 147 NextExp is the Src time from the last in-order packet + 1 clock 148 tick. 150 Each packet within a packet stream can be evaluated for its order 151 singleton metric. 153 4.1 Metric Name: 155 Type-P-Non-Reversing-Order 157 4.2 Metric Parameters: 159 + Src, the IP address of a host 161 + Dst, the IP address of a host 163 + SrcTime, the time of packet emission from the Src 165 + SrcNum, the packet sequence number applied at the Src, in units 166 of messages or bytes. 168 + NextExp, the Next Expected Sequence number at the Dst, in units 169 of messages, time, or bytes. 171 + PayloadSize, the number of bytes contained in the information 172 field and referred to when the SrcNum sequence is based on byte 173 transfer. 175 4.3 Definition: 177 In-order packets have sequence numbers (or Src times) greater than 178 or equal to the value of Next Expected. Each new in-order packet 179 will increase the Next Expected (typically by 1 for message 180 numbering, or the payload size plus 1 for byte numbering). The Next 181 Expected value cannot decrease, thereby specifying non-reversing 182 order as the basis to identify reordered packets. 184 A reordered packet outcome occurs when a single IP packet at the Dst 185 Measurement Point results in the following: 186 The packet has a Src sequence number lower than the Next Expected 187 (NextExp), and therefore the packet is reordered. The Next Expected 188 value does not change on the arrival of this packet. 190 This definition can also be specified in pseudo-code. 191 On successful arrival of a packet with sequence number n: 192 if n >= NextExp, /* n is in-order */ 193 then 194 NextExp = n + PayloadSize + 1; 195 else /* when n < NextExp */ 196 designate packet n as reordered; 198 When using message-based sequence numbering or Src time, 199 PayloadSize=0. 201 4.4 Discussion 203 Any arriving packet bearing a sequence number from the sequence that 204 establishes the Next Expected value can be evaluated to determine if 205 it is in-order, or reordered, based on a previous packet's arrival. 206 In the case where Next Expected is Undefined (because the arriving 207 packet is the first successful transfer), the packet is designated 208 in-order. 210 5. Sample Metrics 212 It is highly desirable to assert the degree to which a packet is 213 out-of-order with respect to a sample of packets. This section 214 defines several metrics that quantify the extent of reordering in 215 various units of measure. Each metric highlights a relevant 216 application. 218 5.1 N-Reordering 220 [Note: This is a modified definition of N-Reordering.] 222 Metric Name: Type-P-packet-N-reordering-Poisson/Periodic-Stream 224 Parameter Notation: Let N be a positive integer (a parameter). Let 225 K be a positive integer (sample size, the number of packets sent). 226 Let L be a non-negative integer representing the number of packets 227 that were received out of the K packets sent. Assign each sent 228 packet a sequence number, 1 to K. Let be the 229 original sequence numbers of the received packets, in the order of 230 arrival (duplicates are possible). 232 Definition 1: Received packet number I (N < I <= L) is called 233 N-reordered IFF for all J such that I-N <= J < I we have S_J > S_I. 235 Let M be the number of N-reordered packets in the sample. 237 Definition 2: The degree of N-reordering of the sample is M/(K-N). 239 Definition 3: The degree of reordering of the sample is its degree 240 of 1-reordering. 242 Definition 4: A sample is said to have no reordering if its degree 243 of reordering is 0. 245 Discussion: 247 The degree of N-reordering may be expressed as a percentage, in 248 which case the number from definition 2 is multiplied by 100. 250 N-reordering is particularly useful for determining the portion of 251 reordered packets which can or cannot be restored to order in a 252 typical TCP receiver buffer based on their arrival order alone (and 253 without the aid of retransmission). 255 [need more on this]. 257 5.2 Reordering Offset 259 Any packet whose sequence number causes the Next Expected value to 260 increment by more than the usual increment indicates a discontinuity 261 in the sequence. From this point on, any packets with sequence 262 number less than the Next Expected value can be assigned Offset 263 values indicating their position (in packets or bytes) and lateness 264 in terms of time of arrival with respect to a sequence 265 discontinuity. The various Offset metrics are calculated only on 266 reordered packets, as defined in section 4. 268 5.2.1 Metric Name: Type-P-packet-Position-Offset-Poisson/Periodic- 269 Stream 271 Metric Parameters: In addition to the parameters defined for Type-P- 272 Non-Reversing-Order, we specify: 274 + DstOrder, numerical order in which each packet in the stream 275 arrives at Dst 277 Definition: Reordered packets are associated with a specific 278 sequence discontinuity by determining which earlier packet's 279 sequence number skipped over them. We calculate all expressions of 280 Offset with respect to that packet. Position Offset is calculated 281 from a Dst Order number assigned to each packet on arrival: 283 Position Offset = 284 DstOrder(reordered packet)-DstOrder(packet at discontinuity) 286 Using the notation of Section 5.1, an equivalent definition is: 287 The Position Offset of Reordered Packet I is M = I-J, for 288 min{J|1<=J S_I. 290 5.2.2 Metric Name: Type-P-packet-Late-Time-Poisson/Periodic-Stream 292 Metric Parameters: In addition to the parameters defined for Type-P- 293 Non-Reversing-Order, we specify: 295 + DstTime, the time that each packet in the stream arrives at Dst 297 Definition: Lateness in time is calculated using Dst times. 299 Late Time = 300 DstTime(reordered packet)-DstTime(packet at discontinuity) 302 Using similar notation to that of Section 5.1, an equivalent 303 definition is: 304 The Late Time of Reordered Packet I is T = DstTime_I-DstTime_J, 305 for min{J|1<=J S_I, or SrcTime_J>SrcTime_I. 307 5.2.3 Metric Name: Type-P-packet-Byte-Offset-Poisson/Periodic-Stream 308 Metric Parameters: We use the same parameters defined above. 310 Definition: Byte stream offset can be determined from the payload 311 sizes of intervening packets. 313 Byte Offset = 314 PayloadNum(reordered packet, DstOrder=m) 315 - Sum[PayloadSize(packet, DstOrder=m-1), 316 PayloadSize(packet, DstOrder=m-2), ... 317 PayloadSize(packet at discontinuity)] 319 5.2.4 Discussion 321 The Offset metrics can predict whether reordered packets will be 322 useful in a general, limited receiver buffer system. The limit may 323 be the number of bytes or packets the buffer can store, or the time 324 of storage prior to a cyclic play-out instant (as with de-jitter 325 buffers). 327 Note that the One-way IPDV [6] gives the delay variation for a 328 packet w.r.t. the preceding packet in the source sequence. Lateness 329 and IPDV give an indication of whether a buffer at Dst has 330 sufficient storage to accommodate the network's behavior and restore 331 order. When an earlier packet in the Src sequence is lost, IPDV will 332 necessarily be undefined for adjacent packets, and Late Time may 333 provide the only way to evaluate the usefulness of a packet. 335 In the case of de-jitter buffers, there are circumstances where the 336 receiver employs loss concealment at the intended play-out time of a 337 late packet. However, if this packet arrives out of order, the Late 338 Time determines whether the packet is still useful. IPDV no longer 339 applies, because the receiver establishes a new play-out schedule 340 with more buffer delay to accommodate similar events in the future - 341 this requires very minimal processing. 343 When packets in the stream have variable sizes, it may be most 344 useful to characterize Offset in terms of the payload size(s) of 345 stored packets (using byte stream numbering). 347 For a sample of packets in a stream, results may be reported as a 348 ratio of reordered packets to total packets sent by the source 349 during the test. If separate reordering events can be distinguished, 350 then an event count may also be reported (along with the event 351 description, such as the number of reordered packets and their 352 offsets). The distribution of various Offset metrics may also be 353 reported and summarized as average, range, etc. 355 6. Measurement Issues 357 The results of sequence tests will be dependent on the time interval 358 between measurement packets (both at the Src, and during transport 359 where spacing may change). Clearly, packets launched infrequently 360 (e.g., 1 per 10 seconds) are unlikely to be reordered. 362 The Non-reversing order criterion remains valid and useful when a 363 stream of packets experiences packet loss, or both loss and 364 reordering. In other words, losses alone do not cause subsequent 365 packets to be declared reordered. 367 Assuming that the necessary sequence information (sequence number 368 and/or source time stamp) is included in the packet payload 369 (possibly in application headers such as RTP), packet sequence may 370 be evaluated in a passive measurement arrangement. Also, it is 371 possible to evaluate sequence at a single point along a path, since 372 the usual need for synchronized Src and Dst Clocks may be relaxed to 373 some extent. 375 When the Src sequence is based on byte stream, or payload numbering, 376 care must be taken to avoid declaring retransmitted packets out-of- 377 sequence. The additional reference of Src Time is one way to avoid 378 this ambiguity. 380 Since this metric definition may use sequence numbers with finite 381 range, it is possible that the sequence numbers could reach end-of- 382 range and roll over to zero during a measurement. By definition, 383 the Next Expected value cannot decrease, and all packets received 384 after a roll-over would be declared out-of-sequence. Sequence 385 number roll-over can be avoided by using combinations of counter 386 size and test duration where roll-over is impossible (and sequence 387 is reset to zero at the start). Also, message-based numbering 388 results in slower sequence consumption. There may still be cases 389 where methodological mitigation of this problem is desirable (e.g., 390 long-term testing). The elements of mitigation are: 392 1. There must be a test to detect if a roll-over has occurred. It 393 would be nearly impossible for the sequence numbers of successive 394 packets to jump by more than half the total range, so these large 395 discontinuities are designated as roll-over. 397 2. All sequence numbers used in computations are represented in a 398 sufficiently large precision. The numbers have a correction applied 399 (equivalent to adding a significant digit) whenever roll-over is 400 detected. 402 3. Out-of-order packets coincident with sequence numbers reaching 403 end-of-range must also be detected for proper application of 404 correction factor. 406 7. Examples of Order Evaluation 408 This section provides some examples to illustrate how the non- 409 reversing order criterion works, and the value of viewing reordering 410 in both the dimensions of time and position. 412 Table 1 gives a simple case of reordering, where one packet (the 413 packet with SrcNum=4) arrives out-of-order. Packets are arranged 414 according to their arrival, and message numbering is used. 416 Table 1 Example with Packet 4 Reordered, 417 Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10 418 SrcNum Src Dst Dst Posit. Late 419 @Dst NextExp Time Time Delay IPDV Order Offset Time 420 1 1 0 68 68 1 421 2 2 20 88 68 0 2 422 3 3 40 108 68 0 3 423 5 4 80 148 68 -82 4 424 6 6 100 168 68 0 5 425 7 7 120 188 68 0 6 426 8 8 140 208 68 0 7 427 4 9 60 210 150 82 8 4 62 428 9 9 160 228 68 0 9 429 10 10 180 248 68 0 10 431 Each column gives the following information: 433 SrcNum Packet sequence number at the Source. 434 NextExp The value of NextExp when the packet arrived(before 435 update). 436 SrcTime Packet time stamp at the Source, ms. 437 DstTime Packet time stamp at the Destination, ms. 438 Delay 1-way delay of the packet, ms. 439 IPDV IP Packet Delay Variation, ms 440 IPDV = Delay(SrcNum)-Delay(SrcNum-1) 441 DstOrder Order in which the packet arrived at the Destination. 442 Posit.Offset The Position Offset of an out-of-order packet. 443 LateTime The lateness of an out-of-order packet, ms. 445 We can see that when packet 4 arrives, NextExp=9, and it is declared 446 reordered. Further, we can compute the Offset of packet 4 in terms 447 of position (8-4=4 using DstOrder) and Late Time (210-148=62ms using 448 DstTime) compared to packet 5's arrival. If Dst has a de-jitter 449 buffer that holds more than 4 packets, or at least 62 ms storage, 450 packet 4 may be useful. Note that 1-way delay and IPDV also indicate 451 unusual behavior for packet 4. 453 If all packets contained 100 byte payloads, then Byte Offset is 454 equal to 500 bytes. 456 In the notation of N-reordering, the 457 received packets are represented as: 459 1_1, 2_2, 3_3, 5_4, 6_5, 7_6, 8_7, 4_8, 9_9, 10_10 461 when N=1, 7<=J<8, and 8_7 > 4_8, so packet I=8 is 1-reordered. 463 when N=2, 6<=J<8, and 7_6 > 4_8, so packet I=8 is 2-reordered. 464 when N=3, 5<=J<8, and 6_5 > 4_8, so packet I=8 is 3-reordered. 465 when N=4, 4<=J<8, and 5_4 > 4_8, so packet I=8 is 4-reordered. 467 We note that the Position Offset is equal to the Max(N) with N- 468 reordering. 470 Table 2 Example with Packets 5 and 6 Reordered, 471 Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10 472 SrcNum Src Dst Dst Posit. Late 473 @Dst NextExp Time Time Delay IPDV Order Offset Time 474 1 1 0 68 68 1 475 2 2 20 88 68 0 2 476 3 3 40 108 68 0 3 477 4 4 60 128 68 0 4 478 7 5 120 188 68 -22 5 479 5 8 80 189 109 41 6 1 1 480 6 8 100 190 90 -19 7 2 2 481 8 8 140 208 68 0 8 482 9 9 160 228 68 0 9 483 10 10 180 248 68 0 10 485 [ Remaining examples need to have N-reordering added ] 487 Table 2 shows a case where packets 5 and 6 arrive just behind packet 488 7, so both 5 and 6 are declared out-of-order. Their positional 489 offsets (6-5=1 and 7-5=2, using DstOrder again) and Late times (189- 490 188=1, 190-188=2) are small. 492 Table 3 Example with Packets 4, 5, and 6 reordered 493 Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10,11 494 SrcNum Src Dst Dst Posit. Late 495 @Dst NextExp Time Time Delay IPDV Order Offset Time 496 1 1 0 68 68 1 497 2 2 20 88 68 0 2 498 3 3 40 108 68 0 3 499 7 4 120 188 68 -68 4 500 8 8 140 208 68 0 5 501 9 9 160 228 68 0 6 502 10 10 180 248 68 0 7 503 4 11 60 250 190 122 8 4 62 504 5 11 80 252 172 -18 9 5 64 505 6 11 100 256 156 -16 10 6 68 506 11 11 200 268 68 0 11 508 The case in Table 3 is where three packets in sequence have long 509 transit times. Delay, Late time, and Offset capture this very well, 510 and indicate variation in reordering extent, while IPDV indicates 511 that the spacing between packets 4,5,and 6 has changed. 513 8. Security Considerations [mostly borrowed from npmps] 515 8.1 Denial of Service Attacks 517 This metric requires a stream of packets sent from one host (Src) to 518 another host (Dst) through intervening networks. This method could 519 be abused for denial of service attacks directed at Dst and/or the 520 intervening network(s). 522 Administrators of Src, Dst, and the intervening network(s) should 523 establish bilateral or multi-lateral agreements regarding the 524 timing, size, and frequency of collection of sample metrics. Use of 525 this method in excess of the terms agreed between the participants 526 may be cause for immediate rejection or discard of packets or other 527 escalation procedures defined between the affected parties. 529 8.2 User data confidentiality 531 Active use of this method generates packets for a sample, rather 532 than taking samples based on user data, and does not threaten user 533 data confidentiality. Passive measurement must restrict attention to 534 the headers of interest. Since user payloads may be temporarily 535 stored for length analysis, suitable precautions MUST be taken to 536 keep this information safe and confidential. 538 8.3 Interference with the metric 540 It may be possible to identify that a certain packet or stream of 541 packets is part of a sample. With that knowledge at Dst and/or the 542 intervening networks, it is possible to change the processing of the 543 packets (e.g. increasing or decreasing delay) that may distort the 544 measured performance. It may also be possible to generate 545 additional packets that appear to be part of the sample metric. 546 These additional packets are likely to perturb the results of the 547 sample measurement. 549 To discourage the kind of interference mentioned above, packet 550 interference checks, such as cryptographic hash, may be used. 552 9. IANA Considerations 554 Since this metric does not define a protocol or well-known values, 555 there are no IANA considerations in this memo. 557 10. References 559 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 560 9, RFC 2026, October 1996. 562 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 563 Levels", RFC 2119, March 1997. 565 3 V.Paxson, "Measurements and Analysis of End-to-End Internet 566 Dynamics," Ph.D. dissertation, U.C. Berkeley, 1997, 567 ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz. 569 4 Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 570 September 1981. 571 Obtain via: http://www.rfc-editor.org/rfc/rfc793.txt 573 5 L.Ciavattone and A.Morton, "Out-of-Sequence Packet Parameter 574 Definition (for Y.1540)", Contribution number T1A1.3/2000-047, 575 October 30, 2000. ftp://ftp.t1.org/pub/t1a1/2000-A13/0a130470.doc 577 6 Demichelis, C., and Chimento, P., "IP Packet Delay Variation 578 Metric for IPPM", work in progress. 580 11. Acknowledgments 582 The authors would like to acknowledge the helpful discussions with 583 Matt Mathis, and . We gratefully acknowledge the foundation laid by 584 the authors of the IP performance Framework [3]. 586 11. Author's Addresses 588 Al Morton 589 AT&T Labs 590 Room D3 - 3C06 591 200 Laurel Ave. South 592 Middletown, NJ 07748 USA 593 Phone +1 732 420 1571 Fax +1 732 368 1192 594 596 Len Ciavattone 597 AT&T Labs 598 Room C4 - 2B29 599 200 Laurel Ave. South 600 Middletown, NJ 07748 USA 601 Phone +1 732 420 1239 602 604 Gomathi Ramachandran 605 AT&T Labs 606 Room C4 - 3D22 607 200 Laurel Ave. South 608 Middletown, NJ 07748 USA 609 Phone +1 732 420 2353 610 612 Stanislav Shalunov 613 University Corporation for Advanced Internet Development 614 200 Business Park Drive, Suite 307 615 Armonk, NY 10504 616 Phone: + 1 914 765 1182 617 EMail: 619 Jerry Perser 620 Spirent Communications 621 26750 Agoura Road 622 Calabasas, CA 91302 USA 623 Phone: + 1 818 676 2300 624 EMail: 626 Full Copyright Statement 628 "Copyright (C) The Internet Society (date). All Rights Reserved. 629 This document and translations of it may be copied and furnished to 630 others, and derivative works that comment on or otherwise explain it 631 or assist in its implmentation may be prepared, copied, published 632 and distributed, in whole or in part, without restriction of any 633 kind, provided that the above copyright notice and this paragraph 634 are included on all such copies and derivative works. However, this 635 document itself may not be modified in any way, such as by removing 636 the copyright notice or references to the Internet Society or other 637 Internet organizations, except as needed for the purpose of 638 developing Internet standards in which case the procedures for 639 copyrights defined in the Internet Standards process must be 640 followed, or as required to translate it into languages other than 641 English. 643 The limited permissions granted above are perpetual and will not be 644 revoked by the Internet Society or its successors or assigns. 646 This document and the information contained herein is provided on an 647 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 648 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 649 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 650 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 651 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.