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

When is RTT calculated?

1

When I look at a TCP connection I see that nearly every ACK packet is used to transmit data to the other side which is perfectly fine. So in theory every sent packet should get an ACK, right? So far so good. But why does Wireshark not calculate the RTT time for every ACK packet? Not that it looks wrong, quite the opposite. But I would like to understand when Wireshark does calculate the RTT? Only for ACK packets with Len 0 (not always the case) or can it detect that multiple packets are ACKed by a delayed ACK?

Below is a typical ACK packet shown which should? have a calculated RTT time. Are RTT times in general useful or are they more confusing when Delayed ACKs are enabled for a socket? I am having a hard time to identify latency issues in the 200ms region where I have tons of 200ms RTT packets on some sockets. This makes it quite hard to identify latency issues in an application if high RTT times are so common.

A much more reliable sign of bad network are TCP Retransmits and Duplicate Acks. But RTT should be also helpful here.

Transmission Control Protocol, Src Port: 8090 (8090), Dst Port: 9789 (9789), Seq: 2356870728, Ack: 991220798, Len: 1460
..
Flags: 0x010 (ACK)
...
SEQ/ACK analysis
Bytes in flight: 1460
No RTT???????????
Timestamps
Time since first frame in this TCP stream: 32.989695000 seconds
Time since previous frame in this TCP stream: 0.000314000 seconds

asked 21 Jun '14, 15:31

akraus1's gravatar image

akraus1
26225
accept rate: 0%


One Answer:

1

So in theory every sent packet should get an ACK, right?

Actually, no. That's not the case. See the answer(s) to the following question for a brief explanation why: http://ask.wireshark.org/questions/33897/how-much-data-for-each-ack

But why does Wireshark not calculate the RTT time for every ACK packet?

well, it does calculate the RTT for every 'valid' ACK, as far as I can see in the code (however: I did not look very thoroughly!).

Only for ACK packets with Len 0 (not always the case)

As I said: it calculates the RTT for every 'valid' ACK (not out-of order, not retransmission, etc.).

BTW: It's not the case, that Wireshark does not use the piggy-packed ACKs for RTT calculation. I have example captures, where you can see that. I guess, that in your example, the 'piggy-packed' ACK is for a frame that has been ACKed before. I can tell you for sure, if you post your capture file somewhere (google drive, dropbox, cloudshark.org).

But RTT should be also helpful here.

So, to answer your question: Yes, RTT values are helpful, but are only one piece of the puzzle.

Regards
Kurt

answered 21 Jun '14, 17:05

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks for Kurt taking the time to give the right backgound.

535 16.917983000    146.254.106.89  192.129.41.82   HTTP    986 Continuation or non-HTTP traffic
Transmission Control Protocol, Src Port: 44242 (44242), Dst Port: ctf (84), Seq: 3380, Ack: 1302, Len: 932

847 17.141959000 192.129.41.82 146.254.106.89 TCP 60 ctf > 44242 [ACK] Seq=1302 Ack=4312 Win=64768 Len=0 Transmission Control Protocol, Src Port: ctf (84), Dst Port: 44242 (44242), Seq: 1302, Ack: 4312, Len: 0

948 17.323640000 192.129.41.82 146.254.106.89 HTTP 1514 HTTP/1.1 200 OK [Unreassembled Packet] Transmission Control Protocol, Src Port: ctf (84), Dst Port: 44242 (44242), Seq: 1302, Ack: 4312, Len: 1460

Packet 535 requests some http data from a server. The server Acks it in packet 847 0,2s later which Wireshark correctly shows as RTT. Now the server sends more data with the same ACK number 4312 in packet 948 which shows no ACK number because this ACK number was already ACKed by our client. If we would calculate the RTT of this one we would end up with an RTT of over 400ms which is very suspicious but this includes the server processing time and not anything related to the TCP stack.

The reason why I was calculating this number is that I wrote a tool to calculate the RTT times of tcp packets on the fly without capturing the complete network traffic and only generating messages when the RTT reaches a certain threshold. To verify the numbers I have used Wireshark but my calculations were not correct all the time. TCP is quite complex after all but thanks to Wireshark I now have a pretty good understanding how TCP works.

(23 Jun ‘14, 04:18) akraus1

TCP is quite complex after all but thanks to Wireshark I now have a pretty good understanding how TCP works.

Good!

(23 Jun ‘14, 05:45) Kurt Knochner ♦