Leave a Comment:
(23) comments
Not a fast retransmission. Because iRTT (trying not to spoil the fun) :-)
Reply
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 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
Awesome example! I am fairly new not to networking but to tcp analysis and this is incredibly helpful
Thank you!
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.
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
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 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?
I just signed up for your awesome mailing list. Where can I get the follow up videos to these older posts?
Reply
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.
Reply
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
Reply
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
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.
Reply