draft-ietf-ippm-reordering-09.txt | draft-ietf-ippm-reordering-10.txt | |||
---|---|---|---|---|
Network Working Group A.Morton | Network Working Group A.Morton | |||
Internet Draft L.Ciavattone | Internet Draft L.Ciavattone | |||
Document: <draft-ietf-ippm-reordering-09.txt> G.Ramachandran | Document: <draft-ietf-ippm-reordering-10.txt> G.Ramachandran | |||
Category: Standards Track AT&T Labs | Category: Standards Track AT&T Labs | |||
S.Shalunov | S.Shalunov | |||
Internet2 | Internet2 | |||
J.Perser | J.Perser | |||
Consultant | Consultant | |||
Packet Reordering Metric for IPPM | Packet Reordering Metric for IPPM | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | ||||
applicable patent or other IPR claims of which he or she is aware | ||||
have been or will be disclosed, and any of which he or she becomes | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
This document is an Internet-Draft and is subject to all provisions | This document is an Internet-Draft and is subject to all provisions | |||
of section 3 of RFC 3667. By submitting this Internet-Draft, each | of section 3 of BCP 78. | |||
author represents that any applicable patent or other IPR claims of | ||||
which he or she is aware have been disclosed, and any of which he or | ||||
she becomes aware will be disclosed, in accordance with RFC 3668. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
at any time. It is inappropriate to use Internet-Drafts as | at any time. It is inappropriate to use Internet-Drafts as | |||
reference material or to cite them other than as "work in progress." | reference material or to cite them other than as "work in progress." | |||
skipping to change at line 71 | skipping to change at line 73 | |||
Abstract...........................................................1 | Abstract...........................................................1 | |||
1. Conventions used in this document...............................3 | 1. Conventions used in this document...............................3 | |||
2. Introduction....................................................3 | 2. Introduction....................................................3 | |||
2.1 Motivation.....................................................4 | 2.1 Motivation.....................................................4 | |||
2.2 Goals and Objectives...........................................5 | 2.2 Goals and Objectives...........................................5 | |||
3. A Reordered Packet Singleton Metric.............................6 | 3. A Reordered Packet Singleton Metric.............................6 | |||
3.1 Metric Name:...................................................7 | 3.1 Metric Name:...................................................7 | |||
3.2 Metric Parameters:.............................................7 | 3.2 Metric Parameters:.............................................7 | |||
3.3 Definition:....................................................7 | 3.3 Definition:....................................................7 | |||
3.4 Sequence Discontinuity Definition..............................8 | 3.4 Sequence Discontinuity Definition..............................8 | |||
3.5 Evaluation of Reordering in Dimensions of Time or Bytes........8 | 3.5 Evaluation of Reordering in Dimensions of Time or Bytes........9 | |||
3.6 Discussion.....................................................9 | 3.6 Discussion.....................................................9 | |||
4. Sample Metrics..................................................9 | 4. Sample Metrics.................................................10 | |||
4.1 Reordered Packet Ratio........................................10 | 4.1 Reordered Packet Ratio........................................10 | |||
4.1.1 Metric Name:................................................10 | 4.1.1 Metric Name:................................................10 | |||
4.1.2 Metric Parameters:..........................................10 | 4.1.2 Metric Parameters:..........................................10 | |||
4.1.3 Definition:.................................................10 | 4.1.3 Definition:.................................................10 | |||
4.1.4 Discussion..................................................10 | 4.1.4 Discussion..................................................11 | |||
4.2 Reordering Extent.............................................11 | 4.2 Reordering Extent.............................................11 | |||
4.2.1 Metric Name:................................................11 | 4.2.1 Metric Name:................................................11 | |||
4.2.2 Parameter Notation:.........................................11 | 4.2.2 Parameter Notation:.........................................11 | |||
4.2.3 Definition:.................................................11 | 4.2.3 Definition:.................................................12 | |||
4.2.4 Discussion:.................................................12 | 4.2.4 Discussion:.................................................12 | |||
4.3 Reordering Late Time Offset...................................12 | 4.3 Reordering Late Time Offset...................................13 | |||
4.3.1 Metric Name:................................................12 | 4.3.1 Metric Name:................................................13 | |||
4.3.2 Metric Parameters:..........................................13 | 4.3.2 Metric Parameters:..........................................13 | |||
4.3.3 Definition:.................................................13 | 4.3.3 Definition:.................................................13 | |||
4.3.4 Discussion..................................................13 | 4.3.4 Discussion..................................................13 | |||
4.4 Reordering Byte Offset........................................14 | 4.4 Reordering Byte Offset........................................14 | |||
4.4.1 Metric Name:................................................14 | 4.4.1 Metric Name:................................................14 | |||
4.4.2 Metric Parameters:..........................................14 | 4.4.2 Metric Parameters:..........................................14 | |||
4.4.3 Definition:.................................................14 | 4.4.3 Definition:.................................................14 | |||
4.4.4 Discussion..................................................14 | 4.4.4 Discussion..................................................15 | |||
4.5 Gaps between multiple Reordering Discontinuities..............15 | 4.5 Gaps between multiple Reordering Discontinuities..............15 | |||
4.5.1 Metric Name:................................................15 | 4.5.1 Metric Name:................................................15 | |||
4.5.2 Parameters:.................................................15 | 4.5.2 Parameters:.................................................15 | |||
4.5.3 Definition of Reordering Discontinuity:.....................15 | 4.5.3 Definition of Reordering Discontinuity:.....................16 | |||
4.5.4 Definition of Reordering Gap:...............................15 | 4.5.4 Definition of Reordering Gap:...............................16 | |||
4.5.5 Discussion..................................................16 | 4.5.5 Discussion..................................................16 | |||
4.6 Reordering-free Runs..........................................16 | 4.6 Reordering-free Runs..........................................17 | |||
4.6.1 Metric Name:................................................16 | 4.6.1 Metric Name:................................................17 | |||
4.6.2 Parameters:.................................................17 | 4.6.2 Parameters:.................................................17 | |||
4.6.3 Definition:.................................................17 | 4.6.3 Definition:.................................................17 | |||
4.6.4 Discussion:.................................................18 | 4.6.4 Discussion:.................................................18 | |||
5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric..18 | 5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric..19 | |||
5.1 Metric Name:..................................................18 | 5.1 Metric Name:..................................................19 | |||
5.2 Parameter Notation:...........................................19 | 5.2 Parameter Notation:...........................................19 | |||
5.3 Definitions...................................................19 | 5.3 Definitions...................................................19 | |||
5.4 Discussion:...................................................19 | 5.4 Discussion:...................................................20 | |||
6. Measurement and Implementation Issues..........................20 | 6. Measurement and Implementation Issues..........................21 | |||
7. Examples of Arrival Order Evaluation...........................24 | 7. Examples of Arrival Order Evaluation...........................24 | |||
7.1 Example with a single packet reordered........................24 | 7.1 Example with a single packet reordered........................24 | |||
7.2 Example with two packets reordered............................25 | 7.2 Example with two packets reordered............................25 | |||
7.3 Example with three packets reordered..........................27 | 7.3 Example with three packets reordered..........................27 | |||
7.4 Example with Multiple Packet Reordering Discontinuities.......28 | 7.4 Example with Multiple Packet Reordering Discontinuities.......28 | |||
8. Security Considerations........................................28 | 8. Security Considerations........................................28 | |||
8.1 Denial of Service Attacks.....................................28 | 8.1 Denial of Service Attacks.....................................28 | |||
8.2 User data confidentiality.....................................29 | 8.2 User data confidentiality.....................................29 | |||
8.3 Interference with the metric..................................29 | 8.3 Interference with the metric..................................29 | |||
9. IANA Considerations............................................29 | 9. IANA Considerations............................................29 | |||
skipping to change at line 240 | skipping to change at line 242 | |||
2.2 Goals and Objectives | 2.2 Goals and Objectives | |||
The definitions below intend to satisfy the goals of: | The definitions below intend to satisfy the goals of: | |||
1. Determining whether or not packet reordering has occurred. | 1. Determining whether or not packet reordering has occurred. | |||
2. Quantifying the degree of reordering. (We define a number of | 2. Quantifying the degree of reordering. (We define a number of | |||
metrics to meet this goal, because receiving procedures differ | metrics to meet this goal, because receiving procedures differ | |||
by protocol or application. Since the affects of packet | by protocol or application. Since the affects of packet | |||
reordering vary with these procedures, a metric that quantifies | reordering vary with these procedures, a metric that quantifies | |||
a key aspect of one receiver's behavior could be irrelevant to | a key aspect of one receiver's behavior could be irrelevant to | |||
a different receiver.) | a different receiver. If all the metrics defined below are | |||
reported, they give a wide-ranging view of reordering | ||||
conditions.) | ||||
Reordering Metrics MUST: | Reordering Metrics MUST: | |||
+ have one or more applications, such as receiver design or network | + have one or more applications, such as receiver design or network | |||
characterization, and a compelling relevance in the working | characterization, and a compelling relevance in the working | |||
group's view. | group's view. | |||
+ be computable "on the fly" | + be computable "on the fly" | |||
+ work even if the stream has duplicate or lost packets | + work even if the stream has duplicate or lost packets | |||
It is desirable for Reordering Metrics to have one or more of the | It is desirable for Reordering Metrics to have one or more of the | |||
skipping to change at line 335 | skipping to change at line 340 | |||
+ Dst, the IP address of a host | + Dst, the IP address of a host | |||
+ SrcTime, the time of packet emission from the Source (or wire | + SrcTime, the time of packet emission from the Source (or wire | |||
time) | time) | |||
+ s, the unique packet sequence number applied at the Source, in | + s, the unique packet sequence number applied at the Source, in | |||
units of messages. | units of messages. | |||
+ NextExp, the Next Expected Sequence number at the Destination, in | + NextExp, the Next Expected Sequence number at the Destination, in | |||
units of messages. | units of messages. The stored value in NextExp is determined from | |||
a previously arriving packet. | ||||
And optionally: | And optionally: | |||
+ PayloadSize, the number of bytes contained in the information | + PayloadSize, the number of bytes contained in the information | |||
field and referred to when the SrcByte sequence is based on bytes | field and referred to when the SrcByte sequence is based on bytes | |||
transfered. | transfered. | |||
+ SrcByte, the packet sequence number applied at the Source, in | + SrcByte, the packet sequence number applied at the Source, in | |||
units of payload bytes. | units of payload bytes. | |||
skipping to change at line 357 | skipping to change at line 363 | |||
If a packet s, (sent at time, SrcTime) is found to be reordered by | If a packet s, (sent at time, SrcTime) is found to be reordered by | |||
comparison with the Next Expected value, its Type-P-Reordered = | comparison with the Next Expected value, its Type-P-Reordered = | |||
TRUE; otherwise Type-P-Reordered = FALSE, as defined below: | TRUE; otherwise Type-P-Reordered = FALSE, as defined below: | |||
The value of Type-P-Reordered is defined as TRUE if s < NextExp (the | The value of Type-P-Reordered is defined as TRUE if s < NextExp (the | |||
packet is reordered). In this case, the NextExp value does not | packet is reordered). In this case, the NextExp value does not | |||
change. | change. | |||
The value of Type-P-Reordered is defined as FALSE if s >= NextExp | The value of Type-P-Reordered is defined as FALSE if s >= NextExp | |||
(the packet is in-order). In this case, NextExp is set to s+1. | (the packet is in-order). In this case, NextExp is set to s+1 for | |||
comparison with the next packet to arrive. | ||||
Since the Next Expected value cannot decrease, it provides a non- | Since the Next Expected value cannot decrease, it provides a non- | |||
reversing order criterion to identify reordered packets. | reversing order criterion to identify reordered packets. | |||
This definition can also be specified in pseudo-code. | This definition can also be specified in pseudo-code. | |||
On successful arrival of a packet with sequence number s: | On successful arrival of a packet with sequence number s: | |||
if s >= NextExp then /* s is in-order */ | if s >= NextExp then /* s is in-order */ | |||
NextExp = s + 1; | NextExp = s + 1; | |||
Type-P-Reordered = False; | Type-P-Reordered = False; | |||
skipping to change at line 573 | skipping to change at line 579 | |||
packets, from a reordered packet to the earliest packet received | packets, from a reordered packet to the earliest packet received | |||
that has a larger sequence number. If a packet is in-order, its | that has a larger sequence number. If a packet is in-order, its | |||
reordering extent is undefined. The first packet to arrive is in- | reordering extent is undefined. The first packet to arrive is in- | |||
order by definition, and has undefined reordering extent. | order by definition, and has undefined reordering extent. | |||
Comment on the definition of extent: For some arrival orders, the | Comment on the definition of extent: For some arrival orders, the | |||
assignment of a simple position/distance as the reordering extent | assignment of a simple position/distance as the reordering extent | |||
tends to overestimate the receiver storage needed to restore order. | tends to overestimate the receiver storage needed to restore order. | |||
A more accurate and complex procedure to calculate packet storage | A more accurate and complex procedure to calculate packet storage | |||
would be to subtract any earlier reordered packets that the receiver | would be to subtract any earlier reordered packets that the receiver | |||
could pass on to the upper layers. With the bias understood, this | could pass on to the upper layers (see the Byte Offset metric). With | |||
definition is deemed sufficient, especially for those who demand "on | the bias understood, this definition is deemed sufficient, | |||
the fly" calculations. | especially for those who demand "on the fly" calculations. | |||
4.2.4 Discussion: | 4.2.4 Discussion: | |||
The packet with index j (s[j], identified in the Definition above) | The packet with index j (s[j], identified in the Definition above) | |||
is the reordering discontinuity associated with packet s at index i | is the reordering discontinuity associated with packet s at index i | |||
(s[i]). This definition is formalized below. | (s[i]). This definition is formalized below. | |||
Note that the K packets in the stream could be some subset of a | Note that the K packets in the stream could be some subset of a | |||
larger stream, but L is still the total number of packets received | larger stream, but L is still the total number of packets received | |||
out of the K packets sent in that subset. | out of the K packets sent in that subset. | |||
If a receiver intends to restore order, then its buffer capacity | If a receiver intends to restore order, then its buffer capacity | |||
determines its ability to handle packets that are reordered. For | determines its ability to handle packets that are reordered. For | |||
cases with single reordered packets, the extent e gives the number | cases with single reordered packets, the extent e gives the number | |||
of packets that must be held in the receiver's buffer while waiting | of packets that must be held in the receiver's buffer while waiting | |||
for the reordered packet to complete the sequence. For more complex | for the reordered packet to complete the sequence. For more complex | |||
scenarios, the extent may be an overestimate of required storage | scenarios, the extent may be an overestimate of required storage | |||
(see the Examples section). | (see section 4.4 on Reordering Byte Offset and the Examples | |||
section). | ||||
Knowledge of the reordering extent, e, is particularly useful for | Although reordering extent primarily quantifies the offset in terms | |||
determining the portion of reordered packets that can or cannot be | of arrival position, it may also be useful for determining the | |||
restored to order in a typical receiver buffer based on their | portion of reordered packets that can or cannot be restored to order | |||
arrival order alone (and without the aid of retransmission). | in a typical receiver buffer based on their arrival order alone (and | |||
without the aid of retransmission). | ||||
A sample's reordering extents may be expressed as a histogram, to | A sample's reordering extents may be expressed as a histogram, to | |||
easily summarize the frequency of various extents. | easily summarize the frequency of various extents. | |||
4.3 Reordering Late Time Offset | 4.3 Reordering Late Time Offset | |||
Reordered packets can be assigned offset values indicating their | Reordered packets can be assigned offset values indicating their | |||
lateness in terms of buffer time that a receiver must possess to | lateness in terms of buffer time that a receiver must possess to | |||
accommodate them. Offset metrics are calculated only on reordered | accommodate them. Offset metrics are calculated only on reordered | |||
packets, as identified by the reordered packet singleton metric in | packets, as identified by the reordered packet singleton metric in | |||
skipping to change at line 674 | skipping to change at line 682 | |||
metric. If presented with the arrival sequence 1, 10, 5 (where | metric. If presented with the arrival sequence 1, 10, 5 (where | |||
packets 2, 3, 4, and 6 through 9 are lost), LateTime would not | packets 2, 3, 4, and 6 through 9 are lost), LateTime would not | |||
indicate exactly how "late" packet 5 is from its intended arrival | indicate exactly how "late" packet 5 is from its intended arrival | |||
position. IPDV [RFC3393] would not capture this either, because of | position. IPDV [RFC3393] would not capture this either, because of | |||
the lack of adjacent packet pairs. Assuming a Periodic Stream | the lack of adjacent packet pairs. Assuming a Periodic Stream | |||
[RFC3432], an expected arrival time could be defined for all | [RFC3432], an expected arrival time could be defined for all | |||
packets, but this is essentially a single-point delay variation | packets, but this is essentially a single-point delay variation | |||
metric (as defined in ITU-T Recommendations [I.356] and [Y.1540]), | metric (as defined in ITU-T Recommendations [I.356] and [Y.1540]), | |||
and not a reordering metric. | and not a reordering metric. | |||
A sample's LateTime results may be expressed as a histogram, to | ||||
summarize the frequency of buffer times needed to accommodate | ||||
reordered packets and permit buffer tuning on that basis. A CDF with | ||||
buffer time vs. percent of reordered packets accommodated may be | ||||
informative. | ||||
4.4 Reordering Byte Offset | 4.4 Reordering Byte Offset | |||
Reordered packets can be assigned offset values indicating the | Reordered packets can be assigned offset values indicating the | |||
storage in bytes that a receiver must possess to accommodate them. | storage in bytes that a receiver must possess to accommodate them. | |||
The various offset metrics are calculated only on reordered packets, | Offset metrics are calculated only on reordered packets, as | |||
as identified by the reordered packet singleton metric in Section 3. | identified by the reordered packet singleton metric in Section 3. | |||
4.4.1 Metric Name: | 4.4.1 Metric Name: | |||
Type-P-packet-Byte-Offset-Stream | Type-P-packet-Byte-Offset-Stream | |||
4.4.2 Metric Parameters: | 4.4.2 Metric Parameters: | |||
We use the same parameters defined earlier, including the optional | We use the same parameters defined earlier, including the optional | |||
parameters of SrcByte and PayloadSize, and define: | parameters of SrcByte and PayloadSize, and define: | |||
skipping to change at line 728 | skipping to change at line 743 | |||
packets and their size, especially when packet size is variable. In | packets and their size, especially when packet size is variable. In | |||
these and other circumstances, it may be most useful to characterize | these and other circumstances, it may be most useful to characterize | |||
offset in terms of the payload size(s) of stored packets, using the | offset in terms of the payload size(s) of stored packets, using the | |||
Type-P-packet-Byte-Offset-Stream metric. | Type-P-packet-Byte-Offset-Stream metric. | |||
The byte offset metric can help predict whether reordered packets | The byte offset metric can help predict whether reordered packets | |||
will be useful in a general receiver buffer system with finite | will be useful in a general receiver buffer system with finite | |||
limits. The limit is expressed as the number of bytes the buffer | limits. The limit is expressed as the number of bytes the buffer | |||
can store. | can store. | |||
A sample's ByteOffset results may be expressed as a histogram, to | ||||
summarize the frequency of buffer lengths needed to accommodate | ||||
reordered packets and permit buffer tuning on that basis. A CDF with | ||||
buffer size vs. percent of reordered packets accommodated may be | ||||
informative. | ||||
4.5 Gaps between multiple Reordering Discontinuities | 4.5 Gaps between multiple Reordering Discontinuities | |||
4.5.1 Metric Name: | 4.5.1 Metric Name: | |||
Type-P-packet-Reordering-Gap-Stream | Type-P-packet-Reordering-Gap-Stream | |||
4.5.2 Parameters: | 4.5.2 Parameters: | |||
We use the same parameters defined earlier, but add the convention | We use the same parameters defined earlier, but add the convention | |||
that index i' is greater than i, likewise j' > j, and define: | that index i' is greater than i, likewise j' > j, and define: | |||
skipping to change at line 1043 | skipping to change at line 1065 | |||
Test stream designers may prefer to use a periodic sending interval | Test stream designers may prefer to use a periodic sending interval | |||
so that a known temporal bias is maintained, also bringing | so that a known temporal bias is maintained, also bringing | |||
simplified results analysis (as described in [RFC3432]). In this | simplified results analysis (as described in [RFC3432]). In this | |||
case, it is RECOMMENDED that the periodic sending interval should be | case, it is RECOMMENDED that the periodic sending interval should be | |||
chosen to reproduce the closest Source packet spacing expected. | chosen to reproduce the closest Source packet spacing expected. | |||
Testers must recognize that streams sent at the link speed | Testers must recognize that streams sent at the link speed | |||
serialization limit MUST have limited duration and MUST consider | serialization limit MUST have limited duration and MUST consider | |||
packet loss as an indication that the stream has caused congestion, | packet loss as an indication that the stream has caused congestion, | |||
and suspend further testing. | and suspend further testing. | |||
When intending to compare or concatenate independent measurements of | When intending to compare independent measurements of reordering, it | |||
reordering, it is RECOMMENDED to use the same test stream parameters | is RECOMMENDED to use the same test stream parameters in each | |||
in each measurement system. | measurement system. | |||
Packet lengths might also be varied to attempt to detect instances | Packet lengths might also be varied to attempt to detect instances | |||
of parallel processing (they may cause steady state reordering). For | of parallel processing (they may cause steady state reordering). For | |||
example, a line-speed burst of the longest (MTU-length) packets | example, a line-speed burst of the longest (MTU-length) packets | |||
followed by a burst of the shortest possible packets may be an | followed by a burst of the shortest possible packets may be an | |||
effective detecting pattern. Other size patterns are possible. | effective detecting pattern. Other size patterns are possible. | |||
The non-reversing order criterion and all metrics described above | The non-reversing order criterion and all metrics described above | |||
remain valid and useful when a stream of packets experiences packet | remain valid and useful when a stream of packets experiences packet | |||
loss, or both loss and reordering. In other words, losses alone do | loss, or both loss and reordering. In other words, losses alone do | |||
not cause subsequent packets to be declared reordered. | not cause subsequent packets to be declared reordered. | |||
Assuming that the necessary sequence information (message number) is | Assuming that the necessary sequence information (message number) is | |||
included in the packet payload (possibly in application headers such | included in the packet payload (possibly in application headers such | |||
as RTP), reordering metrics may be evaluated in a passive | as RTP), reordering metrics may be evaluated in a passive | |||
measurement arrangement. Also, it is possible to evaluate order at | measurement arrangement. Also, it is possible to evaluate order at | |||
any point along a Source-Destination path, recognizing that | any point along a Source-Destination path, recognizing that | |||
intermediate measurements may differ from those made at the | intermediate measurements may differ from those made at the | |||
Destination (where reordering's affect on applications can be | Destination (where the reordering affect on applications can be | |||
inferred). | inferred). | |||
It is possible to apply these metrics to evaluate reordering in a | It is possible to apply these metrics to evaluate reordering in a | |||
TCP sender's stream. In this case, the Source sequence numbers would | TCP sender's stream. In this case, the Source sequence numbers would | |||
be based on byte stream, or segment numbering. Since the stream may | be based on byte stream, or segment numbering. Since the stream may | |||
include retransmissions due to loss or reordering, care must be | include retransmissions due to loss or reordering, care must be | |||
taken to avoid declaring retransmitted packets reordered. The | taken to avoid declaring retransmitted packets reordered. The | |||
additional sequence reference of s or SrcTime helps to avoid this | additional sequence reference of s or SrcTime helps to avoid this | |||
ambiguity, or the optional TCP timestamp field [RFC1323]. | ambiguity, or the optional TCP timestamp field [RFC1323]. | |||
skipping to change at line 1102 | skipping to change at line 1124 | |||
2. All sequence numbers used in computations are represented in a | 2. All sequence numbers used in computations are represented in a | |||
sufficiently large precision. The numbers have a correction applied | sufficiently large precision. The numbers have a correction applied | |||
(equivalent to adding a significant digit) whenever roll-over is | (equivalent to adding a significant digit) whenever roll-over is | |||
detected. | detected. | |||
3. Reordered packets coincident with sequence numbers reaching end- | 3. Reordered packets coincident with sequence numbers reaching end- | |||
of-range must also be detected for proper application of correction | of-range must also be detected for proper application of correction | |||
factor. | factor. | |||
Ideally, the test instrument would have the ability to use all | Ideally, the test instrument would have the ability to use all | |||
earlier packets at any point in the test stream. In practice, there | earlier packets at any point in the test stream. In practice there | |||
will be limited ability to determine reordering extent, due to the | will be limited ability to determine reordering extent, due to the | |||
storage requirements for previous packets. Saving only packets that | storage requirements for previous packets. Saving only packets that | |||
indicate discontinuities (and their arrival positions) will reduce | indicate discontinuities (and their arrival positions) will reduce | |||
storage volume. | storage volume. | |||
Another solution is to use a sliding history window of packets, | Another solution is to use a sliding history window of packets, | |||
where the window size would be determined by an upper bound on the | where the window size would be determined by an upper bound on the | |||
useful reordering extent. This bound could be several packets or | useful reordering extent. This bound could be several packets or | |||
several seconds-worth of packets, depending on the intended | several seconds-worth of packets, depending on the intended | |||
analysis. When discarding all stream information beyond the window, | analysis. When discarding all stream information beyond the window, | |||
skipping to change at line 1126 | skipping to change at line 1148 | |||
would not be possible. | would not be possible. | |||
The requirement to ignore duplicate packets also mandates storage. | The requirement to ignore duplicate packets also mandates storage. | |||
Here, tracking the sequence numbers of missing packets may minimize | Here, tracking the sequence numbers of missing packets may minimize | |||
storage size. Missing packets may eventually be declared lost, or | storage size. Missing packets may eventually be declared lost, or | |||
reordered if they arrive. The missing packet list and the largest | reordered if they arrive. The missing packet list and the largest | |||
sequence number received thus far (NextExp - 1) are sufficient | sequence number received thus far (NextExp - 1) are sufficient | |||
information to determine if a packet is a duplicate (assuming a | information to determine if a packet is a duplicate (assuming a | |||
manageable storage size for packets that are missing due to loss). | manageable storage size for packets that are missing due to loss). | |||
It is important to note that practical IP networks also have limited | ||||
ability to "store" packets, even when routing loops appear | ||||
temporarily. Therefore, the storage for reordering metrics (and | ||||
their complexity) would only approach the number packets in the | ||||
sample, K, when the sending time for K packets is small with respect | ||||
to the network's largest possible transfer time. | ||||
Last, we note that determining reordering extents and gaps is tricky | Last, we note that determining reordering extents and gaps is tricky | |||
when there are overlapped or nested events. Test instrument | when there are overlapped or nested events. Test instrument | |||
complexity and reordering complexity are directly correlated. | complexity and reordering complexity are directly correlated. | |||
7. Examples of Arrival Order Evaluation | 7. Examples of Arrival Order Evaluation | |||
This section provides some examples to illustrate how the non- | This section provides some examples to illustrate how the non- | |||
reversing order criterion works, how n-reordering works in | reversing order criterion works, how n-reordering works in | |||
comparison, and the value of quantifying reordering in all the | comparison, and the value of quantifying reordering in all the | |||
dimensions of time, bytes, and position. | dimensions of time, bytes, and position. | |||
skipping to change at line 1147 | skipping to change at line 1176 | |||
Throughout this section, we will refer to packets by their source | Throughout this section, we will refer to packets by their source | |||
sequence number, except where noted. So "Packet 4" refers to the | sequence number, except where noted. So "Packet 4" refers to the | |||
packet with source sequence number 4, and the reader should refer to | packet with source sequence number 4, and the reader should refer to | |||
the tables in each example to determine packet 4's arrival index | the tables in each example to determine packet 4's arrival index | |||
number, if needed. | number, if needed. | |||
7.1 Example with a single packet reordered | 7.1 Example with a single packet reordered | |||
Table 1 gives a simple case of reordering, where one packet is | Table 1 gives a simple case of reordering, where one packet is | |||
reordered, Packet 4. Packets are listed according to their arrival, | reordered, Packet 4. Packets are listed according to their arrival, | |||
and message numbering is used. All packets contain 100 bytes, | and message numbering is used. All packets contain PayloadSize=100 | |||
beginning with s=1 and (s x 100)-99 for s=2,3,4,... | bytes, with SrcByte=(s x 100)-99 for s=1,2,3,4,... | |||
Table 1 Example with Packet 4 Reordered, | Table 1 Example with Packet 4 Reordered, | |||
Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10 | Sending order(SrcNum@Src): 1,2,3,4,5,6,7,8,9,10 | |||
s Src Dst Dst Byte Late | s Src Dst Dst Byte Late | |||
@Dst NextExp Time Time Delay IPDV Order Offset Time | @Dst NextExp Time Time Delay IPDV Order Offset Time | |||
1 1 0 68 68 1 | 1 1 0 68 68 1 | |||
2 2 20 88 68 0 2 | 2 2 20 88 68 0 2 | |||
3 3 40 108 68 0 3 | 3 3 40 108 68 0 3 | |||
5 4 80 148 68 -82 4 | 5 4 80 148 68 -82 4 | |||
6 6 100 168 68 0 5 | 6 6 100 168 68 0 5 | |||
skipping to change at line 1497 | skipping to change at line 1526 | |||
3393, November 2002. | 3393, November 2002. | |||
[Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data | [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data | |||
communication service - IP packet transfer and | communication service - IP packet transfer and | |||
availability performance parameters", December 2002. | availability performance parameters", December 2002. | |||
12. Acknowledgments | 12. Acknowledgments | |||
The authors would like to acknowledge many helpful discussions with | The authors would like to acknowledge many helpful discussions with | |||
Matt Zekauskas, Jon Bennett (who authored the sections on | Matt Zekauskas, Jon Bennett (who authored the sections on | |||
Reordering-Free Runs), and Matt Mathis. We thank David Newman, Henk | Reordering-Free Runs), and Matt Mathis. We thank David Newman, Henk | |||
Uijterwall, Mark Allman, Vern Paxson, and Phil Chimento for their | Uijterwaal, Mark Allman, Vern Paxson, and Phil Chimento for their | |||
reviews and suggestions, and Michal Przybylski for sharing | reviews and suggestions, and Michal Przybylski for sharing | |||
implementation experiences with us on the ippm-list. We gratefully | implementation experiences with us on the ippm-list. Anura | |||
acknowledge the foundation laid by the authors of the IP performance | Jayasumana and Nischal Piratla brought in recent work-in-progress. | |||
Framework [RFC2330]. | We gratefully acknowledge the foundation laid by the authors of the | |||
IP performance Framework [RFC2330]. | ||||
13. Appendix A Example Implementations in C (Informative) | 13. Appendix A Example Implementations in C (Informative) | |||
Two example c-code implementations of reordering definitions follow: | Two example c-code implementations of reordering definitions follow: | |||
Example 1 n-reordering ============================================ | Example 1 n-reordering ============================================ | |||
#include <stdio.h> | #include <stdio.h> | |||
#define MAXN 100 | #define MAXN 100 | |||
skipping to change at line 1794 | skipping to change at line 1822 | |||
EMail: <shalunov@internet2.edu> | EMail: <shalunov@internet2.edu> | |||
Jerry Perser | Jerry Perser | |||
Consultant | Consultant | |||
Calabasas, CA 91302 USA | Calabasas, CA 91302 USA | |||
Phone: + 1 | Phone: + 1 | |||
EMail: <jerry@perser.org> | EMail: <jerry@perser.org> | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2005). This document is subject | Copyright (C) The Internet Society (2005). | |||
to the rights, licenses and restrictions contained in BCP 78 and | ||||
except as set forth therein, the authors retain all their rights. | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on | This document and the information contained herein are provided on | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE | |||
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR | INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR | |||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
Intellectual Property | Intellectual Property | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |