TCP is the protocol that guarantees we can have a reliable communication channel over an unreliable
network. When we send data from a node to another, packets can be lost, they can arrive out of order,
the network can be congested or the receiver node can be overloaded. When we are writing an
application, though, we usually don’t need to deal with this complexity, we just write some data to a
socket and TCP makes sure the packets are delivered correctly to the receiver node. Another important
service that TCP provides is what is called Flow Control. Let’s talk about what that means and how TCP
does its magic.
What is Flow Control (and what it’s not)
Flow Control basically means that TCP will ensure that a sender is not overwhelming a receiver by
sending packets faster than it can consume. It’s pretty similar to what’s normally called Back pressure in
the Distributed Systems literature. The idea is that a node receiving data will send some kind of feedback
to the node sending the data to let it know about its current condition.
It’s important to understand that this is not the same as Congestion Control. Although there’s some
overlap between the mechanisms TCP uses to provide both services, they are distinct features.
Congestion control is about preventing a node from overwhelming the network (i.e. the links between
two nodes), while Flow Control is about the end-node.
How it works
When we need to send data over a network, this is normally what happens.
The sender application writes data to a socket, the transport layer (in our case, TCP) will wrap this data in
a segment and hand it to the network layer (e.g. IP), that will somehow route this packet to the receiving
node.
On the other side of this communication, the network layer will deliver this piece of data to TCP, that will
make it available to the receiver application as an exact copy of the data sent, meaning if will not deliver
packets out of order, and will wait for a retransmission in case it notices a gap in the byte stream.
If we zoom in, we will see something like this.
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.
