Introduction

As long as the feature has been around, Session Reliability has always been a topic of debate.  As a field consultant I would occasionally go on Issue Resolution projects and these are inevitably the worst to be staffed on because there is rarely a silver bullet to make things perfect.  And inevitably, the topic of Session Reliability would come up as a troubleshooting step to either turn on or off; it didn’t matter what the previous configuration was because hopefully switching it would be that magic switch.  Sometimes configuration errors in the access flow would exist, but often disconnections would occur because of spotty network connections or real network problems.  In this article, I’m not going to talk about when to enable Session Reliability – that has been covered by Nick Rintalan in a recent post – Session Reliability, Frozen Screens and The Hourglass of Death – and this is really a follow-up to that article.   The purpose of this article is to dive into the details of Session Reliability (SR) and look at the new implementation of CGP in the latest versions of XA, XD and Receiver, so we can all make an informed decision about configuring it.

SR Traffic and Flow

One thing I come across is the statement that Session Reliability should be disabled because it increases the amount of bandwidth.  For this article I ran a variety of network traces and LoginVSI simulation from different Citrix Receivers (13.4, 12.3 and 10.150) to published applications and virtual desktops (XenApp 6.5, XenApp 5 and XenDesktop 5.6).  One key finding is that SR with XenApp hasn’t really changed much since its inception.  Funnily enough I looked back at some research I did for a previous client many  years ago where I created a Visio of the Session Reliability traffic flow in the event of a disconnect.  Find and replace MetaFrame Presentation Server with Citrix XenApp, update some logos and it is now current 🙂

With XenApp, in idle communication this confirmation message exchange consumes about 0.2 kbps.  The Session Reliability overhead to maintain a single session is basically negligible.  Also, with active communication simulated using the LoginVSI Medium workload, Session Reliability actually shows a little bit of bandwidth savings (~1-2%).  The average SR-enabled session consumed 262kbps vs. 265kbps for ICA.  (Keep in mind LoginVSI is doing a lot activity which is the reason for the high bandwidth, which is really high for a performance and scalability test but that is another topic of discussion..)

In my testing the 12.3 and 13.4 online plug-in versions consistently followed this process.  However with the 10.150 client I saw some funky behavior where after a session reconnects the 4s periodic client to server communication didn’t occur.  I have also seen in the past where after a reconnect, session traffic goes crazy even in idle communication.  These issues are some of the things Nick noted in his article and in the past have deterred me from broadly recommending Session Reliability for XenApp, unlike now where I feel safe it will work as expected in the newer versions of our products.

With XenDesktop, this communication has changed significantly and the messages are exchanged more frequently.  With the 5.6 version of the VDA, in an idle state the VDA sends communication to the client every second.  In addition, the client sends communication to the VDA every second.  This results in around 1.4 kbps.  I’ve also seen examples where with the VDA 5.5 on Win7 this utilizes 7.1 kbps with a completely idle session.  With a LoginVSI Medium workload to XenDesktop, Session Reliability utilizes pretty much the same bandwidth as an ICA session (1% less for SR).

ICA Traffic and Flow

In comparison, SR can be disabled with periodic ICA keep-alives enabled where the server checks on the client (60 seconds by default).  There are a handful of packets that are exchanged for a keep-alive sequence, amounting to about 2976 bits, or a scant ~50 bps.  The following image shows a network trace at the time of a network disconnect and reconnect.

User Experience

While it is fun to dive into the nitty gritty of Session Reliability versus ICA it is always important to keep in perspective how each impacts the user experience!  Ultimately it is up to the customer to decide which experience is “better”.  Session Reliability can show itself in a couple of ways, depending on the client version and what is being connected to; here is a brief overview:

SR – Disconnected Published Application

  • Receiver 4.0 (with online plug-in 14.0) – application windows dim and Reconnecting balloon tip displays
  • Online plug-in 12.x to Receiver 3.4 (with online plug-in 13.4) – Reconnecting balloon tip displays
  • Pre-12.x – no obvious feedback (i.e. hourglasses and frozen screens)
Receiver 4.0 Online plug-in 12.x – 13.x

SR – Disconnected Virtual Desktop (with Desktop Toolbar)

Citrix client with desktop toolbar

ICA – Disconnected Published Application

After the application disappears from the screen, Auto-Client Reconnect will attempt to reconnect to the servers

After network cannot be re-established users often see a Citrix Receiver error and will need to re-launch the application.

Conclusion

While Session Reliability may have not been so reliable in the past, over the years it seems that bugs have been ironed out and now there should be no broad recommendation to disable it.  As with any design decision, the characteristics, pros and cons must be weighed based on the use cases and organization.  On one hand Session Reliability can mask core networking problems.  On the other hand, it is designed to keep a session alive during network blips.  In theory this should reduce user pain as the alternative is to re-launch the application when a network connection becomes available.  It is up to the design team to determine which is the best strategy.  For me, I lead with Session Reliability enabled unless there are specific reasons to turn if off (incompatible clients, firewall rules, older ICA clients or XA versions etc.).