Why TCP Falters in Weak Networks: Congestion Control, Handshake & Retransmission

TCP is the backbone of today’s Internet, but its original design did not anticipate the high‑loss, high‑latency conditions common in modern wireless networks. This article examines three primary reasons why TCP suffers in weak networks: its congestion‑control algorithm, the three‑way handshake, and its retransmission mechanism.

Congestion Control

TCP uses an Additive Increase/Multiplicative Decrease (AIMD) strategy to avoid network collapse. When packet loss is detected, the congestion window (cwnd) is reduced, assuming loss indicates congestion. Historical data shows that a 2% loss rate can cut throughput by up to 90% when RTT is 30 ms.

Each TCP connection maintains a congestion window and a receive window (rwnd). The amount of data that can be in flight is min(rwnd, cwnd). Linux’s default initial congestion window is defined by TCP_INIT_CWND: #define TCP_INIT_CWND 10 RFCs 2414, 3390, and 6928 have increased the initial window over time to keep pace with higher bandwidths.

The congestion window grows linearly by one segment per RTT (slow start) and halves when loss occurs (multiplicative decrease). For a 10 Mbps link with 40 ms RTT and 1460‑byte segments, the bandwidth‑delay product suggests a window of 35 segments, but reaching this size from the default 10 requires multiple RTTs, adding noticeable delay.

Three‑Way Handshake

The TCP three‑way handshake establishes connection state and negotiates initial sequence numbers. While essential, it adds 1.5 RTT of latency and 222 bytes of overhead (Ethernet + IP + TCP headers). In weak networks with high loss, the handshake may need repeated retries, further inflating latency.

Typical RTT between Beijing and Shanghai is ~40 ms, so the handshake alone consumes about 60 ms, which becomes a dominant factor for short‑lived connections.

Retransmission Mechanism

TCP guarantees reliability by placing each transmitted segment in a retransmission queue and starting a timer. If an ACK is not received before the timer expires, the segment is resent. Because ACKs are cumulative, a lost ACK can cause the sender to retransmit segments that the receiver has already accepted, wasting bandwidth.

In high‑loss scenarios, this behavior can lead to substantial bandwidth waste, as multiple already‑received segments are retransmitted.

Summary and Mitigations

TCP’s design choices—congestion control that backs off on loss, the costly three‑way handshake, and a retransmission strategy that may resend already‑received data—make it ill‑suited for weak networks. Two main mitigation paths are emerging:

Adopt UDP‑based protocols such as QUIC, which avoid TCP’s handshake and allow more aggressive congestion handling.

Enhance TCP itself with extensions like Selective Acknowledgment (SACK) and TCP Fast Open (TFO) to reduce unnecessary retransmissions and handshake latency.

Understanding these mechanisms helps engineers decide when to tune TCP parameters or switch to newer transport protocols for better performance in challenging network conditions.