How to Debug TCP Throughput Bottlenecks: rwnd, cwnd, and Wireshark Tips

When debugging network quality we usually focus on two factors: latency and throughput (bandwidth). Latency is easy to verify with ping or mtr, but this article shares a method to debug throughput.

Throughput‑critical scenarios are often long fat networks (LFN) such as large file downloads. When throughput does not reach the network’s limit, three possible causes exist:

Sender‑side bottleneck

Receiver‑side bottleneck

Intermediate network bottleneck

Sender‑side bottleneck usually occurs when the send buffer is too small. The application writes data to the buffer via a syscall; if the buffer fills, the application blocks (when using blocking APIs) until space is available.

Most sender‑side issues are easier to trace via logs, but the second and third cases are harder. They happen when the application has written data to the system buffer, yet the system does not transmit it quickly.

TCP optimizes transmission efficiency (overall network efficiency) by:

Flow control: protecting the receiver by not sending more data than the receiver’s buffer size.

Congestion control: protecting the network from overwhelming traffic; intermediate network bottlenecks can degrade LFN throughput.

During connection establishment the receiver window size (rwnd) is negotiated, and each ACK reports the remaining window. The sender therefore never exceeds the receiver’s buffer.

The congestion window (cwnd) limits how much data the sender can have in flight without ACKs. The default algorithm is CUBIC, but alternatives like Google’s BBR exist.

Cwnd grows during slow start: each successful ACK doubles cwnd until either a packet is lost (no ACK) or cwnd reaches rwnd.

Packet loss (no ACK)

cwnd equals rwnd

If cwnd equals rwnd, the bottleneck is the receiver’s buffer size, not the network.

Packet loss indicates the network cannot handle the current sending rate, causing cwnd to halve.

Other reasons for cwnd reduction include:

Network reached its limit

Packet loss due to poor network quality

Intermediate devices delayed packets, preventing timely ACKs

Both reasons 2 and 3 cause cwnd to drop, preventing full utilization of the network.

How to View rwnd

The window size is in the TCP header; capture packets to see this field. The actual window size must be multiplied by the scaling factor negotiated during the TCP handshake via TCP options, so you need packets from the handshake to compute the true value.

How to View cwnd

Congestion control is a dynamic variable on the sender side and does not appear in the packet stream. On Linux you can display it with the ss -i command, which prints TCP connection parameters.

The displayed units are TCP MSS; the actual size is 1460 bytes × 10.

Wireshark Analysis

Wireshark’s statistics let you quickly locate the bottleneck. Open the capture, then view the “TCP Stream Graph → Time‑Sequence (tcptrace)” chart. The chart shows a single direction; you can switch direction with the button at the lower right.

The X‑axis is time, the Y‑axis is the TCP Sequence Number. If the Sequence Number does not increase, you are looking at the wrong direction.

Three lines appear:

Red SACK line – segments the receiver reports as received.

Yellow ACK line – segments acknowledged by the receiver.

Blue retransmission line – segments that were retransmitted.

Common patterns:

Packet Loss

Many red SACK segments indicate missing packets.

Throughput Limited by Receiver Window

The yellow ACK line rises until the green window line is filled, showing the network is fine and the receiver buffer can be increased.

Throughput Limited by Network Quality

The window size is not the bottleneck, but many packet losses and retransmissions keep cwnd small.

Zooming in reveals frequent loss and small data bursts, indicating cwnd is too small due to congestion control.