How TCP Detects Congestion and Manages Data Flow

TCP (Transmission Control Protocol) operates at the transport layer, aiming to reliably and efficiently transfer data between applications on different computers. To achieve this, TCP employs mechanisms like sequence and acknowledgment numbers, along with timeouts.

The Challenge of Network Variability

Sending data one packet at a time and waiting for an acknowledgment for each is incredibly slow. A typical data packet is around 1,500 bytes, which is not a lot. To improve efficiency, TCP sends multiple packets in a "flight" before expecting an acknowledgment. This acknowledgment is cumulative, indicating that all packets up to a certain sequence number have been received.

The sender doesn't know the characteristics of the network it's connected to. It could be a high-speed fiber connection or a slow, unreliable link, potentially involving satellite communication with significant delays. This uncertainty makes it difficult to determine how long an acknowledgment should take to return.

Detecting Congestion: The Round Trip Time (RTT)

TCP needs a way to detect network congestion without explicit signals from the network itself. One crucial mechanism is measuring the Round Trip Time (RTT), which is the time it takes for a packet to be sent and its acknowledgment to be received. Fluctuations in RTT can indicate congestion.

The rules for TCP, particularly regarding congestion control, are defined in RFCs (Request for Comments), such as RFC 5681. These RFCs specify what TCP implementations "must," "should," and "may" do, allowing for some flexibility, often referred to as "flavors" of TCP. Modern TCP implementations, like Cubic, are designed to respond to network signals, particularly packet loss, to manage congestion.

Congestion Window and Receiver Window

TCP uses the concept of a "window" to control the amount of data in transit. There are two main types:

• Receiver Window: This window, communicated by the receiver in the packet header, indicates how much data the receiver can currently buffer. In the early days of the internet, this was more critical, but it's less of a bottleneck now.
• Congestion Window (CWND): This is the more important window, tracked by both the sender and receiver, to estimate how much data the network can handle.

Signals of Congestion: Packet Loss

Most TCP variants primarily rely on packet loss as a signal for congestion. Packet loss can be inferred in two main ways:

1. Triple Duplicate ACKs: If a receiver repeatedly sends acknowledgments for the same packet (e.g., ACK 1, ACK 1, ACK 1), it indicates that a subsequent packet (e.g., packet 2) is missing. This is a strong signal that something has gone wrong with packet 2. The sender will then retransmit the missing packet and reduce its congestion window.
2. Timeout: If the sender sends data and receives no acknowledgment within a calculated timeout period, it assumes a more severe congestion event. This leads to a more drastic reduction in the congestion window. The timeout period is dynamically adjusted based on the measured RTT.

Congestion Control Algorithms: AIMD and Slow Start

TCP employs specific algorithms to adjust the congestion window:

• Additive Increase, Multiplicative Decrease (AIMD): Once a connection is established and stable, TCP uses AIMD.

  • Additive Increase: If a full "flight" of packets is acknowledged successfully, the congestion window is increased by a small amount (e.g., one packet). This allows TCP to probe for available bandwidth.
  • Multiplicative Decrease: If congestion is detected (e.g., via a triple duplicate ACK or a timeout), the congestion window is significantly reduced (e.g., cut in half). This quickly alleviates pressure on the network. This behavior often results in a "sawtooth" pattern when plotting the congestion window over time.

• Slow Start: At the beginning of a connection, or after a catastrophic loss, TCP uses "slow start." Despite its name, slow start is a rapid, exponential increase in the congestion window.

  • The sender starts by sending a small number of packets (e.g., one).
  • For each successful acknowledgment, the congestion window is doubled. This allows TCP to quickly discover the available bandwidth.
  • Slow start continues until a loss is detected, at which point TCP transitions to AIMD.

TCP in the Real World

While the theoretical models of TCP congestion control (like the sawtooth pattern) are elegant, real-world network behavior is far more complex and "jaggity." Factors contributing to this complexity include:

• Competing Traffic: Many users and applications share the same network infrastructure, leading to dynamic and unpredictable congestion.
• Network Middleboxes: Firewalls and other network devices can interfere with or modify TCP traffic, making it difficult to interpret signals.
• Protocol Evolution: The TCP protocol dates back to the 1980s. While it has evolved, fundamental changes are slow due to the need for backward compatibility and the widespread deployment of existing infrastructure.

Despite these complexities, TCP has proven remarkably robust and adaptable, performing its job effectively for decades across diverse network environments, from local data centers to satellite links. Tools like Wireshark can be used to observe real-world TCP traffic, revealing the slow start phase and the more erratic behavior of AIMD in practice.