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

TCP packet captures often contain labels such as Out-Of-Order, Retransmission, Fast Retransmission, Duplicate ACK, and Previous segment not captured. These labels are useful, but they can also lead to quick misdiagnosis. Users search for "TCP out of order vs retransmission", "Wireshark TCP previous segment not captured", "duplicate ACK packet loss", and "how to tell packet loss from reordering" because a trace can look bad even when the network did not actually drop the original packet.

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-cost 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:

1. Identify the exact TCP conversation.
2. Confirm where the capture was taken.
3. Check whether capture started before the issue.
4. Inspect sequence numbers around the first warning.
5. Inspect ACKs and duplicate ACKs.
6. Inspect SACK blocks if present.
7. Determine whether the original missing segment arrived late.
8. Determine whether the sender retransmitted because of duplicate ACKs or timeout.
9. Check capture drop statistics and offload context.
10. 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.