Spikes in tcp.analysis.ack_rtt

edit

Hi, there might be different reasons for that depending on your link type, packet loss rate, capture setup etc. Please share PCAP if possible.

Hi, thanks for your answer, I added a link to the pcap file in the post, it is an example tcp stream where you'll find a spike or 2 in it, if you need more details please let me know

Could you please show me a screenshot to look at how exactly you built the graph?

But overall I'd not do any deep RTT analysis on such short (just several packets) trace, even more it is more like applicaton protocol, not bulk data transfer. So I think any RTT analysis except maybe 3-way handhsake analysis won't have a lot of meaning.

The only interesting point I'd look at is Frame no.8 - Retransmission. Possible reasons are Packet loss, ACK loss or not accurate RTO estimation value which could happen on such small packet subset.

Do you have any problems with performance? Is this retransmission behavior consistent? What environment is it? Wired/wireless? Distance between endpoints?

Hello, thanks for your answer,

I'm plotting the graph with wireshark I/O graphs, 1sec interval, here is a screencap:

https://1drv.ms/u/s!AmIyGQHEPWcVjrw-H...

The distance between the two sites is 4000+ km

Indeed I also noticed the Retransmissions, I wonder if they are related to the spikes in RTT, is there a way to confirm if this is the case?

best regards

This is a graph for different trace, much bigger one. Is it consists of request-responce chunks you've shared?

You can check whether all these spikes correspond to Retransmissions.. Make a column for tcp.analysis.ack_rtt and sort it in descending order or apply display filter tcp.analysis.ack_rtt > 0.25 and spot if all packets left are Retransmissions.