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: enter image description here

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?


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.

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 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
TCP then performs a retransmission of what appears to be the
missing segment, without waiting for a retransmission timer to

| improve this answer | |
  • thanks for the amswer, but why 3 duplicated ACKs to trigger the retransmission? why it is not 4 ,5 etc? – amjad May 10 '18 at 4:10
  • The RFC I quoted above explains the reasoning behind choosing 3 over 1 or 2, but think about it this way. If UPS loses your package, and you have to send Amazon X number of emails telling them your package was not delivered before they will resend it, do you want to send them 3, 4, 5, or 100 emails? The lower the number, the faster that packet can be resent. – crrimson May 11 '18 at 22:45

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.


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.

| improve this answer | |
  • thanks for the answer! one thing I still don't quite understand is, why 2 duplicated acks (3 including the first ack) are needed to triger the resend of a missing packet? why not is 1 or 4,5 etc? – amjad May 10 '18 at 2:13
  • I can't claim i know the exact reasons it is that specific number without some research, but i would think this is taking into account long distant network connections and how they behave. TCP adapts itself to delays in a network and the timeout window can adjust accordingly. Fast retransmit helps here to act faster than waiting for a timeout window. – manbearpig May 10 '18 at 2:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.