Do tcp dup acks always mean a retransmission
Hi First post and something I have been wrestling with a while-its all around TCP Dup Ack's and Retransmissions.I have watched and read some excellent stuff from Chris Greer, so I have tried to research it :-)
Firstly, can I put down what I think each is-and then be rebuked if necessary:
Retransmissions-Retransmissions are initiated by the sender if there is no response within it's retransmission timer-so it doesn't need to be told by the client/receiver something has been lost-it just resends?
Dup Acks-Dup Acks are sent by the client/receiver back to the sender, telling the sender something is out of order
Here's my problem-I have a trace where I can see loads of Dup Ack's (sometime 300-400-but only 2 retransmissions-10 second trace over a high speed cable link). RTT says consistent at about 22ms (there are a few spikes to 90s but I cant see any Dup Acks or Retranmissions at the same time?) So Dup Ack's indicate packet loss? But again, the throughput trace looks clean, as does the window scaling.
Should I be worried by these Dup Acks? As all other indications look ok (I think!)
Thanks
cabs
Correct, a retransmission is based on the Retransmission Time Out (RTO) timer set by the OS and typically adjusted continuously during the lifetime of a TCP session - depending on the OS/TCP stack.
Also correct is the your definition of Dup Acks.
You will see Dup ACKs if the receiver sees data out of order, but it will not necessarily result in a retransmission if the data is "just" out of order, because the receiver will eventually receive what it's missing and subsequently ACK it and then everything is fine. This can easily be an explanation to what you see.
If you see three Dup ACKs with very short delay (effectively immediately one after another), the receiver is signaling loss and you should see what's called a Fast Retransmission.
You write RTT spikes to 90s - are you sure? 90 seconds is a looooong time :-)
Is SACK being used ...(more)
Thanks for the reply-sorry, Typo-where I said 90 seconds, should have said 90ms :-) But still big I suppose, when the average is 20-30ms (ish)? I don't think I'm allowed to share a file as a newbie-and the pcap I'm looking at is just under 700MB.
I think you have answered my question anyway-I went back and looked at the file-and there were only a few re-transmissions (although a lot of DUP's). Looking at the SYN/SYN-ACK SACK is indeed in play between the server and the client.
cheers
cabs
Remember you can filter a separate TCP session by right-clicking -> Conversation Filter -> TCP. This can then be exported to a separate capture file by File -> Export Specified Packets. Additionally you should sanitize your capture before sharing it using Dropbox, Google or preferably Cloudshark. Read more about the recommended process here: https://blog.packet-foo.com/2016/11/t...