cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

what can be the reason of having very high RTT and very less ACK RTT, the different is huge , RTT around 180 and ACK RTT around 10-20

ranjana_mishra
Newcomer

what can be the reason of having very high RTT and very less ACK RTT, the different is huge , RTT around 180 and ACK RTT around 10-20

2 REPLIES 2

Babar_Qayyum
Leader

Hello Ranjana,

High RTT may indicate network routing issues. Client ACK RTT is time for an ACK packet to travel from the user to the AMD and back. Client RTT is time for a SYN packet to travel from the user to the AMD and back again.

Regards,

Babar

Krzysztof_Ziemi
Dynatrace Pro
Dynatrace Pro

Hi,

Unfortunately the answer is "it depends". In order to decipher this dependency, it would help to know how the calculations are made by the AMD.

RTT is calculated when a new TCP session establishment sequence is seen: SYN-SYNACK-ACK packet exchange between client and server. AMD measures timings of each packet seen in this sequence and this way calculates the RTT (precisely, RTT between client and AMD and between AMD and server).

An assumption that AMD mades here is that TCP stacks on both client and server respond immediately to the SYN and SYNACK packets. This is generally true, but I can imagine some network devices that delay answers for various reasons (WAN optimization controllers and load balancers could be the suspects). If such delays occur, the RTT measurement would account this artificial delay as a part of the TCP session establishment sequence and thus the measurement may be skewed.

Please also note that RTT is measured only when TCP session is established, so in case of long-lasting sessions the measurements may be rare throughout the day (or even no measurements may be performed for days if sessions last that long).

ACK RTT measurement also depends on the TCP session flow, but it is measured every time a node acknowledges data reception from the other node in conversation. So there may be hundreds of measurements performed every second if the session is busy. In this case AMD measures the time between data packets sent be server (or client) and a packet sent back by the other node with the ACK flag set. Here the measurement algorithm is a bit more sophisticated because it has to account for delayed ACKs that typically happen when Lamont of data sent back and forth is low. So AMD has to take into account packet sizes, amount of data packets and outliers before the ACK RTT measurement is reported. In AMD 17.x this measurement is highly accurate, in AMDs 12.4 and earlier it was accurate when data volumes were high and choppy under low traffic conditions. Typical 12.4 deficiency was that under low traffic conditions ACK RTT showed high values (because delayed ACKs were not eliminated efficiently enough from the raw measurement series). AMD 17 has the ACK RTT algorithms designed to eliminate this deficiency, using distribution calculations and percentile weights to eliminate outliers.

So summarizing, high RTT and low ACK RTT look like a potential effect of some traffic shaping devices on the path. If WOC like Riverbed or Cisco WAAS may be present, use DC RUM's WAN optimization monitoring decode to measure precisely the WOC performance and usage.

Best regards