2026-06-03

TCP SACK and DSACK in Wireshark: Diagnose Packet Loss, sack_perm Option, and Retransmission in PCAPs

Diagnose TCP SACK, DSACK, and sack_perm options in Wireshark PCAPs. Covers selective acknowledgments, packet loss recovery, reordering, duplicate ACKs, and spurious retransmissions.

Duplicate ACKs and retransmissions become more informative when TCP SACK blocks identify the byte ranges the receiver already holds. Reconstruct those ranges across ACKs, then use DSACK to test whether a retransmitted segment was actually a duplicate caused by reordering or an overly aggressive timeout. This packet evidence can distinguish selective loss, reordering, and a likely spurious retransmission at the observed path; it still cannot locate the responsible hop from one trace.

PCAP Surgery is useful because SACK evidence is carried in TCP options. If you trim away the wrong packets, lose the handshake, or separate ACKs from data, the diagnosis becomes weaker.

What SACK adds

Traditional TCP ACKs acknowledge the next expected byte. If one segment is missing but later segments arrive, the receiver can only keep ACKing the gap.

SACK lets the receiver say: "I am still missing this earlier range, but I have received these later ranges."

This helps distinguish:

Actual packet loss.
Out-of-order delivery.
Duplicate packets.
Receiver behavior.
Sender recovery behavior.

SACK must be negotiated

SACK capability is negotiated in the SYN and SYN-ACK. If the capture starts after the handshake, you may not know whether SACK was permitted.

Always preserve:

SYN.
SYN-ACK.
SACK permitted option.
Window scale option.
Timestamp option if present.

This is why a "small pcap around the retransmission" can be insufficient.

Duplicate ACKs with SACK blocks

Duplicate ACKs do not all mean the same thing. A duplicate ACK with SACK blocks can tell the sender exactly which later byte ranges arrived.

Evidence to inspect:

ACK number.
SACK left edge and right edge.
Repeated SACK blocks.
New SACK information.
Whether missing data later appears.
Whether retransmission fills the gap.

This is much stronger than just counting duplicate ACKs.

Packet loss vs reordering

If a segment arrives late but not lost, SACK may show later data was already received. The sender may retransmit, and then the original packet may also arrive. That can look messy.

Questions:

Did the original segment arrive late?
Did the retransmission arrive first?
Did DSACK later report duplicate data?
Is there a path that reorders packets?
Are bursts crossing multiple links, tunnels, or load-balanced paths?

PCAP Surgery can help isolate the exact sequence range and compare packet order.

What DSACK means

Duplicate SACK can report that duplicate data was received. This is useful for identifying spurious retransmissions or reordering.

DSACK evidence may suggest:

Sender retransmitted unnecessarily.
Network delivered original data late.
Capture point saw duplicates.
Receiver got both original and retransmitted bytes.
Middlebox duplicated packets.

That is a different conclusion from "the packet was lost."

Spurious retransmissions

A retransmission is not always proof of loss. It may be triggered by:

Reordering.
Delayed ACK behavior.
Capture offload artifacts.
Too-small retransmission timeout.
ACK compression.
Virtualization timing.
Path asymmetry.

SACK and DSACK help prove whether data was truly missing or just late.

Capture point matters

If the pcap is one-sided or taken behind a NAT, SACK interpretation can be tricky. A packet may be absent from your capture point but present at the receiver.

Useful practice:

Compare sender-side and receiver-side captures.
Keep timestamps synchronized.
Preserve sequence numbers.
Avoid trimming out ACK-only packets.
Note offload and capture location.

SACK analysis without ACK packets is not analysis.

Debug checklist

Use this workflow:

Keep the TCP handshake.
Confirm SACK permitted.
Find first duplicate ACK.
Decode SACK blocks.
Map SACK ranges to data packets.
Identify retransmitted sequence ranges.
Check for DSACK.
Separate loss from reordering.
Check capture point and offload context.
Preserve before/after packets around the recovery event.

Reconstruct one loss hypothesis at a time

SACK analysis is strongest when it answers a bounded question: which byte range was missing at the receiver, what later ranges were already present, and which packet eventually filled the gap? Start from the first ACK that repeats the same cumulative acknowledgment, then write down every SACK block in order. Map each left/right edge to the original data sequence range before looking at Wireshark's retransmission labels. Those labels are useful hints, not evidence that a packet was lost on the network.

Pattern	Packet-level interpretation	Claim that is justified	Claim that is not justified
Cumulative ACK stalls; SACK blocks advance beyond it	Later bytes arrived while an earlier range is absent	Receiver observed a gap in this flow	A particular router dropped the packet
Retransmission fills the gap; ACK advances	Sender recovery likely completed	The missing sequence range became available	The original packet never arrived
DSACK reports the retransmitted range	Receiver saw duplicate bytes	Retransmission may have been spurious or original data was late	Every duplicate is network duplication
No SACK-permitted option in preserved handshake	Capability is unknown or unavailable	This trace cannot support a SACK-based conclusion	SACK was disabled by a specific endpoint
Sender and receiver captures disagree	Capture location changes visibility	One vantage point is incomplete	Either host is necessarily wrong

Sequence arithmetic prevents a frequent error: a SACK block is expressed as byte edges, not packet numbers. A large TCP segment, segmentation offload, or application write may cover more than one observed frame. Normalize every item to sequence start, sequence end, payload length, capture time, and direction. Then inspect whether the alleged retransmission covers the same byte interval or only overlaps it. An overlapping retransmission can be normal recovery; a DSACK for the exact interval is more relevant to a spurious-retransmission hypothesis.

Capture-quality checks before drawing a graph

Keep ACK-only packets. They often carry the decisive SACK blocks and are easy to remove with a display filter or over-aggressive export. Preserve the SYN and SYN-ACK so SACK Permitted, window scale, and timestamps are known. Record whether NIC offload, virtual switching, tunneling, or load balancing affects the capture point. A host-side trace can show coalesced or delayed packets that do not mirror wire order, while a middlebox trace can miss the return path that explains the ACK pattern.

When a case is large, create a small evidence window rather than a random slice: include the handshake if available, the first gap, at least one complete recovery cycle, and the ACKs immediately after it. The PCAP capture-scope guide explains how to retain that window, and the TCP retransmission analysis helps distinguish a wire symptom from a tool label.

Questions a final report should answer

Is this loss or reordering? State the observed facts first: the sequence gap, SACK blocks, arrival order, retransmission interval, and DSACK presence. If the original segment arrived after a retransmission and DSACK confirms a duplicate range, reordering or a spurious retransmission is a stronger working hypothesis than simple loss. If the original never appears at the available capture points, call it an observed gap rather than inventing the failing hop.

Can three duplicate ACKs prove loss? No. Duplicate ACK count is a recovery signal, not a root cause. SACK progression, capture position, and retransmitted sequence coverage provide the context needed to say what the receiver had already seen.

What should be exported for escalation? Include a bounded PCAP, a table of sequence ranges and SACK blocks, capture topology, timestamps, and the exact claim boundary. That produces an evidence package another engineer can replay instead of a screenshot with unexplained red retransmission markers.

Avoid false certainty from capture timing

Host timestamps are observations, not an authoritative wire clock. CPU pressure, packet batching, virtualization, NIC offload, and asynchronous capture writers can change apparent arrival order. That does not make a capture useless; it defines the strength of its conclusion. Say “the sender-side trace observed the original segment after the retransmission” rather than “the network reordered the packet” unless a second capture point supports that wider claim.

When possible, align two captures with a shared event, preserve time-zone and clock metadata, and compare the same TCP sequence ranges rather than matching frame numbers. The recipient can then test whether the apparent gap exists at both edges of the path. If only one capture is available, retain enough context to explain the limitation and focus remediation on what is observable: recovery timing, retransmission behavior, or the need for a better capture location.

This evidence-first wording is especially important for SACK because the option reveals receiver state, not every network event. It lets a report be specific about bytes and ACK behavior without claiming to identify a packet-dropping hop that the PCAP never observed.

Before sharing the result, verify that sequence numbers use one consistent convention. Relative numbers are easier to read; absolute numbers can help a second capture correlate the same bytes. State which form the report uses and retain the original PCAP so another engineer can translate the table without guessing offsets. That check keeps a correct SACK interpretation reproducible.

Final diagnosis

TCP SACK and DSACK provide precise evidence for packet loss, reordering, duplicate delivery, and spurious retransmissions. The key is to preserve handshake options, ACK-only packets, SACK blocks, and retransmitted sequence ranges.

PCAP Surgery helps keep that evidence intact so TCP loss analysis can move beyond generic duplicate ACK counts.

What should the final SACK/DSACK finding contain?

Name the flow, capture point, negotiated SACK-permitted option, cumulative ACK, each relevant SACK block, retransmitted sequence range, and whether DSACK later reported duplicate delivery. Explain capture loss or offload limitations explicitly. Then classify the bounded window as evidence of likely network loss, reordering, sender spurious retransmission, receiver duplicate data, or insufficient capture visibility. Save the untouched source and the failure-window subset so another reviewer can verify the same sequence arithmetic.

Include absolute and relative sequence-number notation in the report so the calculation can be repeated independently.

Record the TCP direction.

Keep the source.

Practical questions

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

Related guides

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