TCP Fast Retransmit and duplicated acknowledgements Ask

Question

Hi I read an Textbook(Computer Networking : a top-down approach / James F. Kurose, Keith W. Ross.) describes the process of TCP's Fast Retransmit, basically TCP retransmits the lost paclet when it receives three duplicated acks for that packet before timeout as the picture below shows:

But one thing I don't understand is, TCP also can buffer out-of-order packets, so the sender side only resends missing packets, so for the case in the picture, because receiver only acked the missing packet whose sequence is 100, but sender have sent packet 120, 135 ...etc, since the receiver didn't ack them, how can the sender know those packets have arrived the receiver? so does sender need to resend all those packets again? It seems to me like fast retransmit can only apply on Go-Back N type TCP, not applicable for selective repeat type TCP?

Answer 1

Your best way to understand TCP is to open up Wireshark, download a large file using HTTP, or any TCP protocol, and look for BLACK lines saying DUP ACK, Fast Retransmit, or Retransmit to scroll across your screen.

Generally you will see some packet loss over an internet connection, and you can dig into this further on your own to see your own client sending DUP ACK's for lost packets.

Or better yet, do an upload, and you can see your client doing a Fast Retransmit after it sees 3 identical ACK's.

You can also look closer at the TCP options and see the SACK's that manbearpig alluded to.

Another good source of info about fast-retransmits is the RFC. The second paragraph answers your comment about why 3 ACK's vs 1,2,4,5.
https://www.rfc-editor.org/rfc/rfc2001

3. Fast Retransmit

Modifications to the congestion avoidance algorithm were proposed in 1990 [3]. Before describing the change, realize that TCP may
generate an immediate acknowledgment (a duplicate ACK) when an out-
of-order segment is received (Section 4.2.2.21 of [1], with a note
that one reason for doing so was for the experimental fast-
retransmit algorithm). This duplicate ACK should not be delayed.
The purpose of this duplicate ACK is to let the other end know that a segment was received out of order, and to tell it what sequence
number is expected.

Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. It is assumed that if there is
just a reordering of the segments, there will be only one or two
duplicate ACKs before the reordered segment is processed, which will
then generate a new ACK. If three or more duplicate ACKs are
received in a row, it is a strong indication that a segment has been
lost. TCP then performs a retransmission of what appears to be the
missing segment, without waiting for a retransmission timer to
expire.

Answer 2

You are reading about TCP in a more primitive land where Selective Acknowledgement did not exist. The problem demonstrated here is true without more advanced TCP behavior.

A great writeup of this is from Packet Life

Selective Acknowledgement lets us do this more efficiently. The ACKs also contain info about sequences it did receive along with what it didn't. Without this TCP is dumb and will request retransmission of packets it already received.

EDIT:

I didn't tie in Fast Retransmit here. Fast retransmit is just a faster way of reacting to an assumption a packet must have been dropped (otherwise why would you ever get 3 ACKs with same SEQ#.) It is among other features, like Selective ACK, that optimizes TCP performance.