When is a Fast Retransmission Not a Fast Retransmission? – PacketBomb

When is a Fast Retransmission Not a Fast Retransmission?

By Kary | text

Jun 10

The Expert Infos in Wireshark are very helpful, but are they always right? You need to understand how TCP behaves to know if you can trust what Wireshark tells you. Let’s take Fast Retransmissions. Here’s what RFC 2581 says:

The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs.  The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost.  After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire.

The devil is in the implementation and some TCP stacks will fast retransmit after the 3rd identical ACK (2nd duplicate ACK). After the fast retransmit, the sender will go into fast recovery mode instead of slow start.

So knowing that, have a look over this pcap and tell me in the comments if frame 24 is really a Fast Retransmission and why or why not. Be careful and pay attention to the details!

If you’d like to see the video of my explanation and walk through, just sign up for the email list below and you’ll get a link to the subscriber-only videos. This one is called “When is a Fast Retransmission not a Fast Retransmission?” Once you confirm your email address, you will get an email with the link within an hour.

BONUS QUESTION: TCP usually ACKs every other packet but you can see every packet is being ACKed. Why?

Share this post! Spread the packet gospel!


About the Author

I like being the hero. Being able to drop a bucket of root cause analysis on a burning network problem has made me a hero (to some people) and it feels real good, y’all. Get good at packet analysis and be the hero too. I also like french fries.

Leave a Comment:

(23) comments

Jasper Bongertz June 11, 2015

Not a fast retransmission. Because iRTT (trying not to spoil the fun) :-)

    Kary June 11, 2015

    Yep :)

    There’s another supporting point in the capture as well.

      Dana Dawson June 11, 2015

      Another clue that the retransmitted packet is actually just out-of-order is the fact that the IP Identification value in frame 24 is smaller than in frames 20 and 22, and in fact, they are sequential values if frame 24 is assumed to have been originally transmitted first. The IP ID field doesn’t technically have to be incremented like this, but many (most?) systems do since it’s an easy way to help ensure uniqueness for fragmentation purposes, so this sequence of ID values strongly suggests that frame 24 was originally transmitted before frames 20 and 22.

        Kary June 11, 2015

        Good spot! :)

Dana Dawson June 11, 2015

Regarding the ACK of every received packet, I suspect this is an optimization by the Linux TCP stack (and perhaps others) that allows the receiving host to send an ACK immediately if it has no data to send and it can advertise a larger RWIN, which is the other slightly different behavior I noticed in the capture. I checked the “wget” source (that’s the “User-Agent” in the initial HTTP request) and couldn’t find any explicit option being set there to turn off Delayed ACK, so unless it’s a global system setting on the receiving host (still a possibility) I’m gonna stick with my theory about this being an optimization.

    Kary June 11, 2015

    Yup, this is quickack mode on linux and can be used at the start of a TCP connection to enable the congestion window to grow quicker during slow start.

Rohan June 12, 2015

Awesome example! I am fairly new not to networking but to tcp analysis and this is incredibly helpful
Thank you!

Christian Reusch June 13, 2015

At Frame 24 there is from the clients point of view no difference, if it is a Fast Retransmission or an Out Of Order Packet. In this example it is at the point of Frame 24 more less equal. Later there may be a needless retransmission… . But at other related problems the state difference could be part of the root cause.


Packet 24 is no retransmission, but simply out of order; it’s sequence number indicates that it should’ve been arrived before packet 20.
The two DUP ACKs we’re seeing have both the left edge of SACK set to 10945, which shows that it was missing the ext expected sequence number of 9577 (packet 24). It’s out-of-order and SACK in action.

Vladimir June 16, 2015

Hi Kary!
Thanks for this beautiful example.

It seems that Wireshark recognizes pattern “dup ACK1 -> dup ACK2 -> Retransmisson” and don’t get into consideration, that client’s dup ACK’s were not able even to get to the server at this time.

By the way, what will the server do after receiving these dup ACK’s? Did you see “spurious retransmission” somewhere down in the trace?

    Kary June 22, 2015

    When these Dup ACKs were received by the server, it did NOT do a fast retransmit or any other kind of retransmit. This is what caused me to take a closer look at the example and why I thought it made for a good puzzle.

    The reason that there was no fast retransmit triggered on the server is coming in a future video :)

      Vladimir June 24, 2015

      Thanks, that got me guessing.
      At first I would check server-side to be sure that these ACK’s have arrived to the server succesfully.
      And if yes, maybe server’s TCP stack is tuned to react to more ACK’s (like 4 identical in RFC or even more), but i don’t know if it’s possible.
      Or maybe ACK’s arrived out-of-order too? And that could potentially destroy “4 identical ACKs” pattern?

Marc November 27, 2015

I just signed up for your awesome mailing list. Where can I get the follow up videos to these older posts?

    Kary November 27, 2015

    Hi Marc, you should get an email with the link within an hour of signing up. Let me know if you don’t.

airomyas December 23, 2015

Interesting topic, I just want to known the answer.

Tong May 7, 2017

Great article

Looking forward for the video

Samuel June 30, 2017

Frame #19 acked #18. No bytes in flight anymore.
Frame #20 and #21 were out of order and arrive/capture earlier.

Frame #19, #21 and #23 are the same. Thus, Frame #21 and #23 are duplicat ACK.
For Frame #21 and #23, there was no bytes in flight to ACK.

Frame #24 should arrive earlier to follow frame #19.

Out of order frames misleads to “TCP Fast Retransmit”, while there is no packets loss.

Biman March 18, 2018

I spent good one hour to find out why acknowledgement was sent after each data packet as opposed to every alternate one. I could not find the answer. There was no PSH flag, there was enough receive buffer. There is enough gap between “Bytes in flight” and Receive window, RTT is small enough.

So I give up for now, and resort to you

    Kary March 18, 2018

    Check out Dana Dawson’s reply on this post for the answer

Jonathan June 28, 2022

Not really sure what to look for here and I cant connect the dots
My observations:
I see a transfer of a 100MB file
It was decided to chop it up
The pcap consists of tcp segment of a reassembled pdus
There is some pause with 0.1 seconds before packet 14 in the tcptrace – not sure what this means and if its relevant

Anindya Das July 5, 2022

Can there be stacks which allows Fast Retransmission after 3 Dup ACKs as well as 2 Dup ACKs? I see in my logs this strange phenomena.

    Kary July 5, 2022

    Yes, I think so

Bengaluru Huduga October 4, 2022

Thanks for going the extra mile!

Add Your Reply

Leave a Comment: