summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5236.txt
blob: 800282e3cb95d32683f1bc58e0558f2c0892c5fa (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
Network Working Group                                      A. Jayasumana
Request for Comments: 5236                     Colorado State University
Category: Informational                                       N. Piratla
                                                   Deutsche Telekom Labs
                                                                T. Banka
                                               Colorado State University
                                                                 A. Bare
                                                              R. Whitner
                                              Agilent Technologies, Inc.
                                                               June 2008


                   Improved Packet Reordering Metrics

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

IESG Note

   The content of this RFC was at one time considered by the IETF, and
   therefore it may resemble a current IETF work in progress or a
   published IETF work.  The IETF standard for reordering metrics is RFC
   4737.  The metrics in this document were not adopted for inclusion in
   RFC 4737.  This RFC is not a candidate for any level of Internet
   Standard.  The IETF disclaims any knowledge of the fitness of this
   RFC for any purpose and in particular notes that the decision to
   publish is not based on IETF review for such things as security,
   congestion control, or inappropriate interaction with deployed
   protocols.  The RFC Editor has chosen to publish this document at its
   discretion.  Readers of this RFC should exercise caution in
   evaluating its value for implementation and deployment.  See RFC 3932
   for more information.

Abstract

   This document presents two improved metrics for packet reordering,
   namely, Reorder Density (RD) and Reorder Buffer-occupancy Density
   (RBD).  A threshold is used to clearly define when a packet is
   considered lost, to bound computational complexity at O(N), and to
   keep the memory requirement for evaluation independent of N, where N
   is the length of the packet sequence.  RD is a comprehensive metric
   that captures the characteristics of reordering, while RBD evaluates
   the sequences from the point of view of recovery from reordering.





Jayasumana, et al.           Informational                      [Page 1]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   These metrics are simple to compute yet comprehensive in their
   characterization of packet reordering.  The measures are robust and
   orthogonal to packet loss and duplication.

Table of Contents

   1. Introduction and Motivation .....................................3
   2. Attributes of Packet Reordering Metrics .........................4
   3. Reorder Density and Reorder Buffer-Occupancy Density ............7
      3.1. Receive Index (RI) .........................................8
      3.2. Out-of-Order Packet ........................................9
      3.3. Displacement (D) ...........................................9
      3.4. Displacement Threshold (DT) ................................9
      3.5. Displacement Frequency (FD) ...............................10
      3.6. Reorder Density (RD) ......................................10
      3.7. Expected Packet (E) .......................................10
      3.8. Buffer Occupancy (B) ......................................10
      3.9. Buffer-Occupancy Threshold (BT) ...........................11
      3.10. Buffer-Occupancy Frequency (FB) ..........................11
      3.11. Reorder Buffer-Occupancy Density (RBD) ...................11
   4. Representation of Packet Reordering and Reorder Density ........11
   5. Selection of DT ................................................12
   6. Detection of Lost and Duplicate Packets ........................13
   7. Algorithms to Evaluate RD and RBD ..............................14
      7.1. Algorithm for RD ..........................................14
      7.2. Algorithm for RBD .........................................16
   8. Examples .......................................................17
   9. Characteristics Derivable from RD and RBD ......................21
   10. Comparison with Other Metrics .................................22
   11. Security Considerations .......................................22
   12. References ....................................................22
      12.1. Normative References .....................................22
      12.2. Informative References ...................................22
   13. Contributors ..................................................24

















Jayasumana, et al.           Informational                      [Page 2]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


1.  Introduction and Motivation

   Packet reordering is a phenomenon that occurs in Internet Protocol
   (IP) networks.  Major causes of packet reordering include, but are
   not limited to, packet striping at layers 2 and 3 [Ben99] [Jai03],
   priority scheduling (e.g., Diffserv), and route fluttering [Pax97]
   [Boh03].  Reordering leads to degradation of the performance of many
   applications [Ben99] [Bla02] [Lao02].  Increased link speeds [Bar04],
   increased parallelism within routers and switches, Quality-of-Service
   (QoS) support, and load balancing among links all point to increased
   packet reordering in future networks.

   Effective metrics for reordering are required to measure and quantify
   reordering.  A good metric or a set of metrics capturing the nature
   of reordering can be expected to provide insight into the reordering
   phenomenon in networks.  It may be possible to use such metrics to
   predict the effects of reordering on applications that are sensitive
   to packet reordering, and perhaps even to compensate for reordering.
   A metric for reordered packets may also help evaluate network
   protocols and implementations with respect to their impact on packet
   reordering.

   The percentage of out-of-order packets is often used as a metric for
   characterizing reordering.  However, this metric is vague and lacking
   in detail.  Further, there is no uniform definition for the degree of
   reordering of an arrived packet [Ban02] [Pi05a].  For example,
   consider the two packet sequences (1, 3, 4, 2, 5) and (1, 4, 3, 2,
   5).  It is possible to interpret the reordering of packets in these
   sequences differently.  For example,

   (i)   Packets 2, 3, and 4 are out of order in both cases.

   (ii)  Only packet 2 is out of order in the first sequence, while
         packets 2 and 3 are out of order in the second.

   (iii) Packets 3 and 4 are out of order in both the sequences.

   (iv)  Packets 2, 3, and 4 are out of order in the first sequence,
         while packets 4 and 2 are out of order in the second sequence.

   In essence, the percentage of out-of-order packets as a metric of
   reordering is subject to interpretation and cannot capture the
   reordering unambiguously and hence, accurately.

   Other metrics attempt to overcome this ambiguity by defining only the
   late packets or only the early packets as being reordered.  However,
   measuring reordering based only on late or only on early packets is
   not always effective.  Consider, for example, the sequence (1, 20, 2,



Jayasumana, et al.           Informational                      [Page 3]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   3, ..., 19, 21, 22, ...); the only anomaly is that packet 20 is
   delivered immediately after packet 1.  A metric based only on
   lateness will indicate a high degree of reordering, even though in
   this example it is a single packet arriving ahead of others.
   Similarly, a metric based only on earliness does not accurately
   capture reordering caused by a late arriving packet.  A complete
   reorder metric must account for both earliness and lateness, and it
   must be able to differentiate between the two.  The inability to
   capture both the earliness and the lateness precludes a metric from
   being useful for estimating end-to-end reordering based on reordering
   in constituent subnets.

   The sensitivity to packet reordering can vary significantly from one
   application to the other.  Consider again the packet sequence (1, 3,
   4, 2, 5).  If buffers are available to store packets 3 and 4 while
   waiting for packet 2, an application can recover from reordering.
   However, with certain real-time applications, the out-of-order
   arrival of packet 2 may render it useless.  While one can argue that
   a good packet reordering measurement scheme should capture
   application-specific effects, a counter argument can also be made
   that packet reordering should be measured strictly with respect to
   the order of delivery, independent of the application.

   Many different packet reordering metrics have been suggested.  For
   example, the standards-track document RFC 4737 [RFC4737] defines 11
   metrics for packet reordering, including lateness-based percentage
   metrics, reordering extent metrics, and N-reordering.

   Section 2 of this document discusses the desirable attributes of any
   packet reordering metric.  Section 3 introduces two additional packet
   reorder metrics: Reorder Density (RD) and Reorder Buffer-occupancy
   Density (RBD), which we claim are superior to the others [Pi07].  In
   particular, RD possesses all the desirable attributes, while other
   metrics fall significantly short in several of these attributes.  RBD
   is unique in measuring reordering in terms of the system resources
   needed for recovery from packet reordering.  Both RD and RBD have a
   computation complexity O(N), where N is the length of the packet
   sequence, and they can therefore be used for real-time online
   monitoring.

2.  Attributes of Packet Reordering Metrics

   The first and foremost requirement of a packet reordering metric is
   its ability to capture the amount and extent of reordering in a
   sequence of packets.  The fact that a measure varies with reordering
   of packets in a stream does not make it a good metric.  In [Ben99],
   the authors have identified desirable features of a reordering
   metric.  This list encloses the foremost requirements stated above:



Jayasumana, et al.           Informational                      [Page 4]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   simplicity, low sensitivity to packet loss, ability to combine
   reorder measures from two networks, minimal value for in-order data,
   and independence of data size.  These features are explained below in
   detail, along with additional desired features.  Note, the ability to
   combine reorder measures from two networks is added to broaden
   applicability, and data size independence is discussed under
   evaluation complexity.  However, data size independence could also
   refer to the final measure, as in percentage reordering or even a
   normalized representation.

   a) Simplicity

      An ideal metric is one that is simple to understand and evaluate,
      and yet informative, i.e., able to provide a complete picture of
      reordering.  Percentage of packets reordered is the simplest
      singleton metric; but the ambiguity in its definition, as
      discussed earlier, and its failure to carry the extent of
      reordering make it less informative.  On the other hand, keeping
      track of the displacements of each and every packet without
      compressing the data will contain all the information about
      reordering, but it is not simple to evaluate or use.

      A simpler metric may be preferred in some cases even though it
      does not capture reordering completely, while other cases may
      demand a more complex, yet complete metric.

      In striving to strike a balance, the lateness-based metrics
      consider only the late packets as reordered, and earliness-based
      metrics only the early packets as reordered.  However, a metric
      based only on earliness or only on lateness captures only a part
      of the information associated with reordering.  In contrast, a
      metric capturing both early and late arrivals provides a complete
      picture of reordering in a sequence.

   b) Low Sensitivity to Packet Loss and Duplication

      A reorder metric should treat only an out-of-order packet as
      reordered, i.e., if a packet is lost during transit, then this
      should not result in its following packets, which arrive in order,
      being classified as out of order.  Consider the sequence (1, 3, 4,
      5, 6).  If packet 2 has been lost, the sequence should not be
      considered to contain any out-of-order packets.  Similarly, if
      multiple copies of a packet (duplicates) are delivered, this must








Jayasumana, et al.           Informational                      [Page 5]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


      not result in a packet being classified as out of order, as long
      as one copy arrives in the proper position.  For example, sequence
      (1, 2, 3, 2, 4, 5) has no reordering.  The lost and duplicate
      packet counts may be tracked using metrics specifically intended
      to measure those, e.g., percentage of lost packets, and percentage
      of duplicate packets.

   c) Low Evaluation Complexity

      Memory and time complexities associated with evaluating a metric
      play a vital role in implementation and real-time measurements.
      Spatial/memory complexity corresponds to the amount of buffers
      required for the overall measurement process, whereas
      time/computation complexity refers to the number of computation
      steps involved in computing the amount of reordering in a
      sequence.  On-the-fly evaluation of the metric for large streams
      of packets requires the computational complexity to be O(N), where
      N denotes the number of received packets, used for the reordering
      measure.  This allows the metric to be updated in constant-time as
      each packet arrives.  In the absence of a threshold defining
      losses or the number of sequence numbers to buffer for detection
      of duplicates, the worst-case complexity of loss and duplication
      detection will increase with N.  The rate of increase will depend,
      among other things, on the value of N and the implementation of
      the duplicate detection scheme.

   d) Robustness

      Reorder measurements should be robust against different network
      phenomena and peculiarities in measurement or sequences such as a
      very late arrival of a duplicate packet, or even a rogue packet
      due to an error or sequence number wraparound.  The impact due to
      an event associated with a single or a small number of packets
      should have a sense of proportionality on the reorder measure.
      Consider, for example, the arrival sequence: (1, 5430, 2, 3, 4, 5,
      ...) where packet 5430 appears to be very early; it may be due to
      either sequence rollover in test streams or some unknown reason.

   e) Broad Applicability

      A framework for IP performance metrics [RFC2330] states: "The
      metrics must aid users and providers in understanding the
      performance they experience or provide".

      Rather than being a mere value or a set of values that changes
      with the reordering of packets in a stream, a reorder metric
      should be useful for a variety of purposes.  An application or a
      transport protocol implementation, for example, may be able to use



Jayasumana, et al.           Informational                      [Page 6]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


      the reordering information to allocate resources to recover from
      reordering.  A metric may be useful for TCP flow control, buffer
      resource allocation for recovery from reordering and/or network
      diagnosis.

      The ability to combine the reorder metrics of constituent subnets
      to measure the end-to-end reordering would be an extremely useful
      property.  In the absence of this property, no amount of
      individual network measurements, short of measuring the reordering
      for the pair of endpoints of interest, would be useful in
      predicting the end-to-end reordering.

      The ability to provide different types of information based on
      monitoring or diagnostic needs also broadens the applicability of
      a metric.  Examples of applicable information for reordering may
      include parameters such as the percentage of reordered packets
      that resulted in fast retransmissions in TCP, or the percentage of
      utilization of the reorder recovery buffer.

3.  Reorder Density and Reorder Buffer-Occupancy Density

   In this memo, we define two discrete density functions, Reorder
   Density (RD) and Reorder Buffer-occupancy Density (RBD), that capture
   the nature of reordering in a packet stream.  These two metrics can
   be used individually or collectively to characterize the reordering
   in a packet stream.  Also presented are algorithms for real-time
   evaluation of these metrics for an incoming packet stream.

   RD is defined as the distribution of displacements of packets from
   their original positions, normalized with respect to the number of
   packets.  An early packet corresponds to a negative displacement and
   a late packet to a positive displacement.  A threshold on
   displacement is used to keep the computation within bounds.  The
   choice of threshold value depends on the measurement uses and
   constraints, such as whether duplicate packets are accounted for when
   evaluating these displacements (discussed in Section 5).

   The ability of RD to capture the nature and properties of reordering
   in a comprehensive manner has been demonstrated in [Pi05a], [Pi05b],
   [Pi05c], and [Pi07].  The RD observed at the output port of a subnet
   when the input is an in-order packet stream can be viewed as a
   "reorder response" of a network, a concept somewhat similar to the
   "system response" or "impulse response" used in traditional system
   theory.  For a subnet under stationary conditions, RD is the
   probability density of the packet displacement.  RD measured on
   individual subnets can be combined, using the convolution operation,
   to predict the end-to-end reorder characteristics of the network
   formed by the cascade of subnets under a fairly broad set of



Jayasumana, et al.           Informational                      [Page 7]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   conditions [Pi05b].  RD also shows significant promise as a tool for
   analytical modeling of reordering, as demonstrated with a load-
   balancing scenario in [Pi06].  Use of a threshold to define the
   condition under which a packet is considered lost makes the metric
   robust, efficient, and adaptable for different network and stream
   characteristics.

   RBD is the normalized histogram of the occupancy of a hypothetical
   buffer that would allow the recovery from out-of-order delivery of
   packets.  If an arriving packet is early, it is added to a
   hypothetical buffer until it can be released in order [Ban02].  The
   occupancy of this buffer, after each arrival, is used as the measure
   of reordering.  A threshold, used to declare a packet as lost, keeps
   the complexity of computation within bounds.  The threshold may be
   selected based on application requirements in situations where the
   late arrival of a packet makes it useless, e.g., a real-time
   application.  In [Ban02], this metric was called RD and buffer
   occupancy was known as displacement.

   RD and RBD are simple, yet useful, metrics for measurement and
   evaluation of reordering.  These metrics are robust against many
   peculiarities, such as those discussed previously, and have a
   computational complexity of O(N), where N is the received sequence
   size.  RD is orthogonal to loss and duplication, whereas RBD is
   orthogonal to duplication.

   A detailed comparison of these and other proposed metrics for
   reordering is presented in [Pi07].

   The following terms are used to formally define RD, RBD, and the
   measurement algorithms.  The wraparound of sequence numbers is not
   addressed in this document explicitly, but with the use of modulo-N
   arithmetic, all claims made here remain valid in the presence of
   wraparound.

3.1.  Receive Index (RI)

   Consider a sequence of packets (1, 2, ..., N) transmitted over a
   network.  A receive index RI (1, 2, ...), is a value assigned to a
   packet as it arrives at its destination, according to the order of
   arrival.  A receive index is not assigned to duplicate packets, and
   the receive index value skips the value corresponding to a lost
   packet.  (The detection of loss and duplication for this purpose is
   described in Section 6.)  In the absence of reordering, the sequence
   number of the packet and the receive index are the same for each
   packet.





Jayasumana, et al.           Informational                      [Page 8]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   RI is used to compute earliness and lateness of an arriving packet.
   Below are two examples of received sequences with receive index
   values for a sequence of 5 packets (1, 2, 3, 4, 5) arriving out of
   order:

   Example 1:
   Arrived sequence:    2   1   4   5    3
   receive index:       1   2   3   4    5

   Example 2:
   Arrived sequence:    1   4   3   5    3
   receive index:       1   3   4   5    -

   In Example 1, there is no loss or duplication.  In Example 2, the
   packet with sequence number 2 is lost.  Thus, 2 is not assigned as an
   RI.  Packet 3 is duplicated; thus, the second copy is not assigned an
   RI.

3.2.  Out-of-Order Packet

   When the sequence number of a packet is not equal to the RI assigned
   to it, it is considered to be an out-of-order packet.  Duplicates for
   which an RI is not defined are ignored.

3.3.  Displacement (D)

   Displacement (D) of a packet is defined as the difference between RI
   and the sequence number of the packet, i.e., the displacement of
   packet i is RI[i] - i.  Thus, a negative displacement indicates the
   earliness of a packet and a positive displacement the lateness.  In
   example 3 below, an arrived sequence with displacements of each
   packet is illustrated.

   Example 3:
   Arrived sequence:    1   4   3   5   3   8   7   6
   receive index:       1   3   4   5   -   6   7   8
   Displacement:        0  -1   1   0   -  -2   0   2

3.4.  Displacement Threshold (DT)

   The displacement threshold is a threshold on the displacement of
   packets that allows the metric to classify a packet as lost or
   duplicate.  Determining when to classify a packet as lost is
   difficult because there is no point in time at which a packet can
   definitely be classified as lost; the packet may still arrive after
   some arbitrarily long delay.  However, from a practical point of
   view, a packet may be classified as lost if it has not arrived within
   a certain administratively defined displacement threshold, DT.



Jayasumana, et al.           Informational                      [Page 9]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   Similarly, to identify a duplicate packet, it is theoretically
   necessary to keep track of all the arrived (or missing) packets.
   Again, however, from a practical point of view, missing packets
   within a certain window of sequence numbers suffice.  Thus, DT is
   used as a practical means for declaring a packet as lost or
   duplicated.  DT makes the metric more robust, keeps the computational
   complexity for long sequences within O(N), and keeps storage
   requirements independent of N.

   If the DT selected is too small, reordered packets might be
   classified as lost.  A large DT will increase both the size of memory
   required to keep track of sequence numbers and the length of
   computation time required to evaluate the metric.  Indeed, it is
   possible to use two different thresholds for the two cases.  The
   selection of DT is further discussed in Section 5.

3.5.  Displacement Frequency (FD)

   Displacement Frequency FD[k] is the number of arrived packets having
   a displacement of k, where k takes values from -DT to DT.

3.6.  Reorder Density (RD)

   RD is defined as the distribution of the Displacement Frequencies
   FD[k], normalized with respect to N', where N' is the length of the
   received sequence, ignoring lost and duplicate packets.  N' is equal
   to the sum(FD[k]) for k in [-DT, DT].

3.7.  Expected Packet (E)

   A packet with sequence number E is expected if E is the largest
   number such that all the packets with sequence numbers less than E
   have already arrived or have been determined to be lost.

3.8.  Buffer Occupancy (B)

   An arrived packet with a sequence number greater than that of an
   expected packet is considered to be stored in a hypothetical buffer
   sufficiently long to permit recovery from reordering.  At any packet
   arrival instant, the buffer occupancy is equal to the number of
   out-of-order packets in the buffer, including the newly arrived
   packet.  One buffer location is assumed for each packet, although it
   is possible to extend the concept to the case where the number of
   bytes is used for buffer occupancy.  For example, consider the







Jayasumana, et al.           Informational                     [Page 10]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   sequence of packets (1, 2, 4, 5, 3) with expected order (1, 2, 3, 4,
   5).  When packet 4 arrives, the buffer occupancy is 1 because packet
   4 arrived early.  Similarly, the buffer occupancy becomes 2 when
   packet 5 arrives.  When packet 3 arrives, recovery from reordering
   occurs and the buffer occupancy reduces to zero.

3.9.  Buffer-Occupancy Threshold (BT)

   Buffer-occupancy threshold is a threshold on the maximum size of the
   hypothetical buffer that is used for recovery from reordering.  As
   with the case of DT for RD, BT is used for loss and duplication
   classification for Reorder Buffer-occupancy Density (RBD) computation
   (see Section 3.11).  BT provides robustness and limits the
   computational complexity of RBD.

3.10.  Buffer-Occupancy Frequency (FB)

   At the arrival of each packet, the buffer occupancy may take any
   value, k, ranging from 0 to BT.  The buffer occupancy frequency FB[k]
   is the number of arrival instances after which the occupancy takes
   the value of k.

3.11.  Reorder Buffer-Occupancy Density (RBD)

   Reorder buffer-occupancy density is the buffer occupancy frequencies
   normalized by the total number of non-duplicate packets, i.e.,
   RBD[k] = FB[k]/N' where N' is the length of the received sequence,
   ignoring excessively delayed (deemed lost) and duplicate packets.  N'
   is also the sum(FB[k]) for all k such that k belongs to [0, BT].

4.  Representation of Packet Reordering and Reorder Density

   Consider a sequence of packets (1, 2, ..., N).  Let the RI assigned
   to packet m be "the sequence number m plus an offset dm", i.e.,

            RI = m + dm; D  = dm

   A reorder event of packet m is represented by r(m, dm).  When dm is
   not equal to zero, a reorder event is said to have occurred.  A
   packet is late if dm > 0 and early if dm < 0.  Thus, packet
   reordering of a sequence of packets is completely represented by the
   union of reorder events, R, referred to as the reorder set:

            R = {r(m,dm)| dm not equal to 0 for all m}

   If there is no reordering in a packet sequence, then R is the null
   set.




Jayasumana, et al.           Informational                     [Page 11]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   Examples 4 and 5 illustrate the reorder set:

   Example 4. No losses or duplicates

   Arrived Sequence     1       2       3       5       4       6
   receive index (RI)   1       2       3       4       5       6
   Displacement (D)     0       0       0      -1       1       0
   R = {(4,1), (5,-1)}

   Example 5. Packet 4 is lost and 2 is duplicated

   Arrived Sequence     1       2       5       3       6       2
   receive index (RI)   1       2       3       5       6       -
   Displacement (D)     0       0       -2      2       0       -
   R = {(3, 2), (5, -2)}

   RD is defined as the discrete density of the frequency of packets
   with respect to their displacements, i.e., the lateness and earliness
   from the original position.  Let S[k] denote the set of reorder
   events in R with displacement equal to k.  That is:

            S[k]= {r(m, dm)| dm = k}

   Let |S[k]| be the cardinality of set S[k].  Thus, RD[k] is defined as
   |S[k]| normalized with respect to the total number of received
   packets (N').  Note that N' does not include duplicate or lost
   packets.

            RD[k]  = |S[k]| / N' for k not equal to zero

   RD[0] corresponds to the packets for which RI is the same as the
   sequence number:

            RD[0] = 1 - sum(|S[k]| / N')

   As defined previously, FD[k] is the measure that keeps track of
   |S[k]|.

5.  Selection of DT

   Although assigning a threshold for determining lost and duplicate
   packets might appear to introduce error into the reorder metrics, in
   practice this need not be the case.  Applications, protocols, and the
   network itself operate within finite resource constraints that
   introduce practical limits beyond which the choice of certain values
   becomes irrelevant.  If the operational nature of an application is
   such that a DT can be defined, then using DT in the computation of
   reorder metrics will not invalidate nor limit the effectiveness of



Jayasumana, et al.           Informational                     [Page 12]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   the metrics, i.e., increasing DT does not provide any benefit.  In
   the case of TCP, the maximum transmit and receive window sizes impose
   a natural limit on the useful value of DT.  Sequence number
   wraparound may provide a useful upper bound for DT in some instances.

   If there are no operational constraints imposed by factors as
   described above, or if one is purely interested in a more complete
   picture of reordering, then DT can be made as large as required.  If
   DT is equal to the length of the packet sequence (worst case
   scenario), a complete picture of reordering is seen.  Any metric that
   does not rely on a threshold to declare a packet as lost implicitly
   makes one of two assumptions: a) A missing packet is not considered
   lost until the end of the sequence, or b) the packet is considered
   lost until it arrives.  The former corresponds to the case where DT
   is set to the length of the sequence.  The latter leads to many
   problems related to complexity and robustness.

6.  Detection of Lost and Duplicate Packets

   In RD, a packet is considered lost if it is late beyond DT.
   Non-duplicate arriving packets do not have a copy in the buffer and
   do not have a sequence number less (earlier) than E.  In RBD, a
   packet is considered lost if the buffer is filled to its threshold
   BT.  A packet is considered a duplicate when the sequence number is
   less than the expected packet, or if the sequence number is already
   in the buffer.

   Since RI skips the sequence number of a lost packet, the question
   arises as to how to assign an RI to subsequent packets that arrive
   before it is known that the packet is lost.  This problem arises only
   when reorder metrics are calculated in real-time for an incoming
   sequence, and not with offline computations.  This concern can be
   handled in one of two ways:

   a) Go-back Method:  RD is computed as packets arrive.  When a packet
   is deemed lost, RI values are corrected and displacements are
   recomputed.  The Go-back Method is only invoked when a packet is lost
   and recomputing RD involves at most DT packets.

   b) Stay-back Method:  RD evaluation lags the arriving packets so that
   the correct RI and E values can be assigned to each packet as it
   arrives.  Here, RI is assigned to a packet only once, and the value
   assigned is guaranteed to be correct.  In the worst case, the
   computation lags the arriving packet by DT.  The lag associated with
   the Stay-back Method is incurred only when a packet is missing.






Jayasumana, et al.           Informational                     [Page 13]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   Another issue related to a metric and its implementation is the
   robustness against peculiarities that may occur in a sequence as
   discussed in Section 2.  Consider, for example, the arrival sequence
   (1, 5430, 2, 3, 4, 5, ...).  With RD, a sense of proportionality is
   easily maintained using the concept of threshold (DT), which limits
   the effects a rogue packet can have on the measurement results.  In
   this example, when the displacement is greater than DT, rogue packet
   5430 is discarded.  In this way the impact due to the rogue packet is
   limited, at most, to DT packets, thus imposing a limit on the amount
   of error it can cause in the results.  Note also that a threshold
   different from DT can be used for the same purpose.  For example, a
   pre-specified threshold that limits the time a packet remains in the
   buffer can make RBD robust against rogue packets.

7.  Algorithms to Evaluate RD and RBD

   The algorithms to compute RD and RBD are given below.  These
   algorithms are applicable for online computation of an incoming
   packet stream and provide an up-to-date metric for the packet stream
   read so far.  For simplicity, the sequence numbers are considered to
   start from 1 and continue in increments of 1.  Only the Stay-back
   Method of loss detection is presented here; hence, the RD values lag
   by a maximum of DT.  The algorithm for the Go-back Method is given in
   [Bar04].  Perl scripts for these algorithms are posted in [Per04].

7.1.  Algorithm for RD

   Variables used:
   -------------------------------------------------------------------
    RI: receive index.
    S: Arrival under consideration for lateness/earliness computation.
    D: Lateness or earliness of the packet being processed: dm for m.
    FD[-DT..DT]: Frequency of lateness and earliness.
    window[1..DT+1]: List of incoming sequence numbers; FIFO buffer.
    buffer[1..DT]: Array to hold sequence numbers of early arrivals.
    window[] and buffer[] are empty at the beginning.
   ===================================================================

   Step 1. Initialize:

      Store first unique DT+1 sequence numbers in arriving order into
      window; RI = 1;

   Step 2. Repeat (until window is empty):

      If (window or buffer contains sequence number RI)
      {
         Move sequence number out of window to S # window is FIFO



Jayasumana, et al.           Informational                     [Page 14]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


         D = RI - S; # compute displacement

         If (absolute(D) <= DT) # Apply threshold
         {
            FD[D]++; # Update frequency

            If (buffer contains sequence number RI)
               Delete RI from buffer;

            If (D < 0) # Early Arrival
               add S to empty slot in buffer;
            RI++; # Update RI value
         }

         Else # Displacement beyond threshold.
         {
            Discard S;
            # Note, an early arrival in window is moved to buffer if
            # its displacement is less or equal to DT.  Therefore, the
            # contents in buffer will have only possible RIs.  Thus,
            # clearing an RI as it is consumed prevents memory leaks
            # in buffer
         }
         # Get next incoming non-duplicate sequence number, if any.
         newS = get_next_arrival(); # subroutine called*
         if (newS != null)
         {
              add newS to window;
         }
         if (window is empty) go to step 3;
      }
      Else # RI not found.  Get next RI value.
      {
         # Next RI is the minimum among window and buffer contents.
         m = minimum (minimum (window), minimum (buffer));
         If (RI < m)
            RI = m;
         Else
            RI++;
      }

   Step 3. Normalize FD to get RD;

   # Get a new sequence number from packet stream, if any
   subroutine get_next_arrival()
   {
        do   # get non-duplicate next arrival
        {



Jayasumana, et al.           Informational                     [Page 15]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


              newS = new sequence from arriving stream;
              if (newS == null) # End of packet stream
                 return null;
        } while (newS < RI or newS in buffer or newS in window);

        return newS;
   }

7.2.  Algorithm for RBD

   Variables used:
   ---------------------------------------------------------------------
   # E : Next expected sequence number.
   # S : Sequence number of the packet just arrived.
   # B : Current buffer occupancy.
   # BT: Buffer Occupancy threshold.
   # FB[i]: Frequency of buffer occupancy i  (0 <= i <= BT).
   # in_buffer(N) : True if the packet with sequence number N is
     already stored in the buffer.
   =====================================================================

   1.  Initialize E = 1, B = 0 and FB[i] = 0 for all values of i.

   2.  Do the following for each arrived packet.

          If (in_buffer(S) || S < E) /*Do nothing*/;
          /* Case a: S is a duplicate or excessively delayed packet.
          Discard the packet.*/
          Else
          {

             If (S == E)
             /* Case b: Expected packet has arrived.*/
             {
                E = E + 1;
                While (in_buffer(E))
                {
                   B = B - 1; /* Free buffer occupied by E.*/
                   E = E + 1; /* Expect next packet.*/
                }
                FB[B] = FB[B] + 1; /*Update frequency for buffer
                occupancy B.*/
             } /* End of If (S == E)*/

             ElseIf (S > E)
             /* Case c: Arrived packet has a sequence number higher
                than expected.*/
             {



Jayasumana, et al.           Informational                     [Page 16]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


                If (B < BT)
                /* Store the arrived packet in a buffer.*/
                   B = B + 1;
                Else
                /* Expected packet is delayed beyond the BT.
                Treat it as lost.*/
                {
                   Repeat
                   {
                      E = E + 1;
                   }
                   Until (in_buffer(E) || E == S);

                   While (in_buffer(E) || E == S)
                   {
                      if (E != S) B = B - 1;
                      E = E + 1;
                   }
                 }
                 FB[B] = FB[B] + 1; /*Update frequency for buffer
                 occupancy B.*/
             } /* End of ElseIf (S > E)*/

          }

   3. Normalize FB[i] to obtain RBD[i], for all values of i using

                            FB[i]
      RBD[i] = ----------------------------------
                  Sum(FB[j] for 0 <= j <= BT)

8.  Examples

   a. Scenario with no packet loss

   Consider the sequence of packets (1, 4, 2, 5, 3, 6, 7, 8) with DT =
   BT = 4.

   Tables 1 and 2 show the computational steps when the RD algorithm is
   applied to the above sequence.











Jayasumana, et al.           Informational                     [Page 17]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   ------------------------------------------------------
   Table 1: Late/Early-packet Frequency computation steps
   ------------------------------------------------------
   S         1     4     2     5     3     6   7    8
   RI        1     2     3     4     5     6   7    8
   D         0    -2     1    -1     2     0   0    0
   FD[D]     1     1     1     1     1     2   3    4
   ------------------------------------------------------
   (S, RI,D and FD[D] as described in Section 7.1)
   ------------------------------------------------------

   The last row (FD[D]) represents the current frequency of occurrence
   of the displacement D, e.g., column 3 indicates FD[1] = 1 while
   column 4 indicates FD[-1] = 1.  The final set of values for RD are
   shown in Table 2.

   -------------------------------------------------
   Table 2: Reorder Density (RD)
   -------------------------------------------------
     D       -2       -1      0     1       2
   FD[D]      1        1      4     1       1
   RD[D]     0.125   0.125   0.5   0.125   0.125
   -------------------------------------------------
   (D,FD[D] and RD[D] as described in Section 7.1)
   -------------------------------------------------

   Tables 3 and 4 illustrate the computational steps for RBD for the
   same example.

   ------------------------------------------------------------
   Table 3: Buffer occupancy frequencies (FB) computation steps
   ------------------------------------------------------------
   S         1     4     2     5     3     6     7     8
   E         1     2     2     3     3     6     7     8
   B         0     1     1     2     0     0     0     0
   FB[B]     1     1     2     1     2     3     4     5
   ------------------------------------------------------------
   (E,S,B and FB[B] as described in Section 7.2)
   ------------------------------------------------------------












Jayasumana, et al.           Informational                     [Page 18]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   ------------------------------------------------------------
   Table 4: Reorder Buffer-occupancy Density
   ------------------------------------------------------------
   B           0        1     2
   FB[B]       5        2     1
   RBD[B]     0.625   0.25  0.125
   ------------------------------------------------------------
   (B,FB[B] and RBD[B] as discussed in Section 7.2)
   ------------------------------------------------------------

   Graphical representations of the densities are as follows:


                ^                            ^
                |                            |
                |                            _
    ^       0.5 _                   ^ 0.625 | |
    |          | |                  |       | |
               | |                          | |
   RD[D]       | |                RBD[B]    | | - o.25
          _  _ | | _  _ 0.125               | || | - 0.125
         | || || || || |                    | || || |
        --+--+--+--+--+--+-->             ---+--+--+--
         -2 -1  0  1  2                      0  1  2
                D  -->                        B -->

   b. Scenario with packet loss

   Consider a sequence of 6 packets (1, 2, 4, 5, 6, 7) with DT = BT = 3.
   Table 5 shows the computational steps when the RD algorithm is
   applied to the above sequence to obtain FD[D].

   ------------------------------------------------------
   Table 5: Late/Early-packet Frequency computation steps
   ------------------------------------------------------
   S         1     2     4     5     6     7
   RI        1     2     4     5     6     7
   D         0     0     0     0     0     0
   FD[D]     1     2     3     4     5     6
   ------------------------------------------------------
   (S,RI,D and FD[D] as described in Section 7.1)
   ------------------------------------------------------









Jayasumana, et al.           Informational                     [Page 19]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   Table 6 illustrates the FB[B] for the above arrival sequence.

   -------------------------------------------------
   Table 6: Buffer occupancy computation steps
   -------------------------------------------------
   S        1     2     4     5     6     7
   E        1     2     3     3     3     7
   B        0     0     1     2     3     0
   FB[B]    1     2     1     1     1     3
   -------------------------------------------------
   (E,S,B and FB[B] as described in Section 7.2)
   -------------------------------------------------

   Graphical representations of RD and RBD for the above sequence are as
   follows.

                ^                        ^
                |                        |
          1.0   _                        |
      ^        | |                ^      |
      |        | |                | 0.5  _
               | |                      | |
    RD[D]      | |               RBD[B] | | _  _  _ 0.167
               | |                      | || || || |
           --+--+--+-->                --+--+--+--+-->
            -1  0  1                     0  1  2  3
                D  -->                      B -->

   c. Scenario with duplicate packets

   Consider a sequence of 6 packets (1, 3, 2, 3, 4, 5) with DT = 2.
   Table 7 shows the computational steps when the RD algorithm is
   applied to the above sequence to obtain FD[D].

   ------------------------------------------------------
   Table 7: Late/Early-packet Frequency computation steps
   ------------------------------------------------------
   S         1     3     2     3     4     5
   RI        1     2     3     -     4     5
   D         0    -1     1     -     0     0
   FD[D]     1     1     1     -     2     3
   ------------------------------------------------------
   (S, RI,D and FD[D] as described in Section 7.1)
   ------------------------------------------------------







Jayasumana, et al.           Informational                     [Page 20]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   Table 8 illustrates the FB[B] for the above arrival sequence.

   ------------------------------------------------------
   Table 8: Buffer Occupancy Frequency computation steps
   ------------------------------------------------------
   S     1     3     2     3     4     5
   E     1     2     2     -     4     5
   B     0     1     0     -     0     0
   FB[B] 1     1     2     -     3     4
   ------------------------------------------------------
   (E,S,B and FB[B] as described in Section 7.2)
   ------------------------------------------------------

   Graphical representations of RD and RBD for the above sequence are as
   follows:


                 ^                            ^
                 |                            |
     ^           |                   ^   0.8  _
     |       0.6 _                   |       | |
                | |                          | |
    RD[D]       | |                RBD[B]    | |
          0.2 _ | | _ 0.2                    | | _ 0.2
             | || || |                       | || |
         --+--+--+--+--+--+-->             ---+--+--+--
          -2 -1  0  1  2                      0  1  2
                 D  -->                        B -->

9.  Characteristics Derivable from RD and RBD

   Additional information may be extracted from RD and RBD depending on
   the specific applications.  For example, in the case of resource
   allocation at a node to recover from reordering, the mean and
   variance of buffer occupancy can be derived from RBD.  For example:

   Mean occupancy of recovery buffer =  sum(i*RBD[i] for 0 <= i <= BT)

   The basic definition of RBD may be modified to count the buffer
   occupancy in bytes as opposed to packets when the actual buffer space
   is more important.  Another alternative is to use time to update the
   buffer occupancy compared to updating it at every arrival instant.

   The parameters that can be extracted from RD include the percentage
   of late (or early) packets, mean displacement of packets, and mean
   displacement of late (or early) packets [Ye06].  For example, the
   fraction of packets that arrive after three or more of their
   successors according to the order of transmission is given by Sum



Jayasumana, et al.           Informational                     [Page 21]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   [RD[i] for 3<=i<=DT].  RD also allows for extraction of parameters
   such as entropy of the reordered sequence, a measure of disorder in
   the sequence [Ye06].  Due to the probability mass function nature of
   RD, it is also a convenient measure for theoretical modeling and
   analysis of reordering, e.g., see [Pi06].

10.  Comparison with Other Metrics

   RD and RBD are compared to other metrics of [RFC4737] in [Pi07].

11.  Security Considerations

   The security considerations listed in [RFC4737], [RFC3763], and
   [RFC4656] are extensive and directly applicable to the usage of these
   metrics; thus, they should be consulted for additional details.

12.  References

12.1.  Normative References


   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330, May
              1998.

   [Pi07]     N. M. Piratla and A. P. Jayasumana, "Metrics for Packet
              Reordering - A Comparative Analysis," International
              Journal of Communication Systems (IJCS), Vol. 21/1, 2008,
              pp: 99-113.

12.2.  Informative References


   [Ben99]    J. C. R. Bennett, C. Partridge and N. Shectman, "Packet
              Reordering is Not Pathological Network Behavior," IEEE/ACM
              Trans. on Networking , Dec. 1999, pp.789-798.

   [Jai03]    S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose and D.
              Towsley, "Measurement and Classification of Out-of-
              sequence Packets in Tier-1 IP Backbone," Proc. IEEE
              INFOCOM, Mar.  2003, pp. 1199-1209.

   [Pax97]    V.Paxson, "Measurements and Analysis of End-to-End
              Internet Dynamics," Ph.D. Dissertation, U.C. Berkeley,
              1997, ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz.






Jayasumana, et al.           Informational                     [Page 22]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   [Boh03]    S. Bohacek, J. Hespanha, J. Lee, C. Lim and K.Obraczka,
              "TCP-PR: TCP for Persistent Packet Reordering," Proc. of
              the IEEE 23rdICDCS, May 2003, pp.222-231.

   [Bla02]    E. Blanton and M. Allman, "On Making TCP More Robust to
              Packet Reordering," ACM Computer Comm. Review, 32(1), Jan.
              2002, pp.20-30.

   [Lao02]    M. Laor and L. Gendel, "The Effect of Packet Reordering in
              a Backbone Link on Application Throughput," IEEE Network,
              Sep./Oct. 2002, pp.28-36.

   [Bar04]    A. A. Bare, "Measurement and Analysis of Packet Reordering
              Using Reorder Density," Masters Thesis, Department of
              Computer Science, Colorado State University, Fort Collins,
              Colorado, Fall 2004.

   [Ban02]    T. Banka, A. A. Bare, A. P. Jayasumana, "Metrics for
              Degree of Reordering in Packet Sequences", Proc. 27th IEEE
              Conference on Local Computer Networks, Tampa, FL, Nov.
              2002, pp. 332-342.

   [Pi05a]    N. M. Piratla, "A Theoretical Foundation, Metrics and
              Modeling of Packet Reordering and Methodology of Delay
              Modeling using Inter-packet Gaps," Ph.D. Dissertation,
              Department of Electrical and Computer Engineering,
              Colorado State University, Fort Collins, CO, Fall 2005.

   [Pi05b]    N. M. Piratla, A. P. Jayasumana and A. A. Bare, "RD: A
              Formal, Comprehensive Metric for Packet Reordering," Proc.
              5th International IFIP-TC6 Networking Conference
              (Networking 2005), Waterloo, Canada, May 2-6, 2005, LNCS
              3462, pp: 78-89.

   [Pi06]     N. M. Piratla and A. P. Jayasumana, "Reordering of Packets
              due to Multipath Forwarding - An Analysis," Proc. IEE
              Intl.  Conf. Communications ICC 2006, Istanbul, Turkey,
              Jun. 2006, pp:829-834.

   [Per04]    Perl Scripts for RLED and RBD,
              http://www.cnrl.colostate.edu/packet_reorder.html, Last
              modified on Jul. 18, 2004.

   [Ye06]     B. Ye, A. P. Jayasumana and N. Piratla, "On Monitoring of
              End-to-End Packet Reordering over the Internet," Proc.
              Int.  Conf. on Networking and Services (ICNS'06), Santa
              Clara, CA, July 2006.




Jayasumana, et al.           Informational                     [Page 23]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


   [RFC4737]  Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
              S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
              November 2006.

   [RFC3763]  Shalunov, S. and B. Teitelbaum, "One-way Active
              Measurement Protocol (OWAMP) Requirements", RFC 3763,
              April 2004.

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", RFC 4656, September 2006.

   [Pi05c]    N. M. Piratla, A. P. Jayasumana and T. Banka, "On Reorder
              Density and its Application to Characterization of Packet
              Reordering," Proc. 30th IEEE Local Computer Networks
              Conference (LCN 2005), Sydney, Australia, Nov. 2005,
              pp:156-165.

13.  Contributors

   Jerry McCollom
   Hewlett Packard, 3404 East Harmony Road
   Fort Collins, CO 80528, USA

   EMail: jerry_mccollom@hp.com


























Jayasumana, et al.           Informational                     [Page 24]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


Authors' Addresses

   Anura P. Jayasumana
   Computer Networking Research Laboratory
   Department of Electrical and Computer Engineering
   1373 Colorado State University,
   Fort Collins, CO 80523, USA

   EMail: Anura.Jayasumana@colostate.edu


   Nischal M. Piratla
   Deutsche Telekom Laboratories
   Ernst-Reuter-Platz 7
   D-10587 Berlin, Germany

   EMail: Nischal.Piratla@telekom.de


   Tarun Banka
   Computer Networking Research Laboratory
   Department of Electrical and Computer Engineering
   1373 Colorado State University
   Fort Collins, CO 80523, USA

   EMail: Tarun.Banka@colostate.edu


   Abhijit A. Bare
   Agilent Technologies, Inc.
   900 South Taft Ave.
   Loveland, CO 80537, USA

   EMail: abhijit_bare@agilent.com


   Rick Whitner
   Agilent Technologies, Inc.
   900 South Taft Ave.
   Loveland, CO 80537, USA

   EMail: rick_whitner@agilent.com









Jayasumana, et al.           Informational                     [Page 25]
^L
RFC 5236           Improved Packet Reordering Metrics          June 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78 and at http://www.rfc-editor.org/copyright.html,
   and except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.












Jayasumana, et al.           Informational                     [Page 26]
^L