Summary

  • RFC 5236's Reorder Density describes packet displacement, while Reorder Buffer-occupancy Density models the buffer occupancy needed to restore order. Both are transformations of an observed sequence, not sensors that identify the network mechanism responsible.
  • Displacement and buffer thresholds decide what the calculation retains, discards or reclassifies. A report without thresholds, sequence identity, observation point, loss and duplicate rules, and algorithm mode is not a complete measurement record.
  • Path attribution and application impact require separate evidence. RFC 5236 is Informational, and its IESG Note explicitly distinguishes it from the IETF standards-track metrics in RFC 4737; publication in the RFC series is not an operational endorsement.

A clean graph arrived before the explanation

Imagine a morning incident review. The network team projects a beautiful density curve. It has two shoulders, a long late-packet tail and a second chart showing how often a hypothetical resequencing buffer would have held several packets. The chart is reproducible. The analyst has checked the arithmetic. Someone then points to a load balancer and says: there is the cause.

Nothing in the curve supports that last step by itself.

The trace may have crossed parallel links. A priority scheduler may have advanced one class. A route may have fluttered. A switch may have processed packets along different internal paths. The capture point may have seen a local effect that the receiving application did not. Missing packets may have been classified according to a threshold that was never shown. The density can faithfully summarize the recorded sequence while remaining compatible with several causal stories.

This is the governance problem hidden inside a measurement problem. Institutions like a single object that can travel upward: one graph, one score, one red light. But the authority of a metric ends at the transformation it actually performs. A displacement distribution may authorize the statement that observed order changed under stated rules. It does not authorize the statement that a named mechanism caused the change, that a particular user suffered, or that remediation belongs to a particular operator.

RFC 5236 is useful because it gives the observation more structure than a crude count of reordered packets. Its value increases, not decreases, when the boundary is enforced.

Two densities, two different questions

Reorder Density, or RD, starts with unique packets in a sequence. At the receiver, each unique arrival receives a receive index. The packet's displacement is the receive index minus its sequence number. A packet that appears earlier than its original position has negative displacement; one that appears later has positive displacement; an in-order position has zero displacement within the model.

The resulting normalized distribution retains shape. A single reordered-packet fraction would tell management that some portion of traffic crossed a classification line. RD can reveal whether displacement clusters close to zero, whether early and late observations are balanced, whether there is a narrow secondary mode or a long tail. Derived values can include early and late fractions, mean displacement and entropy.

Reorder Buffer-occupancy Density, or RBD, asks a different question. It models a buffer that holds early packets until the missing sequence arrives and contiguous packets can be released. The density records the distribution of that hypothetical buffer's occupancy. It can be counted in packets or bytes. Mean occupancy, variance and other summaries can then be derived.

The distinction matters. RD describes where packets appeared relative to original order. RBD describes modeled recovery demand under a particular resequencing process. Neither is the actual internal state of every transport or application. A product may use another buffer, a timeout, a playout deadline, a different sequence space or no resequencing at all. Treating RBD as an application-buffer readout would cross from a defined model into an invented fact.

The same restraint applies in the other direction. An application that experienced no visible failure does not retroactively make the packet observation false. Observation and consequence are separate records and should remain separately queryable.

The threshold is inside the result

RFC 5236 uses a displacement threshold, DT, to bound how far the algorithm will search or retain state for missing and displaced packets. It also uses a buffer threshold, BT, to bound modeled buffer occupancy. Those parameters make computation practical. They also define the evidence surface.

Suppose DT is too small. A packet that is substantially late may be treated as lost rather than reordered. Increase DT and the same packet can move into the displacement distribution, at a cost in memory and processing. An extreme arrival beyond the boundary may be discarded as a rogue packet so that one observation cannot make the algorithm's work unbounded. The choice is defensible, but it is not neutral.

BT has a similar role. A modeled buffer cannot grow without limit merely to accommodate every possible arrival. The selected boundary may reflect an application's requirements, a device's capacity or an analytical convention. Change the boundary and the reported occupancy distribution can change.

For that reason, “RD increased” is incomplete. The defensible record says which sequence was measured, where, during what interval, with which DT and BT, which loss and duplicate rules, and how many observations were discarded or reclassified at the boundary. A threshold belongs beside the chart, not in an undocumented configuration file.

Sensitivity analysis is often more revealing than the headline value. If a modest change in DT transforms many apparent losses into reordered packets, the classification is fragile. If RBD changes sharply with a small change in BT, capacity conclusions need qualification. Stable results across a reasonable parameter range are more useful, but even stability does not identify cause.

This is why measurement governance cannot be reduced to algorithm correctness. The code may implement the published formula perfectly and still deliver a misleading institutional object if its parameters, exclusions and input custody are invisible.

Receive index is a contract, not a natural fact

The receive index sounds obvious until loss and duplication enter the trace. RFC 5236 does not assign receive indexes to duplicate packets, and the index advances across unique arrivals while accounting for sequence numbers treated as lost. The resulting displacement therefore depends on classification decisions made around the observed sequence.

Sequence identity also has to survive operational reality. Sequence numbers can wrap. Flows can reset, multiplex, fragment or be joined from several capture files. RFC 5236 says wrap can be handled with modulo-N arithmetic, but that statement does not prove that every implementation identifies epochs correctly. A valid formula applied across a mistaken reset boundary creates confident nonsense.

The evidence record should therefore include the sequence namespace, wrap and reset handling, duplicate identity, capture ordering and any preprocessing that joined or filtered packets. Where packets are generated for active measurement, generation records and authentication matter. Where production traffic is observed, lawful scope, sampling and capture loss matter.

RD is described as orthogonal to loss and duplication; RBD is orthogonal to duplication. Orthogonal does not mean those phenomena evaporate. It means the method seeks to separate their metrics. The separation itself depends on the classifier. An executive report that omits loss and duplication policy hides a material part of how the supposedly independent result was created.

Online algorithms exchange immediacy for retained state

An offline analyst can examine an entire completed sequence. A live monitor cannot. RFC 5236 therefore describes online strategies with different operational behavior.

A go-back strategy can revise earlier assumptions when a late packet finally appears. A stay-back strategy avoids revisiting previous state but may lag when a packet remains missing, with the lag bounded by the displacement threshold. Neither strategy is simply “the online version.” They trade memory, work, latency and revision behavior differently.

This has consequences for dashboards. A current-window density may be provisional. A go-back implementation can revise it after late evidence arrives. A stay-back implementation may intentionally withhold a segment. Two systems using the same nominal metric can disagree for a time without either violating its own algorithm.

Leaders should ask whether the displayed value is final, provisional or revised; how long revision remains possible; which packets were beyond the retention horizon; and whether alerts are retracted when the density changes. A graph without those states can turn computation latency into an apparent network event.

Bounded error is still error that must be named. Discarding a rogue packet can be the correct engineering choice. The report should say that the result is the density of the retained sample under a declared boundary, not the total truth of every arrival.

A list of possible causes is not an attribution engine

RFC 5236 names several mechanisms that can produce reordering: striping packets across Layer 2 or Layer 3 links, priority scheduling, route flutter, internal parallelism in routers and switches, quality-of-service treatment and link load balancing. These examples help readers understand why order can change. They do not map a density shape to a unique mechanism.

Several causes can coexist. A load-balanced path can also undergo a routing transition. A priority scheduler can act inside a device whose parallel forwarding paths already introduce variation. Capture behavior can add its own ordering artefact. Conversely, one mechanism can produce different density shapes as traffic mix and queue state change.

Causal attribution needs evidence from the candidate control surface. A route claim needs route history aligned to the same interval. A link-aggregation claim needs member selection and state. A scheduling claim needs class and queue records. A device-parallelism claim needs implementation or telemetry evidence. A capture artefact needs independent capture or integrity checks. The metric indicates where to investigate; it does not close the investigation.

This boundary is especially important in multi-operator paths. An endpoint observation can establish that order changed between two points. It does not locate the responsible administrative domain. Assigning blame from the endpoint density alone converts uncertainty into a political fact that the evidence did not produce.

Composition works only under its assumptions

RFC 5236 considers whether reorder densities from individual subnets can be combined. Under stationary conditions and sufficiently broad assumptions, composition may be analytically useful. But a path is not automatically the sum of independent, stable components.

Traffic selection can correlate with path selection. Queues can interact. A transition in one segment can change arrival patterns presented to the next. Observation windows may not align. Sampling can alter the population. If those conditions fail, multiplying or convolving subnet summaries does not discover the endpoint truth.

This is a recurring institutional temptation: because several local teams each have a metric, a central team assumes it owns a global causal model. The mathematical operation does not supply missing authority or missing evidence. When composition assumptions cannot be defended, direct endpoint measurement is the stronger record.

Even direct endpoint measurement remains bounded. It describes the visible segment and sample. It does not automatically reveal which hop acted or whether the same behavior exists outside the measured population.

The application lives in another layer

Packet order can matter greatly, but not uniformly. A transport may recover. A media player may have enough playout buffer. A real-time packet may arrive after its deadline and be worthless. A request-response workload may experience a latency tail without any visible failure. A bulk transfer may show lower throughput because transport behavior reacts to the sequence.

RD and RBD help describe conditions that could matter to those systems. They do not contain the application's deadline, recovery logic, congestion state, retry policy or user interaction. A density therefore cannot prove degraded throughput, audible impairment, failed transactions or customer harm.

Impact claims need aligned evidence: transport counters, application latency, playout or deadline misses, retries, errors, quality measurements or user outcomes for the same time and population. Alignment is essential. A weekly application metric paired with a five-minute packet trace is not causal closure.

The separation also prevents false reassurance. If an application dashboard is green, a persistent reorder pattern may still reveal a path characteristic worth monitoring. No visible harm today is not proof that every workload can absorb it. The correct statement is that this application evidence did not demonstrate harm in the observed interval.

The document label has its own boundary

RFC 5236 entered the RFC series as Informational. Its IESG Note is unusually direct: RFC 4737 is the IETF standards-track document for packet-reordering metrics; the RFC 5236 metrics were not adopted into it; RFC 5236 is not a candidate for Internet Standard; and readers should use caution because the publication decision was not based on IETF review of areas such as security, congestion control or interactions with deployed protocols.

That note does not make RFC 5236 useless. It prevents a category error. The RFC series contains documents from different streams and with different statuses. Publication makes a stable, citable document available. It does not certify that the method is deployed, fit for every purpose or endorsed as the IETF standard.

RFC 4737's standards-track status must also remain narrow. Standards status is documentary and procedural evidence. It is not proof that a product implements the metric, that an implementation is correct or that a measured path produced a particular outcome.

The status distinction belongs in procurement, monitoring and incident reports. “Based on RFC 5236” should not be shortened to “the IETF standard says” when the IESG Note says the opposite.

Measurement input needs custody

RFC 5236 directs security attention to RFC 4737 and to the active-measurement framework around RFC 3763 and RFC 4656. The central lesson is simple: a calculation cannot authenticate the packets from which it is calculated.

Test streams may be spoofed, replayed, filtered or treated differently from ordinary traffic. Capture systems can drop or reorder records. Clocks can drift. Resource pressure can alter sampling. An observer can select only windows that support a desired story. None of those failures is repaired by a correct density formula.

A leadership-grade record should bind generation or capture provenance, packet identity, observation points, integrity checks, time source, loss and duplicate handling, preprocessing, parameter values, algorithm version and output hash. Access controls should separate the ability to collect a trace, alter the trace, compute the metric and approve an incident conclusion.

This is not bureaucracy added after engineering. It is the chain that lets another team distinguish a network observation from a capture artefact, a computational change or a narrative choice.

Four statements instead of one red light

Lu Heng's institutional framework clarifies why the separation matters. Participation, expertise and measurement can contribute evidence without inheriting authority over everyone affected. A thin common mechanism should specify what it can coordinate and leave later operational decisions to actors holding the relevant local facts. A record-keeper becomes dangerous when the record is presented as sovereign judgment. Running code and observed behavior remain different from documentary coordinates.

Applied to reordering, a responsible report contains four independently reviewable statements.

First, the observation: which packet sequence was seen, from which source to which destination, at which observation point and time. Second, the transformation: which algorithm, DT, BT, sequence rules and exclusions produced RD or RBD. Third, attribution: which independent routing, link, queue, device or capture evidence supports a proposed mechanism. Fourth, impact: which transport, application or user evidence supports a consequence.

The first two may be strong while the last two remain unknown. That is not an analytical failure. It is a truthful state. The pressure to fill every cell is precisely how measurements become myths.

Sources

  1. RFC 5236
  2. RFC 5236 plain text
  3. RFC 5236 on IETF Datatracker
  4. RFC 5236 status
  5. RFC 5236 history
  6. RFC 5236 errata
  7. RFC 4737
  8. RFC 4737 plain text
  9. RFC 4737 on IETF Datatracker
  10. RFC 4737 status
  11. RFC 4737 history
  12. RFC 4737 errata
  13. RFC 2330
  14. RFC 3763
  15. RFC 4656
  16. RFC 3932
  17. RFC 4844
  18. RFC 8729
  19. Lu Heng — The Multi-Stakeholder Mirage
  20. Lu Heng — Minimum Initial Specification
  21. Lu Heng — When the Bookkeeper Auditions for Olympus
  22. Lu Heng — Running-Code Primacy