2026-06-02

TCP Retransmission and Duplicate ACK Analysis in PCAP

Learn how to analyse TCP retransmissions, duplicate ACKs, fast retransmit, SACK, packet loss, and reordering in a PCAP without assigning blame beyond the evidence.

TCP retransmission and duplicate ACK analysis begins with a restraint: a Wireshark label is an observation aid, not a verdict about the server, client, or network. A capture can reveal that a sender retransmitted bytes, that a receiver continued to acknowledge an earlier sequence number, or that packets arrived in a surprising order at one capture point. It cannot, by itself, identify the physical hop that discarded a packet or prove that an application is defective.

That distinction matters when a slow API call, a broken upload, an RTSP ingest stall, or an intermittent VPN complaint reaches an engineering team. The useful output is a small, reproducible packet-evidence case: which direction carried the missing sequence range, when recovery happened, what the receiver acknowledged, where the trace was captured, and which conclusions remain uncertain.

This guide uses the phrases TCP retransmission, duplicate ACK, fast retransmit, packet loss, and PCAP analysis in their practical troubleshooting sense. It also explains when those labels can be caused by reordering or a capture artifact rather than loss on the live path.

The short answer: read the sequence before counting the labels

A duplicate ACK normally means that a TCP receiver received data beyond a gap and is still acknowledging the next byte it expects. Repeated duplicate ACKs can prompt the sender to retransmit the missing range before its retransmission timer expires. That sequence is valuable evidence of recovery, but it does not automatically answer why the receiver lacked the earlier bytes.

Start by answering five questions:

Which data direction contains the apparently missing sequence range?
Which host sent the duplicate ACKs, and which host received them?
Does a retransmission actually fill that gap at the observed capture point?
Does SACK or DSACK add evidence about later or duplicate byte ranges?
Was the capture taken at the sender, receiver, proxy, firewall, mirror port, or an unknown middle point?

If those questions are not recorded, a statement such as “the server has retransmissions” is too weak for a handoff.

TCP retransmission and duplicate ACK terms

Term in a packet analysis view	What the trace can support	What it does not prove alone
Retransmission	A sender sent a sequence range again after the analyzer's expected timing/order	The sender caused loss or the network discarded the first copy
Duplicate ACK	A receiver repeated an ACK number, often while later bytes had arrived	Which hop lost the earlier segment
Fast retransmit	A retransmission followed a run of duplicate ACKs quickly enough to suggest loss recovery	That exactly three duplicate ACKs occurred on every path
Out-of-order packet	Packets appeared in a non-monotonic sequence order at this capture point	The application experienced a loss or delay
SACK block	The receiver reported a later byte range it already holds	The initial missing segment was permanently lost
DSACK	The receiver reported duplicate data	Whether duplication came from reordering, a retransmission, or the capture setup without more context
RTO retransmission	A sender resent data after waiting for a retransmission timeout	The peer or application was unavailable

Packet analyzers infer several of these labels from the packets they can see. A trace that starts after the handshake, misses one direction, or drops packets at the capture interface reduces the certainty of those inferences.

Build a defensible PCAP analysis window

Do not begin with a one-packet screenshot. Preserve enough context to include the TCP handshake where possible, the first affected application request, the recovery sequence, and a short period after recovery. The initial SYN and SYN-ACK can show negotiated options such as window scaling, timestamps, and SACK permission. Without them, later SACK evidence may be less clear.

For an incident handoff, note the following before applying a display filter or exporting a subset:

Evidence item	Why it belongs in the case
Capture host and interface	Explains whether this is sender-side, receiver-side, or an intermediate view
Time source and timezone	Makes multi-capture comparison possible
Five-tuple and stream identifier	Prevents unrelated connections from being mixed together
Start and end packet numbers	Lets another engineer reproduce the observation
Missing or sampled directions	Sets a limit on conclusions
Offload or mirror-port notes	Flags possible capture-order artifacts
Relevant application timestamp	Connects transport recovery to the user-visible symptom without claiming causation

Use PCAP capture scope to decide what must remain in an exported case. If the file needs to be trimmed or anonymized, preserve the original separately and retain a record of the transformation. The timestamp rewrite evidence guide explains why time edits require an explicit evidence trail.

Follow the byte gap, not the color or warning label

Suppose a sender transmits sequence ranges 1000–1999, 2000–2999, and 3000–3999. If the receiver sees the first and third ranges but not the second, it may acknowledge 2000 repeatedly. If selective acknowledgment is active, it can also report that it already has 3000–3999. The sender may then resend 2000–2999.

The key object is the byte gap: which range was expected, which later ranges arrived, and whether the repeated copy repaired the observed gap. This is more reliable than the number of packets marked “TCP Retransmission,” especially when segmentation sizes differ.

A practical review sequence is:

Isolate one TCP conversation and identify the client-to-server and server-to-client data directions.
Locate the first duplicate ACK or retransmission label near the user-visible delay.
Read sequence number, next expected ACK number, payload length, and timestamp for the preceding data packets.
Mark the missing sequence range and list any later ranges received before it.
Check whether a retransmitted segment covers that range and when the cumulative ACK advances.
Look for another occurrence of the same pattern later in the stream.
Record the observation in words that remain true at the capture point.

For example: “At the client-side capture point, the client repeated ACK 2000 after receiving later server-to-client bytes. The server then resent bytes 2000–2999; the client’s cumulative ACK advanced afterward.” That is much stronger and more honest than “the server lost a packet.”

Interpret direction correctly

Duplicate ACK direction is easy to reverse mentally. The host sending duplicate ACKs is generally the host waiting for an earlier byte range. The original data associated with that gap traveled in the opposite direction.

Observed pattern	A reasonable next investigation	Do not jump to
Client sends duplicate ACKs for server data	Inspect server-to-client path, server NIC/capture, and client receive path	“The client is retransmitting”
Server sends duplicate ACKs for client data	Inspect client-to-server path, client send path, and server receive path	“The server dropped the upload”
Both directions retransmit	Check congestion, duplex/physical errors, asymmetric capture, CPU pressure, and application burst behavior	A single faulty device
Retransmissions appear only in one middlebox trace	Compare capture placement and mirror/offload behavior	End-host packet loss
Delay exists before any retransmission	Inspect application response time, DNS, connect time, flow control, and server work	TCP loss as the primary cause

The HTTP slow request and TTFB PCAP guide is useful when the visible symptom is latency rather than a failed stream. Transport recovery may occur after the application was already waiting on a different dependency.

Fast retransmit, timeout retransmission, and the timing story

Fast retransmit is a sender reaction to repeated duplicate ACK evidence. A retransmission timeout is a sender reaction to an ACK not arriving within its timer. Both can place a second copy of data on the wire, but their timing tells a different story.

Recovery shape	What to inspect	Why it matters
Duplicate ACKs followed quickly by a resend	ACK count, SACK blocks, gap size, cumulative ACK after resend	Often consistent with gap recovery before timer expiry
Long quiet interval followed by resend	RTT estimate, timer interval, missing return traffic	May be timeout-driven, but capture loss can imitate it
Repeated resend of the same range	Whether any ACK progress occurred, receiver window, connection reset	Shows persistent lack of observed recovery, not necessarily the reason
Many small resends during a busy transfer	Congestion window, SACK, burst timing, packet size pattern	Helps distinguish a local event from a broad throughput issue

Never estimate an RTO from wall-clock intuition alone. Use the packet timestamps in the same capture and state whether timestamp resolution or capture load could distort them. If two captures are compared, validate host clocks before treating a cross-host time difference as network delay.

Use SACK and DSACK to challenge a simple loss story

Selective ACK (SACK) makes duplicate ACK evidence more specific. A receiver can acknowledge the first missing byte while describing later byte ranges it has already received. When SACK is visible, record the left and right edges of the blocks as the incident evolves.

DSACK can report that duplicate data reached the receiver. This may be consistent with a spurious retransmission caused by reordering, a late original segment, a duplicated packet, or a retransmission that arrived after the original. It is a reason to slow down, not a reason to announce a culprit.

Review these cases side by side:

PCAP pattern	Most careful interpretation
Duplicate ACKs, SACK blocks for later bytes, retransmission, ACK advances	The observed receiver was missing a range and later accepted a copy that restored cumulative progress
Later original packet arrives before resend, then DSACK appears	Reordering or a spurious resend is plausible; verify capture placement
No SACK negotiation visible because handshake is missing	Treat lack of SACK blocks as inconclusive, not as proof SACK was disabled
Duplicate ACKs with no later data or SACK	Could be repeated acknowledgments for several reasons; inspect full stream context
Analyzer marks retransmission but sequence range differs after segmentation	Check relative sequence numbers, payload length, and offload behavior before counting loss events

The companion TCP SACK and DSACK PCAP analysis goes deeper into selective acknowledgment evidence and reordering. Keep both pages with the same case so a reviewer can see the reasoning boundary.

Rule out reordering and capture artifacts before escalating loss

Out-of-order packets are not necessarily lost packets. Parallel paths, link aggregation, tunnels, virtual switches, receive-side scaling, and mirror ports can change the order in which an observer sees frames. NIC checksum/segmentation offload can also make host captures look different from packets on the wire.

Before escalating a “packet loss” finding, ask:

Is the trace at an endpoint, and was hardware offload considered?
Is the trace from a SPAN/TAP that may oversubscribe or drop mirrored packets?
Is there evidence from a second capture point with synchronized clocks?
Do SACK/DSACK details suggest the original packet arrived late?
Does the same range appear absent at both endpoints, or only at one observer?
Does the pattern repeat across independent streams and time windows?

A two-sided capture can strengthen the case, but it must preserve direction, time basis, and capture-loss caveats. Do not merge files merely because their wall-clock timestamps look similar. Use a documented alignment method and retain source copies.

A QA checklist for a TCP retransmission incident

Before sharing a PCAP or opening a network ticket, verify the following:

The conversation is identified by both endpoints, ports, protocol, and capture interval.
The capture point is stated, including any proxy, VPN, load balancer, or mirror port between endpoints.
The first affected byte range is documented rather than only packet numbers or analyzer labels.
Duplicate ACK direction and retransmitted-data direction are described separately.
SACK/DSACK evidence is retained when it exists, along with handshake context if available.
The report distinguishes observed facts, plausible explanations, and facts that need another capture or host metric.
Any exported PCAP remains reproducible from a preserved original and a documented edit.

PCAP Surgery helps organize a case around this evidence instead of forcing a premature diagnosis. Use the overview for the workbench path, capture scope before exporting a subset, and the blog index for related TCP, HTTP, TLS, and timing investigations.

Frequently asked questions

Do duplicate ACKs always mean packet loss?

No. They often appear when a receiver has a gap, but the missing packet may be delayed, reordered, absent from the capture, or actually lost. Sequence ranges, SACK/DSACK evidence, timing, and capture placement determine how strong the conclusion can be.

Is every TCP retransmission a server problem?

No. The server may have retransmitted because it did not observe an acknowledgment. The cause may be on the return path, at the receiver, in the network, or in the capture setup. State which endpoint sent the repeated data and what the trace directly shows.

What display filters are useful for initial PCAP analysis?

Analyzer fields such as tcp.analysis.retransmission, tcp.analysis.fast_retransmission, tcp.analysis.duplicate_ack, and tcp.analysis.out_of_order are useful starting points. Return to the surrounding sequence and ACK packets before treating any filtered result as a conclusion.

Should I trim a PCAP before sending it to another team?

You can create a controlled subset, but retain the original and preserve handshake, timing, and surrounding recovery context. A too-small file may remove the only evidence that distinguishes loss, reordering, or a timeout.

Related guides

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