Link to home
Start Free TrialLog in
Avatar of illfusion82
illfusion82

asked on

Citrix network tolerance

What is the network tolerance that Citrix XenApp 6.5 can with stand before disconnecting a session? Does a session disconnect with a single packet dropping or can Citrix sustain multiple packets being dropped without disconnecting the session?
Avatar of joharder
joharder
Flag of United States of America image

XenApp employs Session Reliability by default which allows for ICA communications to be buffered for a period of up to 3 minutes (default).  Thus, if a quick network blip occurs, the user may not even know it.  If the network failure is longer than 3 minutes or if Session Reliability is disabled, then the user session will disconnect after multiple packets fail.
Avatar of illfusion82
illfusion82

ASKER

Is there documentation anywhere that states the number of packet failures a Citrix session can sustain before disconnecting?
Sorry forgot to mention when session reliability is disabled is there documentation that states the number of packet failures a session can sustain before disconnecting?
ASKER CERTIFIED SOLUTION
Avatar of Olivier Marchetta
Olivier Marchetta
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
It depends on the version of Citrix and ICA versus FMA protocol stack.  The short answer is upwards of 400ms latency but that requires further explanation.

One of the reasons for using Citrix is due to their protocol to handle higher latency networks including dial up modems (back in the day).  I remember running Citrix on NT 3.51 and Winframe 1.0 about 20 years ago or so over a 28.8kbps then 33.6kbps then 56k was introduced.  I've also leveraged Citrix over Satellite connections to remote areas of the world.

XenApp 6.5 the Session Reliability is generally disabled by default so your connection will use ICA on port 1494.  

There are multiple factors in regard to connectivity and bandwidth.  The published applications or whether you are using published desktop would impact overall bandwidth but also keeping in mind that the only thing traversing the wire (for the most part) are "screen scrapes" and "keystrokes".  

A published application (seamless session) with 32-bit icon consumes ~65kB of memory
A session consumes 1.6KB
A server consumes 210KB
A worker group consumes 8KB

This does not account for the application itself.  Some applications require a lot more "screen scrape" to look right down level and these settings can also be tweaked on the Published application.

However, this is only when the user is active.  For example, let's say you have a T1 worth of bandwidth to LocationA.  You might be able to get 15 concurrent sessions on this pipe but this is highly contingent on usage patterns.

The usage patterns could be extensive and if you want some scenarios please see my article on Citrix licensing where I delve into some of the case scenarios relative to users, licensing, and items that would impact bandwidth being a session does not consume bandwidth unless in use.

Reference: https://www.experts-exchange.com/articles/25022/Maximize-Citrix-Concurrent-Licensing-To-Reduce-Cost-Session-Timeouts-3-Millon-Dollar-Cost-Save.html

Then, you have the printing aspect of Citrix and whether or not you are using Citrix Universal Print Driver.  Versus not and where the print servers are located relative to the client machines.  To maximize this performance of printing I have another article written for 7.6 but is still relevant to 6.5.

Reference: https://www.experts-exchange.com/articles/25499/Citrix-XenDesktop-7-6-Citrix-Policies-Advanced-Printing.html 

There are other tweaks to the ICA protocol using Citrix Policies (such as the Advanced Printing) that will improve end-user experience on high latency scenarios.

In my experience, the protocol can handle upwards of 400ms latency times across the network when tweaked.

You would simply need to look at latency multiple times throughout the day and particularly if/when users are experiencing disconnects.

A simple way to do this is from various workstations located at different locations back to where the Citrix environment is hosted.

Start by opening command prompt and using the "pathping" (one example) from Windows OS to get an idea of latency but this assumes that ICMP is not disabled on switches, routers and firewalls.

I would pathping from servers to servers located on the same physical LAN but split between separate switches on your network.

Then, pathping from workstations to different Citrix servers hosting applications and if those servers are spread across different switches make sure you pathping to all because you might find a latency issue on LAN or WAN.  

Then from remote sites use pathping from workstations to the different Citrix servers to determine latency issues at the remote site and across the WAN hitting different route points.  This data is not always 100% accurate but it is a good starting point.  

Sample output:
pathping 192.168.0.100

Tracing route to citrix1.corp.local [192.168.0.100]
over a maximum of 30 hops:
  0  x.corp.local [192.168.0.100]
  1  x.corp.local [192.168.0.100]

Computing statistics for 25 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0    0ms     0/ 100 =  0%
  1    0ms     0/ 100 =  0%     0/ 100 =  0%

Trace complete.
-----------------------

Your looking at RTT and any packet loss.  Packet loss might be attributable to having low grade switches or hubs at remote sites that are maxed out, for example.  Then you have latency and attenuation.  

Another example of this would be using "tracert" command.

You can script these out and schedule them to run at various times if network monitoring tools are not available.

Generally what we look for are latency issues being packet loss is not "as common" today where the duplex setting would vary when some customer NICs where set to "Auto Negotiate" and you would have some NIC's connected at half duplex others at full.

You could generally see this as dropped packets on the workstation side by running command prompt on the workstation and typing

net statistics workstation

This would show you packet drops and indicates a localized issue where looking at the latency output above should show you what "hop" is experiencing the latency.  For example, if the user is connecting over the internet using an ISP connection and there are 10 hops then 1 or 2 or more of those hops could have high latency.

You can also examine the end-user Citrix client statistics through the Program Neighborhood Connection Center in the bottom right corner in Task Tray.

Highlight the server. From the Properties tab determine if the incoming bytes and / or frames adjust themselves when performing an action within the application.  (See Image1.jpg attachment).  This will show frame errors and incoming/outgoing statistics for the session.

As a best practice I would disable aspects of the ICA channel that are not needed.  One example of this and still applicable to 6.5 is my article on disabling peripherals: (one example)
https://www.experts-exchange.com/articles/25519/Citrix-XenDesktop-7-6-Citrix-Policies-Disable-Peripherals.html

There are other tweaks you can do from the Web Interface side relative to launch ICA file that will modify other settings allowing for more latency tolerance.

If you need to scale for better latency see:
XenApp 6.5 Enterprise Scalable XenApp Deployments
https://support.citrix.com/article/CTX131102

In summary, the Citrix session can handle higher latency times (which would cause packet loss) and remain connected.  This was part of the stack design day one.

With that said, you can tweak the ICA protocol to withstand higher latency times and even enable different connection "profiles" from the web interface that a user can choose - for example, WAN connection - that will further increase the threshold.

However, latency and bandwidth constraints can be separate issues.  If someone is running a file copy process across the WAN and this might cause a saturation of that connection resulting in packet loss although latency times seem fine.  Or, running all Internet usage across the WAN back up through a centralized connection at corporate and where multiple users are playing Video's online or watching movies.

This is where we would discuss network analysis and using a proxy server for Internet Traffic and Quality of Service policies across the network to ensure Citrix ICA protocol is given precedence.  

On average the ICA connection might use 15-25k of bandwidth per user but this can change dramatically when it comes to printing, type of published application, using published desktop and during times of inactivity the bandwidth use might be 0k which is why we enable the ICA keep alive among other reasons to maintain session over firewalls and deal with disconnected sessions and reverting those to disconnect state so the user can reconnect back to the original session.

Hope this answers your question.
image1.jpg