2026-06-02

TCP Out-of-Order vs Retransmission in PCAP: How to Tell Reordering from Packet Loss

How to distinguish TCP out-of-order packets, retransmissions, duplicate ACKs, SACK blocks, delayed packets, packet loss, and capture artifacts in PCAP analysis.

Wireshark labels such as Out-Of-Order, Retransmission, Duplicate ACK, and Previous segment not captured are interpretations of one capture, not ground truth. Use sequence ranges, arrival order, ACK/SACK progress, retransmission timing, and the capture location to separate genuine TCP packet loss from reordering or local capture loss. The trace can prove what this sensor saw and how endpoints reacted; it cannot prove the original segment was absent from every link in the path.

The difference matters. Packet loss means data disappeared and had to be sent again. Reordering means data arrived in a different order. Capture artifact means the capture did not see every packet even if the endpoint did. Each diagnosis points to a different fix.

PCAP Surgery is useful in this workflow because you often need to isolate the conversation, preserve timestamps, avoid deleting the packets that explain the sequence gap, and share a smaller capture without breaking the evidence.

TCP sequence numbers are the source of truth

TCP is a byte stream. Every data byte has a sequence number. Packet analysis depends on the relationship between:

Sequence number
Segment length
ACK number
SACK blocks
Timestamp
Direction
Capture point

Labels are interpretations of these facts. When a label looks suspicious, inspect the sequence and ACK numbers directly.

What out-of-order means

Out-of-order means a later segment arrived before an earlier segment. For example:

Sender -> Receiver: Seq 1000 Len 1000
Sender -> Receiver: Seq 3000 Len 1000
Sender -> Receiver: Seq 2000 Len 1000

The segment starting at 3000 arrived before the segment starting at 2000. If the missing segment arrives soon, TCP can continue without retransmission. Some reordering is tolerable. Too much reordering can trigger duplicate ACKs and unnecessary retransmissions.

What retransmission means

Retransmission means the sender sent data with a sequence range that appears to have been sent before. This may happen because:

The original packet was lost.
The ACK was lost.
The original packet was delayed and arrived late.
The receiver sent duplicate ACKs.
The sender's retransmission timeout fired.
The capture missed the original packet.

A retransmission label does not automatically prove network loss. It proves repeated sequence bytes were observed from the sender.

Duplicate ACKs and fast retransmission

Duplicate ACKs are receiver feedback. They often mean the receiver saw later data but is still missing an earlier sequence range.

If the sender receives enough duplicate ACKs, it may perform fast retransmission. This is usually faster than waiting for a timeout.

Look for:

A gap in received sequence numbers.
Multiple ACKs for the same next expected sequence.
SACK blocks showing later data received.
A retransmission of the missing range.
Recovery after retransmission.

This pattern is strong evidence of loss or reordering severe enough to look like loss.

SACK blocks clarify the picture

Selective Acknowledgment helps the receiver say: "I am still waiting for byte X, but I did receive these later ranges."

SACK blocks can show that the receiver got data after the missing gap. That helps distinguish:

True missing segment.
Out-of-order arrival.
Capture point missing a packet.
Delayed segment that arrived after duplicate ACKs.

If SACK is enabled, use it. It is one of the clearest tools in TCP loss analysis.

Previous segment not captured

Previous segment not captured often means the analyzer expected a sequence range that is not present in the capture. That can mean packet loss, but it can also mean capture loss.

Ask:

Was the capture started after the connection began?
Did the capture tool report dropped packets?
Was the capture taken on a busy host?
Is offload changing the visible packet shape?
Does the other endpoint's ACK behavior prove it missed the data too?

If the receiver ACKs data that your capture never saw, your capture point likely missed packets or started late.

Reordering patterns

Reordering can happen because of:

Equal-access multipath routing.
VPN or tunnel behavior.
Wi-Fi retransmission and aggregation.
Load-balanced paths.
Driver or offload behavior.
Virtual switches.
Capture point placement.

Occasional small reordering may not matter. Repeated reordering that triggers fast retransmissions can reduce throughput and look like packet loss to applications.

Measure how often it happens and how large the reordering gap is.

Capture point matters

A sender-side capture can show what the sender transmitted. A receiver-side capture can show what arrived. A middle capture can show what passed that point. None of them alone always proves the entire path.

For difficult cases, compare two captures:

Near sender
Near receiver

If the sender capture shows a packet and the receiver capture does not, the packet disappeared between them. If the sender capture does not show it but the receiver capture does, the sender-side capture missed it or offload changed visibility.

Offload artifacts

TCP segmentation offload and large receive offload can affect host captures. You may see large synthetic packets or checksum warnings that do not represent wire-level packets exactly.

Do not overreact to offload artifacts. Focus on sequence continuity, ACK behavior, SACK blocks, timing, and whether the peer behaved as if data was missing.

Checklist for out-of-order vs retransmission analysis

Use this order:

Identify the exact TCP conversation.
Confirm where the capture was taken.
Check whether capture started before the issue.
Inspect sequence numbers around the first warning.
Inspect ACKs and duplicate ACKs.
Inspect SACK blocks if present.
Determine whether the original missing segment arrived late.
Determine whether the sender retransmitted because of duplicate ACKs or timeout.
Check capture drop statistics and offload context.
Use a second capture point if exact loss location matters.

Why capture editing must preserve sequence context

If you trim a trace too aggressively, you can remove the packet that proves whether the segment was lost, delayed, or merely not captured. Keep enough packets before and after the warning to preserve the sequence story.

PCAP Surgery is meant for this kind of evidence-preserving workflow. The goal is to reduce noise without destroying the TCP context.

Final diagnosis

TCP out-of-order, retransmission, duplicate ACK, and previous-segment warnings are not interchangeable. The correct diagnosis depends on sequence numbers, ACK behavior, SACK blocks, timestamps, capture point, and capture quality.

PCAP Surgery helps turn a noisy trace into a focused packet story so teams can distinguish real packet loss from reordering, delayed delivery, offload artifacts, or missing capture data.

Sequence-range decision table

Track byte ranges, not packet colors. Suppose the receiver expects sequence 1000, observes 2000–2999, then later receives 1000–1999. If the later segment is the original transmission arriving late, that is reordering. If the sender emitted a second copy after duplicate ACKs or an RTO, retransmission occurred; the original may still have been lost or delayed.

Evidence pattern	Best bounded interpretation
Later range arrives, then original range arrives before resend	Reordering observed
Duplicate ACK/SACK followed by sender copy of missing range	Retransmission observed
Original and copy both arrive; DSACK acknowledges duplicate	Spurious or delayed-original scenario likely
“Previous segment not captured” with capture drops	Sensor incompleteness is plausible
Gap appears at one point but not another	Loss/capture issue is bounded between observers

Use TCP timestamp options, IP IDs, payload lengths, checksums where meaningful, and packet timing to distinguish original from retransmitted copies. Offload can alter segmentation, so compare byte coverage even when packet boundaries differ.

Does SACK prove packet loss?

SACK proves the receiver reported later byte ranges while a lower range was missing at that moment. It does not reveal whether the missing segment was lost, delayed, or absent only from the analyst’s capture. The later arrival and sender behavior complete the story.

What is DSACK useful for?

DSACK can indicate that the receiver got duplicate data. Combined with timing, it may show a retransmission was unnecessary because the original was delayed, or that both copies arrived. It remains endpoint-reported evidence, not a path location.

Can packet capture loss mimic network loss?

Yes. Check capture dropped-packet counters, CPU/storage pressure, ring buffers, offload, and whether ACK progress implies the receiver saw bytes absent from the trace. A second capture point can separate sensor loss from path behavior.

Regression and evidence handoff

Record flow, capture point, first unexpected sequence range, duplicate ACK/SACK sequence, original/later arrival, retransmission trigger, recovery time, and capture-drop counters. Compare healthy and affected flows through the same sensor.

Keep enough context before the gap to establish expected sequence and enough after it to show recovery. The packet-loss guide covers location evidence; capture scope help prevents a trimmed derivative from removing the decisive original or duplicate.

A worked classification method

Start at the first unexpected ACK, not the first highlighted retransmission. Write the receiver’s next expected byte, every later range observed, each duplicate ACK/SACK block, and the time the missing range appears. Then inspect sender timing to determine whether a resend was triggered by duplicate ACK threshold, RACK-like timing, or RTO.

If the original range arrives before the sender’s copy, classify reordering at that observer. If only the copy arrives and ACK progress follows, retransmission recovery is observed, while the original’s loss location remains unknown. If ACKs advance over data missing from the capture, suspect sensor loss or an unseen path. If both copies arrive and DSACK follows, investigate spurious retransmission or delayed original delivery.

How much reordering is harmful?

Impact depends on depth, duration, congestion control, and whether it triggers unnecessary retransmission or head-of-line waiting. Report the maximum displaced byte range and delay rather than only the number of out-of-order labels.

Can multipath cause reordering?

Yes. Link aggregation, ECMP changes, bonding, tunnels, and multipath transports can produce different delays. Correlate path/interface data and determine whether the receiver recovers without loss-driven congestion response.

A useful report says “segment range X arrived Y ms after later range Z and before any sender copy” or “sender retransmitted X after three duplicate ACKs; original X was not observed at this sensor.” Those are reviewable facts.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: