TCP Retransmission Analysis: Prove the Cause

TCP retransmission analysis begins by proving that the sender transmitted the same byte range again. It ends only after you determine whether the retry reflects network loss, delayed feedback, packet reordering, a capture artifact, or a sender decision, and whether it materially affected the application.

Wireshark's tcp.analysis.* fields are valuable analysis hints. They are not omniscient endpoint telemetry. Wireshark infers TCP state from the packets visible at one capture point, which may be incomplete, duplicated, reordered, or affected by offloading.

Start with the relevant filters

Useful Wireshark filters include:

tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.spurious_retransmission
tcp.analysis.duplicate_ack
tcp.options.sack
tcp.analysis.ack_lost_segment
tcp.analysis.out_of_order

Use them to locate candidate events, then remove or widen the filter and inspect the complete stream. A filtered list can hide the original data, intervening acknowledgments, window updates, and application timing needed to explain the retry.

Confirm the retransmitted byte range

For the candidate packet, record:

• TCP stream
• sender and receiver
• sequence number
• TCP payload length
• timestamp
• acknowledgment number
• SACK blocks if present
• relevant TCP flags and options

Find the earlier packet covering the same sequence range. Confirm that both packets carry the same bytes or at least the same sequence interval. A packet labeled retransmission can overlap prior data without being an identical frame.

Then build the sequence from the original transmission through the acknowledgment of that byte range.

Distinguish the main recovery patterns

Fast retransmission

Traditional fast retransmit follows duplicate acknowledgments indicating a gap at the receiver. SACK can identify which later byte ranges arrived beyond the gap. Modern TCP implementations can use more advanced loss-detection behavior, but the visible evidence still centers on sequence progress and feedback.

In this simplified sequence, three later segments extend the SACK range while the cumulative acknowledgment remains at the missing byte range. The retransmission fills the gap and cumulative acknowledgment advances.

Inspect:

• duplicate ACK count and acknowledgment number
• SACK blocks covering later data
• time from original segment to retry
• whether the receiver eventually acknowledges the missing range

Do not assume every duplicate ACK means loss. Reordering, duplication, and capture artifacts can produce similar traces.

Retransmission timeout

RFC 6298 defines the standard TCP retransmission timer based on smoothed RTT and RTT variation. An RTO event usually shows a longer silent period followed by retransmission of the earliest unacknowledged data, with exponential backoff after repeated timeout.

An RTO can create a conspicuous application stall. Confirm that the sender had outstanding data, received no covering acknowledgment, and retried after a delay consistent with timeout behavior.

SACK-based and modern loss recovery

Selective acknowledgment lets the receiver report blocks received beyond a gap. RFC 8985 specifies RACK-TLP, a time-based loss-detection approach used by modern TCP stacks.

A packet trace may therefore show recovery behavior that does not fit a simple “three duplicate ACKs, then fast retransmit” story. Use visible sequence and timing evidence, and avoid claiming the endpoint's exact internal algorithm unless endpoint telemetry confirms it.

Spurious retransmission

Wireshark may label a packet spurious when the visible acknowledgment history suggests the data was already acknowledged. Possible explanations include:

• delayed or reordered capture packets
• ACK visible at the analyzer but not at the sender before the retry
• duplicated traffic on a SPAN or aggregation path
• capture taken at a point with asymmetric timing
• sender behavior such as tail-loss probing
• incorrect state caused by missing earlier packets

The Wireshark spurious retransmission guide explores this case in detail.

Rule out capture artifacts

Before blaming the path, check:

• capture drop counters
• whether both directions are present
• missing packets acknowledged by the peer
• duplicate frames with identical IP IDs, sequence numbers, and timestamps
• packet reordering introduced by multi-interface or aggregated capture
• TCP segmentation offload and generic receive offload on endpoint captures
• checksum offloading
• SPAN oversubscription
• packet slicing

If the receiver acknowledges data whose original segment is absent from the trace, the network delivered something the analyzer did not see. That is evidence of a capture gap or another unseen transmission, not proof of path loss.

Locate the loss domain with two capture points

A single capture can establish that recovery occurred on the observed connection. It often cannot identify which device or link lost the packet.

With synchronized captures near sender and receiver:

• packet present near sender but absent near receiver supports loss between points
• packet present at receiver and ACK returned there, but ACK absent near sender, supports reverse-path loss between points
• packet absent at the first capture suggests sender, host stack, or first capture boundary
• timing differences can expose queuing or delayed forwarding

Account for different timestamp clocks, offloading, asymmetric routes, and capture loss before comparing frame arrival times.

Correlate recovery with application impact

Counts are not enough. Determine whether each event overlaps:

• a flat section in TCP sequence progress
• reduced transfer throughput
• a request or response timeout
• delayed first response byte
• a voice or video quality event
• an application retry or connection abort

A capture with 500 retransmissions across background transfers may contain no recovery event in the affected transaction. Another capture with one RTO in a login exchange may explain the entire user-visible pause.

Use the slow-application troubleshooting workflow to place TCP recovery inside the wider transaction timeline.

Compare with a healthy flow

Choose a baseline with the same application, endpoints or roles, capture position, path, and approximate transfer size. Compare:

• RTT and RTT variation
• sequence progress
• retransmitted ranges
• SACK behavior
• advertised receive window
• server or application wait
• total transaction outcome

Repeated analysis flags in both healthy and affected flows may indicate a capture artifact or tolerated background condition. A recovery pattern unique to failures increases confidence but still requires exact packet validation.

Write a defensible conclusion

Separate observation, interpretation, and limitation:

Stream 42 retransmits bytes 186721-188180 after no covering ACK is visible for the original segment. The receiver's duplicate ACKs and SACK blocks show later data arriving beyond that range, and the retry aligns with a 620 ms pause in sequence progress. This supports loss or severe reordering of the original segment between the observed endpoints. The client-side capture does not identify the device or link responsible.

That conclusion is useful because another analyst can inspect the byte range, ACK history, timing, and capture boundary.

Avoid conclusions such as “Wireshark found 37 percent packet loss.” Retransmission count is not equivalent to unique packets lost, and a one-sided trace rarely measures end-to-end loss directly.

Verification checklist

• Did you identify the original and repeated sequence range?
• Was a covering ACK visible before the retry?
• Did SACK show later data beyond a gap?
• Does timing fit fast recovery, timeout, or another sender behavior?
• Could capture drops, duplication, reordering, or offloading explain the trace?
• Did the event affect the reported application transaction?
• Was a healthy baseline compared?
• Does the conclusion stop at the observed capture boundary?

PacketSafari performance analysis correlates TCP recovery, transaction timing, exact frames, alternatives, and capture quality in one investigation. Use the same representative capture to verify every automated TCP finding in Wireshark.