What is Packet Reordering?
Updated: 3 days ago
Packet reordering happens when packets from the same traffic flow arrive at their destination in a different order from the order in which they were sent. Nothing necessarily has to be lost: one packet can simply be delayed long enough for a later packet to overtake it. It matters because transport protocols and real-time applications may have to buffer, retransmit or otherwise compensate for that changed arrival order.
Packet reordering is different from packet loss, where a packet fails to arrive, and from jitter, which describes variation in delay. Reordering is specifically about sequence.
At the IP layer, ordered delivery is not guaranteed. RFC 4737 therefore defines ways to detect and quantify reordering rather than assuming that every packet stream will always arrive in sequence.
How does packet reordering happen?
Imagine four packets leave a device in the sequence 1, 2, 3, 4. If packet 2 encounters a longer delay while packet 3 follows a quicker path or is processed sooner, the receiver might see 1, 3, 2, 4. Packet 2 has not vanished. It is late relative to packet 3.
Multiple network paths with different delays can allow later packets to overtake earlier packets.
Layer 2 retransmissions can delay one frame while later traffic continues.
Parallel links or parallel packet processing can complete work at different times.
Different queues, scheduling policies or service rates can alter the order in which packets leave a device.
Route instability can temporarily move traffic between paths and create transient reordering.
RFC 4737 identifies these mechanisms as examples of path characteristics that can make reordering more likely. RFC 5236 also notes packet striping, priority scheduling and route fluttering as important causes.
Packet reordering is not packet loss
The distinction is important when diagnosing broadband performance. Loss means expected data never reaches the observation point. Reordering means data does arrive, but the sequence has changed. A test or protocol that treats every out-of-order arrival as a loss event can therefore overstate the actual loss on the path.
A connection can experience reordering with zero packet loss, and it can experience loss without reordering. The two can also occur together.
Packet reordering versus jitter and latency
Latency measures how long data takes to travel, while jitter measures how much that delay varies over time. Reordering can be a consequence of unequal delay between packets, but it is not another name for either metric.
Latency asks: how long did the packet take?
Jitter asks: how much did delay vary?
Packet loss asks: did the expected packet arrive?
Packet reordering asks: did packets arrive in the same sequence in which they were sent?
Why does packet reordering matter to TCP?
TCP provides an ordered byte stream to the application, so out-of-order network delivery has to be handled before the application sees the data in order. Historically, sufficiently severe reordering could also resemble packet loss to TCP's loss-detection logic, causing unnecessary retransmission and congestion-control responses.
RFC 3819 explains the classic problem: out-of-order TCP segments can generate duplicate acknowledgements, and older loss-detection behaviour can interpret enough duplicate acknowledgements as evidence of a dropped segment. RFC 3522 describes how network reordering can therefore lead to a spurious fast retransmit.
Modern transport implementations are more tolerant than a simple description of classic TCP might suggest. A current IETF Internet-Draft published in August 2026 specifically discusses how modern TCP and QUIC mechanisms have improved tolerance to out-of-order delivery. Because that document is still an Internet-Draft, it should be treated as current engineering guidance under development rather than a final RFC.
What does packet reordering do to real-time traffic?
Real-time audio and video can often absorb small amounts of reordering by holding packets briefly in a jitter buffer and playing them in the required order. That protection is finite. RFC 7657 notes that minor reordering contained within a jitter buffer may have no effect on rendering, while reordering beyond the buffer's capacity can create user-perceptible glitches or other quality problems.
The trade-off is familiar in real-time networking: a larger buffer can tolerate more variation and reordering, but extra buffering also adds delay. Interactive voice, gaming and video calls therefore cannot hide arbitrarily late packets without harming responsiveness.
How packet reordering can appear on UK broadband
Packet reordering is an end-to-end path behaviour rather than a feature unique to FTTP, FTTC, cable, mobile or any particular UK ISP. The access connection is only one part of the route. Reordering can occur in the home network, access network, ISP network, interconnection path or remote network.
Relevant mechanisms include changing routing, route flapping, parallel forwarding paths and link-layer retransmission. On WiFi or mobile links, retransmission below IP can also change the timing of individual packets.
Do not assume that a reordered packet proves the broadband provider is at fault. The useful question is where along the complete path the ordering changed and whether the amount is large enough to affect the application.
End-to-end view of packet ordering
A broadband flow can cross many components before it reaches an application. The relevant path may include the remote service, transit or peering networks, the ISP core, the access network, the ONT or modem, the router, Ethernet or WiFi and the end device. Any stage that introduces unequal delay or parallel processing can contribute.
An asymmetric route is not itself packet reordering. Asymmetric routing means the forward and return directions take different paths. Reordering concerns the relative arrival sequence of packets travelling in the same observed direction or stream.
Techie Broadband worked example: reordering depth
Consider a practical example where packets are transmitted as 1, 2, 3, 4, 5, 6 but arrive as 1, 2, 5, 3, 4, 6. Packet 5 has overtaken packets 3 and 4. In simple sequence terms, it arrived two positions ahead of where the receiver expected it relative to those packets.
TECHIE BROADBAND CALCULATION: if a stream contains 100,000 observed packets and 250 are classified as reordered under the chosen measurement definition, the observed reordered-packet proportion is 250 ÷ 100,000 × 100 = 0.25%. That percentage alone is not enough to predict application impact. The distance of the reordering, timing, burst pattern and transport behaviour also matter.
This is why RFC 4737 defines more than a single yes-or-no indicator. Useful measurements include whether reordering occurred, how frequently it occurred and how extensive the changed ordering was.
The diagram above shows the central distinction: packets can all arrive successfully while still arriving in a different sequence. Diagnosis therefore needs to separate ordering, loss and delay rather than collapsing them into one generic connection problem.
How to test for packet reordering
Ordinary consumer speed tests are not designed to give a definitive packet-reordering measurement. Proper diagnosis needs sequence-aware traffic or a packet capture that lets you compare expected sequence with observed arrival order.
Start with a wired Ethernet connection to remove WiFi as a variable.
Pause unrelated uploads, downloads and cloud synchronisation so the test path is easier to interpret.
Capture traffic at an appropriate observation point or use a purpose-built sequence-aware measurement tool.
Check whether apparent missing packets later arrive out of order rather than never arriving.
Repeat the test against more than one destination so a single remote path is not mistaken for a local broadband problem.
Repeat at different times to distinguish persistent behaviour from a transient routing event.
Compare the local LAN side and WAN side where equipment and access permit. This can help narrow down where ordering changes.
Correlate reordering with latency, jitter, packet loss and route changes instead of interpreting it in isolation.
If TCP is affected, inspect sequence numbers, duplicate acknowledgements and retransmissions to distinguish genuine loss from possible spurious recovery.
Document the exact test method, packet rate, packet size, destination and observation point so repeated measurements are comparable.
Can WiFi cause packet reordering?
It can contribute. Wireless links may retransmit frames after errors, changing when an affected packet becomes available to higher layers. RFC 4737 explicitly identifies layer 2 retransmission as one mechanism that can produce reordering. Whether a particular WiFi connection actually shows meaningful reordering depends on implementation and conditions.
This is another reason to diagnose broadband performance over wired Ethernet first. If the behaviour disappears on Ethernet, the investigation can move toward the wireless link rather than the wider internet path.
Can load balancing cause packet reordering?
Yes, if packets belonging to the same flow are distributed across paths whose delays differ enough for one packet to overtake another. Well-designed per-flow load balancing normally tries to keep a flow on a consistent path specifically to avoid this type of problem, but parallel forwarding and path changes can still create reordering in some circumstances.
Is packet reordering always a fault?
No. IP does not promise in-order delivery, so a small amount of reordering is not automatically evidence that a network is broken. The engineering question is whether the frequency and extent are sufficient to trigger retransmissions, exceed a real-time buffer, reduce throughput or otherwise affect the application.
Trying to force perfect in-order delivery at every lower layer can also have a cost. The August 2026 IETF Internet-Draft on reordering warns that resequencing mechanisms can introduce delay, and argues that modern higher-layer protocols can tolerate more out-of-order delivery than older guidance sometimes assumed.
Common packet reordering misconceptions
Reordering does not mean the packet was lost.
A higher ping does not automatically mean packets were reordered.
Jitter and packet reordering are related through variable delay but are not the same metric.
Different forward and return routes do not automatically mean packets within either direction are out of order.
A speed test result cannot by itself prove or disprove packet reordering.
Zero packet loss does not prove packets arrived in sequence.
Some reordering can be tolerated without a visible problem, especially when transport or application buffering absorbs it.
Frequently asked questions
What is packet reordering in simple terms?
Packet reordering is when packets arrive in a different sequence from the one in which they were sent. For example, 1, 2, 3, 4 might arrive as 1, 3, 2, 4.
Does packet reordering mean packet loss?
No. A reordered packet can arrive successfully but later than a packet that was sent after it. Loss means an expected packet does not arrive at the observation point.
Can packet reordering reduce download performance?
It can. Severe reordering can interfere with transport loss detection, trigger unnecessary retransmission or recovery behaviour and reduce useful throughput. The impact depends on the transport implementation and the extent of reordering.
Does packet reordering affect gaming and calls?
It can when packets arrive too late for the application's buffering strategy. Small amounts may be absorbed, while larger or deeper reordering can contribute to glitches or delayed delivery.
Can a router cause packet reordering?
Potentially. Parallel processing, multiple queues, scheduling or changing forwarding paths can alter relative packet timing. A router is only one possible point along the path.
How do I distinguish reordering from loss?
Use sequence-aware measurements or packet captures. A packet that appears missing at first but arrives later is reordered; a packet that never arrives is lost under that observation.
Should I contact my ISP if I see reordered packets?
Not from one isolated observation. First eliminate WiFi and local traffic, repeat measurements, test multiple destinations and establish whether the behaviour is persistent and where it appears to begin.
Key takeaway
Packet reordering is a change in arrival sequence, not automatically a loss event. It can be created by unequal path delays, retransmissions, parallel processing, queueing or route changes. Modern networks and transports can tolerate some reordering, but deeper or frequent events can still harm TCP efficiency and real-time applications. Diagnose it with sequence-aware evidence and always separate it from latency, jitter and packet loss.
To explore the related technical concepts used in this Packet Reordering guide, visit our broadband terminology guide.
