What is TCP New Reno?

TCP New Reno is the extension of TCP Reno. It overcomes the limitations of Reno. TCP Reno is the second variant of the TCP which came up with an in-built congestion algorithm. Congestion handling was not an integral part of the original TCP/IP suite. TCP Reno is the extension of TCP Tahoe, and NewReno is the extension of TCP Reno. In Reno, when packet loss occurs, the sender reduces the cwnd by 50% along with the ssthresh value. This would allow the network to come out of the congestion state easily. But Reno suffered from a very critical backlog which hurts its performance. 

When multiple packets are dropped in the same congestion window (say 1-10) then every time it knows about a packet loss it reduces the cwnd by 50%. So, for 2 packet loss, it will reduce the cwnd by 4 times (50% twice). But, one reduction of 50% per congestion window was enough for recovering all those lost packets. Say cwnd=1024 and 10 packets are dropped in this window, Reno will reduce cwnd by 50% 10 times, finally cwnd=1024/2¹⁰ = 1, it is astonishing. It would take 10 RTTs by the sender to again grow its cwnd up to 1024 using slow start leave alone the AIMD algorithm.

Limitation of Reno:

1. It takes a lot of time to detect multiple packet losses in the same congestion window.
2. It reduces the congestion window multiple times for multiple packet loss in the same window, where one reduction was sufficient.

How did New Reno Evolve?

The idea was to overcome Reno’s limitations. The trick was to let know the sender that it needs to reduce the cwnd by 50% for all the packets loss that happened in the same congestion window. This was done using partial ACK. The new type of ACK was introduced for letting know the sender about this. In Reno, after half window of silence when it receives the ACK of the retransmitted packet it considers it a new ACK and comes out fast recovery and enters AIMD then again if packet loss (same cwnd) occurs then it repeats the same procedure of reducing cwnd by half. But NewReno sender will check if the ACK of the retransmitted packet is new or not in the sense that all the packets of that particular cwnd are ACKed by the receiver or not. If all packets of that particular cwnd are ACKed by the receiver then the sender will consider that ACK as new otherwise partial ACK. If it is partial ACK then the sender will not reduce cwnd by 50% again. It will keep is same and won’t come out of the fast recovery phase.

NewReno Solution:

It uses the concept of partial acknowledgement. When the sender receives the ACK of the first retransmitted packet then it does not consider it a “New ACK” unlike TCP Reno. NewReno checks if all the previously transmitted packets of that particular window are ACKed or not. If there are multiple packets lost in the same congestion window then the receiver would have been sending the duplicate ACKs only even after receiving the retransmitted packet. This will make it clear to the sender that all the packets are not reached the receiver and hence sender will not consider that ACK as new. It will consider it a partial ACK because only a partial window is being ACKed not the whole. Reno used to come out of the fast recovery phase after receiving a new ACK, but NewReno considers that ACK as partial and does not come out of the fast recovery phase. It wisely makes the decision of ending the fast recovery phase when it receives the Cumulative ACK of the entire congestion window.

Therefore, NewReno will detect multiple packet loss immediately and does not come out of the Fast recovery phase prematurely unlike Reno.

Understanding with an Example:

Assumption:

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

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	Re 3
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)			23
18.	3	7	7	24
19.	3(DA1, R19)	7	7	25
20.	3(DA2, R20)	7	7	26
21.	3(DA3, R21)*	7	7	Re 4
22.	3(DA4, R22)	7	7	27
23.	3(DA5, R23)	7	7	28
24.	3(DA6, R24)	7	7	29
25.	3(DA7, R25)	7	7	30
26.	3(DA8, R26)	7	7	32
27.	26	(7+1/7)	7	32

Step 18 to 20: TCP Reno considers it a new ACK and comes out of the Fast Recovery phase and enters the AI phase. Whereas NewReno marks it as partial ACK and stays continuously in the Fast Recovery phase. Sender checks if it has received all ACK of all packets of this particular congestion window. If yes, then this is a new ACK otherwise a partial ACK.

Step 21: From 18-20, TCP Reno increases the congestion window by 1/7 per ACK. But NewReno keeps cwnd=inflight=7 because it is still in the Fast Recovery phase and has not yet entered into the AI phase. It retransmits packet-4 after receiving 3 duplicate ACKs.

Step 22 to 26: The sender is getting duplicate ACKs and maintaining cwnd=inflight. It sends a new packet into the link per ACK. The Fast Recovery phase is not ended yet. Because it has not received a new ACK.

Step 27: The receiver received packet-4 which was retransmitted by the sender. Now, the receiver has all the packets from 1-26 in order. The lost packets 3 and 4 are also received by the receiver, so now it sends the cumulative ACK for packets 4-26 as ACK-26. Till the last step, it was sending duplicate ACK-3 saying that it has received up to packet-3 in order. The sender now received the cumulative ACK and checks if it is a new ACK or not. 

ACK received > cwnd ? Yes : No
26 > 10 ? yes : No

Thus, Yes, ACK-26 is a new ACK. Therefore, now the sender will come out of the Fast Recovery phase.

Note that the sender stayed longer in the Fast Recovery phase compared to Reno but it has not reduced the cwnd and ssthresh multiple times for the same congestion window. This was not available in TCP Reno.