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

When debugging network quality we usually focus on two factors: latency and throughput (bandwidth). Latency is easy to verify with ping or mtr . This article shares a method for debugging 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 are considered:

Sender‑side bottleneck

Receiver‑side bottleneck

Intermediate network bottleneck

Sender‑side bottlenecks usually stem from an insufficient buffer. The application writes data to a buffer via a syscall; if the buffer is full, the application blocks (when using blocking APIs) until space becomes available.

Most cases involve receiver‑side or network‑side bottlenecks, where data is placed in the system buffer but not transmitted quickly.

TCP optimizes overall network efficiency through two mechanisms:

Flow control : protects the receiver by not sending more data than the receiver’s buffer (rwnd) can hold.

Congestion control : protects the network by limiting the amount of in‑flight data (cwnd) to avoid overwhelming intermediate devices.

During connection establishment the receiver advertises its window size (rwnd). Each ACK reports the remaining window, ensuring the sender never exceeds the receiver’s capacity.

The congestion window (cwnd) represents the network’s current limit; the sender never sends more than cwnd bytes without ACKs.

Finding the cwnd value depends on the congestion‑control algorithm (default is CUBIC, others include Google’s BBR).

The core logic follows slow‑start: the sender probes the network, doubles cwnd on successful ACKs, and stops when either a packet is lost (no ACK) or cwnd reaches rwnd.

Packet loss detected (no ACK)

cwnd equals rwnd

If loss occurs, the sender halves cwnd; if cwnd equals rwnd, the receiver’s buffer is the bottleneck.

Other reasons for cwnd reduction include network congestion, packet loss due to poor quality, or delayed delivery by intermediate devices.

Viewing rwnd

The advertised window size appears in the TCP header; capture packets to read this field. The actual window size must be multiplied by the scaling factor negotiated during the TCP handshake via TCP Options.

Viewing cwnd

cwnd is a dynamic variable calculated by the sender’s congestion‑control algorithm and is not transmitted in packets. To inspect it, run the following command on the sender’s Linux machine:

ss -i

The displayed units are TCP MSS (e.g., 1460 bytes × 10).

Wireshark Analysis

Wireshark’s statistics can quickly reveal where the bottleneck lies. Open the capture, then view the “TCP Stream Graph → Time‑Sequence (tcptrace)” plot.

The graph shows data flow in one direction; use the “Switch Direction” button to view the opposite flow.

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

Three lines appear in the plot:

Red lines represent SACK (segments received), yellow lines represent ACKed segments, and blue lines indicate retransmissions.

Common Patterns

Packet Loss

Many red SACK markers indicate missing packets.

Throughput Limited by Receiver Window

The yellow ACK line rises, prompting the blue send line to increase until the green window line is filled, suggesting the receiver’s buffer can be enlarged.

Throughput Limited by Network Quality

The receiver’s window is not the bottleneck, but many gaps and retransmissions show a small cwnd caused by congestion control.

Further Evidence of Congestion

Zoomed view reveals numerous loss and retransmission events, confirming cwnd is too small.

References

mtr – https://www.kawabangga.com/posts/4275

RFC 7323 – https://datatracker.ietf.org/doc/html/rfc7323

BBR – https://www.kawabangga.com/posts/4086

TCP window scaling – https://en.wikipedia.org/wiki/TCP_window_scale_option

TCP MSS – https://www.cloudflare.com/learning/network-layer/what-is-mss/

spate – https://github.com/royzhr/spate