0

In the fast retransmission logic in TCP, TCP retransmit the packet when the sender gets the 3 duplicated ACKs. However, what if the sender gets 6 duplicated ACKS?

The following procedure is what I think,

1) sender sends lots of packets with big window size

2) the first packet is dropped

3) Receiver sends ACKS that contains the seq # of the first packets. And other ACKS will have same ack numbers. (For example, the sender send 1,2,3,4,5,6,7 and packet 1 is dropped. Then, the receiver sends ACKs 1,1,1,1,1,1,1)

4) The sender gets 3 dup acks and retransmit the dropped packet However, the receiver still sends 6 dup acks because the receiver doesn't get retransmitted packet. Therefore, the receiver will send duplicated ACK until it gets the dropped packet

5) The sender gets 3 dup acks again, and retransmits the packet again.

Therefore, the sender will retransmit the packet repeatedly. I thinks this is weird. Is there any problem in the above procedure (scenario) ? Or is there any TCP logic that can prevent the above problem?

Sangwook Bae
  • 21
  • 3
  • (3) doesn't make sense. The 'following ACKs' can't ACK packets that weren't received. – user207421 Jul 23 '16 at 06:27
  • @EJP For example, if sender sends packet 1,2,3,4,5,6,7,8,9,10 and packet 1 is dropped. Then, receiver will send 1,1,1,1,1,1,1,1 for ACK until it receives packet 1. Am I right? – Sangwook Bae Jul 24 '16 at 03:52
  • TCP doesn't care about packets (layer-3, IP datagrams), it uses segments (layer-4, TCP datagrams). The host expecting to receive data doesn't send ACKs for the missing segment, it sends multiple, duplicate ACKs for the segment preceding the missing data. "_Or is there any TCP logic that can prevent the above problem?_" That is not a problem; it is expected behavior. The problem would be if one of the required three ACKs was lost on the way back to the sender. The sender needs to receive three ACKs, not the receiver sending only three ACKs. – Ron Maupin Jul 24 '16 at 04:16

0 Answers0