“What is the recommended network latency for a good user experience in an ICA session?” This age-old question comes up all the time, and in true consulting fashion the answer is… it depends 😊

So, why is that? What does it depend on? Well, first and foremost, it depends on what the user is doing within the session. Given the exact same network conditions, resources, and configuration, the activities taking place within the session could affect the experience. For example, someone who’s checking email, working on Word documents, spreadsheets, etc., could have better perceived performance than someone who’s watching videos. (i.e. the higher the graphic intensity within the session, the higher the perceived degradation could be, and vice versa).

It also depends on who you ask. User experience is a very subjective thing. Different people have different opinions on what constitutes a good user experience. Based on what I’ve seen over the years, different people measure user experience differently. Some people base their opinion solely on what they see whereas others take into account the mechanics of the solution, all the pieces of the puzzle and how each one works, so tend to have a higher tolerance for the perceived performance and are more lenient with their opinions. And you will also have varying opinions within those two groups of people. A tool like Login PI can help in situations like this by proactively monitoring and measuring user experience and helping determine whether there is really an issue within the environment or somewhere between the chair and keyboard.

With that said, the first thing that needs to be addressed is the configuration. Different use cases, and even groups within the same use cases, may require different settings based on what type of activities they need to perform within their session, how far they are from the XenApp servers or VDI desktops hosting their sessions, and the characteristics of their network connection. Therefore, make sure to select the appropriate graphics mode for each scenario.

In addition to the graphics mode, HDX offers an array of options that can help further optimize the performance and experience of multimedia content.  You can learn more about this in the product documentation.

There are also settings that should be applied or changed in Windows itself to optimize the operating system for a virtual workload. If you search for “Citrix Windows optimization,” a few links will come up with various Citrix optimization guides that provide the details on what we normally recommend.  You can also take a look at the Citrix Optimizer tool to facilitate the process of optimizing Windows for your virtual environment.

Assuming the environment has been tuned properly, this is what we (Citrix Consulting) see on average in regards to network latency when using legacy Thinwire or Thinwire+ (a.k.a. modern Thinwire):

  • Up to 150ms: great user experience
  • 150ms – 300ms: good/acceptable user experience
  • Over 300ms: degraded user experience

What about those users with over 300ms latency or applications/use cases that are highly susceptible to latency and don’t quite fit within the above thresholds? Fortunately, we do have options. Derek Thorslund talks about this in his post titled Overcoming Latency to Serve a Global User population, but essentially, as I mentioned earlier, choosing the right graphics mode is important. For these scenarios, Framehawk, which is designed for unreliable high-latency networks, could be used instead. To give you a few examples, we have customers using HDX 3D Pro successfully with 250ms latency while others have more demanding applications and require latency to be no more than 210ms. We have other customers whose use cases are not as demanding, but the users are in remote locations with latency going over 300ms and are happy with the performance.

Alternatively, you could (and probably should) consider Citrix’s latest transport mechanism and secret weapon: Adaptive Transport.  Adaptive Transport uses Citrix’s Enlightened Data Transport (EDT) protocol, which is built on top of UDP and adds reliability, fair sharing, and flow control, thus allowing it to overcome the issues that typically affect TCP and UDP.  Similar to Framehawk, EDT can provide faster data throughput than TCP at higher latencies.  Unlike Framehawk, EDT applies not only to graphics but to all ICA virtual channels!  That means that it improves data throughput for all virtual channels in the session including graphics, printing, client drive mapping, etc.  As the name suggests, Adaptive Transport is meant to be adaptive.  As of the time of writing, the way it works is that it tries to establish sessions using EDT upon connection/reconnection and falls back to TCP if it fails, maintaining high server scalability and efficient bandwidth usage regardless of the protocol used.  As the transport mechanism evolves, it will become smarter and will be able to adapt during the session instead of just upon connection/reconnection.  We will keep you posted!

So, if your user experience issues for sessions over the WAN include things like poor performance for client printer and client drive mappings, I would give Adaptive Transport a try. You can find more details about Adaptive Transport in the documentation.

Having said all that, make sure you tune your environment, do some testing, and define your particular thresholds.

Once you’ve figured out what your standards are, you may want to consider adding the Connection Quality Indicator to your VDI environment so that way your users can know when their experience is suffering due to a poor connection.

Happy tuning!

Migs
Enterprise Architect | Citrix Consulting Services