What is the Receiver Window (rwnd)?
The Receiver Window (rwnd) is the amount of free buffer space the receiving TCP stack currently has available for incoming data.
- Mechanism: The receiver constantly advertises its current rwnd size to the sender using the Window Size field in the TCP header of every ACK segment it sends back.
- Purpose: The rwnd acts as a limit on the amount of unacknowledged data the sender is allowed to have "in flight" at any given time.
- Location: The rwnd is maintained by the receiving end of the connection.
Unacknowledged Data
This refers to the data segments that the sender has transmitted but has not yet received a confirmation (ACK) for from the receiver.
- When the sender transmits a packet, that data is temporarily stored in the sender's buffer.
- It remains in the sender's buffer (and is considered "unacknowledged") until the receiver sends an ACK indicating it has successfully received and processed that sequence of bytes.
Data In Flight
This is a common term in networking that means the same thing as "unacknowledged data" (or sometimes slightly more specifically, the amount of unacknowledged data currently residing in the network path, which is often called the Flight Size).
- It is data that has left the sender's machine and is currently traveling across the network, sitting in router queues, or waiting in the receiver's buffer before being processed by the application.
- It's data that is "out there" and for which the sender is waiting for a positive acknowledgement.
"The rwnd acts as a limit..."
This is the key point for flow control. The sender must obey the receiver's advertised window.
- The Rule: The sender calculates the amount of unacknowledged data it currently has "in flight" and must ensure that this amount never exceeds the current rwnd value advertised by the receiver.
- Bytes In Flight≤min(Congestion Window,Receiver Window)
- The Purpose: This mechanism prevents the sender from sending data faster than the receiver can read it from its buffer. If the sender ignored the rwnd, it would flood the receiver's limited buffer space, causing the receiver to drop packets, which wastes network bandwidth and triggers unnecessary retransmissions.
The rwnd is the receiver's way of shouting back to the sender, "I have this much room left! Don't send more than that total amount of data until I tell you I've cleared some space!" This is the mechanism for Flow Control.
The Role of rwnd in Flow Control
While the Congestion Window (cwnd) limits transmission based on the network's capacity (congestion control), the Receiver Window (rwnd) limits transmission based on the receiver's processing capacity and available memory (flow control).
Flow Control Rule:
- The TCP sender must adhere to the following rule when determining how much data to send:
- Effective Window=min(cwnd,rwnd)
| Scenario | Limiting Factor | Focus |
| If | Congestion Window () | The sender is limited by what the network can handle. (Congestion Control) |
| If | Receiver Window () | The sender is limited by what the receiver can handle. (Flow Control) |
Window Size Management:
- Data Arrives: When data arrives, the receiver places it into its buffer, and the available rwnd decreases.
- Data Read: When the application layer reads the data from the buffer, that buffer space is freed up, and the available rwnd increases.
- Feedback: The receiver includes the new, updated rwnd value in the next ACK it sends to the sender.
If the receiver's buffer fills up completely, the rwnd is advertised as zero. This is known as Zero Window, and it stops the sender from transmitting new data until the application reads the buffered data, and the receiver can advertise a non-zero rwnd again.
What is the Congestion Window (cwnd)?
The cwnd, or Congestion Window, is a crucial state variable in TCP (Transmission Control Protocol) used by a sender to limit the amount of unacknowledged data it can transmit into the network before receiving an acknowledgment (ACK).
The primary purpose of the cwnd is to perform congestion control, which is a set of algorithms TCP uses to prevent network overload.
How the cwnd Works
- Sender-Side Limit: The cwnd is maintained by the sending host and is a local estimate of how much capacity is currently available on the path to the receiver without causing congestion (like router buffer overflow).
- The Transmission Limit: A TCP sender's window size—the maximum amount of data it can have "in flight" (sent but not yet acknowledged)—is determined by the minimum of two values:
- Sender Window Size=min(Congestion Window (cwnd),Receiver Window (rwnd))
- The Receiver Window (rwnd) is advertised by the receiver for flow control (preventing the sender from overwhelming the receiver's buffer), while the cwnd is for congestion control (preventing network congestion).
- Dynamic Adjustment: The cwnd size changes dynamically based on network feedback:
- Increase (Probing for Capacity): The cwnd is increased when the sender receives ACKs, which implicitly signal that the network is capable of handling the current data rate. This increase is typically exponential (during the Slow Start phase) and then linear (during the Congestion Avoidance phase).
- Decrease (Reacting to Congestion): The cwnd is reduced when the sender detects packet loss (often via a timeout or receiving duplicate ACKs), which is interpreted as a sign of network congestion. This is a multiplicative decrease to rapidly reduce the offered load on the network.
Duplicate ACK (DUP ACK):
- Sent by the TCP Receiver.
- A receiver sends a Duplicate ACK when it receives a segment that is out of order, indicating a gap in the sequence numbers (i.e., a segment is missing).
- The ACK number in the duplicate ACK is the sequence number of the missing segment (the next expected byte).
- The purpose is to quickly notify the sender of the apparent loss, without waiting for the retransmission timer to expire
First Retransmission (Fast Retransmit):
- Performed by the TCP Sender.
- The sender triggers a "Fast Retransmit" when it receives a certain number of identical Duplicate ACKs (typically three, meaning one original ACK and three duplicates, or four ACKs with the same sequence number).
- Upon receiving the third duplicate ACK, the sender retransmits the missing segment (the one indicated by the ACK number in the DUP ACKs) immediately, without waiting for the retransmission timeout.
This filter identifies a Retransmission Timeout (RTO) loss event, which is the more severe type of loss detection.
- Mechanism: The sender sends a segment and starts its internal RTO timer. If the sender does not receive an ACK for that data segment before the timer expires, it assumes the packet (or the ACK) is lost and retransmits the segment.
- Resulting Action (Congestion Control): When an RTO occurs, the TCP stack assumes severe congestion.
- The congestion window (cwnd) is reset to 1 MSS.
- The slow start threshold (ssthresh) is set to half of the previous cwnd.
- The connection enters the Slow Start phase to probe the network cautiously
- Trace Signature: A large, often increasing, delay (the RTO value) between the original packet and the retransmitted packet. The RTO starts at a relatively high value (often 1 second or 3 seconds) and doubles with each subsequent timeout (exponential backoff).
tcp.analysis.fast_retransmission (Duplicate-ACK Based Loss)
- Mechanism: The sender receives three or more duplicate ACKs for the same data segment. A duplicate ACK means the receiver got data out-of-order and is informing the sender of the highest sequence number received in-order. Three duplicates strongly suggest a lost packet without having to wait for the RTO timer.
- Resulting Action (Congestion Control): When a Fast Retransmit occurs, the TCP stack assumes moderate congestion.
- The slow start threshold (ssthresh) is set to half of the current cwnd (or cwnd/2).
- The missing segment is retransmitted immediately (Fast Retransmit).
- The connection enters Fast Recovery, typically setting cwnd to ssthresh+3 MSS (for the "inflated" cwnd state).
- Trace Signature: The retransmitted packet arrives immediately after the third duplicate ACK is received, which is much faster than an RTO
| Feature | tcp.analysis.retransmission | tcp.analysis.fast_retransmission |
| Detection | timer expires (no received). | Three or more Duplicate received. |
| Severity | Severe Congestion (assumes network saturation). | Moderate Congestion (assumes a single dropped packet). |
| Response | Slow Start / Exponential Backoff. | Fast Retransmit / Fast Recovery. |
| Action | Resets to . | is halved (set to ), then inflated. |
| Timing | Long delay (seconds) that doubles. | Immediate retransmission. |
The key to differentiating between a retransmission that is part of a Fast Recovery (after a Fast Retransmit) and a retransmission due to an (Timeout) lies in two primary factors: the preceding packets and the time delay.
This is the most definitive way to tell them apart in a packet trace.
Differentiating by Preceding Packets
| Type of Retransmission | Preceding Packets to Look For |
| RTO Retransmission | You will see NO traffic from the receiver (the host that should be acknowledging the data) for the entire duration of the Retransmission Timeout (). The communication simply stops, and after a long silence, the sender resends the data. This implies that the were likely lost, or the original data segment was lost and the receiver never got it. |
| Fast Retransmission | You must see or more identical Duplicate ACKs immediately before the retransmitted data packet. These are the explicit trigger for the Fast Retransmit. The duplicate prove that the receiver is still active, has received subsequent data (out-of-order), and is requesting the missing segment. |
Differentiating by Timing and RTO Value
The time difference between the original segment and the retransmitted segment clearly separates the two.
| Type of Retransmission | Time Delay | RTO Value in Trace | Congestion Action |
| RTO Retransmission | Long and Exponentially Increasing | The delay will be equal to the current calculated RTO value (e.g., , , , , etc.). | reset to (Slow Start). |
| Fast Retransmission | Immediate | The delay will be very short, typically in the range of to . It is dictated only by the time it took for the third Duplicate to arrive at the sender's buffer. | is halved (Fast Recovery). |
Practical Validation in Wireshark
Fast Retransmission: Filter for tcp.analysis.duplicate_ack. Look for a packet labeled "Fast Retransmission" immediately following the 3rd duplicate ACK. The time delta will be tiny.
RTO Retransmission: Filter for tcp.analysis.retransmission (excluding the fast ones). The retransmitted packet's TCP analysis detail will show a long delay, and you can confirm no intervening packets were sent by the receiver.
In summary, a Fast Retransmission is a quick, proactive correction based on clear feedback (Duplicated ACKs), while an RTO Retransmission is a last resort based on silence and the expiration of a defensive timer.