Clicky

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!

Facebooktwittergoogle_plusredditlinkedinmail
Follow

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:

(15) comments

Jasper Bongertz June 11, 2015

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

Reply
    Kary June 11, 2015

    Yep :)

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

    Reply
      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.

      Reply
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.

Reply
    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.

    Reply
Rohan June 12, 2015

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

Reply
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.

Reply

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.

Reply
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?

Reply
    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 :)

    Reply
      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?

      Reply
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?

Reply
    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.

    Reply
airomyas December 23, 2015

Interesting topic, I just want to known the answer.

Reply
Add Your Reply

Leave a Comment: