This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Retransmission and RTO

I am hoping to confirm I am on the right track in understanding TCP retransmissions. I have uploaded the trace file to CloudShark. https://www.cloudshark.org/captures/0e6fc62cdd21

We can see that frame #9 ACKed frame #8 but frame#10 is a retransmission of frame #8. So would it seem the frame #9 ACK was not received by TCP causing the RTO timer to expire resulting in the retransmission seen in frame #10?

I guess my confusion is if 10.69.67.100 actually received the ACK of frame #9, did the RTO timer expire early causing an unnecessary retransmission?

I am researching and reading some relevant papers and RFC's but still not certain of the analysis. Any comments are definitely appreciated.

I am sure you can see that I did anonymize the trace file but the ip.id values for 10.69.67.100 were sequential starting in frame #4 and sequential for 172.16.1.216 starting in frame #7.

Cheers GP

rto

asked 17 Aug '15, 13:21

GP CC
10●3●3●5
accept rate: 0%

One Answer:

This seems to be a timing issue with the delay-ack timer at the windows client (200ms) matching the Retransmission-Time-Out of 200ms at the Linux server.
The trace was taken at the server running Linux under VMWare and frame 9 - a delayed ACK - was not lost but was arriving shortly after the 200ms RTO at the server already expired and the (assumed to be lost) segment was already put on the retransmission queue resulting in this spurious retransmission.

alt text

answered 18 Aug '15, 05:58

mrEEde
3.9k●15●22●70
accept rate: 20%

Thank you mrEEde for your review and comments.

I believe the capture was taken off the same switch as the server but am still trying to confirm that.

Just based on what we see in the trace file is it possible to be 100% sure of the suspected spurious retransmission? Please do not take the question wrong, I am just trying to understand better.

I am reading on SACK also, does the fact that frame #11 (the DUP ACK) include a SLE/SRE of 463-468 provide any extra confirmation that the original frame #8 was actually received?

Again your comments are greatly appreciated.

Cheers GP

(18 Aug '15, 08:56) GP CC

The trace was taken close to the server as the TTL of the server's packets are still at its initial value of 64 whereas the clients packets arrive with a TTL of 127 which is 128 decremented by 1 router (Juniper).

Is it possible to be 100% sure ? - It is 50% possible to be 200% sure ;-) The retransmission was not necessary (or spurious) as the client's ACK in #9 asked the server to continue with seq 468 so there is no need to send 463 again. As the server retransmits 463 the client's dup_ACK still asks for 468, why Windows TCP attaches a SACK option is as needless as the re-transmission itself as there was no gap to report.

(18 Aug '15, 10:40) mrEEde