idnits 2.17.1 draft-ietf-ippm-reordering-12.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1956. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1720 has weird spacing: '...tic int ring[...' == Line 1721 has weird spacing: '...tic int r = 0...' == Line 1722 has weird spacing: '... int l = ...' == Line 1723 has weird spacing: '... int j;...' == Line 1724 has weird spacing: '... int iRetu...' -- 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) -- Looks like a reference, but probably isn't: '1' on line 1334 -- Looks like a reference, but probably isn't: '2' on line 957 == Missing Reference: 'L' is mentioned on line 1218, but not defined -- Looks like a reference, but probably isn't: '9' on line 1347 == Missing Reference: 'MAXN' is mentioned on line 1720, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Downref: Normative reference to an Informational RFC: RFC 3148 ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A.Morton 3 Internet Draft L.Ciavattone 4 Document: G.Ramachandran 5 Category: Standards Track AT&T Labs 6 S.Shalunov 7 Internet2 8 J.Perser 9 Veriwave 11 Packet Reordering Metric for IPPM 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 This document is an Internet-Draft and is subject to all provisions 21 of section 3 of BCP 78. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This memo defines metrics to evaluate if a network has maintained 46 packet order on a packet-by-packet basis. It provides motivations 47 for the new metrics and discusses the measurement issues, including 48 the context information required for all metrics. The memo first 49 defines a reordered singleton, and then uses it as the basis for 50 sample metrics to quantify the extent of reordering in several 51 useful dimensions for network characterization or receiver design. 52 Additional metrics quantify the frequency of reordering and the 53 distance between separate occurrences. We then define a metric 54 oriented toward assessing reordering effects on TCP. Several 55 examples of evaluation using the various sample metrics are 56 included. An Appendix gives extended definitions for evaluating 57 order with packet fragmentation. 59 Contents 61 Status of this Memo................................................1 62 Copyright Notice...................................................1 63 Abstract...........................................................1 64 1. Conventions Used in this Document...............................3 65 2. Introduction....................................................4 66 2.1 Motivation.....................................................4 67 2.2 Goals and Objectives...........................................5 68 2.3 Required Context for All Reordering Metrics....................6 69 3. A Reordered Packet Singleton Metric.............................6 70 3.1 Metric Name....................................................7 71 3.2 Metric Parameters..............................................7 72 3.3 Definition.....................................................7 73 3.4 Sequence Discontinuity Definition..............................8 74 3.5 Evaluation of Reordering in Dimensions of Time or Bytes........9 75 3.6 Discussion.....................................................9 76 4. Sample Metrics.................................................10 77 4.1 Reordered Packet Ratio........................................10 78 4.1.1 Metric Name.................................................10 79 4.1.2 Metric Parameters...........................................10 80 4.1.3 Definition..................................................10 81 4.1.4 Discussion..................................................11 82 4.2 Reordering Extent.............................................11 83 4.2.1 Metric Name.................................................11 84 4.2.2 Notation and Metric Parameters..............................11 85 4.2.3 Definition..................................................12 86 4.2.4 Discussion..................................................12 87 4.3 Reordering Late Time Offset...................................13 88 4.3.1 Metric Name.................................................13 89 4.3.2 Metric Parameters...........................................13 90 4.3.3 Definition..................................................13 91 4.3.4 Discussion..................................................13 92 4.4 Reordering Byte Offset........................................14 93 4.4.1 Metric Name.................................................14 94 4.4.2 Metric Parameters...........................................14 95 4.4.3 Definition..................................................14 96 4.4.4 Discussion..................................................15 97 4.5 Gaps between multiple Reordering Discontinuities..............15 98 4.5.1 Metric Name.................................................15 99 4.5.2 Parameters..................................................15 100 4.5.3 Definition of Reordering Discontinuity......................16 101 4.5.4 Definition of Reordering Gap................................16 102 4.5.5 Discussion..................................................17 103 4.6 Reordering-free Runs..........................................17 104 4.6.1 Metric Name.................................................17 105 4.6.2 Parameters..................................................17 106 4.6.3 Definition..................................................17 107 4.6.4 Discussion and Illustration.................................18 108 5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric..19 109 5.1 Metric Name...................................................19 110 5.2 Parameter Notation............................................19 111 5.3 Definitions...................................................19 112 5.4 Discussion....................................................20 113 6. Measurement and Implementation Issues..........................21 114 7. Examples of Arrival Order Evaluation...........................24 115 7.1 Example with a Single Packet Reordered........................24 116 7.2 Example with Two Packets Reordered............................25 117 7.3 Example with Three Packets Reordered..........................27 118 7.4 Example with Multiple Packet Reordering Discontinuities.......28 119 8. Security Considerations........................................28 120 8.1 Denial of Service Attacks.....................................28 121 8.2 User Data Confidentiality.....................................29 122 8.3 Interference with the Metric..................................29 123 9. IANA Considerations............................................29 124 10. Normative References..........................................31 125 11. Informative References........................................31 126 12. Acknowledgments...............................................33 127 13. Appendix A Example Implementations in C (Informative).........33 128 14. Appendix B Fragment Order Evaluation (Informative)............35 129 14.1 Metric Name..................................................36 130 14.2 Additional Metric Parameters.................................36 131 14.3 Definition...................................................36 132 14.4 Discussion: Notes on Sample Metrics when Evaluating Fragments38 133 15. Author's Addresses............................................38 134 Full Copyright Statement..........................................39 135 Intellectual Property.............................................39 136 Acknowledgement...................................................39 138 1. Conventions Used in this Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. Although 143 RFC 2119 was written with protocols in mind, the key words are used 144 in this document for similar reasons. They are used to ensure the 145 results of measurements from two different implementations are 146 comparable, and to note instances when an implementation could 147 perturb the network. 149 In this memo, the characters "<=" should be read as "less than or 150 equal to" and ">=" as "greater than or equal to". 152 2. Introduction 154 Ordered arrival is a property found in packets that transit their 155 path, where the packet sequence number increases with each new 156 arrival and there are no backward steps. The Internet Protocol 157 [RFC791] has no mechanisms to assure either packet delivery or 158 sequencing, and higher layer protocols (above IP) should be prepared 159 to deal with both loss and reordering. This memo defines reordering 160 metrics. 162 A unique sequence identifier carried in each packet, such as an 163 incrementing consecutive integer message number, establishes the 164 Source Sequence. 166 The detection of reordering at the Destination is based on packet 167 arrival order in comparison with a non-reversing reference value. 169 This metric is consistent with [RFC2330], and classifies arriving 170 packets with sequence numbers smaller than their predecessors as 171 out-of-order, or reordered. For example, if sequentially numbered 172 packets arrive 1,2,4,5,3, then packet 3 is reordered. This is 173 equivalent to Paxon's reordering definition in [Pax98], where "late" 174 packets were declared reordered. The alternative is to emphasize 175 "premature" packets instead (4 and 5 in the example), but only the 176 arrival of packet 3 distinguishes this circumstance from packet 177 loss. Focusing attention on late packets allows us to maintain 178 orthogonality with the packet loss metric. The metric's construction 179 is very similar to the sequence space validation for received 180 segments in [RFC793]. Earlier work to define ordered delivery 181 includes [Cia00], [Ben99], [Lou01], [Bel02], [Jai02] and [Cia03]. 183 2.1 Motivation 185 A reordering metric is relevant for most applications, especially 186 when assessing network support for Real-Time media streams. The 187 extent of reordering may be sufficient to cause a received packet to 188 be discarded by functions above the IP layer. 190 Packet order may change during transfer, and several specific path 191 characteristics can make reordering more likely. 193 Examples are: 194 * When two (or more) paths with slightly differing transfer times 195 support a single packet stream or flow, then packets traversing 196 the longer path(s) may arrive out-of-order. Multiple paths may be 197 used to achieve load balancing, or may arise from route 198 instability. 199 * To increase capacity, a network device designed with multiple 200 processors serving a single port (or parallel links) may reorder 201 as a byproduct. 202 * A layer 2 retransmission protocol that compensates for an error- 203 prone link may cause packet reordering. 205 * If for any reason, the packets in a buffer are not serviced in the 206 order of their arrival, their order will change. 207 * If packets in a flow are assigned to multiple buffers (following 208 evaluation of traffic characteristics, for example), and the 209 buffers have different occupations and/or service rates, then 210 order will likely change. 212 When one or more of the above path characteristics are present 213 continuously, then reordering may be present on a steady-state 214 basis. The steady-state reordering condition typically causes an 215 appreciable fraction of packets to be reordered. This form of 216 reordering is most easily detected by minimizing the spacing between 217 test packets. Transient reordering may occur in response to network 218 instability; temporary routing loops can cause periods of extreme 219 reordering. This condition is characterized by long in-order streams 220 with occasional instances of reordering, sometimes with extreme 221 correlation. However, we do not expect packet delivery in a 222 completely random order, where for example, the last packet or the 223 first packet in a sample is equally likely to arrive first at the 224 destination. Thus we expect at least a minimal degree of order in 225 the packet arrivals, as exhibited in real networks. 227 The ability to restore order at the destination will likely have 228 finite limits. Practical hosts have receiver buffers with finite 229 size in terms of packets, bytes, or time (such as de-jitter 230 buffers). Once the initial determination of reordering is made, it 231 is useful to quantify the extent of reordering, or lateness, in all 232 meaningful dimensions. 234 2.2 Goals and Objectives 236 The definitions below intend to satisfy the goals of: 238 1. Determining whether or not packet reordering has occurred. 239 2. Quantifying the degree of reordering. (We define a number of 240 metrics to meet this goal, because receiving procedures differ 241 by protocol or application. Since the effects of packet 242 reordering vary with these procedures, a metric that quantifies 243 a key aspect of one receiver's behavior could be irrelevant to 244 a different receiver. If all the metrics defined below are 245 reported, they give a wide-ranging view of reordering 246 conditions.) 248 Reordering Metrics MUST: 250 + have one or more applications, such as receiver design or network 251 characterization, and a compelling relevance in the view of the 252 interested community. 253 + be computable "on the fly" 254 + work even if the stream has duplicate or lost packets 255 It is desirable for Reordering Metrics to have one or more of the 256 following attributes: 258 + ability to concatenate results for segments measured separately 259 to estimate the reordering of an entire path 260 + simplicity for easy consumption and understanding 261 + relevance to TCP design 262 + relevance to Real-time application performance 264 The current set of metrics meets all the requirements above and 265 provides all but the concatenation attribute (except in the case 266 where measurements of path segments exhibit no reordering, and one 267 may estimate that the complete path composed of these segments would 268 also exhibit no reordering). However, satisfying these goals 269 restricts the set of metrics to those that provide some clear 270 insight into network characterization or receiver design. They are 271 not likely to be exhaustive in their coverage of reordering effects 272 on applications, and additional measurements may be possible. 274 2.3 Required Context for All Reordering Metrics 276 A critical aspect of all reordering metrics is their inseparable 277 bond with the measurement conditions. Packet reordering is not well 278 defined unless the full measurement context is reported. Therefore, 279 all reordering metric definitions include the following parameters: 281 1. The "Packet of Type-P" [RFC2330] identifiers for the packet 282 stream, including the transport addresses for source and 283 destination, and any other information which may result in different 284 packet treatments. 286 2. The stream parameter set for the sending discipline, such as the 287 parameters unique to Periodic Streams (as in [RFC3432]), TCP-like 288 Streams (as in [RFC3148]), or Poisson Streams (as in [RFC2330]). The 289 stream parameters include the packet size, either specified as a 290 fixed value or as a pattern of sizes (as applicable). 292 Whenever a metric is reported, it MUST include a description of 293 these parameters to provide a context for the results. 295 3. A Reordered Packet Singleton Metric 297 The IPPM framework [RFC2330] describes the notions of singletons, 298 samples, and statistics. For easy reference: 300 By a 'singleton' metric, we refer to metrics that are, 301 in a sense, atomic. For example, a single instance of "bulk 302 throughput capacity" from one host to another might be defined 303 as a singleton metric, even though the instance involves 304 measuring the timing of a number of Internet packets. 306 The evaluation of packet order requires several supporting concepts. 307 The first is an algorithm (function) that produces a series of 308 monotonically increasing identifiers applied to packets at the 309 source to uniquely establish the order of packet transmission. The 310 unique sequence identifier may simply be an incrementing consecutive 311 integer message number, or sequence number as used below. The 312 prospect of sequence number roll-over is discussed in Section 6. 314 The second supporting concept is a stored value which is the "next 315 expected" packet number. Under normal conditions, the value of Next 316 Expected (NextExp) is the sequence number of the previous packet 317 plus 1 for message numbering (in general, the receiver reproduces 318 the sender's algorithm and the sequence of identifiers so that the 319 "next expected" can be determined). 321 Each packet within a packet stream can be evaluated with this order 322 singleton metric. 324 3.1 Metric Name 326 Type-P-Reordered 328 3.2 Metric Parameters 330 + Src, the IP address of a host 332 + Dst, the IP address of a host 334 + SrcTime, the time of packet emission from the Source (or wire 335 time) 337 + s, the unique packet sequence number applied at the Source, in 338 units of messages. 340 + NextExp, the Next Expected Sequence number at the Destination, in 341 units of messages. The stored value in NextExp is determined from 342 a previously arriving packet. 344 And optionally: 346 + PayloadSize, the number of bytes contained in the information 347 field and referred to when the SrcByte sequence is based on bytes 348 transfered. 350 + SrcByte, the packet sequence number applied at the Source, in 351 units of payload bytes. 353 3.3 Definition 354 If a packet s, (sent at time, SrcTime) is found to be reordered by 355 comparison with the Next Expected value, its Type-P-Reordered = 356 TRUE; otherwise Type-P-Reordered = FALSE, as defined below: 358 The value of Type-P-Reordered is defined as TRUE if s < NextExp (the 359 packet is reordered). In this case, the NextExp value does not 360 change. 362 The value of Type-P-Reordered is defined as FALSE if s >= NextExp 363 (the packet is in-order). In this case, NextExp is set to s+1 for 364 comparison with the next packet to arrive. 366 Since the Next Expected value cannot decrease, it provides a non- 367 reversing order criterion to identify reordered packets. 369 This definition can also be specified in pseudo-code. 371 On successful arrival of a packet with sequence number s: 372 if s >= NextExp then /* s is in-order */ 373 NextExp = s + 1; 374 Type-P-Reordered = False; 375 else /* when s < NextExp */ 376 Type-P-Reordered = True 378 3.4 Sequence Discontinuity Definition 380 Packets with s > NextExp are a special case of in-order delivery. 381 This condition indicates a sequence discontinuity, either because of 382 packet loss or reordering. Reordered packets must arrive for the 383 sequence discontinuity to be defined as a reordering discontinuity 384 (see section 4). 386 We define two different states for in-order packets. 388 When s = NextExp, the original sequence has been maintained, and 389 there is no discontinuity present. 391 When s > NextExp, some packets in the original sequence have not yet 392 arrived, and there is a sequence discontinuity associated with 393 packet s. The size of the discontinuity is s - NextExp, equal to 394 the number of packets presently missing, either reordered or lost. 396 In pseudo-code: 398 On successful arrival of a packet with sequence number s: 399 if s >= NextExp, then /* s is in-order */ 400 if s > NextExp then 401 SequenceDiscontinuty = True; 402 SeqDiscontinutySize = s - NextExp; 403 else 404 SequenceDiscontinuty = False; 405 NextExp = s + 1; 406 Type-P-Reordered = False; 408 else /* when s < NextExp */ 409 Type-P-Reordered = True; 410 SequenceDiscontinuty = False; 412 Whether any Sequence Discontinuities occur (and their size) is 413 determined by the conditions causing loss and/or reordering along 414 the measurement path. Note that a packet could be reordered at one 415 point, and subsequently lost elsewhere on the path, but this cannot 416 be known from observations at the Destination. 418 3.5 Evaluation of Reordering in Dimensions of Time or Bytes 420 It is possible to use alternate dimensions of time or payload bytes 421 to test for reordering in the definition of section 3.3, as long as 422 the SrcTimes and SrcBytes are unique and reliable. Sequence 423 Discontinuities are easily defined and detected with message 424 numbering, however, this is not so simple in the dimensions of time 425 or bytes. This is a detractor for the alternate dimensions because 426 the Sequence Discontinuity definition plays a key role in the sample 427 metrics that follow. 429 It is possible to detect Sequence Discontinuities with payload byte 430 numbering, but only when the complete pattern of payload sizes is 431 stored at the Destination, or when payload size is constant and then 432 the byte numbering adds needless complexity over message numbering. 434 It may be possible to detect Sequence Discontinuities with Periodic 435 Streams and Source Time numbering, but there are practical pitfalls 436 with sending exactly on-schedule and with clock reliability. 438 The dimensions of time and bytes remain an important basis for 439 characterizing the extent of reordering, as described in sections 440 4.3 and 4.4. 442 3.6 Discussion 444 Any arriving packet bearing a sequence number from the sequence that 445 establishes the Next Expected value can be evaluated to determine 446 whether it is in-order or reordered, based on a previous packet's 447 arrival. In the case where Next Expected is Undefined (because the 448 arriving packet is the first successful transfer), the packet is 449 designated in-order (Type-P-Reordered=FALSE). 451 This metric assumes re-assembly of packet fragments before 452 evaluation. In principle, it is possible to use the Type-P-Reordered 453 metric to evaluate reordering among packet fragments, but each 454 fragment must contain source sequence information. 455 See the Appendix on fragment order evaluation for more detail. 457 If duplicate packets (multiple non-corrupt copies) arrive at the 458 destination, they MUST be noted and only the first to arrive is 459 considered for further analysis (copies would be declared reordered 460 according to the definition above). This requirement has the same 461 storage implications as earlier IPPM metrics, and follows the 462 precedent of RFC 2679. We provide a suggestion to minimize storage 463 size needed in Section 6 on Measurement and Implementation Issues. 465 4. Sample Metrics 467 In this section, we define metrics applicable to a sample of packets 468 from a single Source sequence number system. When reordering occurs, 469 it is highly desirable to assert the degree to which a packet is 470 out-of-order, or reordered with respect other packets. This section 471 defines several metrics that quantify the extent of reordering in 472 various units of measure. Each metric highlights a relevant use. 474 The metrics in the sub-sections below have a network 475 characterization orientation, but also have relevance to receiver 476 design where reordering compensation is of interest. We begin with a 477 simple ratio metric indicating the reordered portion of the sample. 479 4.1 Reordered Packet Ratio 481 4.1.1 Metric Name 483 Type-P-Reordered-Ratio-Stream 485 4.1.2 Metric Parameters 487 The parameter set includes Type-P-Reordered singleton parameters, 488 the parameters unique to Poisson Streams (as in [RFC2330], Periodic 489 Streams (as in [RFC3432]), or TCP-like Streams (as in [RFC3148]), 490 packet size or size patterns, and the following: 492 + T0, a start time 494 + Tf, an end time 496 + dT, a waiting time for each packet to arrive 498 + K, the total number of packets in the stream sent from Source to 499 Destination 501 + L, the total number of packets received (arriving between T0 and 502 Tf+dT) out of the K packets sent. Recall that identical copies 503 (duplicates) have been removed, so L <= K. 505 4.1.3 Definition 506 Given a stream of packets sent from a Source to a Destination, the 507 ratio of reordered packets in the sample is 509 (Count of packets with Type-P-Reordered=TRUE) / ( L ) 511 This fraction may be expressed as a percentage (multiply by 100). 512 Note that in the case of duplicate packets, only the first copy is 513 used. 515 4.1.4 Discussion 517 When the Type-P-Reordered-Ratio-Stream is zero, no further 518 reordering metrics need be examined for that sample. Therefore, the 519 value of this metric is its simple ability to summarize the results 520 for a reordering-free sample. 522 4.2 Reordering Extent 524 This section defines the extent to which packets are reordered, and 525 associates a specific Sequence Discontinuity with each reordered 526 packet. This section inherits the Parameters defined above. 528 4.2.1 Metric Name 530 Type-P-Packet-Reordering-Extent-Stream 532 4.2.2 Notation and Metric Parameters 534 Recall that K is the number of packets in the stream at the Source 535 and L is the number of packets received at the Destination. 537 Each packet has been assigned a sequence number, s, a consecutive 538 integer from 1 to K in the order of packet transmission (at the 539 source). 541 Let s[1], s[2], ..., s[L], represent the original sequence numbers 542 associated with the packets in order of arrival. 544 s[i] can be thought of as a vector, where the index i is the arrival 545 position of the packet with sequence number s. In theory, any 546 Source sequence number could appear in any arrival position, but 547 this is unlikely in reality. 549 Consider a reordered packet (Type-P-Reordered=TRUE) with arrival 550 index i and source sequence number s[i]. There exists a set of 551 indexes j (1 <= j < i) such that s[j] > s[i]. 553 The new parameters are: 555 + i, the index for arrival position, where i-1 represents an 556 arrival earlier than i. 558 + j, a set of one or more arrival indexes, where 1 <= j < i. 560 + s[i], the original sequence numbers, s, in order of arrival. 562 + e, the Reordering Extent, defined below. 564 4.2.3 Definition 566 The reordering extent, e, of packet s[i] is defined to be i-j for 567 the smallest value of j where s[j] > s[i]. 569 Informally, the reordering extent is the maximum distance, in 570 packets, from a reordered packet to the earliest packet received 571 that has a larger sequence number. If a packet is in-order, its 572 reordering extent is undefined. The first packet to arrive is in- 573 order by definition, and has undefined reordering extent. 575 Comment on the definition of extent: For some arrival orders, the 576 assignment of a simple position/distance as the reordering extent 577 tends to overestimate the receiver storage needed to restore order. 578 A more accurate and complex procedure to calculate packet storage 579 would be to subtract any earlier reordered packets that the receiver 580 could pass on to the upper layers (see the Byte Offset metric). With 581 the bias understood, this definition is deemed sufficient, 582 especially for those who demand "on the fly" calculations. 584 4.2.4 Discussion 586 The packet with index j (s[j], identified in the Definition above) 587 is the reordering discontinuity associated with packet s at index i 588 (s[i]). This definition is formalized below. 590 Note that the K packets in the stream could be some subset of a 591 larger stream, but L is still the total number of packets received 592 out of the K packets sent in that subset. 594 If a receiver intends to restore order, then its buffer capacity 595 determines its ability to handle packets that are reordered. For 596 cases with single reordered packets, the extent e gives the number 597 of packets that must be held in the receiver's buffer while waiting 598 for the reordered packet to complete the sequence. For more complex 599 scenarios, the extent may be an overestimate of required storage 600 (see section 4.4 on Reordering Byte Offset and the Examples 601 section). 603 Although reordering extent primarily quantifies the offset in terms 604 of arrival position, it may also be useful for determining the 605 portion of reordered packets that can or cannot be restored to order 606 in a typical receiver buffer based on their arrival order alone (and 607 without the aid of retransmission). 609 A sample's reordering extents may be expressed as a histogram, to 610 easily summarize the frequency of various extents. 612 4.3 Reordering Late Time Offset 614 Reordered packets can be assigned offset values indicating their 615 lateness in terms of buffer time that a receiver must possess to 616 accommodate them. Offset metrics are calculated only on reordered 617 packets, as identified by the reordered packet singleton metric in 618 Section 3. 620 4.3.1 Metric Name 622 Type-P-Packet-Late-Time-Stream 624 4.3.2 Metric Parameters 626 In addition to the parameters defined for Type-P-Reordered-Ratio- 627 Stream, we specify: 629 + DstTime, the time that each packet in the stream arrives at the 630 destination, and may be associated with index i, or packet s[i] 632 + LateTime(s[i]), the offset of packet s[i] in time, defined below 634 4.3.3 Definition 636 Lateness in time is calculated using destination times. When 637 received packet s[i] is reordered, and has a reordering extent e, 638 then: 640 LateTime(s[i]) = DstTime(i)-DstTime(i-e) 642 Alternatively, using similar notation to that of section 4.2, an 643 equivalent definition is: 645 LateTime(s[i]) = DstTime(i)-DstTime(j), for min{j|1<=js[i]. 648 4.3.4 Discussion 650 The offset metrics can help predict whether reordered packets will 651 be useful in a general receiver buffer system with finite limits. 652 The limit may be the time of storage prior to a cyclic play-out 653 instant (as with de-jitter buffers). 655 Note that the One-way IPDV [RFC3393] gives the delay variation for a 656 packet w.r.t. the preceding packet in the source sequence. Lateness 657 and IPDV give an indication of whether a buffer at the destination 658 has sufficient storage to accommodate the network's behavior and 659 restore order. When an earlier packet in the Source sequence is 660 lost, IPDV will necessarily be undefined for adjacent packets, and 661 LateTime may provide the only way to evaluate the usefulness of a 662 packet. 664 In the case of de-jitter buffers, there are circumstances where the 665 receiver employs loss concealment at the intended play-out time of a 666 late packet. However, if this packet arrives out of order, the Late 667 Time determines whether the packet is still useful. IPDV no longer 668 applies, because the receiver establishes a new play-out schedule 669 with additional buffer delay to accommodate similar events in the 670 future (this requires very minimal processing). 672 The combination of loss and reordering influences the LateTime 673 metric. If presented with the arrival sequence 1, 10, 5 (where 674 packets 2, 3, 4, and 6 through 9 are lost), LateTime would not 675 indicate exactly how "late" packet 5 is from its intended arrival 676 position. IPDV [RFC3393] would not capture this either, because of 677 the lack of adjacent packet pairs. Assuming a Periodic Stream 678 [RFC3432], an expected arrival time could be defined for all 679 packets, but this is essentially a single-point delay variation 680 metric (as defined in ITU-T Recommendations [I.356] and [Y.1540]), 681 and not a reordering metric. 683 A sample's LateTime results may be expressed as a histogram, to 684 summarize the frequency of buffer times needed to accommodate 685 reordered packets and permit buffer tuning on that basis. A CDF with 686 buffer time vs. percent of reordered packets accommodated may be 687 informative. 689 4.4 Reordering Byte Offset 691 Reordered packets can be assigned offset values indicating the 692 storage in bytes that a receiver must possess to accommodate them. 693 Offset metrics are calculated only on reordered packets, as 694 identified by the reordered packet singleton metric in Section 3. 696 4.4.1 Metric Name 698 Type-P-Packet-Byte-Offset-Stream 700 4.4.2 Metric Parameters 702 We use the same parameters defined earlier, including the optional 703 parameters of SrcByte and PayloadSize, and define: 705 + ByteOffset(s[i]), the offset of packet s[i] in bytes 707 4.4.3 Definition 709 The Byte stream offset for reordered packet s[i] is the sum of the 710 payload sizes of packets qualified by the following criteria: 712 * Arrival prior to the reordered packet, s[i], and 714 * The send sequence number, s, is greater than s[i]. 716 Packets that meet both these criteria are normally buffered until 717 the sequence beneath them is complete. Note that these criteria 718 apply to both in-order and reordered packets. 720 For reordered packet s[i] with a reordering extent e: 721 ByteOffset(s[i]) = Sum[qualified packets] 722 = Sum[PayloadSize(packet at i-1 if qualified), 723 PayloadSize(packet at i-2 if qualified), ... 724 PayloadSize(packet at i-e always qualified)] 726 Using our earlier notation: 727 ByteOffset(s[i]) = 728 Sum[payloads of s[j] where s[j]>s[i] and i > j >= i-e] 730 4.4.4 Discussion 732 We note that estimates of buffer size due to reordering depend 733 greatly on the test stream, in terms of the spacing between test 734 packets and their size, especially when packet size is variable. In 735 these and other circumstances, it may be most useful to characterize 736 offset in terms of the payload size(s) of stored packets, using the 737 Type-P-packet-Byte-Offset-Stream metric. 739 The byte offset metric can help predict whether reordered packets 740 will be useful in a general receiver buffer system with finite 741 limits. The limit is expressed as the number of bytes the buffer 742 can store. 744 A sample's ByteOffset results may be expressed as a histogram, to 745 summarize the frequency of buffer lengths needed to accommodate 746 reordered packets and permit buffer tuning on that basis. A CDF with 747 buffer size vs. percent of reordered packets accommodated may be 748 informative. 750 4.5 Gaps between multiple Reordering Discontinuities 752 4.5.1 Metric Name 754 Type-P-Packet-Reordering-Gap-Stream 756 4.5.2 Parameters 758 We use the same parameters defined earlier, but add the convention 759 that index i' is greater than i, likewise j' > j, and define: 761 + Gap(s[j']), the Reordering Gap of packet s[j'] in units of 762 integer messages 764 + GapTime(s[j']), the Reordering Gap of packet s[j'] in units of 765 time 767 4.5.3 Definition of Reordering Discontinuity 769 All reordered packets are associated with a packet at a reordering 770 discontinuity, defined as the in-order packet s[j] that arrived at 771 the minimum value of j (1<=j s[i]. 773 Note that s[j] will have been found to cause a sequence 774 discontinuity, where s > NextExp when evaluated with the reordered 775 singleton metric as described in section 3.4. 777 Recall that i - e = min(j). Subsequent reordered packets may be 778 associated with the same s[j], or with a different discontinuity. 779 This fact is used in the definition of the Reordering Gap, below. 781 4.5.4 Definition of Reordering Gap 783 A reordering gap is the distance between successive reordering 784 discontinuities. Type-P-packet-Reordering-Gap-Stream assigns a value 785 to (all) packets in a stream. 787 If: 789 The packet s[j'] is found to be a reordering discontinuity, based 790 on the arrival of reordered packet s[i'] with extent e', and 792 an earlier reordering discontinuity s[j], based on the arrival of 793 reordered packet s[i] with extent e was already detected, and 795 i' > i, and 797 there are no reordering discontinuities between j and j', 799 then the Reordering Gap for packet s[j'] is the difference between 800 the arrival positions the reordering discontinuities, as shown 801 below: 803 Gap(s[j']) = (j') - (j) 805 Otherwise: 807 The Type-P-packet-Reordering-Gap-Stream for the packet is 0. 809 Gaps may also be expressed in time: 811 GapTime(s[j']) = DstTime(j') - DstTime(j) 813 4.5.5 Discussion 815 When separate reordering discontinuities can be distinguished, then 816 a count may also be reported (along with the discontinuity 817 description, such as the number of reordered packets associated with 818 that discontinuity and their extents and offsets). The Gaps between 819 a sample's reordering discontinuities may be expressed as a 820 histogram, to easily summarize the frequency of various gaps. 821 Reporting the mode, average, range, etc. may also summarize the 822 distributions. 824 The Gap metric may help to correlate the frequency of reordering 825 discontinuities with their cause. Gap lengths are also informative 826 to receiver designers, revealing the period of reordering 827 discontinuities. The combination of reordering gaps and extent 828 reveals whether receivers will be required to handle cases of 829 overlapping reordered packets. 831 4.6 Reordering-free Runs 833 This section defines a metric based on a count of consecutive in- 834 order packets between reordered packets. 836 4.6.1 Metric Name 838 Type-P-Packet-Reordering-Free-Run-Stream 840 4.6.2 Parameters 842 We use the same parameters defined earlier, and define the 843 following: 845 + r, the run counter 847 + x, the number of runs, also the number of reordered packets 849 + a, the accumulator of in-order packets 851 + p, the number of packets (when the stream is complete, p=(x+a)=L) 853 + q, the sum of the squares of the runs counted 855 4.6.3 Definition 857 As packets in a sample arrive at the Destination, the count of in- 858 order packets between reordered packets is a Reordering-Free run. 859 Note that the minimum run-length is zero according to this 860 definition. A pseudo code example follows: 862 r = 0; /* r is the run counter */ 863 x = 0; /* x is the number of runs */ 864 a = 0; /* a is the accumulator of in-order packets */ 865 p = 0; /* p is the number of packets */ 866 q = 0; /* q is the sum of the squares of the runs counted */ 868 while(packets arrive with sequence number s) 869 { 870 p++; 871 if (s >= NextExp) /* s is in-order */ 872 then r++; 873 a++; 874 else /* s is reordered */ 875 q+= r*r; 876 r = 0; 877 x++; 878 } 880 Each in-order arrival increments the run counter and the accumulator 881 of in-order packets, each reordered packet resets the run counter 882 after adding it to the sum of the squared lengths. 884 Each arrival of a reordered packet yields a new run count. Long 885 runs accompany periods where order was maintained, while short runs 886 indicate frequent, or multi-packet reordering. 888 The percent of packets in-order is 100*a/p 890 The average Reordering-Free run length is a/x 892 The q counter gives an indication of variation of the Reordering- 893 Free runs from the average by comparing q/a to a/x ((q/a)/(a/x)) 895 4.6.4 Discussion and Illustration 897 Type-P-packet-Reordering-Free-Run-Stream parameters give a brief 898 summary of the stream's reordering characteristics including the 899 average reordering-free run length, and the variation of run 900 lengths, therefore a key application of this metric is network 901 evaluation. 903 For 36 packets with 3 runs of 11 in-order packets we have: 904 p = 36 905 x = 3 906 a = 33 907 q = 3 * (11*11) = 363 908 ave reordering-free run = 11 909 q/a = 11 910 (q/a)/(a/x) = 1.0 912 For 36 packets with 3 runs, 2 runs of length 1 and one of length 31 913 p = 36 914 x = 3 915 a = 33 916 q = 1 + 1 + 961 = 963 917 ave reordering-free run = 11 918 q/a = 29.18 919 (q/a)/(a/x) = 2.65 921 The variability in run length is prominent in the difference between 922 the q values (sum of the squared run lengths) and comparing average 923 run length to the (q/a)/(a/x) ratios (equals 1 when all runs are the 924 same length). 926 5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric 928 This section describes a metric that conveys information associated 929 with the effect of reordering on TCP. However, in order to infer 930 anything about TCP performance, the test stream MUST bear a close 931 resemblance to the TCP sender of interest. [RFC3148] lists the 932 specific aspects of congestion control algorithms that must be 933 specified. Further, RFC 3148 recommends that Bulk Transfer Capacity 934 metrics SHOULD have instruments to distinguish three cases of packet 935 reordering (in section 3.3). The sample metrics defined above 936 satisfy the requirements to classify packets that are slightly or 937 grossly out-of-order. The metric in this section adds the capability 938 to estimate whether reordering might cause the DUP-ACK threshold to 939 be exceeded causing the Fast Retransmit algorithm to be invoked. 940 Additional TCP Kernel Instruments are summarized in [Mat03]. 942 5.1 Metric Name 944 Type-P-Packet-n-Reordering-Stream 946 5.2 Parameter Notation 948 Let n be a positive integer (a parameter). Let k be a positive 949 integer equal to the number of packets sent (sample size). Let l be 950 a non-negative integer representing the number of packets that were 951 received out of the k packets sent. (Note that there is no 952 relationship between k and l: on one hand, losses can make l less 953 than k; on the other hand, duplicates can make l greater than k.) 954 Assign each sent packet a sequence number, 1 to k, in order of 955 packet emission. 957 Let s[1], s[2], ..., s[l] be the original sequence numbers of the 958 received packets, in the order of arrival. 960 5.3 Definitions 962 Definition 1: Received packet number i (n < i <= l), with source 963 sequence number s[i], is n-reordered if and only if for all j such 964 that i-n <= j < i, s[j] > s[i]. 966 Claim: If by this definition, a packet's reordering is n and 0 < n' 967 < n, then the packet is also reordered to the n' extent. 969 Note: This definition is illustrated by C code in Appendix A. It 970 determines the n-reordering for a value of n=3 (when actually 971 writing applications that would report the metric, one would 972 probably report it for several values of n, such as 1, 2, 3, 4 -- 973 and maybe a few more consecutive values). 975 This definition does not assign an n to all reordered packets as 976 defined by the singleton metric, in particular when blocks of 977 successive packets are reordered. (In the arrival sequence 978 s={1,2,3,7,8,9,4,5,6}, packets 4, 5, and 6 are reordered, but only 979 packet 4 is n-reordered, with n=3.) 981 Definition 2: The degree of n-reordering of the sample is m/l, where 982 m is the number of n-reordered packets in the sample. 984 Definition 3: The degree of "monotonic reordering" of the sample is 985 its degree of 1-reordering. 987 Definition 4: A sample is said to have no reordering if its degree 988 of n-reordering is 0. 990 5.4 Discussion 992 The degree of n-reordering may be expressed as a percentage, in 993 which case the number from Definition 2 is multiplied by 100. 995 The n-reordering metric is helpful for matching the duplicate ACK 996 threshold setting to a given path. For example, if a path exhibits 997 no more than 5-reordering, a DUP-ACK threshold of 6 may avoid 998 unnecessary retransmissions. 1000 Important special cases are n=1 and n=3: 1002 - For n=1, absence of 1-reordering means the sequence numbers that 1003 the receiver sees are monotonically increasing with respect to the 1004 previous arriving packet. 1006 - For n=3, a NewReno TCP sender would retransmit 1 packet in 1007 response to an instance of 3-reordering and therefore consider this 1008 packet lost for the purposes of congestion control (the sender will 1009 halve its congestion window, see [RFC2581]). Three is default 1010 threshold for Stream Control Transport Protocol (SCTP) [RFC2960], 1011 and the Datagram Congestion Control Protocol (DCCP) [RFC4340] when 1012 used with Congestion Control ID 2: TCP-like Congestion Control 1013 [RFC4341]. 1015 A sample's n-reordering may be expressed as a histogram, to 1016 summarize the frequency for each value of n. 1018 We note that the definition of n-reordering cannot predict the exact 1019 number of packets unnecessarily retransmitted by a TCP sender under 1020 some circumstances, such as cases with closely-spaced reordered 1021 singletons. Both time and position influence the sender's behavior. 1023 A packet's n-reordering designation is sometimes equal to its 1024 reordering extent, e. n-reordering is different in the following 1025 ways: 1027 1. n is a count of early packets with consecutive arrival positions 1028 at the receiver. 1030 2. Reordered packets (Type-P-Reordered=TRUE) may not be n-reordered, 1031 but will have an extent, e (see the examples). 1033 6. Measurement and Implementation Issues 1035 The results of tests will be dependent on the time interval between 1036 measurement packets (both at the Source, and during transport where 1037 spacing may change). Clearly, packets launched infrequently (e.g., 1038 1 per 10 seconds) are unlikely to be reordered. 1040 In order to gauge the reordering for an application according to the 1041 metrics defined in this memo, it is RECOMMENDED to use the same 1042 sending pattern as the application of interest. In any case, the 1043 exact method of packet generation MUST be reported with the 1044 measurement results, including all stream parameters. 1046 + To make inferences about applications that use TCP, it is 1047 REQUIRED to use TCP-like Streams as in [RFC3148] 1049 + For real-time applications, it is RECOMMENDED to use Periodic 1050 Streams as in [RFC3432] 1052 It is acceptable to report the metrics of Sections 3 and 4 with 1053 other IPPM metrics using Poisson Streams [RFC2330]. Poisson streams 1054 represent an "unbiased sample" of network performance for packet 1055 loss and delay metrics. However, it would be incorrect to make 1056 inferences about the application categories above using reordering 1057 metrics measured with Poisson streams. 1059 Test stream designers may prefer to use a periodic sending interval 1060 so that a known temporal bias is maintained, also bringing 1061 simplified results analysis (as described in [RFC3432]). In this 1062 case, it is RECOMMENDED that the periodic sending interval should be 1063 chosen to reproduce the closest Source packet spacing expected. 1064 Testers must recognize that streams sent at the link speed 1065 serialization limit MUST have limited duration and MUST consider 1066 packet loss as an indication that the stream has caused congestion, 1067 and suspend further testing. 1069 When intending to compare independent measurements of reordering, it 1070 is RECOMMENDED to use the same test stream parameters in each 1071 measurement system. 1073 Packet lengths might also be varied to attempt to detect instances 1074 of parallel processing (they may cause steady state reordering). For 1075 example, a line-speed burst of the longest (MTU-length) packets 1076 followed by a burst of the shortest possible packets may be an 1077 effective detecting pattern. Other size patterns are possible. 1079 The non-reversing order criterion and all metrics described above 1080 remain valid and useful when a stream of packets experiences packet 1081 loss, or both loss and reordering. In other words, losses alone do 1082 not cause subsequent packets to be declared reordered. 1084 Assuming that the necessary sequence information (message number) is 1085 included in the packet payload (possibly in application headers such 1086 as RTP), reordering metrics may be evaluated in a passive 1087 measurement arrangement. Also, it is possible to evaluate order at 1088 any point along a Source-Destination path, recognizing that 1089 intermediate measurements may differ from those made at the 1090 Destination (where the reordering effect on applications can be 1091 inferred). 1093 It is possible to apply these metrics to evaluate reordering in a 1094 TCP sender's stream. In this case, the Source sequence numbers would 1095 be based on byte stream, or segment numbering. Since the stream may 1096 include retransmissions due to loss or reordering, care must be 1097 taken to avoid declaring retransmitted packets reordered. The 1098 additional sequence reference of s or SrcTime helps to avoid this 1099 ambiguity, or the optional TCP timestamp field [RFC1323]. 1101 Since this metric definition may use sequence numbers with finite 1102 range, it is possible that the sequence numbers could reach end-of- 1103 range and roll over to zero during a measurement. By definition, 1104 the Next Expected value cannot decrease, and all packets received 1105 after a roll-over would be declared reordered. Sequence number 1106 roll-over can be avoided by using combinations of counter size and 1107 test duration where roll-over is impossible (and sequence is reset 1108 to zero at the start). Also, message-based numbering results in 1109 slower sequence consumption. There may still be cases where 1110 methodological mitigation of this problem is desirable (e.g., long- 1111 term testing). The elements of mitigation are: 1113 1. There must be a test to detect if a roll-over has occurred. It 1114 would be nearly impossible for the sequence numbers of successive 1115 packets to jump by more than half the total range, so these large 1116 discontinuities are designated as roll-over. 1118 2. All sequence numbers used in computations are represented in a 1119 sufficiently large precision. The numbers have a correction applied 1120 (equivalent to adding a significant digit) whenever roll-over is 1121 detected. 1123 3. Reordered packets coincident with sequence numbers reaching end- 1124 of-range must also be detected for proper application of correction 1125 factor. 1127 Ideally, the test instrument would have the ability to use all 1128 earlier packets at any point in the test stream. In practice there 1129 will be limited ability to determine reordering extent, due to the 1130 storage requirements for previous packets. Saving only packets that 1131 indicate discontinuities (and their arrival positions) will reduce 1132 storage volume. 1134 Another solution is to use a sliding history window of packets, 1135 where the window size would be determined by an upper bound on the 1136 useful reordering extent. This bound could be several packets or 1137 several seconds worth of packets, depending on the intended 1138 analysis. When discarding all stream information beyond the window, 1139 the reordering extent or degree of n-reordering may need to be 1140 expressed as greater than the window length if the reordering 1141 discontinuity information has been discarded, and Gap calculations 1142 would not be possible. 1144 The requirement to ignore duplicate packets also mandates storage. 1145 Here, tracking the sequence numbers of missing packets may minimize 1146 storage size. Missing packets may eventually be declared lost, or 1147 reordered if they arrive. The missing packet list and the largest 1148 sequence number received thus far (NextExp - 1) are sufficient 1149 information to determine if a packet is a duplicate (assuming a 1150 manageable storage size for packets that are missing due to loss). 1152 It is important to note that practical IP networks also have limited 1153 ability to "store" packets, even when routing loops appear 1154 temporarily. Therefore, the maximum storage for reordering metrics 1155 (and their complexity) would only approach the number packets in the 1156 sample, K, when the sending time for K packets is small with respect 1157 to the network's largest possible transfer time. Another possible 1158 limitation on storage is the maximum length of the sequence number 1159 field, assuming that most test streams do not exhaust this length in 1160 practice. 1162 Last, we note that determining reordering extents and gaps is tricky 1163 when there are overlapped or nested events. Test instrument 1164 complexity and reordering complexity are directly correlated. 1166 7. Examples of Arrival Order Evaluation 1168 This section provides some examples to illustrate how the non- 1169 reversing order criterion works, how n-reordering works in 1170 comparison, and the value of quantifying reordering in all the 1171 dimensions of time, bytes, and position. 1173 Throughout this section, we will refer to packets by their source 1174 sequence number, except where noted. So "Packet 4" refers to the 1175 packet with source sequence number 4, and the reader should refer to 1176 the tables in each example to determine packet 4's arrival index 1177 number, if needed. 1179 7.1 Example with a Single Packet Reordered 1181 Table 1 gives a simple case of reordering, where one packet is 1182 reordered, Packet 4. Packets are listed according to their arrival, 1183 and message numbering is used. All packets contain PayloadSize=100 1184 bytes, with SrcByte=(s x 100)-99 for s=1,2,3,4,... 1186 Table 1 Example with Packet 4 Reordered, 1187 Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10 1188 s Src Dst Dst Byte Late 1189 @Dst NextExp Time Time Delay IPDV Order Offset Time 1190 1 1 0 68 68 1 1191 2 2 20 88 68 0 2 1192 3 3 40 108 68 0 3 1193 5 4 80 148 68 -82 4 1194 6 6 100 168 68 0 5 1195 7 7 120 188 68 0 6 1196 8 8 140 208 68 0 7 1197 4 9 60 210 150 82 8 400 62 1198 9 9 160 228 68 0 9 1199 10 10 180 248 68 0 10 1201 Each column gives the following information: 1203 s Packet sequence number at the Source. 1204 NextExp The value of NextExp when the packet arrived(before 1205 update). 1206 SrcTime Packet time stamp at the Source, ms. 1207 DstTime Packet time stamp at the Destination, ms. 1208 Delay 1-way delay of the packet, ms. 1209 IPDV IP Packet Delay Variation, ms 1210 IPDV = Delay(SrcNum)-Delay(SrcNum-1) 1211 DstOrder Order in which the packet arrived at the Destination. 1212 Byte Offset The Byte Offset of a reordered packet, in bytes. 1213 LateTime The lateness of a reordered packet, in ms. 1215 We can see that when Packet 4 arrives, NextExp=9, and it is declared 1216 reordered. We compute the extent of reordering as follows: 1218 Using the notation , the received 1219 packets are represented as: 1221 \/ 1222 s = 1, 2, 3, 5, 6, 7, 8, 4, 9, 10 1223 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 1224 /\ 1226 Applying the definition of Type-P-packet-Reordering-Extent-Stream: 1227 when j=7, 8 > 4, so the reordering extent is 1 or more. 1228 when j=6, 7 > 4, so the reordering extent is 2 or more. 1229 when j=5, 6 > 4, so the reordering extent is 3 or more. 1230 when j=4, 5 > 4, so the reordering extent is 4 or more. 1231 when j=3, but 3 < 4, and 4 is the maximum extent, e=4 (assuming 1232 there are no earlier sequence discontinuities, as in this example). 1234 Further, we can compute the Late Time (210-148=62ms using DstTime) 1235 compared to Packet 5's arrival. If the receiver has a de-jitter 1236 buffer that holds more than 4 packets, or at least 62 ms storage, 1237 Packet 4 may be useful. Note that 1-way delay and IPDV indicate 1238 unusual behavior for Packet 4. Also, if Packet 4 had arrived at 1239 least 62ms earlier, it would have been in-order in this example. 1241 If all packets contained 100 byte payloads, then Byte Offset is 1242 equal to 400 bytes. 1244 Following the definitions of section 5.1, Packet 4 is designated 4- 1245 reordered. 1247 7.2 Example with Two Packets Reordered 1249 Table 2 Example with Packets 5 and 6 Reordered, 1250 Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10 1251 s Src Dst Dst Byte Late 1252 @Dst NextExp Time Time Delay IPDV Order Offset Time 1253 1 1 0 68 68 1 1254 2 2 20 88 68 0 2 1255 3 3 40 108 68 0 3 1256 4 4 60 128 68 0 4 1257 7 5 120 188 68 -22 5 1258 5 8 80 189 109 41 6 100 1 1259 6 8 100 190 90 -19 7 100 2 1260 8 8 140 208 68 0 8 1261 9 9 160 228 68 0 9 1262 10 10 180 248 68 0 10 1264 Table 2 shows a case where Packets 5 and 6 arrive just behind Packet 1265 7, so both 5 and 6 are reordered. The Late times (189-188=1, 190- 1266 188=2) are small. 1268 Using the notation , the received 1269 packets are represented as: 1271 \/ \/ 1272 s = 1, 2, 3, 4, 7, 5, 6, 8, 9, 10 1273 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 1274 /\ /\ 1276 Considering Packet 5 first: 1277 when j=5, 7 > 5, so the reordering extent is 1 or more. 1278 when j=4, we have 4 < 5, so 1 is its maximum extent, and e=1. 1280 Considering Packet 6 next: 1281 when j=6, 5 < 6, the extent is not yet defined. 1282 when j=5, 7 > 6, so the reordering extent is i-j=2 or more. 1283 when j=4, 4 < 6, and we find 2 is its maximum extent, and e=2. 1285 We can also associate each of these reordered packets with a 1286 reordering discontinuity. We find the minimum j=5 (for both packets) 1287 according to Section 4.2.3. So Packet 6 is associated with the same 1288 reordering discontinuity as Packet 5, the Reordering Discontinuity 1289 at Packet 7. 1291 This is a case where reordering extent e would over-estimate the 1292 packet storage required to restore order. Only one packet storage is 1293 required (to hold Packet 7), but e=2 for Packet 6. 1295 Following the definitions of section 5, Packet 5 is designated 1- 1296 reordered, but Packet 6 is not designated n-reordered. 1298 A hypothetical sender/receiver pair may retransmit Packet 5 1299 unnecessarily, since it is 1-reordered (in agreement with the 1300 singleton metric). Though Packet 6 may not be unnecessarily 1301 retransmitted, the receiver cannot advance Packet 7 to the higher 1302 layers until after Packet 6 arrives. Therefore, the singleton metric 1303 correctly determined that Packet 6 is reordered. 1305 7.3 Example with Three Packets Reordered 1307 Table 3 Example with Packets 4, 5, and 6 reordered 1308 Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10,11 1309 s Src Dst Dst Byte Late 1310 @Dst NextExp Time Time Delay IPDV Order Offset Time 1311 1 1 0 68 68 1 1312 2 2 20 88 68 0 2 1313 3 3 40 108 68 0 3 1314 7 4 120 188 68 -88 4 1315 8 8 140 208 68 0 5 1316 9 9 160 228 68 0 6 1317 10 10 180 248 68 0 7 1318 4 11 60 250 190 122 8 400 62 1319 5 11 80 252 172 -18 9 400 64 1320 6 11 100 256 156 -16 10 400 68 1321 11 11 200 268 68 0 11 1323 The case in Table 3 is where three packets in sequence have long 1324 transit times (Packets with s = 4,5,and 6). Delay, Late time, and 1325 Byte Offset capture this very well, and indicate variation in 1326 reordering extent, while IPDV indicates that the spacing between 1327 packets 4,5,and 6 has changed. 1329 The histogram of Reordering extents (e) would be: 1331 Bin 1 2 3 4 5 6 7 1332 Frequency 0 0 0 1 1 1 0 1334 Using the notation , the received 1335 packets are represented as: 1337 s = 1, 2, 3, 7, 8, 9,10, 4, 5, 6, 11 1338 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,11 1340 We first calculate the n-reordering. Considering Packet 4 first: 1341 when n=1, 7<=j<8, and 10> 4, so the packet is 1-reordered. 1342 when n=2, 6<=j<8, and 9 > 4, so the packet is 2-reordered. 1343 when n=3, 5<=j<8, and 8 > 4, so the packet is 3-reordered. 1344 when n=4, 4<=j<8, and 7 > 4, so the packet is 4-reordered. 1345 when n=5, 3<=j<8, but 3 < 4, and 4 is the maximum n-reordering. 1347 Considering packet 5[9] next: 1348 when n=1, 8<=j<9, but 4 < 5, so the packet at i=9 is not designated 1349 as n-reordered. We find the same to for Packet 6. 1351 We now consider whether reordered Packets 5 and 6 are associated 1352 with the same reordering discontinuity as Packet 4. Using the test 1353 of Section 4.2.3, we find that the minimum j=4 for all three 1354 packets. They are all associated with the reordering discontinuity 1355 at Packet 7. 1357 This example shows again that the n-reordering definition identifies 1358 a single Packet (4) with a sufficient degree of n-reordering that 1359 might cause one unnecessary packet retransmission by the New Reno 1360 TCP sender (with DUP-ACK threshold=3 or 4). Also, the reordered 1361 arrival of Packets 5 and 6 will allow the receiver process to pass 1362 Packets 7 through 10 up the protocol stack (the singleton Type-P- 1363 Reordered = TRUE for Packets 5 and 6, and they are all associated 1364 with a single reordering discontinuity). 1366 7.4 Example with Multiple Packet Reordering Discontinuities 1368 Table 4 Example with Multiple Packet Reordering Discontinuities 1369 Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 1371 Discontinuity Discontinuity 1372 |---------Gap---------| 1373 s = 1, 2, 3, 6, 7, 4, 5, 8, 9, 10, 12, 13, 11, 14, 15, 16 1374 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 1376 r = 1, 2, 3, 4, 5, 0, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, ... 1377 number of runs,n = 1 2 3 1378 end r counts = 5 0 5 1379 (these values are computed after the packet arrives) 1381 Packet 4 has extent e=2, Packet 5 has extent e=3, and Packet 11 has 1382 e=2. There are two different reordering discontinuities, one at 1383 Packet 6 (where j=4) and one at Packet 12 (where j'=11). 1385 According to the definition of Reordering Gap 1386 Gap(s[j']) = (j') - (j) 1387 Gap(Packet 12) = (11) - (4) = 7 1389 We also have three reordering-free runs of lengths 5, 0, and 5. 1391 The differences between these two multiple-event metrics are evident 1392 here. Gaps are the distance between sequence discontinuities that 1393 are subsequently defined as reordering discontinuities, while 1394 reordering-free runs capture the distance between reordered packets. 1396 8. Security Considerations 1398 8.1 Denial of Service Attacks 1400 This metric requires a stream of packets sent from one host (source) 1401 to another host (destination) through intervening networks. This 1402 method could be abused for denial of service attacks directed at 1403 destination and/or the intervening network(s). 1405 Administrators of source, destination, and the intervening 1406 network(s) should establish bilateral or multi-lateral agreements 1407 regarding the timing, size, and frequency of collection of sample 1408 metrics. Use of this method in excess of the terms agreed between 1409 the participants may be cause for immediate rejection or discard of 1410 packets or other escalation procedures defined between the affected 1411 parties. 1413 8.2 User Data Confidentiality 1415 Active use of this method generates packets for a sample, rather 1416 than taking samples based on user data, and does not threaten user 1417 data confidentiality. Passive measurement must restrict attention to 1418 the headers of interest. Since user payloads may be temporarily 1419 stored for length analysis, suitable precautions MUST be taken to 1420 keep this information safe and confidential. In most cases, a 1421 hashing function will produce a value suitable for payload 1422 comparisons. 1424 8.3 Interference with the Metric 1426 It may be possible to identify that a certain packet or stream of 1427 packets is part of a sample. With that knowledge at the destination 1428 and/or the intervening networks, it is possible to change the 1429 processing of the packets (e.g. increasing or decreasing delay) that 1430 may distort the measured performance. It may also be possible to 1431 generate additional packets that appear to be part of the sample 1432 metric. These additional packets are likely to perturb the results 1433 of the sample measurement. 1435 To discourage the kind of interference mentioned above, packet 1436 interference checks, such as cryptographic hash, may be used. 1438 9. IANA Considerations 1440 Metrics defined in this memo SHOULD be registered in the IANA IPPM 1441 METRICS REGISTRY as described in initial version of the registry 1442 [RFC4148]. 1444 IANA is asked to register the following metrics in the IANA-IPPM- 1445 METRICS-REGISTRY-MIB (where RFC xxxx is replaced with the number of 1446 this memo): 1448 ietfReorderedSingleton OBJECT-IDENTITY 1449 STATUS current 1450 DESCRIPTION 1451 "Type-P-Reordered" 1452 REFERENCE 1453 "Reference RFC xxxx, section 3" 1454 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1456 ietfReorderedPacketRatio OBJECT-IDENTITY 1457 STATUS current 1458 DESCRIPTION 1459 "Type-P-Reordered-Ratio-Stream" 1460 REFERENCE 1461 "Reference RFC xxxx, section 4.1" 1462 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1464 ietfReorderingExtent OBJECT-IDENTITY 1465 STATUS current 1466 DESCRIPTION 1467 "Type-P-Packet-Reordering-Extent-Stream" 1468 REFERENCE 1469 "Reference RFC xxxx, section 4.2" 1470 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1472 ietfReorderingLateTimeOffset OBJECT-IDENTITY 1473 STATUS current 1474 DESCRIPTION 1475 "Type-P-Packet-Late-Time-Stream" 1476 REFERENCE 1477 "Reference RFC xxxx, section 4.3" 1478 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1480 ietfReorderingByteOffset OBJECT-IDENTITY 1481 STATUS current 1482 DESCRIPTION 1483 "Type-P-Packet-Byte-Offset-Stream" 1484 REFERENCE 1485 "Reference RFC xxxx, section 4.4" 1486 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1488 ietfReorderingGap OBJECT-IDENTITY 1489 STATUS current 1490 DESCRIPTION 1491 "Type-P-Packet-Reordering-Gap-Stream" 1492 REFERENCE 1493 "Reference RFC xxxx, section 4.5" 1494 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1496 ietfReorderingFreeRun OBJECT-IDENTITY 1497 STATUS current 1498 DESCRIPTION 1499 "Type-P-Packet-Reordering-Free-Run-Stream" 1500 REFERENCE 1501 "Reference RFC xxxx, section 4.6" 1502 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1504 ietfnReordering OBJECT-IDENTITY 1505 STATUS current 1506 DESCRIPTION 1507 "Type-P-Packet-n-Reordering-Stream" 1508 REFERENCE 1509 "Reference RFC xxxx, section 5" 1510 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1512 10. Normative References 1514 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1515 September 1981. 1516 Obtain via: http://www.rfc-editor.org/rfc/rfc791.txt 1518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1519 Requirement Levels", RFC 2119, March 1997. 1520 Obtain via: http://www.rfc-editor.org/rfc/rfc2119.txt 1522 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., 1523 "Framework for IP Performance Metrics", RFC 2330, May 1524 1998. 1525 Obtain via: http://www.rfc-editor.org/rfc/rfc2330.txt 1527 [RFC3148] Mathis, M. and Allman, M., "A Framework for Defining 1528 Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 1529 2001. 1530 Obtain via: http://www.rfc-editor.org/rfc/rfc3148.txt 1532 [RFC3432] Raisanen, V., Grotefeld, G., and Morton, A., "Network 1533 performance measurement with periodic streams", RFC 3432, 1534 November 2002. 1535 Obtain via: http://www.rfc-editor.org/rfc/rfc3432.txt 1537 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1538 Registry", RFC 4148, August 2005. 1539 Obtain via: http://www.rfc-editor.org/rfc/rfc4148.txt 1541 11. Informative References 1543 [Bel02] J.Bellardo and S.Savage, "Measuring Packet Reordering," 1544 Proceedings of the ACM SIGCOMM Internet Measurement 1545 Workshop 2002, November 6-8, Marseille, France. 1547 [Ben99] J.C.R.Bennett, C.Partridge, and N.Shectman, "Packet 1548 Reordering is Not Pathological Network Behavior," 1549 IEEE/ACM Transactions on Networking, vol.7, no.6, pp.789- 1550 798, December 1999. 1552 [Cia00] L.Ciavattone and A.Morton, "Out-of-Sequence Packet 1553 Parameter Definition (for Y.1540)", Contribution number 1554 T1A1.3/2000-047, October 30, 2000. 1555 ftp://ftp.t1.org/pub/t1a1/2000-A13/0a130470.doc 1557 [Cia03] L.Ciavattone, A.Morton, and G.Ramachandran, "Standardized 1558 Active Measurements on a Tier 1 IP Backbone," IEEE 1559 Communications Mag., pp 90-97, June 2003. 1561 [I.356] ITU-T Recommendation I.356, "B-ISDN ATM layer cell 1562 transfer performance", March 2000. 1564 [Jai02] S.Jaiswal et al., "Measurement and Classification of Out- 1565 of-Sequence Packets in a Tier-1 IP Backbone," Proceedings 1566 of the ACM SIGCOMM Internet Measurement Workshop 2002, 1567 November 6-8, Marseille, France. 1569 [Lou01] D.Loguinov and H.Radha, "Measurement Study of Low-bitrate 1570 Internet Video Streaming", Proceedings of the ACM SIGCOMM 1571 Internet Measurement Workshop 2001 November 1-2, 2001, 1572 San Francisco, USA. 1574 [Mat03] M. Mathis, J Heffner and R Reddy, "Web100: Extended TCP 1575 Instrumentation for Research, Education and Diagnosis", 1576 ACM Computer Communications Review, Vol 33, Num 3, July 1577 2003. http://www.web100.org/docs/mathis03web100.pdf 1579 [Pax98] V.Paxson, "Measurements and Analysis of End-to-End 1580 Internet Dynamics," Ph.D. dissertation, U.C. Berkeley, 1581 1997, ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz. 1583 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1584 793, September 1981. 1585 Obtain via: http://www.rfc-editor.org/rfc/rfc793.txt 1587 [RFC1323] Jacobson, V., Braden, R., and Borman, D., "TCP Extensions 1588 for High Performance", RFC 1323, May 1992. 1590 [RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion 1591 Control", RFC 2581, April 1999. 1593 [RFC2960] Stewart, R., et al., "Stream Control Transmission 1594 Protocol", RFC 2960, October 2000. 1596 [RFC3393] Demichelis, C., and Chimento, P., "IP Packet Delay 1597 Variation Metric for IP Performance Metrics (IPPM)", RFC 1598 3393, November 2002. 1600 [RFC4340] Kohler, E., Handley, M. and Floyd, S., "Datagram 1601 Congestion Control Protocol (DCCP)", RFC 4340, March 1602 2006. 1604 [RFC4341] Floyd, S. and Kohler, E., "Profile for Datagram 1605 Congestion Control Protocol (DCCP) Congestion Control ID 1606 2: TCP-like Congestion Control", RFC 4341, March 2006. 1608 [TBABAJ02] T. Banka, A. A. Bare, A. P. Jayasumana, "Metrics for 1609 Degree of Reordering in Packet Sequences", Proc. 27th 1610 IEEE Conference on Local Computer Networks, Tampa, FL, 1611 Nov. 2002. 1613 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1614 communication service - IP packet transfer and 1615 availability performance parameters", December 2002. 1617 12. Acknowledgments 1619 The authors would like to acknowledge many helpful discussions with 1620 Matt Zekauskas, Jon Bennett (who authored the sections on 1621 Reordering-Free Runs), and Matt Mathis. We thank David Newman, Henk 1622 Uijterwaal, Mark Allman, Vern Paxson, and Phil Chimento for their 1623 reviews and suggestions, and Michal Przybylski for sharing 1624 implementation experiences with us on the ippm-list. Anura 1625 Jayasumana and Nischal Piratla brought in recent work-in-progress 1626 [TBABAJ02]. We gratefully acknowledge the foundation laid by the 1627 authors of the IP performance Framework [RFC2330]. 1629 13. Appendix A Example Implementations in C (Informative) 1631 Two example c-code implementations of reordering definitions follow: 1633 Example 1 n-reordering ============================================ 1635 #include 1637 #define MAXN 100 1639 #define min(a, b) ((a) < (b)? (a): (b)) 1640 #define loop(x) ((x) >= 0? x: x + MAXN) 1642 /* 1643 * Read new sequence number and return it. Return a sentinel value 1644 * of EOF (at least once) when there are no more sequence numbers. 1645 * In this example, the sequence numbers come from stdin; 1646 * in an actual test, they would come from the network. 1647 * 1648 */ 1649 int 1650 read_sequence_number() 1651 { 1652 int res, rc; 1653 rc = scanf("%d\n", &res); 1654 if (rc == 1) return res; 1655 else return EOF; 1656 } 1658 int 1659 main() 1660 { 1661 int m[MAXN]; /* We have m[j-1] == number of 1662 * j-reordered packets. */ 1663 int ring[MAXN]; /* Last sequence numbers seen. */ 1664 int r = 0; /* Ring pointer for next write. */ 1665 int l = 0; /* Number of sequence numbers read. */ 1666 int s; /* Last sequence number read. */ 1667 int j; 1669 for (j = 0; j < MAXN; j++) m[j] = 0; 1670 for (;(s = read_sequence_number())!= EOF;l++,r=(r+1)%MAXN) { 1671 for (j=0; j 1691 #define MAXN 100 1692 #define min(a, b) ((a) < (b)? (a): (b)) 1693 #define loop(x) ((x) >= 0? x: x + MAXN) 1695 /* Global counters */ 1696 int receive_packets=0; /* number of received */ 1697 int reorder_packets_Al=0; /* num reordered pkts (singleton) */ 1698 int reorder_packets_Stas=0; /* num reordered pkts(n-reordering)*/ 1700 /* function to test if current packet has been reordered 1701 * returns 0 = not reordered 1702 * 1 = reordered 1703 */ 1704 int testorder1(int seqnum) // Al 1705 { 1706 static int NextExp = 1; 1707 int iReturn = 0; 1709 if (seqnum >= NextExp) { 1710 NextExp = seqnum+1; 1712 } else { 1713 iReturn = 1; 1714 } 1715 return iReturn; 1716 } 1718 int testorder2(int seqnum) // Stanislav 1719 { 1720 static int ring[MAXN]; /* Last sequence numbers seen. */ 1721 static int r = 0; /* Ring pointer for next write */ 1722 int l = 0; /* Number of sequence numbers read. */ 1723 int j; 1724 int iReturn = 0; 1726 l++; 1727 r = (r+1) % MAXN; 1728 for (j=0; j= NextExp, 1805 * AND the fragment offset FragOffset >= NextExpFrag 1807 However, it more efficient to define reordered conditions exactly, 1808 and designate Type-P-Reordered as False otherwise. 1810 The value of Type-P-Reordered is defined as True (the packet is 1811 reordered) under the conditions below. In these cases, the NextExp 1812 value does not change. 1814 Case 1: if s < NextExp 1815 Case 2: if s < FragSeq# 1817 Case 3: if s>= NextExp AND s = FragSeq# AND FragOffset < NextExpFrag 1819 This definition can also be illustrated in pseudo-code. A version of 1820 the code follows, and some simplification may be possible. A 1821 challenging aspect surrounds the housekeeping for the new 1822 parameters. 1824 NextExp=0; 1825 NextExpFrag=0; 1826 FragSeq#=0; 1828 while(packets arrive with s, MoreFrag, FragOffset) 1829 { 1830 if (s>=NextExp AND MoreFrag==0 AND s>=FragSeq#){ 1831 /* a normal packet or last frag of an in-order packet arrived 1832 */ 1833 NextExp = s+1; 1834 FragSeq# = 0; 1835 NextExpFrag = 0; 1836 Reordering = False; 1837 } 1838 if (s>=NextExp AND MoreFrag==1 AND s>FragSeq#>=0){ 1839 /* a fragment of a new packet arrived, possibly with a 1840 higher sequence number than the current fragmented packet */ 1841 FragSeq# = s; 1842 NextExpFrag = FragOffset+1; 1843 Reordering = False; 1844 } 1845 if (s>=NextExp AND MoreFrag==1 AND s==FragSeq#){ 1846 /* a fragment of the "current packet s" arrived */ 1847 if (FragOffset >= NextExpFrag){ 1848 NextExpFrag = FragOffset+1; 1849 Reordering = False; 1850 } 1851 else{ 1852 Reordering = True; /* fragment reordered */ 1853 } 1854 } 1855 if (s>=NextExp AND MoreFrag==1 AND s < FragSeq#){ 1856 /* case where a late fragment arrived, 1857 for illustration only, redundant with else below */ 1858 Reordering = True; 1859 } 1860 else { /* when s < NextExp, or MoreFrag==0 AND s < FragSeq# */ 1861 Reordering = True; 1862 } 1863 } 1864 A working version of the code would include a check to ensure that 1865 all fragments of a packet arrive before using the Reordered status 1866 further, such as in sample metrics. 1868 14.4 Discussion: Notes on Sample Metrics when Evaluating Fragments 1870 All fragments with the same Source Sequence Number are assigned the 1871 same Source Time. 1873 Evaluation with byte stream numbering may be simplified if the 1874 fragment offset is simply added to the SourceByte of the first 1875 packet (with fragment offset = 0), keeping the 8 octet units of the 1876 offset in mind. 1878 15. Author's Addresses 1880 Al Morton 1881 AT&T Labs 1882 Room D3 - 3C06 1883 200 Laurel Ave. South 1884 Middletown, NJ 07748 USA 1885 Phone +1 732 420 1571 1886 EMail: 1888 Len Ciavattone 1889 AT&T Labs 1890 Room A2 - 4G06 1891 200 Laurel Ave. South 1892 Middletown, NJ 07748 USA 1893 Phone +1 732 420 1239 1894 EMail: 1896 Gomathi Ramachandran 1897 AT&T Labs 1898 Room C4 - 3D22 1899 200 Laurel Ave. South 1900 Middletown, NJ 07748 USA 1901 Phone +1 732 420 2353 1902 EMail: 1904 Stanislav Shalunov 1905 Internet2 1906 1000 Oakbrook DR STE 300 1907 Ann Arbor, MI 48104 1908 +1 734 995 7060 1909 EMail: 1911 Jerry Perser 1912 Veriwave 1913 USA 1914 Phone: 1916 EMail: 1918 Full Copyright Statement 1920 Copyright (C) The Internet Society (2006). 1922 This document is subject to the rights, licenses and restrictions 1923 contained in BCP 78, and except as set forth therein, the authors 1924 retain all their rights. 1926 This document and the information contained herein are provided on 1927 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1928 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1929 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1930 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1931 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1932 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1934 Intellectual Property 1936 The IETF takes no position regarding the validity or scope of any 1937 Intellectual Property Rights or other rights that might be claimed 1938 to pertain to the implementation or use of the technology described 1939 in this document or the extent to which any license under such 1940 rights might or might not be available; nor does it represent that 1941 it has made any independent effort to identify any such rights. 1942 Information on the procedures with respect to rights in RFC 1943 documents can be found in BCP 78 and BCP 79. 1945 Copies of IPR disclosures made to the IETF Secretariat and any 1946 assurances of licenses to be made available, or the result of an 1947 attempt made to obtain a general license or permission for the use 1948 of such proprietary rights by implementers or users of this 1949 specification can be obtained from the IETF on-line IPR repository 1950 at http://www.ietf.org/ipr. 1952 The IETF invites any interested party to bring to its attention any 1953 copyrights, patents or patent applications, or other proprietary 1954 rights that may cover technology that may be required to implement 1955 this standard. Please address the information to the IETF at ietf- 1956 ipr@ietf.org. 1958 Acknowledgement 1960 Funding for the RFC Editor function is currently provided by the 1961 Internet Society.