Differences between TCP congestion and TCP flow control

Question

From my understanding, flow control essentially how much the receiver can process.

Suppose I can send packets at 100mb/s but the receiver can only process information at 10mb/s, flow control would essentially mean that the receiver tells me, "Hey, I can at max process information at 10mb/s" and as a result, I would tweak my sending speed to be maximum 10mb/s.

Congestion control would be for example like TCP tahoe:

We start by sending 1 packet and wait for an ACK, then we double the amount of packets we send and wait for ACKs until we reach a certain threshold, then we only increment the amount of packets we send by one. If we receive a timeout, we know congestion has occurred and we decrease the amount of packets we send at a time to avoid congestion at the receiver.

So Congestion control ensure the receiver isn't overwhelmed with more packets than it can handle which would cause congestion.

Flow control regulates the speed at which the sender sends packets to the receiver.

Are my conclusions accurate? I honestly find them quite similar.

Answer 1

No, your conclusions are not quite accurate. Flow and congestion control have different goals.

Short answer:

the goal of flow control is to ensure that the sender is not overloading the receiver

the goal of congestion control is to ensure that the sender is not overloading the network, e.g., by sending much more packets that the link with lowest capacity on the path can process and transmit.

Long answer:

Flow control.

So, short answer holds, but it is not exactly about limiting the capacity.

First, if the receiver is connected by a 10Mb link, than the system that will be overloaded is not the receiver, but the "kinda other side of that link" (basically if there is a router that has 100Mb incoming and 10Mb outgoing link, than it will be the overloaded system in this scenario), which is then the problem of congestion control.

The receiver is supposed to have a buffer, where it stores received packets. This buffer is needed for TCP operation when the packets are reordered. On desktop PCs this buffer is also needed to store packets when the application is not reading packets from the socket. This buffer can store a range of continuous sequence numbers. If a packet with a sequence numbers outside this range is received, the packet is discarded.

Now, the goal of flow control is not to send packets that will be discarded. The receiver tells the sender how much space there is in a buffer and the sender is not sending more packets that that.

The issue here is that you can't usually say that the receiver can process 10Mbps. It depends on how many reordered packets arrive, and on how process scheduling is done on the receiver. So this varies constantly (unless you have a real-time OS, in which case you would probably not use TCP to begin with).

Congestion Control

The goal of congestion control is to adjust sending rate to the capacity of the network in between, which is more or less the capacity of the "slowest" link on the path.

Here is a classical example.

sender <=== 1Gbps ===> router (R1) <--- 50Mbps --> router (R2) <=== 1Gbps ===> receiver

So, the sender is connected to a 1Gb Ethernet link and is capable of sending 1Gb worth of traffic. Receiver is also connected to 1Gb link and its buffer is set accordingly. So TCP can technically send 1Gbps worth of traffic.

Obviously there is no point in sending 1Gbps worth of traffic, because the bottleneck link between two routers will not be able to transfer it. The extra packets will just be dropped at R1.

The goal of congestion control is to figure out what the capacity of this bottleneck link is and to not send more packets than this link can transmit.

Why packet drops? So, packet drops will occur at R1 because it tries to send traffic from 1Gb to 50Mb link. The way packet-switched network is supposed to work: R1 receives packets from 1Gb link; R1 need to send packets out of 5Mb link. R1 should have a buffer before the link. Ether the link is free and packets can be sent, or they should be buffered. Once the buffer is full the packets are dropped. This drop is taken as an indication of congestion. When packet drop occurs the idea is that the sender should reduce its sending rate.

Well, since TCP is window based and congestion control is window based, what actually happens is that TCP reduce the number of packets it sends out per RTT.

Now, I will leave the discussion on how good congestion control works, since it requires a really long wall of text. Tahoe is too aggressive, and degrades performance. Normal sender uses at least Reno.

Answer 2

Flow control and congestion control are essentially the same from the sender's perspective. The point is for the sender to detect any lack of timely reception.

Whether the limit is the receiver itself or the path capacity doesn't matter. A receiver limit would be fairly static but the current path capacity may be highly variable, so an algorithm is required that handles both situations. The bottleneck is most likely neither the sender nor the receiver but a path component somewhere on its way.