TCP series - Part 3: Congestion control

In this series, you will learn about crucial (but easily overlooked) details of the most important (and complicated) protocol in computer networking, aka TCP. For your reference, below is a list of the articles in this series:

• Part 1: connection establishment
• Part 2: connection termination
• Part 3: congestion control (this article)

Introduction

Congestion is the state of overwhelmed traffic load that might cause intermediate devices such as routers to drop incoming data due to the limited data queue and the data outgoing rate is less than arrival rate. There are a few reasons for this:

• The competition for the resource by different sources which are unaware of each other
• The unnecessary re-transmission of packets, i.e. when senders don’t see ACK, they can re-transmit and result in many copies of same packets at a time.
• Packets are undelivered are dropped elsewhere in network

Congestion control is an attempt by TCP to slow down when it has the reason to believe that the network is being congested. The natural questions to ask are how TCP can detect congestion and how it can slow down the transmission. There is actually no explicit signaling that helps TCP to know about the congestion, except for using the lost packets for this purpose. To answer the second question, we first look at the TCP header that we briefly mentioned in the first and second parts of the series. There is a 16-bit window field that is used by receiver to tell the sender the amount of data that is able to accept.

Using this advertisement window, together with the estimation of the network’s available capacity, the congestion window, the TCP senders’ window W (either in packet or byte units) is the minimum of the receiver’s advertised window and the congestion window:

W = min(receiver’s advertised window, the congestion window)

With this relationship, the TCP sender will not have more than W unacknowledged packets or bytes outstanding in the network.