TCP Flow Control

What is TCP Flow Control?

In a communication network, in order for two network hosts to communicate with each other, one has to send a packet while another host has to receive it. It might happen that both the hosts have different hardware and software specifications and accordingly their processors might differ. If the receiver host has a fast processor which can consume messages sent at a higher rate by the sender then the communication works well and no problem will occur. But have you ever wondered what would happen if the receiver had a slower processor? Well, in this case, the incoming messages will keep coming and will be added to the receiver’s queue. Once the receiver’s queue is filled, the messages will start dropping leading to the wastage of channel packets. In order to overcome this issue of the slow receiver and fast sender, the concept of flow control comes into the picture.

For the slow sender and fast receiver, no flow control is required. Whereas for the fast sender and slow receiver, flow control is important.

In the diagram given, there is a fast sender and a slow receiver. Here are the following points to understand how the message will overflow after a certain interval of time.

• In the diagram, the receiver is receiving the message sent by the sender at the rate of 5 messages per second while the sender is sending the messages at the rate of 10 messages per second.
• When the sender sends the message to the receiver, it gets into the network queue of the receiver.
• Once the user reads the message from the application, the message gets cleared from the queue and the space becomes free.
• According to the mentioned speed of the sender and receiver, the receiver queue will be getting shortened and the buffer space will reduce at the speed of 5 messages/ second. Since, the receiver buffer size can accomodate 200 messages, hence, in 40 seconds, the receiver buffer will become full.
• So, after 40 seconds, the messages will start dropping as there will be no space remaining for the incoming messages.

This is why flow control becomes important for TCP protocol for data transfer and communication purposes.

How Does Flow Control in TCP Work?

When the data is sent on the network, this is what normally happens in the network layer.

The sender writes the data to a socket and sends it to the transport layer which is TCP in this case. The transport layer will then wrap this data and send it to the network layer which will route it to the receiving node.

If you look at the diagram closely, you will notice this part of the diagram. The TCP stores the data that needs to be sent in the send buffer and the data to be received in the receive buffer. Flow control makes sure that no more packets are sent by the sender once the receiver’s buffer is full as the messages will be dropped and the receiver won’t be able to handle them. In order to control the amount of data sent by the TCP, the receiver will create a buffer which is also known as Receive Window. The TCP needs to send ACK every time it receives the data packet, acknowledging that the packet is received successfully and with this value of ACK it sends the value of the current receive window so that sender knows where to send the data.

The Sliding Window

The sliding window is used in TCP to control the number of bytes a channel can accommodate. It is the number of bytes that were sent but not acknowledged. This is done in TCP by using a window in which packets in sequence are sent and authorized. When the sending host receives the ACK from the receiving host about the packets the window size is incremented in order to allow new packets to come in. There are several techniques used by the receiver window including go-back-n and selective repeat but the fundamental of the communication remains the same.

Receive Window

The TCP flow control is maintained by the receive window on the sender side. It tracks the amount of space left vacant inside the buffer on the receiver side. The figure below shows the receive window. The formula for calculating the receive window is given in the figure. The window is constantly updated and reported via the window segment of the header in TCP. Some of the important terminals in the TCP receive window are receiveBuffer, receiverWindow, lastByteRead, and lastByteReceived.

Whenever the receive buffer is full, the receiver sends receiveWindow=0 to the sender. When the remaining buffer is consumed and there’s nothing back to acknowledge then it creates a problem in the application of the receiver.

In order to create a solution for this problem, the TCP makes explicit consideration by dictating the sender a single bit of data to the receiver side continuously. This minimizes strain on the network while maintaining a constant check on the status of the buffer at the receiving side. In this way, as soon as buffer space frees up, an ACK is sent.

In this, a control mechanism is adopted to ensure that the rate of incoming data is not greater than its consumption. This mechanism relies on the window field of the TCP header and provides reliable data transport over a network.

The Persist Timer

From the above condition, there might be a possibility of deadlock. After the receiver shows a zero window, if the ACK message is not sent by the receiver to the sender, it will never know when to start sending the data. This situation in which the sender is waiting for a message to start sending the data and the receiver is waiting for more incoming data is called a deadlock condition in flow control. In order to solve this problem, whenever the TCP receives the zero window message, it starts a persistent timer that will send small packets to the receiver periodically. This is also called WindowProbe.