TCP Congestion Control & Application Protocols

TCP Congestion Control: Navigating the Digital Traffic Jam

Imagine a highway system. If every car enters the highway at full speed without regard for others, a massive traffic jam—or "congestion collapse"—is inevitable. The early internet faced this exact problem. TCP's congestion control is the set of rules drivers (senders) follow to keep traffic flowing smoothly.

The core idea is for each TCP sender to probe the network to find the available bandwidth. It does this by regulating its sending rate based on network feedback, which it infers primarily from lost packets.

The Congestion Window (cwnd)

TCP doesn't directly control its sending rate in "bits per second." Instead, it manages a congestion window (cwnd), which limits the amount of unacknowledged data it can have in flight. The effective sending rate can be approximated as:

Where RTT is the round-trip time. By dynamically adjusting the size of cwnd, TCP adjusts its sending rate. The video below from Jim Kurose, a co-author of a classic networking textbook, provides an excellent overview of the algorithms TCP uses to manage this window.

The Two Phases of TCP Congestion Control

As you saw in the video, TCP's strategy is not a single algorithm but a combination of two main phases, governed by the cwnd and a variable called the slow start threshold (ssthresh).

1. Slow Start (Exponential Growth)

   • Goal: To quickly find the approximate available bandwidth when a connection begins.
   • Mechanism: The connection starts with a small cwnd, typically 1 Maximum Segment Size (MSS). For every acknowledgment (ACK) received, cwnd is increased by 1 MSS. Since multiple ACKs are received within one RTT, this results in the cwnd doubling approximately every RTT.
   • When does it end? This exponential growth continues until cwnd reaches the ssthresh value. The name "slow start" is a misnomer; it's an aggressive exponential ramp-up.

2. Congestion Avoidance (Additive Increase)

   • Goal: To probe for more bandwidth cautiously once the "danger zone" (the ssthresh) is reached.
   • Mechanism: Once cwnd is greater than or equal to ssthresh, TCP enters Congestion Avoidance. Here, it increases cwnd much more slowly—by just 1 MSS per RTT. This is the "Additive Increase" part of AIMD.

Reacting to Loss (Multiplicative Decrease)

Congestion is inferred from packet loss. When a loss event occurs (detected via a timeout or triple duplicate ACKs):

• The ssthresh is set to half of the current cwnd value.
• The cwnd is drastically reduced. In the classic case of a timeout, cwnd is reset to 1 MSS, and the connection re-enters the Slow Start phase.
• This halving of the rate is the "Multiplicative Decrease" part of AIMD.

This combination of aggressive startup, careful probing, and sharp back-off gives TCP its robust and fair nature.

Example for GATE:
A TCP connection has an ssthresh of 8 MSS. It is currently in the Slow Start phase with cwnd = 4 MSS. Assuming no packet loss, what will the cwnd be after 3 RTTs?

• After 1 RTT: In Slow Start, cwnd doubles. cwnd = 4 * 2 = 8 MSS.
• After 2 RTTs: Now cwnd (8 MSS) is equal to ssthresh (8 MSS). The connection moves to Congestion Avoidance. cwnd increases linearly. cwnd = 8 + 1 = 9 MSS.
• After 3 RTTs: Still in Congestion Avoidance. cwnd = 9 + 1 = 10 MSS.

The final cwnd is 10 MSS.

The Application Layer: Where Programs Talk

We now ascend to the top of the network stack: the Application Layer. This is where network-aware applications like web browsers, email clients, and video streaming services live. These applications use the services of the lower layers (like TCP and UDP) to communicate. We'll focus on two pillars of the modern internet: DNS and HTTP.

Domain Name System (DNS): The Internet's Phonebook

When you want to visit a website, you type a name like www.google.com, not an IP address like 142.250.196.68. How does your browser translate the human-friendly name into the machine-friendly IP address? That is the job of the Domain Name System (DNS).

The following video from Gate Smashers provides an excellent, GATE-focused explanation of why DNS is needed and how it works.

The DNS resolution process is a beautiful example of a distributed, hierarchical database in action. A request for www.example.com would typically follow this path:

1. Client's Resolver: Your computer first asks its configured DNS server (often your ISP's). "What is the IP for www.example.com?"
2. Root Server: If the local server doesn't know, it asks one of the 13 root servers. "Where can I find information about .com domains?" The root server replies with the IP address of the TLD server for .com.
3. TLD Server: Your local server then asks the .com TLD server. "Where can I find information about the example.com domain?" The TLD server replies with the IP address of the authoritative name server for example.com.
4. Authoritative Name Server: Finally, your local server asks the example.com authoritative server. "What is the IP for www.example.com?" This server holds the actual record and provides the final IP address.
5. Response: The local server sends this IP address back to your computer and caches it for future use.

Hypertext Transfer Protocol (HTTP): The Language of the Web

Once your browser has the server's IP address thanks to DNS, it establishes a TCP connection (usually on port 80 for HTTP or 443 for HTTPS) and starts speaking the Hypertext Transfer Protocol (HTTP).

Key Characteristics of HTTP:

• Client-Server Protocol: The browser (client) sends a request message to the web server, which replies with a response message.
• Uses TCP: HTTP relies on TCP for reliable data transfer. This ensures the web page components arrive correctly and in order.
• Stateless: This is a crucial concept. The server does not remember anything about past requests from a client. Each request is independent. Mechanisms like cookies were invented to build a "stateful" session on top of the stateless HTTP protocol.

HTTP Request/Response:

• An HTTP Request typically includes:
  • A method, like GET (to retrieve data) or POST (to submit data).
  • The path of the resource, e.g., /images/logo.png.
  • The HTTP version, e.g., HTTP/1.1.
  • Headers with additional information (e.g., Host: www.example.com).
• An HTTP Response includes:
  • A status code, like 200 OK (success), 404 Not Found (resource doesn't exist), or 301 Moved Permanently.
  • Headers with information about the response.
  • The requested resource itself (e.g., the HTML code or image data).

Persistent vs. Non-Persistent HTTP (Classic GATE Topic)
This distinction relates to how TCP connections are used.

• Non-Persistent HTTP (HTTP/1.0): A separate TCP connection is established for every single object on a webpage. If a page has an HTML file and 10 images, this requires 11 TCP connections. This is inefficient due to the high overhead of repeatedly setting up and tearing down connections (3-way handshake for each).
• Persistent HTTP (HTTP/1.1 default): A single TCP connection is established and kept open to download multiple objects (the HTML file and all 10 images). This significantly reduces latency.

Example for GATE:
A webpage contains a base HTML file and 5 small images. The RTT to the server is 100ms. Assume it takes a negligible amount of time to transmit the files. How long does it take to load the entire page?

• With Non-Persistent HTTP:

  • We need 1 connection for the HTML file + 5 connections for the images = 6 TCP connections.
  • Each connection requires: 1 RTT (for connection setup) + 1 RTT (for request/response) = 2 RTTs.
  • Total time = 6 * (2 * RTT) = 12 * 100ms = 1200ms.

• With Persistent HTTP:

  • We need only 1 TCP connection.
  • Time for connection setup = 1 RTT.
  • Time for HTML request/response = 1 RTT.
  • Time for all 5 image requests/responses (can be sent back-to-back on the same connection) = 5 * 1 RTT. Correction: With pipelining, the requests can be sent one after another without waiting for each response. A simpler model for GATE is 1 RTT for the HTML and 1 RTT for all images (assuming they can be requested in parallel or pipelined). Let's use a standard model: 1 RTT for TCP setup, 1 RTT for HTML, then 1 RTT for the images.
  • A more accurate model: 1 RTT (TCP handshake) + 1 RTT (request HTML, get HTML) + 5 RTTs (request/get 5 images sequentially) = 7 RTTs.
  • Using the pipelined model (requests sent without waiting): 1 RTT (TCP) + 1 RTT (HTML) + 1 RTT (for the last image to arrive after all were requested) = 3 RTTs. The common GATE interpretation is often the sequential one unless pipelining is specified. Let's stick to the simpler, non-pipelined persistent model for clarity.
  • Total time = 1 RTT (connection setup) + 1 RTT (HTML) + 5 RTTs (for the 5 images) = 7 * RTT = 700ms.
  • The time saving is substantial.

Conclusion and Course Wrap-up

In this final lesson, we've explored how TCP masterfully manages network traffic and prevents congestion collapse using its Slow Start and AIMD algorithms. We also completed our tour of the network stack by examining the Application Layer, understanding how DNS resolves names to numbers and how HTTP facilitates communication on the World Wide Web.

Key Takeaways:

• TCP Congestion Control: A dynamic mechanism using the cwnd to control sending rate. It begins with an exponential Slow Start and transitions to a more cautious linear Additive Increase phase. Upon detecting loss, it performs a sharp Multiplicative Decrease.
• AIMD Fairness: The AIMD algorithm naturally converges towards providing a fair share of bottleneck bandwidth to competing TCP flows.
• Domain Name System (DNS): A hierarchical, distributed system that acts as the internet's phonebook, translating human-readable domain names into machine-readable IP addresses.
• Hypertext Transfer Protocol (HTTP): A stateless, client-server application protocol that powers the web. It relies on TCP for reliability and its performance is greatly enhanced by persistent connections.

This lesson marks the end of your learning journey through the 12 modules of the GATE CS syllabus. From the abstract foundations of logic and sets to the concrete mechanics of computer networks, you have built a comprehensive and deep understanding of the core subjects in Computer Science. The goal was not just to learn facts, but to see the connections between different areas and to build the analytical skills required to solve challenging problems.

Your preparation is now in your hands. Continue to revise these concepts, practice previous year's questions, and take mock tests to hone your speed and accuracy. The foundation is laid; now it is time to build upon it. We wish you the very best in your pursuit of a top rank in GATE 2026. Good luck