idnits 2.17.00 (12 Aug 2021) /tmp/idnits38965/draft-morton-ippm-nonrev-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: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 12 looks like a reference -- Missing reference section? '2' on line 47 looks like a reference -- Missing reference section? '3' on line 401 looks like a reference -- Missing reference section? '4' on line 69 looks like a reference -- Missing reference section? '5' on line 71 looks like a reference -- Missing reference section? '6' on line 72 looks like a reference -- Missing reference section? '7' on line 175 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 0 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Performance Measurement Working Group A.Morton 2 Internet Draft L.Ciavattone 3 Document: G.Ramachandran 4 Category: Informational AT&T Labs 6 Reordering Metric for IPPM using Non-Reversing Sequence 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or made obsolete by other 18 documents at any time. It is inappropriate to use Internet-Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 1. Abstract 29 This memo proposes a simple metric to determine if a network has 30 maintained packet sequence. It provides motivations for the new 31 metric, suggests a metric definition, and discusses the issues 32 associated with measuring packet sequence. The memo includes 33 secondary metrics to quantify the extent of reordering in several 34 useful dimensions. Some examples of evaluation using the non- 35 reversing sequence criterion are included. 37 2. Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [2]. 42 Although RFC 2119 was written with protocols in mind, the key words 43 are used in this document for similar reasons. They are used to 44 ensure the results of measurements from two different 45 implementations are comparable, and to note instances when an 46 implementation could perturb the network. 48 3. Introduction 50 Packet Sequence is a property of successful packet transfer 51 attempts, where the sending packet order is preserved on arrival at 52 the destination (measurement point). This memo defines a simple 53 metric to determine if a network has maintained packet sequence, 54 consistent with the IPPM framework RFC 2330 [3]. It provides 55 motivations for the new metric, suggests a metric definition, and 56 discusses the issues associated with measuring packet sequence. 58 Source Sequence may be established by the sending time of each 59 packet, or there may be an explicit sequence number carried in each 60 packet. 62 Destination Sequence is determined by arrival order or time. Partial 63 indication of reordering may be captured in one-way delay and delay 64 variation. When a packet is deemed reordered, its distance from the 65 onset of reordering in the dimensions of position and time give one 66 view of the extent of reordering, or lateness. 68 This metric classifies late packets as out-of-sequence. This is 69 equivalent to Paxon's definition in [4]. Its construction is very 70 similar to the sequence space validation for received segments in 71 RFC793 [5]. An earlier version of this definition was described in 72 [6]. 74 3.1 Motivation 76 A reordering metric is relevant for most applications, especially 77 when assessing network support for Real-Time media streams. IPPM has 78 not defined a reordering metric. 80 Packet order is not expected to change during transfer, but several 81 specific path characteristics can cause sequence to change. 83 Examples are: 84 * When two paths, one with slightly longer transfer time, support a 85 single packet stream or flow, then packets traversing the longer 86 path may arrive out-of-sequence. Multiple paths may be used to 87 achieve load balancing, or may arise from route instability. 88 * To increase capacity, a network device designed with multiple 89 processors serving a single port may alter sequence as a 90 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 serviced in reverse 94 order from their arrival, the sequence will change. 96 The ability to restore order at the destination will likely have 97 finite limits. Practical hosts have receiver buffers, such as de- 98 jitter buffers with finite size in terms of packets, bytes, or time. 99 Once the initial determination of reordering is made, it is useful 100 to quantify the extent of sequence change, or lateness, in all 101 meaningful dimensions. 103 The definitions below intend to satisfy the goals of: 104 1. Determining whether or not packet sequence is maintained. 105 2. Quantifying the extent of sequence change (this second problem 106 will have many possible solutions). 108 4. Definitions 110 The IPPM framework RFC 2330 [3] gives the definitions of singletons, 111 samples, and statistics. 113 The evaluation of packet sequence requires several supporting 114 concepts. The first is a stream of packets with an incrementing 115 sequence number at the source (decrementing sequences can be 116 accommodated, and sequence roll-over is treated later). The source 117 sequence number may be a simple message number, a byte stream 118 number, or it may be the actual time when each packet departs from 119 the Src. 121 The second supporting concept is a stored value called a sequence 122 Reference Number, which is the "next expected" packet number. Under 123 normal conditions, the Reference Number (RefNum) contains the 124 sequence number of the previous packet plus 1 for message numbering. 125 In byte stream numbering, RefNum is a value 1 byte greater than the 126 last in-order packet sequence number + payload. If Src time is used 127 as the sequence number, RefNum is the Src time from the last in- 128 order packet + 1 clock tick. 130 Each packet within a packet stream can be evaluated for its sequence 131 singleton metric. 133 In-order packets have sequence numbers (or Src times) greater than 134 or equal to the Reference Number. Each new in-order packet will 135 increase the Reference Number (typically by 1 for message numbering, 136 or the payload size for byte numbering). The Reference Number 137 cannot decrease, thereby requiring a non-reversing sequence. 139 An out-of-sequence (OOS) packet outcome occurs when a single IP 140 packet at the Dst Measurement Point results in the following: 141 The packet has a Src sequence number lower than the Reference 142 Number, and therefore the packet is late. The Reference Number does 143 not change on the arrival of this packet. 145 This definition can also be specified in pseudo-code. 146 On successful arrival of a packet with sequence number n: 147 if n >= RefNum, then 148 RefNum = n + payload_size + 1; 149 else /* when n < RefNum */ 150 designate packet n as OOS; 152 When using message-based sequence numbering or Src time, 153 payload_size=0. 155 It is also possible to assert the degree to which a packet is out- 156 of-sequence. Any packet whose sequence number causes the Reference 157 Number to increment by more than the usual increment indicates a 158 discontinuity in the sequence. From this point on, any packets with 159 sequence number less than the Reference Number can be assigned 160 "lateness" values indicating their position (in packets or bytes) 161 and time of arrival with respect to a sequence discontinuity. 163 Late packets are associated with a specific sequence discontinuity 164 by determining which earlier packet's sequence number skipped over 165 them. We calculate all expressions of lateness with respect to that 166 packet. Position lateness is calculated from a Dst Order number 167 assigned to each packet on arrival: 168 Late Offset = DstOrder(OOS packet)-DstOrder(packet at discontinuity) 170 Lateness in time is calculated similarly using Dst times. Byte 171 stream lateness can be determined from the payload sizes of 172 intervening packets. The various measures of lateness are only 173 calculated on out-of-sequence packets. 175 Note that the One-way IPDV [7] gives the delay variation for a 176 packet w.r.t. the preceding packet in the source sequence. Lateness 177 and IPDV give an indication of whether a buffer at Dst has 178 sufficient storage to accommodate the network's behavior and restore 179 order. 181 When packets in the stream have variable sizes, it may be most 182 useful to characterize lateness in terms of the payload size(s) of 183 stored packets (using byte stream numbering). 185 For a sample of packets in a stream, OOS may be reported as a ratio 186 of OOS packets to total packets sent by the source during the test. 187 If separate OOS events can be distinguished, then an event count may 188 also be reported (along with the event description, such as the 189 number of OOS packets and their offsets). The distribution of 190 lateness may also be reported and summarized. 192 5. Measurement Issues 194 The results of sequence tests will be dependent on the time interval 195 between measurement packets (both at the Src, and during transport 196 where spacing may change). Clearly, packets launched infrequently 197 (e.g., 1 per 10 seconds) are unlikely to be reordered. 199 The Non-reversing Sequence criterion remains valid and useful when a 200 stream of packets experiences packet loss, or both loss and 201 reordering. In other words, losses alone do not cause subsequent 202 packets to be declared out-of-sequence. 204 Assuming that the necessary sequence information (sequence number 205 and/or source time stamp) is included in the packet payload 206 (possibly in application headers such as RTP), packet sequence may 207 be evaluated in a passive measurement arrangement. Also, it is 208 possible to evaluate sequence at a single point along a path, since 209 synchronized Src and Dst Clocks are not strictly necessary. 211 When the Src sequence is based on byte stream, or payload numbering, 212 care must be taken to avoid declaring retransmitted packets out-of- 213 sequence. The additional reference of Src Time is one way to avoid 214 this ambiguity. 216 Since this metric definition may use sequence numbers with finite 217 range, it is possible that the sequence numbers could reach end-of- 218 range and roll over to zero during a measurement. By definition, 219 the Reference Number cannot decrease, and all packets received after 220 a roll-over would be declared out-of-sequence. Sequence number 221 roll-over can be avoided by using combinations of counter size and 222 test duration where roll-over is impossible (and sequence is reset 223 to zero at the start). Also, message-based numbering results in 224 slower sequence consumption. There may still be cases where 225 methodological mitigation of this problem is desirable (e.g., long- 226 term testing). The elements of mitigation are: 228 1. There must be a test to detect if a roll-over has occurred. It 229 would be nearly impossible for the sequence numbers of successive 230 packets to jump by more than half the total range, so these large 231 discontinuities are designated as roll-over. 233 2. All sequence numbers used in computations are represented in a 234 sufficiently large precision. The numbers have a correction applied 235 (equivalent to adding a significant digit) whenever roll-over is 236 detected. 238 3. Out-of-sequence packets coincident with sequence numbers reaching 239 end-of-range must also be detected for proper application of 240 correction factor. 242 6. Examples of Sequence Evaluation 244 This section provides some examples to illustrate how the non- 245 reversing sequence criterion works, and the value of viewing 246 reordering in both the dimensions of time and position. 248 Table 1 gives a simple case of reordering, where one packet (the 249 packet with SrcNum=4) arrives out-of-sequence. Packets are arranged 250 according to their arrival, and message numbering is used. 252 Table 1 Example with Packet 4 Late, 253 Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10 254 SrcNum Src Dst Dst Late Late 255 @Dst RefNum Time Time Delay IPDV Order Offset Time 256 1 1 0 68 68 1 257 2 2 20 88 68 0 2 258 3 3 40 108 68 0 3 259 5 4 80 148 68 -82 4 260 6 6 100 168 68 0 5 261 7 7 120 188 68 0 6 262 8 8 140 208 68 0 7 263 4 9 60 210 150 82 8 4 62 264 9 9 160 228 68 0 9 265 10 10 180 248 68 0 10 267 Each column gives the following information: 269 SrcNum Packet sequence number at the Source. 270 RefNum The value of RefNum when the packet arrived(before update). 271 SrcTime Packet time stamp at the Source, ms. 272 DstTime Packet time stamp at the Destination, ms. 273 Delay 1-way delay of the packet, ms. 274 IPDV IP Packet Delay Variation, ms 275 IPDV = Delay(SrcNum)-Delay(SrcNum-1) 276 DstOrder Order in which the packet arrived at the Destination. 277 LateOffset The position offset of an out-of-sequence packet. 278 LateTime The lateness of an out-of-sequence packet, ms. 280 We can see that when packet 4 arrives, RefNum=9, and it is declared 281 out-of-sequence. Further, we can compute the lateness of packet 4 in 282 terms of position (8-4=4 using DstOrder) and time (210-148=62 using 283 DstTime) compared to packet 5's arrival. If Dst has a de-jitter 284 buffer that holds more than 4 packets, or at least 62 ms storage, 285 packet 4 may be useful. Note that 1-way delay and IPDV also indicate 286 unusual behavior for packet 4. 288 Table 2 Example with Packets 5 and 6 Late, 289 Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10 290 SrcNum Src Dst Dst Late Late 291 @Dst RefNum Time Time Delay IPDV Order Offset Time 292 1 1 0 68 68 1 293 2 2 20 88 68 0 2 294 3 3 40 108 68 0 3 295 4 4 60 128 68 0 4 296 7 5 120 188 68 -22 5 297 5 8 80 189 109 41 6 1 1 298 6 8 100 190 90 -19 7 2 2 299 8 8 140 208 68 0 8 300 9 9 160 228 68 0 9 301 10 10 180 248 68 0 10 302 Table 2 shows a case where packets 5 and 6 arrive just behind packet 303 7, so both 5 and 6 are declared out-of-sequence. Their positional 304 offsets (6-5=1 and 7-5=2, using DstOrder again) and Late times (189- 305 188=1, 190-188=2) are small. 307 Table 3 Example with Packets 4, 5, and 6 Late 308 Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10,11 309 SrcNum Src Dst Dst Late Late 310 @Dst RefNum Time Time Delay IPDV Order Offset Time 311 1 1 0 68 68 1 312 2 2 20 88 68 0 2 313 3 3 40 108 68 0 3 314 7 4 120 188 68 -68 4 315 8 8 140 208 68 0 5 316 9 9 160 228 68 0 6 317 10 10 180 248 68 0 7 318 4 11 60 250 190 122 8 4 62 319 5 11 80 252 172 -18 9 5 64 320 6 11 100 256 156 -16 10 6 68 321 11 11 200 268 68 0 11 323 The case in Table 3 is where three packets in sequence have long 324 transit times. Delay, Late time, and Offset capture this very well, 325 and indicate variation in lateness, while IPDV indicates that the 326 spacing between packets 4,5,and 6 has changed. 328 7. Security Considerations [mostly borrowed from npmps] 330 7.1 Denial of Service Attacks 332 This metric requires a stream of packets sent from one host (Src) to 333 another host (Dst) through intervening networks. This method could 334 be abused for denial of service attacks directed at Dst and/or the 335 intervening network(s). 337 Administrators of Src, Dst, and the intervening network(s) should 338 establish bilateral or multi-lateral agreements regarding the 339 timing, size, and frequency of collection of sample metrics. Use of 340 this method in excess of the terms agreed between the participants 341 may be cause for immediate rejection or discard of packets or other 342 escalation procedures defined between the affected parties. 344 7.2 User data confidentiality 346 Active use of this method generates packets for a sample, rather 347 than taking samples based on user data, and does not threaten user 348 data confidentiality. Passive measurement must restrict attention to 349 the headers of interest. Since user payloads may be temporarily 350 stored for length analysis, suitable precautions MUST be taken to 351 keep this information safe and confidential. 353 7.3 Interference with the metric 355 It may be possible to identify that a certain packet or stream of 356 packets is part of a sample. With that knowledge at Dst and/or the 357 intervening networks, it is possible to change the processing of the 358 packets (e.g. increasing or decreasing delay) that may distort the 359 measured performance. It may also be possible to generate 360 additional packets that appear to be part of the sample metric. 361 These additional packets are likely to perturb the results of the 362 sample measurement. 364 To discourage the kind of interference mentioned above, packet 365 interference checks, such as cryptographic hash, may be used. 367 8. IANA Considerations 369 Since this metric does not define a protocol or well-known values, 370 there are no IANA considerations in this memo. 372 9. References 374 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 375 9, RFC 2026, October 1996. 377 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 378 Levels", RFC 2119, March 1997. 380 3 Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework 381 for IP Performance Metrics", RFC 2330, May 1998. 383 4 V.Paxson, "Measurements and Analysis of End-to-End Internet 384 Dynamics," Ph.D. dissertation, U.C. Berkeley, 1997, 385 ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz. 387 5 Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 388 September 1981. 389 Obtain via: http://www.rfc-editor.org/rfc/rfc793.txt 391 6 L.Ciavattone and A.Morton, "Out-of-Sequence Packet Parameter 392 Definition (for Y.1540)", Contribution number T1A1.3/2000-047, 393 October 30, 2000. ftp://ftp.t1.org/pub/t1a1/2000-A13/0a130470.doc 395 7 Demichelis, C., and Chimento, P., "IP Packet Delay Variation 396 Metric for IPPM", work in progress. 398 10. Acknowledgments 400 We gratefully acknowledge the foundation laid by the authors of the 401 IP performance Framework [3]. 403 11. Author's Addresses 405 Al Morton 406 AT&T Labs 407 Room D3 - 3C06 408 200 Laurel Ave. South 409 Middletown, NJ 07748 USA 410 Phone +1 732 420 1571 Fax +1 732 368 1192 411 413 Len Ciavattone 414 AT&T Labs 415 Room C4 - 2B29 416 200 Laurel Ave. South 417 Middletown, NJ 07748 USA 418 Phone +1 732 420 1239 419 421 Gomathi Ramachandran 422 AT&T Labs 423 Room C4 - 3D22 424 200 Laurel Ave. South 425 Middletown, NJ 07748 USA 426 Phone +1 732 420 2353 427 429 Full Copyright Statement 431 "Copyright (C) The Internet Society (date). All Rights Reserved. 432 This document and translations of it may be copied and furnished to 433 others, and derivative works that comment on or otherwise explain it 434 or assist in its implmentation may be prepared, copied, published 435 and distributed, in whole or in part, without restriction of any 436 kind, provided that the above copyright notice and this paragraph 437 are included on all such copies and derivative works. However, this 438 document itself may not be modified in any way, such as by removing 439 the copyright notice or references to the Internet Society or other 440 Internet organizations, except as needed for the purpose of 441 developing Internet standards in which case the procedures for 442 copyrights defined in the Internet Standards process must be 443 followed, or as required to translate it into languages other than 444 English. 446 The limited permissions granted above are perpetual and will not be 447 revoked by the Internet Society or its successors or assigns. 449 This document and the information contained herein is provided on an 450 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 451 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 452 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 453 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 454 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.