idnits 2.17.1 draft-ietf-ippm-reordering-01.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? ** The document is more than 15 pages and seems to lack a Table of Contents. 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: ---------------------------------------------------------------------------- == Line 792 has weird spacing: '...tic int r = ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 505 looks like a reference -- Missing reference section? '2' on line 50 looks like a reference -- Missing reference section? '3' on line 696 looks like a reference -- Missing reference section? '4' on line 68 looks like a reference -- Missing reference section? '5' on line 561 looks like a reference -- Missing reference section? '6' on line 548 looks like a reference -- Missing reference section? '7' on line 563 looks like a reference -- Missing reference section? '8' on line 600 looks like a reference -- Missing reference section? '9' on line 607 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Performance Metrics Working Group A.Morton 2 Internet Draft L.Ciavattone 3 Document: G.Ramachandran 4 Category: Standards Track AT&T Labs 5 S.Shalunov 6 Internet2 7 J.Perser 8 Spirent 10 Packet Reordering Metric for IPPM 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or made obsolete by other 22 documents at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1. Abstract 33 This memo defines a simple metric to determine if a network has 34 maintained packet order. It provides motivations for the new metric, 35 suggests a metric definition, and discusses the issues associated 36 with measurement. The memo includes sample metrics to quantify the 37 extent of reordering in several useful dimensions. Some examples of 38 evaluation using the various sample metrics are included. 40 2. Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [2]. 45 Although RFC 2119 was written with protocols in mind, the key words 46 are used in this document for similar reasons. They are used to 47 ensure the results of measurements from two different 48 implementations are comparable, and to note instances when an 49 implementation could perturb the network. 51 3. Introduction 53 Ordered delivery is a property of successful packet transfer 54 attempts, where the packet sequence ascends for each arriving packet 55 and there are no backward steps. 57 An explicit sequence number, such as the sending time of each packet 58 or an incrementing message number carried in each packet establishes 59 the Source Sequence. 61 The presence of reordering at the Destination is based on arrival 62 order. 64 This metric is consistent with RFC 2330 [3], and classifies arriving 65 packets with sequence numbers smaller than their predecessors as 66 out-of-order, or reordered. For example, if arriving packets are 67 numbered 1,2,4,5,3, then packet 3 is reordered. This is equivalent 68 to Paxon's reordering definition in [4], where "late" packets were 69 declared reordered. The alternative is to emphasize "premature" 70 packets instead (4 and 5 in the example). The metric's construction 71 is very similar to the sequence space validation for received 72 segments in RFC793 [5]. Earlier work to define ordered delivery 73 includes [6], [7] and more ???. 75 3.1 Motivation 77 A reordering metric is relevant for most applications, especially 78 when assessing network support for Real-Time media streams. The 79 extent of reordering may be sufficient to cause a received packet to 80 be discarded by functions above the IP layer. 82 Packet order is not expected to change during transfer, but several 83 specific path characteristics can cause their order to change. 85 Examples are: 86 * When two paths, one with slightly longer transfer time, support a 87 single packet stream or flow, then packets traversing the longer 88 path may arrive out-of-order. Multiple paths may be used to 89 achieve load balancing, or may arise from route instability. 90 * To increase capacity, a network device designed with multiple 91 processors serving a single port may reorder as a byproduct. 92 * A layer 2 retransmission protocol that compensates for an error- 93 prone link may cause packet reordering. 94 * If for any reason, the packets in a buffer are not serviced in the 95 order of their arrival, their order will change. 96 * If packets in a flow are assigned to multiple buffers (following 97 evaluation of traffic characteristics, for example), and the 98 buffers have different occupations and/or service rates, then 99 order will likely change. 101 The ability to restore order at the destination will likely have 102 finite limits. Practical hosts have receiver buffers with finite 103 size in terms of packets, bytes, or time (such as de-jitter 104 buffers). Once the initial determination of reordering is made, it 105 is useful to quantify the extent of reordering, or lateness, in all 106 meaningful dimensions. 108 3.2 Goals and Objectives 110 The definitions below intend to satisfy the goals of: 111 1. Determining whether or not packet order is maintained. 112 2. Quantifying the extent (achieving this second goal requires 113 assumptions of upper layer functions and capabilities to 114 restore order, and therefore several solutions). 116 Reordering Metrics MUST: 118 + be relevant to one or more known applications 119 + be computable "on the fly" 120 + work with Poisson and Periodic test streams 121 + work even if the stream has duplicate or lost packets 123 Reordering Metrics SHOULD: 125 + have concatenating results for segments measured separately 126 + have simplicity for easy consumption and understanding 127 + have relevance to TCP performance 128 + have relevance to Real-time application performance 130 4. An Ordered Arrival Singleton Metric 132 The IPPM framework RFC 2330 [3] gives the definitions of singletons, 133 samples, and statistics. 135 The evaluation of packet order requires several supporting concepts. 136 The first is a sequence number applied to packets at the source to 137 uniquely identify the order of packet transmission. The sequence 138 number may be established by a simple message number, a byte stream 139 number, or it may be the actual time when each packet departs from 140 the Src. 142 The second supporting concept is a stored value which is the "next 143 expected" packet number. Under normal conditions, the value of Next 144 Expected (NextExp) is the sequence number of the previous packet 145 (plus 1 for message numbering). In byte stream numbering, NextExp 146 is a value 1 byte greater than the last in-order packet sequence 147 number + payload. If Src time is used as the sequence number, 148 NextExp is the Src time from the last in-order packet + 1 clock 149 tick. 151 Each packet within a packet stream can be evaluated for its order 152 singleton metric. 154 4.1 Metric Name: 156 Type-P-Non-Reversing-Order 158 4.2 Metric Parameters: 160 + Src, the IP address of a host 162 + Dst, the IP address of a host 164 + SrcTime, the time of packet emission from the Src (or wire time) 166 + SrcNum, the packet sequence number applied at the Src, in units 167 of messages or bytes. 169 + NextExp, the Next Expected Sequence number at the Dst, in units 170 of messages, time, or bytes. 172 + PayloadSize, the number of bytes contained in the information 173 field and referred to when the SrcNum sequence is based on byte 174 transfer. 176 4.3 Definition: 178 In-order packets have sequence numbers (or Src times) greater than 179 or equal to the value of Next Expected. Each new in-order packet 180 will increase the Next Expected (typically by 1 for message 181 numbering, or the payload size plus 1 for byte numbering). The Next 182 Expected value cannot decrease, thereby specifying non-reversing 183 order as the basis to identify reordered packets. 185 A reordered packet outcome occurs when a single IP packet at the Dst 186 Measurement Point results in the following: 187 The packet has a Src sequence number lower than the Next Expected 188 (NextExp), and therefore the packet is reordered. The Next Expected 189 value does not change on the arrival of this packet. 191 This definition can also be specified in pseudo-code. 192 On successful arrival of a packet with sequence number n: 193 if n >= NextExp, /* n is in-order */ 194 then 195 NextExp = n + PayloadSize + 1; 196 else /* when n < NextExp */ 197 designate packet n as reordered; 199 When using message-based sequence numbering or Src time, 200 PayloadSize=0. 202 4.4 Discussion 203 Any arriving packet bearing a sequence number from the sequence that 204 establishes the Next Expected value can be evaluated to determine if 205 it is in-order, or reordered, based on a previous packet's arrival. 206 In the case where Next Expected is Undefined (because the arriving 207 packet is the first successful transfer), the packet is designated 208 in-order. 210 5. Sample Metrics 212 It is highly desirable to assert the degree to which a packet is 213 out-of-order, or reordered with respect to a sample of packets. This 214 section defines several metrics that quantify the extent of 215 reordering in various units of measure. Each metric highlights a 216 relevant application. 218 5.1 n-Reordering 220 [Note: This is the 10/2002 definition of n-Reordering. This 221 definition focuses on TCP sender and receiver behavior, and in 222 particular, New Reno TCP behavior when n=3.] 224 Metric Name: Type-P-packet-n-reordering-Poisson/Periodic-Stream 226 Parameter Notation: Let n be a positive integer (a parameter). Let 227 k be a positive integer (sample size, the number of packets sent). 228 Let l be a non-negative integer representing the number of packets 229 that were received out of the k packets sent. (Note that there is 230 no relationship between k and l: on one hand, losses can make l less 231 than k; on the other hand, duplicates can make l greater than k.) 232 Assign each sent packet a sequence number, 1 to k. Let s[1], ..., 233 s[l] be the original sequence numbers of the received packets, in 234 the order of arrival (duplicates are possible). 236 Definition 1: Received packet number i (n < i <= l) is called n- 237 reordered if and only if for all j such that i-n <= j < i we have 238 s[j] > s[i]. 240 Note: This definition is illustrated by C code in Appendix A. It 241 computes n-reordering for a particular value of n (when actually 242 writing applications that would report the metric, one would 243 probably report it for several values of n, such as 1, 2, 3, 4 -- 244 and maybe a few more consecutive values). 246 Claim: If a packet is n-reordered and 0 < n' < n, then the packet is 247 also n'-reordered. 249 Let m be the number of n-reordered packets in the sample. 251 Definition 2: The degree of n-reordering of the sample is m/(l-n). 253 Definition 3: The degree of reordering of the sample is its degree 254 of 1-reordering. 255 <<< s[i]. 327 A sample's position offset may be expressed as a histogram, to 328 easily summarize the extent and frequency of various offsets. 330 5.2.2 Metric Name: Type-P-packet-Late-Time-Poisson/Periodic-Stream 332 Metric Parameters: In addition to the parameters defined for Type-P- 333 Non-Reversing-Order, we specify: 335 + DstTime, the time that each packet in the stream arrives at Dst 337 Definition: Lateness in time is calculated using Dst times. 339 Late Time = 340 DstTime(reordered packet)-DstTime(packet at discontinuity) 342 Using similar notation to that of Section 5.1, an equivalent 343 definition is: 344 The Late Time of Reordered Packet i is t = DstTime[i]-DstTime[j], 345 for min{j|1<=js[i], or 346 SrcTime[j]>SrcTime[i]. 348 5.2.3 Metric Name: Type-P-packet-Byte-Offset-Poisson/Periodic-Stream 350 Metric Parameters: We use the same parameters defined above. 352 Definition: Byte stream offset is the sum of the payload sizes of 353 all intervening packets between the reordered packet and the 354 discontinuity (including the packet at the discontinuity). 356 When reordered packet has DstOrder=m 357 Byte Offset = Sum[PayloadSize(packet, DstOrder=m-1), 358 PayloadSize(packet, DstOrder=m-2), ... 359 PayloadSize(packet at discontinuity)] 361 5.2.4 Discussion 363 The Offset metrics can predict whether reordered packets will be 364 useful in a general, but limited receiver buffer system. The limit 365 may be the number of bytes or packets the buffer can store, or the 366 time of storage prior to a cyclic play-out instant (as with de- 367 jitter buffers). 369 Note that the One-way IPDV [8] gives the delay variation for a 370 packet w.r.t. the preceding packet in the source sequence. Lateness 371 and IPDV give an indication of whether a buffer at Dst has 372 sufficient storage to accommodate the network's behavior and restore 373 order. When an earlier packet in the Src sequence is lost, IPDV will 374 necessarily be undefined for adjacent packets, and Late Time may 375 provide the only way to evaluate the usefulness of a packet. 377 In the case of de-jitter buffers, there are circumstances where the 378 receiver employs loss concealment at the intended play-out time of a 379 late packet. However, if this packet arrives out of order, the Late 380 Time determines whether the packet is still useful. IPDV no longer 381 applies, because the receiver establishes a new play-out schedule 382 with additional buffer delay to accommodate similar events in the 383 future - this requires very minimal processing. 385 When packets in the stream have variable sizes, it may be most 386 useful to characterize Offset in terms of the payload size(s) of 387 stored packets (using byte stream numbering). 389 For a sample of packets in a stream, results may be reported as a 390 ratio of reordered packets to total packets sent by the source 391 during the test. If separate reordering events can be distinguished, 392 then an event count may also be reported (along with the event 393 description, such as the number of reordered packets and their 394 offsets). The distribution of various Offset metrics may also be 395 reported and summarized as average, range, etc. 397 6. Measurement Issues 399 The results of tests will be dependent on the time interval between 400 measurement packets (both at the Src, and during transport where 401 spacing may change). Clearly, packets launched infrequently (e.g., 402 1 per 10 seconds) are unlikely to be reordered. 404 Test streams may prefer to use a periodic sending interval so that a 405 known temporal bias is maintained, also bringing simplified results 406 analysis [Ref to npmps]. In this case, the periodic sending interval 407 should be chosen to reproduce the closest Src packet spacing 408 expected. 409 <<< the 506 received packets are represented as: 508 \/ 509 s = 1, 2, 3, 5, 6, 7, 8, 4, 9, 10 510 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 511 /\ 512 when n=1, 7<=J<8, and 8 > 4, so the packet at i=8 is 1-reordered. 513 when n=2, 6<=J<8, and 7 > 4, so the packet at i=8 is 2-reordered. 514 when n=3, 5<=J<8, and 6 > 4, so the packet at i=8 is 3-reordered. 515 when n=4, 4<=J<8, and 5 > 4, so the packet at i=8 is 4-reordered. 516 when n=5, 3<=J<8, but 3 < 4, no more reordering. 518 We note that the Position Offset is equal to the Max(n) with n- 519 reordering. 521 Table 2 Example with Packets 5 and 6 Reordered, 522 Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10 523 SrcNum Src Dst Dst Posit. Late 524 @Dst NextExp Time Time Delay IPDV Order Offset Time 525 1 1 0 68 68 1 526 2 2 20 88 68 0 2 527 3 3 40 108 68 0 3 528 4 4 60 128 68 0 4 529 7 5 120 188 68 -22 5 530 5 8 80 189 109 41 6 1 1 531 6 8 100 190 90 -19 7 2 2 532 8 8 140 208 68 0 8 533 9 9 160 228 68 0 9 534 10 10 180 248 68 0 10 536 Table 2 shows a case where packets 5 and 6 arrive just behind packet 537 7, so both 5 and 6 are declared out-of-order. Their positional 538 offsets (6-5=1 and 7-5=2, using DstOrder again) and Late times (189- 539 188=1, 190-188=2) are small. 541 In the notation of n-reordering, the received packets are 542 represented as: 543 \/ \/ 544 s = 1, 2, 3, 4, 7, 5, 6, 8, 9, 10 545 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 546 /\ /\ 548 Considering packet 5[6] first: 549 when n=1, 5<=J<6, and 7 > 5, so the packet at i=6 is 1-reordered. 550 when n=2, 4<=J<6, but 4 < 5, same for all earlier packets. 552 Considering packet 6[7] next: 553 when n=1, 6<=J<7, and 5 < 6, so the packet at I=7 is not n-reordered 554 for any n, even though: 555 when N=2, 5<=J<7, and 7 > 6, 556 because n-reordering requires s[j]>s[i] 557 for all j such that i-n <= j < i (see Definition 1 in section 5.1). 559 A hypothetical sender/receiver pair may retransmit packet 5[8] 560 unnecessarily, since it is 1-reordered (in agreement with the 561 singleton metric). However, the receiver cannot advance packet 7[5] 562 to the higher layers until after packet 6[7] arrives. Therefore, the 563 singleton metric correctly determined that 6[7] is reordered, and 564 the n-reordering metric indicates that the hypothetical receiver can 565 deal with its arrival efficiently (no unnecessary retransmission). 567 Table 3 Example with Packets 4, 5, and 6 reordered 568 Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10,11 569 SrcNum Src Dst Dst Posit. Late 570 @Dst NextExp Time Time Delay IPDV Order Offset Time 571 1 1 0 68 68 1 572 2 2 20 88 68 0 2 573 3 3 40 108 68 0 3 574 7 4 120 188 68 -68 4 575 8 8 140 208 68 0 5 576 9 9 160 228 68 0 6 577 10 10 180 248 68 0 7 578 4 11 60 250 190 122 8 4 62 579 5 11 80 252 172 -18 9 5 64 580 6 11 100 256 156 -16 10 6 68 581 11 11 200 268 68 0 11 583 The case in Table 3 is where three packets in sequence have long 584 transit times (packets with SrcNum 4,5,and 6). Delay, Late time, and 585 Position Offset capture this very well, and indicate variation in 586 reordering extent, while IPDV indicates that the spacing between 587 packets 4,5,and 6 has changed. 589 The histogram of Position Offsets would be: 591 Bin 1 2 3 4 5 6 7 592 Frequency 0 0 0 1 1 1 0 594 In the notation of n-reordering, the received packets are 595 represented as: 597 s = 1, 2, 3, 7, 8, 9,10, 4, 5, 6, 11 598 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,11 600 Considering packet 4[8] first: 601 when n=1, 7<=J<8, and 10> 4, so the packet at i=8 is 1-reordered. 602 when n=2, 6<=J<8, and 9 > 4, so the packet at i=8 is 2-reordered. 603 when n=3, 5<=J<8, and 8 > 4, so the packet at i=8 is 3-reordered. 604 when n=4, 4<=J<8, and 7 > 4, so the packet at i=8 is 4-reordered. 605 when n=5, 3<=J<8, but 3 < 4, same for all earlier packets. 607 Considering packet 5[9] next: 609 when n=1, 8<=J<9, and 4 < 5, so the packet at I=9 is not n-reordered 611 This example shows again that the n-reordering definition identifies 612 a single packet (SrcNum=4) with a sufficient degree of reordering to 613 result in one unnecessary packet retransmission by the New Reno TCP 614 sender. Also, the delayed arrival of SrcNum=5 and SrcNum=6 will 615 allow the receiver process to pass Src packets 7 through 10 up the 616 protocol stack (the singleton metric indicates 5 and 6 are 617 reordered). 619 8. Security Considerations [mostly borrowed from npmps] 621 8.1 Denial of Service Attacks 623 This metric requires a stream of packets sent from one host (Src) to 624 another host (Dst) through intervening networks. This method could 625 be abused for denial of service attacks directed at Dst and/or the 626 intervening network(s). 628 Administrators of Src, Dst, and the intervening network(s) should 629 establish bilateral or multi-lateral agreements regarding the 630 timing, size, and frequency of collection of sample metrics. Use of 631 this method in excess of the terms agreed between the participants 632 may be cause for immediate rejection or discard of packets or other 633 escalation procedures defined between the affected parties. 635 8.2 User data confidentiality 637 Active use of this method generates packets for a sample, rather 638 than taking samples based on user data, and does not threaten user 639 data confidentiality. Passive measurement must restrict attention to 640 the headers of interest. Since user payloads may be temporarily 641 stored for length analysis, suitable precautions MUST be taken to 642 keep this information safe and confidential. 644 8.3 Interference with the metric 646 It may be possible to identify that a certain packet or stream of 647 packets is part of a sample. With that knowledge at Dst and/or the 648 intervening networks, it is possible to change the processing of the 649 packets (e.g. increasing or decreasing delay) that may distort the 650 measured performance. It may also be possible to generate 651 additional packets that appear to be part of the sample metric. 652 These additional packets are likely to perturb the results of the 653 sample measurement. 655 To discourage the kind of interference mentioned above, packet 656 interference checks, such as cryptographic hash, may be used. 658 9. IANA Considerations 659 Since this metric does not define a protocol or well-known values, 660 there are no IANA considerations in this memo. 662 10. References 664 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 665 9, RFC 2026, October 1996. 667 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 668 Levels", RFC 2119, March 1997. 670 3 Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework 671 for IP Performance Metrics", RFC 2330, May 1998. 673 4 V.Paxson, "Measurements and Analysis of End-to-End Internet 674 Dynamics," Ph.D. dissertation, U.C. Berkeley, 1997, 675 ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz. 677 5 Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 678 September 1981. 679 Obtain via: http://www.rfc-editor.org/rfc/rfc793.txt 681 6 L.Ciavattone and A.Morton, "Out-of-Sequence Packet Parameter 682 Definition (for Y.1540)", Contribution number T1A1.3/2000-047, 683 October 30, 2000. ftp://ftp.t1.org/pub/t1a1/2000-A13/0a130470.doc 685 7 J.C.R.Bennett, C.Partridge, and N.Shectman, "Packet Reordering is 686 Not Pathological Network Behavior," IEEE/ACM Transactions on 687 Neteworking, vol.7, no.6, pp.789-798, December 1999. 689 8 Demichelis, C., and Chimento, P., "IP Packet Delay Variation 690 Metric for IPPM", work in progress. 692 11. Acknowledgments 694 The authors would like to acknowledge the helpful discussions with 695 Matt Mathis and Jon Bennett. We gratefully acknowledge the 696 foundation laid by the authors of the IP performance Framework [3]. 698 12. Appendix A (informative) 700 Two example c-code implementations of reordering definitions follow: 702 Example 1 n-reordering ============================================ 704 #include 706 #define MAX_N 100 708 #define min(a, b) ((a) < (b)? (a): (b)) 709 #define loop(x) ((x) >= 0? x: x + MAX_N) 710 /* 711 * Read new sequence number and return it. Return a sentinel value 712 of EOF 713 * (at least once) when there are no more sequence numbers. In this 714 example, 715 * the sequence numbers come from stdin; in an actual test, they 716 would come 717 * from the network. 718 */ 719 int 720 read_sequence_number() 721 { 722 int res, rc; 723 rc = scanf("%d\n", &res); 724 if (rc == 1) return res; 725 else return EOF; 726 } 728 int 729 main() 730 { 731 int m[MAX_N]; /* We have m[j-1] == number 732 of 733 * j-reordered packets. */ 734 int ring[MAX_N]; /* Last sequence numbers 735 seen. */ 736 int r = 0; /* Ring pointer for next 737 write. */ 738 int l = 0; /* Number of sequence 739 numbers read. */ 740 int s; /* Last sequence number 741 read. */ 742 int j; 744 for (j = 0; j < MAX_N; j++) m[j] = 0; 745 for (; (s = read_sequence_number()) != EOF; l++, r = (r+1) % 746 MAX_N) { 747 for (j=0; j 763 #define MAX_N 100 764 #define min(a, b) ((a) < (b)? (a): (b)) 765 #define loop(x) ((x) >= 0? x: x + MAX_N) 767 /* Global counters */ 768 int receive_packets=0; /* number of recieved */ 769 int reorder_packets=0; /* number of reordered packets */ 771 /* function to test if current packet has been reordered 772 * returns 0 = not reordered 773 * 1 = reordered 774 */ 775 int testorder1(int seqnum) // Al 776 { 777 static int NextExp = 1; 778 int iReturn = 0; 780 if (seqnum >= NextExp) { 781 NextExp = seqnum+1; 782 } else { 783 iReturn = 1; 784 } 785 return iReturn; 786 } 788 int testorder2(int seqnum) // Stanislav 789 { 790 static int ring[MAX_N]; /* Last sequence numbers 791 seen. */ 792 static int r = 0; /* Ring pointer for next write. 793 */ 794 int l = 0; /* Number of sequence 795 numbers read. */ 796 int j; 797 int iReturn = 0; 799 l++; 800 r = (r+1) % MAX_N; 801 for (j=0; j 831 Len Ciavattone 832 AT&T Labs 833 Room C4 - 2B29 834 200 Laurel Ave. South 835 Middletown, NJ 07748 USA 836 Phone +1 732 420 1239 837 839 Gomathi Ramachandran 840 AT&T Labs 841 Room C4 - 3D22 842 200 Laurel Ave. South 843 Middletown, NJ 07748 USA 844 Phone +1 732 420 2353 845 847 Stanislav Shalunov 848 Internet2 849 200 Business Park Drive, Suite 307 850 Armonk, NY 10504 851 Phone: + 1 914 765 1182 852 EMail: 854 Jerry Perser 855 Spirent Communications 856 26750 Agoura Road 857 Calabasas, CA 91302 USA 858 Phone: + 1 818 676 2300 859 EMail: 861 Full Copyright Statement 862 "Copyright (C) The Internet Society (date). All Rights Reserved. 863 This document and translations of it may be copied and furnished to 864 others, and derivative works that comment on or otherwise explain it 865 or assist in its implmentation may be prepared, copied, published 866 and distributed, in whole or in part, without restriction of any 867 kind, provided that the above copyright notice and this paragraph 868 are included on all such copies and derivative works. However, this 869 document itself may not be modified in any way, such as by removing 870 the copyright notice or references to the Internet Society or other 871 Internet organizations, except as needed for the purpose of 872 developing Internet standards in which case the procedures for 873 copyrights defined in the Internet Standards process must be 874 followed, or as required to translate it into languages other than 875 English. 877 The limited permissions granted above are perpetual and will not be 878 revoked by the Internet Society or its successors or assigns. 880 This document and the information contained herein is provided on an 881 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 882 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 883 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 884 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 885 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.