How to calculate ICA RTT on NetScaler Insight

ICA Round Trip Time (RTT) is the elapsed time from when the user hits a key until the response is displayed back at the end point. This is neither calculated by NetScaler nor by MAS. This value is calculated in the XenApp/XenDesktop level, which will be picked up by NetScaler and provided to MAS. MAS displays the value accordingly.

Therefore, ICA RTT constitutes of the actual application delay, which includes:
 
1. Client OS introduced delay
2. Client to NS introduced network delay  (Wan Latency)
3. NS introduced delay in processing client to NS traffic  (Client Side Device Latency)
4. NS introduced delay in processing NS to Server (XA/XD) traffic (Server Side Device Latency)
5. NS to Server network delay  (DC Latency)
6. Server (XA/XD) OS introduced delay (Host Delay)
 
ICA_RTT is Not equal to the delays in each of the above added together ( 1 + 2 + 3 + 4 + 5 + 6 ), however all 6 items do comprise the ICA RTT delay. They do not add up as the majority of these values are L4 while ICA RTT is calculated at L7 layer. Layer 7 can be comprised of multiple Layer 4 round trips, so it is incorrect to assume ICA_RTT = 1 + 2 + 3 + 4 + 5 + 6. That said, those times provide significant insight to where an issue may lie and you should use the Layer 4 delays to determine where issues may lie when there are reports of slowness.

One should also take into account that acceptable Layer 4 latency or ICA_RTT metrics and their values are dependent upon the type of content being delivered, as well as various components of your network, servers, and users, so we do not publish "acceptable values".

Here are Examples of how these values can vary and why it matters.

• Video or audio streaming can tolerate far more latency to remain smooth without buffering, however jitter and limited bandwidth can cause issues.
• Audio or video teleconferences would tolerate far less of either jitter or latency, but latency of up to 30ms may be acceptable for audio calls.
• Desktop apps can tolerate significantly more latency and jitter. However the type of app also makes the requirement vary. AutoCAD for example requires precision with the mouse, and therefore may necessitate low latency. However MS Word has no such requirement, and latency is far less of an issue.

Additionally, none of these latency metrics account for packet loss, out of order packets, duplicate Acks, or retransmissions. Latency can increase when these are occurring, but not always and WAN latency also increases the further away a user is Geographically from the NetScaler, so an increase in latency is not a deterministic relation for any of those TCP issues. Therefore engineers must use judgement based upon data you know about your network, users, and their patterns of usage, and may need to take a NetScaler trace to evaluate if there exist any TCP issues on the user's WAN link, as those will not be obvious by the Layer 4 metrics shown in NMAS but will cause an increase in the ICA_RTT.

Finally the values are cumulative. Take for example a situation where perhaps WAN Latency is high but generally Ok, and 2 servers, one with low latency and one with high but generally Ok latency. When a user has high WAN latency but connects to a server with low latency, they could have no issues. However when they connect to the server with High latency, it could be Not Ok and cause the user to have a poor experience. This is where ICA RTT comes into play as it gives you a better overall picture of the user's experience.