When is RTT calculated?

Question

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

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