How does Wireshark 4.6 decide to label a TCP segment Retransmission, Fast Retransmission, Spurious Retransmission or Out-Of-Order, and what do those labels depend on?
answer
- heuristics from one vantage point
- repeated bytes, then which kind
- duplicate ACKs and a time window
- already acknowledged in the capture
- iRTT or a 3 ms fallback
basics
~20 sWireshark 4.6 compares each segment with the sequence state it saw: resent bytes are a Retransmission, Fast after two duplicate ACKs, Spurious if already ACKed, Out-Of-Order if new and within the initial RTT. All are guesses from the capture point.
solid answer
~40 sEach label is a heuristic from the sequence analysis, so it needs the **Analyze TCP sequence numbers** preference (on by default) and both directions in the capture. A data segment whose sequence number is below the next one expected is a **Retransmission**. It becomes a **Fast Retransmission** when the reverse direction has shown at least two duplicate ACKs, the segment starts at the acknowledged edge and the last ACK was under 20 ms ago; a **Spurious Retransmission** when the capture already saw an ACK covering it; and **Out-Of-Order** when its bytes were not already in the capture and it arrived within the connection's iRTT (3 ms if no handshake was seen) of the peer's last ACK. Retransmissions are Notes, out-of-order a Warn, and the filter `tcp.analysis.retransmission` also matches the fast and spurious ones.
go deeper
Recall that the labels are Wireshark's guesses from sequence numbers seen in the capture, and that retransmission, fast and spurious are Notes while out-of-order is a Warn.
Explain each condition: below the next expected sequence, two duplicate ACKs within 20 ms for fast, already ACKed for spurious, within iRTT or 3 ms for out-of-order, plus the precedence between them.
Show that the vantage point changes the label, that one-way captures cannot tell fast from plain retransmissions, and that spurious retransmissions point away from path loss.
Frame these counts as evidence with known error bars: say where the capture was taken and which preferences were set before a retransmission rate goes into a post-incident review.
## What Wireshark is actually doing Wireshark does not know what the sender's TCP stack decided. It sees packets at one point on the path and, for every TCP conversation, keeps a little state per direction: the **next expected sequence number** (the last sequence number seen plus that segment's length) and the **last-seen acknowledgment number** from the other side. When a new segment does not fit that state, the TCP dissector attaches an analysis flag under **SEQ/ACK analysis > TCP Analysis Flags** and an expert item, and prefixes the Info column, for example `[TCP Retransmission]`. Every summary text says *suspected*: these are inferences. Why a sender retransmits at all (a timer expiry versus duplicate ACKs, how the timeout is computed) belongs to TCP itself; this answer is about how the analyser labels what it sees. ## The four labels and their conditions The Wireshark 4.6 user guide documents the conditions: | Label (Info prefix) | Field | Set when, in short | Severity | |---|---|---|---| | TCP Retransmission | `tcp.analysis.retransmission` | a non-keep-alive segment carrying data (or SYN/FIN) whose sequence number is below the next expected one | Note | | TCP Fast Retransmission | `tcp.analysis.fast_retransmission` | as above, plus at least **two** duplicate ACKs seen in the reverse direction, the sequence number equals the next expected acknowledgment, and the last ACK was seen **less than 20 ms** earlier | Note | | TCP Spurious Retransmission | `tcp.analysis.spurious_retransmission` | data segment (no SYN/FIN) whose bytes the capture has **already seen acknowledged** by the other side | Note | | TCP Out-Of-Order | `tcp.analysis.out_of_order` | below the next expected sequence, bytes **not already in the capture**, and arriving within the out-of-order threshold of the last ACK seen from the other side: the connection's **iRTT** (`tcp.analysis.initial_rtt`) if the handshake was captured, otherwise **3 ms** | Warn | Precedence matters because one packet can meet several conditions: - **Fast Retransmission** supersedes Out-Of-Order and Retransmission. - **Spurious Retransmission** supersedes Fast Retransmission, Out-Of-Order and Retransmission. - **Out-Of-Order** supersedes Retransmission. - **Keep-Alive** supersedes all of them, so a one-byte keep-alive is never counted as a retransmission. - A segment whose bytes the capture **already holds** is never labelled Out-Of-Order: if it is not fast or spurious, it is a plain Retransmission. When a capture is genuinely ambiguous between a fast retransmission and reordering, the TCP preference **Fast Retransmission supersedes Out-of-Order interpretation** (on by default) decides which label wins. ## Duplicate ACKs, which the labels lean on A **duplicate ACK** (`tcp.analysis.duplicate_ack`, a Note) is a segment with no data, no SYN, FIN or RST, on an established connection, whose window is non-zero and unchanged or which carries SACK data, repeating the previous acknowledgment number. The Info column reads `[TCP Dup ACK 57#3]`: the third duplicate of the ACK in frame 57. A burst of Dup ACKs followed by a Fast Retransmission is the analyser's picture of the receiver reporting a hole and the sender filling it. ## A filtering trap In the 4.6 dissector, a fast retransmission and a spurious retransmission each also add the plain retransmission expert item. So the display filter `tcp.analysis.retransmission` counts **all three kinds**, while `tcp.analysis.fast_retransmission` and `tcp.analysis.spurious_retransmission` count only their own. If you want only timer-style retransmissions, subtract the other two. ## What the labels depend on 1. **The preference.** All of these fields exist only while **Analyze TCP sequence numbers** is enabled in the TCP protocol preferences; it is on by default, and turning it off removes them, along with relative sequence numbers and bytes in flight. 2. **Both directions.** Fast and spurious detection read the reverse direction's ACKs. A capture that sees only one direction (asymmetric routing, a one-way mirror) cannot tell them apart from plain retransmissions. 3. **The capture point.** Near the receiver, a segment lost upstream shows first as a gap and then as a retransmission; near the sender, you see the original, the duplicate ACKs and the retransmission. The same event earns different labels at different vantage points. 4. **Timing.** The out-of-order threshold uses the iRTT measured from the captured handshake. Start the capture mid-connection and the 3 ms fallback applies, so on a 40 ms path a late retransmission and a reordered segment are judged by a much shorter clock. ## Reading them in practice - Count each label per conversation (Statistics > Conversations with a display filter applied, or the Expert Info dialog) rather than per capture. - Look at **spurious retransmissions** separately: they mean data the receiver already acknowledged was sent again, so the delay is not loss at all. - Treat a wall of Out-Of-Order flags with no duplicate ACKs as reordering or a capture artefact to verify, not as loss.
- A capture shows many TCP Spurious Retransmission flags and almost no Dup ACKs. What does that tell you?The capture had already seen the other side acknowledge those bytes before they were sent again, so the receiver had the data; the retransmissions were unnecessary. That points at the sender's retransmission timer or at ACKs that reached the capture point but not the sender, not at a lossy path. Why the timer fired early is the TCP retransmission subject.
- How do you count only timeout-style retransmissions in Wireshark 4.6?Use `tcp.analysis.retransmission && !tcp.analysis.fast_retransmission && !tcp.analysis.spurious_retransmission`, because in 4.6 the fast and spurious labels also add the plain retransmission expert item, so the plain field alone counts all three kinds.
- Why can the same lost segment be labelled differently in two captures of the same transfer?The labels come from what each capture point saw. Upstream of the loss you see the original, the duplicate ACKs and a Fast Retransmission; downstream you first see a gap and then the repair. A capture started mid-connection also lacks the iRTT, so out-of-order is judged against 3 ms.
saying these in an interview costs you the question
- Wireshark reads the sender's retransmission decision straight out of the packet.
- Wireshark labels Fast Retransmission only after three duplicate ACKs.
- Filtering on tcp.analysis.retransmission excludes fast and spurious retransmissions.
- Out-Of-Order always means the network reordered packets.
- A Spurious Retransmission is evidence of packet loss on the path.
- These flags still appear with Analyze TCP sequence numbers switched off.