TCP Reno with Example

TCP Reno is an integral part of TCP protocols responsible for congestion control in the network. TCP Reno is an extension of TCP Tahoe (the first in-built congestion control algorithm). 

TCP Reno = Slow Start + AIMD + Fast Retransmit + Fast Recovery

Working of TCP Reno 

Assumption: 

1. The sender has unlimited data to send
2. initcwnd = 10 segments
3. Packets 3 and 4 are dropped.

Let’s see the working of TCP reno with the help of an example:

S.No.	Packets ACKed	cwnd	inflight	Packets transmitted
1.	None	10	10	1, 2, 3, 4, 5, 6, 7, 8, 9, 10
2.	1	11	11	11, 12
3.	2	12	12	13, 14
4.	2(DA1, R5)	13	13	15, 16
5.	2(DA2, R6)	14	14	17, 18
6.	2(DA3, R7) *	7	13	Re3
7.	2(DA4, R8)	7	12	–
8.	2(DA5, R9)	7	11	–
9.	2(DA6, R10)	7	10	–
10.	2(DA7, R11)	7	9	–
11.	2(DA8, R12)	7	8	–
12.	2(DA9, R13)	7	7	–
13.	2(DA10, R14)	7	7	19
14.	2(DA11, R15)	7	7	20
15.	2(DA12, R16)	7	7	21
16.	2(DA13, R17)	7	7	22
17.	2(DA14, R18)	7	7	23
18.	3	7+1/7	7	24
19.	3(DA1, R19)	7+2/7	7	25
20.	3(DA2, R20)	7+3/7	7	26
21.	3(DA3, R21)*	(7+4/7)/2	7	Re 4

Step 1: Initially, sender sends 10 packets into the network without waiting for any ACK. 

cwnd = 10, inflight = 10. 

We are assuming beforehand that packet 3 and 4 are lost, the sender does not know about that yet.

Step 2-5: Sender gets the ACK for packet-1 and increases the cwnd by 1. Thus, cwnd = 11. Since packet-1 is received by the receiver, it is not inflight. Thus, inflight = 10 – 1 = 9. But max. value of inflight is equal to cwnd, thus sender sends 2 new packets into the link. Packets 11 and 12 are transmitted.

When a new ACK arrives at the sender side and inflight <= cwnd then the sender increases its cwnd and inflight by 1 and transmits 2 new packets into the network. Steps 2-5 follow the same scenario. 

Step 6: 

• When the receiver receives the packets out of order (i.e. 1, 2, 5, 7) it generates duplicate ACK. 
• The receiver sends the ACK of the last packet that was received in order. 
• When the sender gets the 3rd duplicate ACK it retransmits the lost packet (packet-3).
• This time cwnd is not increased, unlike the above steps.

4 things occur when a packet loss is detected in TCP Reno:

1. cwnd is reduced to half i.e. cwnd = cwnd/2
2. sthresh is reduced to half of cwnd i.e. ssthresh = cwnd/2
3. Sender becomes silence for half window called half window of silence.
4. Sender enters the Fast Recovery phase.

The sender doesn’t transmit any new packet during half a window of silence, but since a packet loss is confirmed, it retransmits that packet immediately. This is the unique case when inflight is greater than cwnd. Sender remains silent until infight becomes equal to cwnd, this period itself is called the half window of silence.

Steps 7-12: is the half window of silence. Sender gets the ACKs of previously transmitted packets but doesn’t transmit any new packet into the network. Sender gets the duplicate ACKs of packet-2 because it has not received the packets in order. The retransmitted packet-3 is still in-flight and has not been received by the receiver.

Steps 13-17: the half window silence is over and now the sender maintains the inflight = cwnd, by transmitting a new packet when a duplicate ACK arrives. If it does not send a new packet then inflight will become less than cwnd by 1, per ACK, so to utilize the link fully, new packets are transmitted.

Step-18: Sender receives the ACK of packet-3 which was retransmitted before entering into the fast recovery phase. ACK-3 is considered a new ACK. This is the point when the sender comes out of the Fast Recovery phase. Now, it enters the AI phase. AI stands for additive increase. Now the cwnd will increase by 1/cwnd per ACK. Thus, inflight will be increased by 1 per RTT. 

Step-19 & 20: Sender gets the duplicate ACKs-1 and 2 of packet-3. We know that packet-4 is lost (assumption), but the sender doesn’t know this yet. This is one major limitation of TCP Reno.

The receiver has received the packets-1,2,3 in order, packet-4 is missing, that’s why it is sending the duplicate ACK of the last packet received in order (packet-3).

Step-21: sender gets the 3rd duplicate ACK of packet-3. It confirms that the next packet is lost; packet-4 is lost. It will again enter the Fast Recovery phase but before that, it will retransmit the packet-4.

Thus, cwnd = current cwnd / 2
inflight > cwnd {exception}
Enters Fast recovery.

Limitation of TCP Reno: 

1. It can’t detect multiple packet loss in a single cwnd window size. It reduces the cwnd multiple times (equal to packet lost) in single window size. Thus it reduces the cwnd significantly which is unnecessary cause the network can come out of the congestion state by reducing the cwnd once.
2. During half window silence, the sender is wasting its resources by sitting idle.
3. It takes a lot of time to detect multiple packets lost in the same congestion window.
4. Performance degradation over long distances: TCP Reno relies on packet loss as an indication of congestion. When packets are lost due to factors other than congestion, such as long delays in transit, the performance of TCP Reno can degrade significantly.
5. Fairness issues: TCP Reno is not always fair when multiple flows share a bottleneck link. This is because TCP Reno reduces its sending rate by the same factor for each packet loss, regardless of the number of flows sharing the link.
6. Limited congestion control: TCP Reno is designed to perform congestion control on a per-flow basis. However, in modern network environments, flows can often have multiple paths with different levels of congestion. TCP Reno is not able to effectively utilize 
7. Inability to handle bursty traffic: TCP Reno is not well-suited for handling bursty traffic, as it relies on packet loss as an indication of congestion. Bursty traffic can cause congestion, but may not result in packet loss, leading to suboptimal performance.