I am currently auditing a client application with DCRUM, and I have a question regarding Client RTT and Client ACK RTT. I have added an image that shows higher Client ACK RTT than Client RTT. What does this mean? That there is something occurring network-wise causing elevated times to establish a TCP session?. Any help is greatly appreciated
I have asked the network teams whether there is proxy, and they have responded that there is only a point-to-point connection through a MPLS with a firewall in the middle.
Solved! Go to Solution.
Usually the ACK RTT will be higher than RTT. RTT is calculated at the beginning of the TCP session. There is no load, or data being transferred/processed yet.
ACT RTT is calculated during the sessions - many times. ACK RTT is calculated when the server/client sends an ACK while sending data (to ensure the data was recieved before sending more). There may be data immediately preceeding the ACK as well. Processing is probably taking place while ACKing the reception of the data itself.
This is like comparing apples and oranges. You cannot really directly compare them. Rather, they should each be trended and analyzed individually. RTT gives you times you would expect if you were to ping a device from your workstation/laptop. ACK RTT trends can be used to see how the network is handling the load of data being transferred.
Thanks for your response. There is still something that is not clear. When hovering over the Client ACK RTT column, you get the definition that is shown in the following image:
It mentions no payload. So does it include data or not?
The ACK itself does not include payload. However the ACK is sent right
after payload has been sent. The client may still be processing the
previously sent data.
Sorry if I was unclear in my originaly post.
I will add that a high client RTT can be a network device in the middle that is colapsed, or it can be quite diferent if the use transparent mode for example the WAN Devices as network optimizer/Routers doing NAT can open a connection to your server. Then the connection is really fast (thanks to our WAN optimization decode, we are able to adjust this time on the Wan optimization, because we see the connection of the Wand devices and we correlate it with the backend), once the transmition is done, the device becomes transparent, because it has to send the packets till the endpoint. This could explain the diferences too. Of course a client with problems, a network device in the middle with a bad connection and in your case as you transit over a WAN, some element in the middle can colapse. It can be not only problems on the client side.