Understanding Fast Retransmit in this project

[TANSixu]

What will happen if Fast Retransmit has been triggered, but the retransmitted packet is lost again?

Put the answer first: The sender will wait until timeout

According to the document:

Please note, the duplicate ACK is per round, that is, each seq-ack round has its own duplicate ACK counter. To
simplify your design, Fast Retrasnmit will be triggered at most once for each round when duplicateACK==3. After Fast Retransmit, the duplicateACK will not be zeroed out. So, when you first trigger
re-transmission when duplicateACK == 3, it will not be triggered again when duplicateACK==6.

which suggests that the duplicatACK should not be zeroed out, and Fast Retransmit will be triggered only once.

Why we set this rule?

Take a scenario without this rule, which means to zero out duplicateACK and to retransmit whenever duplicateACK ==3, for instance, if the sending window is 64 when sending packets starting with packet no.192, and no.193 is lost. Then the arrival of packets no.194-255 at the receiver will trigger 62 ACKs of no.192 due to the loss of no.193. The 62 duplicateACKs will trigger 20 Retransmit of no.193 at the sender side, which will then make the receiver send 20 ACKs back because the sender will just normally accept the 20 packets no.193 and ACK them. However, the returned 20 ACKs of no.193 will confuse the sender that packet no.194 has been lost, so it will be triggered to send 6 retransmitted no.194. As you may guess, these chain effects will make your sending window turbulent (ssthresh and window size will be changed on every retransmit) without this rule. So that's why we set this rule to avoid messing up.

What is it like in a real TCP congestion control?

Honestly, we are not sure. The RFC does not provide any supporting claims of this rule, but it makes sense to accept it. Though not convincing, we do find a pseudo code snippet that supports our rule in the textbook:

From the textbook 3.5.4 Fast Retransmit

Note that here the Fast Retransmit is only triggered when y==3, where y is the duplicateACK count. And y is not zeroed out after a Fast Retransmit.

Should you have any other questions regarding this, please reach out.