Packet Reordering Metrics
updated by
- rfc-6248 — RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete
Extracted elements (28)
Reordering is defined by classifying 'late' arriving packets (those with sequence numbers smaller than previously seen) rather than 'premature' packets, because only the arrival of the late packet distinguishes reordering from packet loss. This maintains orthogonality with the packet loss metric and matches Paxson's definition.
Sequence number rollover is mitigated by: (1) detecting rollover via impossibly large jumps (more than half the total range) between successive packets, (2) representing all sequence numbers in sufficient precision with a correction factor applied on rollover, and (3) detecting reordered packets coincident with end-of-range.
The n-reordering metric was designed to estimate whether reordering might cause the TCP DUP-ACK threshold to be exceeded and trigger Fast Retransmit. n=3 corresponds to the default DUP-ACK threshold in RFC 2581 (NewReno TCP), SCTP (RFC 2960), and DCCP with CC-ID 2 (RFC 4341).
The reordering extent metric tends to overestimate the receiver storage needed to restore order because it does not subtract earlier reordered packets the receiver could pass on. This bias is acknowledged as acceptable, especially for on-the-fly calculation requirements.
To minimize storage for duplicate detection, tracking the sequence numbers of missing packets (rather than storing full packet copies) is sufficient. The missing packet list plus NextExp-1 fully determines whether any arriving packet is a duplicate.
Reordering metrics may be evaluated passively if the packet payload carries sequence information (e.g., RTP headers). For TCP streams, retransmitted segments must be distinguished from original transmissions to avoid false reordering declarations; the optional TCP timestamp field (RFC 1323) or the SrcTime parameter helps resolve this ambiguity.
The Reordering Late Time metric differs from IPDV (RFC 3393), which gives delay variation for a packet with respect to its predecessor in source sequence. When earlier packets are lost, IPDV is undefined for adjacent pairs, whereas LateTime may still be computable and is the only way to evaluate usefulness of a late packet.
If duplicate packets (multiple non-corrupt copies) arrive at the destination, they MUST be noted and only the first copy considered for further analysis; subsequent copies are treated as reordered according to the singleton definition.
In the fragment order evaluation appendix, packets with missing fragments MUST be declared lost and the reordering status of any fragments that do arrive MUST be excluded from sample metrics.
It is RECOMMENDED to use the same test stream parameters when intending to compare independent measurements of reordering, and RECOMMENDED to choose the periodic sending interval to reproduce the closest expected source packet spacing.
Reordering Metrics MUST have one or more applications, MUST be computable 'on the fly', and MUST work even if the stream has duplicate or lost packets.
Streams sent at the link speed serialization limit MUST have limited duration and MUST consider packet loss an indication that the stream has caused congestion; testing MUST be suspended in that case.
To make inferences about TCP, it is REQUIRED to use TCP-like streams as in RFC 3148. For real-time applications, it is RECOMMENDED to use periodic streams as in RFC 3432. The exact method of packet generation MUST be reported with the measurement results.
Whenever a reordering metric is reported, it MUST include a description of the Packet of Type-P identifiers and the stream parameter set (sending discipline, packet size, etc.) to provide a complete measurement context.
A Sequence Discontinuity occurs when an arriving packet s > NextExp, indicating missing packets (lost or reordered). Its size is s - NextExp. A discontinuity is reclassified as a Reordering Discontinuity only if the missing packets subsequently arrive as reordered packets.
The Type-P-Packet-Reordering-Free-Run metrics (numruns x, squruns q, numpkts p, accpkts a) count consecutive in-order packets between reordered packets. The average free-run length is a/x and the ratio (q/a)/(a/x) equals 1 when all runs are equal length, indicating run-length variability.
Type-P-Packet-Byte-Offset-Stream measures the byte storage a receiver needs to accommodate a reordered packet. ByteOffset(s[i]) is the sum of payload sizes of all packets that arrived before s[i] and have a larger source sequence number than s[i]; these are the packets normally buffered waiting for order to be restored.
Type-P-Packet-Late-Time-Stream measures the temporal lateness of a reordered packet: LateTime(s[i]) = DstTime(i) - DstTime(j), where j is the earliest arrival index of a packet with a larger sequence number. This helps predict whether reordered packets will be useful in a finite receiver buffer or de-jitter buffer.
Type-P-Packet-n-Reordering-Stream: a received packet with arrival index i is n-reordered if and only if all n packets preceding it in arrival order (indexes i-n through i-1) have larger source sequence numbers. The degree of n-reordering is m/l, where m is the count of n-reordered packets and l is packets received.
Type-P-Packet-Reordering-Extent-Stream quantifies how far out-of-order a reordered packet is. The reordering extent e of packet s[i] is i - j, where j is the smallest arrival index before i such that s[j] > s[i]. This represents the maximum distance to the earliest packet received with a larger sequence number.
Type-P-Packet-Reordering-Gap-Stream measures the arrival-position distance between successive reordering discontinuities: Gap(s[j']) = j' - j, where j and j' are the arrival indexes of two consecutive reordering discontinuities. An optional GapTime metric expresses the same distance in seconds.
Type-P-Reordered is the singleton metric. A packet with sequence number s is declared reordered (TRUE) if s < NextExp at the time of arrival; otherwise it is in-order (FALSE) and NextExp is updated to s+1. NextExp never decreases, providing a non-reversing order criterion.
Type-P-Reordered-Ratio-Stream measures the ratio R of reordered packets to received packets in a sample: R = (count of packets with Type-P-Reordered=TRUE) / L, where L is the number of received packets (duplicates removed). When R = 0, no further reordering metrics need be examined.
This document registered 12 metrics in the IANA IPPM METRICS REGISTRY (RFC 4148): ietfReorderedSingleton (34), ietfReorderedPacketRatio (35), ietfReorderingExtent (36), ietfReorderingLateTimeOffset (37), ietfReorderingByteOffset (38), ietfReorderingGap (39), ietfReorderingGapTime (40), ietfReorderingFreeRunx (41), ietfReorderingFreeRunq (42), ietfReorderingFreeRunp (43), ietfReorderingFreeRuna (44), and ietfnReordering (45).
An adversary who identifies measurement packets can manipulate the metric by altering packet processing (changing delay) or injecting additional packets that appear part of the sample, perturbing results by causing injected or original packets to be seen as duplicates. OWAMP (RFC 4656) provides mechanisms for data collection resistance to such interference.
Passive measurement may require temporarily storing user payloads for length analysis; suitable precautions MUST be taken to keep this information safe and confidential. In most cases, a hashing function will produce a value suitable for payload comparisons without retaining the payload itself.
The packet stream required by these metrics could be abused for denial-of-service attacks against the destination or intervening networks. Administrators should establish bilateral or multilateral agreements regarding timing, size, and frequency of sample metric collection.
The NextExp state variable tracks the next expected sequence number. On arrival of packet s: if s >= NextExp, set NextExp = s+1 and mark in-order; if s < NextExp, mark reordered without changing NextExp. When s > NextExp a sequence discontinuity of size s - NextExp is recorded.