Dive into Citrix ICA protocol – Part1

24 September 2014 by pawelserwan 12 Comments

Despite of the change of delivery technology in XenApp/XenDesktop from IMA (Independent Management Infrastructure) to FMA (FlexCast Management Infrastructure) Citrix still uses ICA for end user session connections. New HDX technologies were presented together with FMA but they are still built on top of the Citrix ICA protocol. Even though it’s over 20 years since it was invented it’s really hard to find comprehensive source of information about ICA. That’s the reason I’ve decided to gather it on my blog.

Some history…

ICA stands for Independent Computing Architecture. It is a proprietary protocol for an application server system, designed by Citrix Systems. The aim of developing ICA was to streamline the data delivery process between a server and a client without binding it to a specific platform or transport protocol. That is why it can run on top of many operating systems including Windows, Linux, iOS. ICA is designed to run over industry-standard network protocols, such as TCP/IP, NetBEUI, IPX/SPX, and PPP and industry-standard transport protocols, such as async, ISDN, Frame Relay and ATM. First version of ICA protocol was developed in 1989-1990 and was used in Citrix Multiuser OS/2. In 1992 Citrix signed licensing agreement with Microsoft for NT Server which resulted in WinFrame – a multi-user version of Windows NT 3.51 which was fully repackaged by Citrix. At this stage of the product development Citrix Systems licensed the Windows NT 3.51 base operating system from Microsoft. The core development that Citrix delivered was the Multi-Win engine. This allowed multiple users to logon and execute applications on a WinFrame server with use of ICA protocol. Citrix licensed the Multi-Win technology to Microsoft few years later, forming the basis of Microsoft’s Terminal Services. This version of ICA is an ancestor of Microsoft RDP protocol. Thanks to that agreement Citrix got access to source code of Microsoft Windows operating system.

ICA is not RDP

As I wrote above early version of ICA (Multi-Win) was sold to Microsoft in 1997 and formed new protocol: Remote Desktop Protocol (RPD) version 4.0. It is quite common that many people (not only non-IT) mix up ICA with RDP. Just to be clear: ICA is not RDP. Even though they seem to be similar they both work completely different way. Below you can find main differences between those protocols:

ICA – Independent Computing Architecture:

– Application publishing is supported by ICA.

– Low bandwidth is sufficient for ICA.

– Encryption is possible I ICA.

– Keyboard and Mouse inputs are present in ICA.

– ICA ensures session reliability.

RDP – Remote Desktop Protocol:

– RDP works only under TCP/IP.

– RDP does not support applications to run in a browser.

– Only 128-bit encryption, using the RC4 encryption algorithm, as of Version 6.

– Session reliability is not ensured by RDP.

Great comparison of different remoting protocols: ICA HDX (Citrix), PCOIP (VMware) and RemoteFX (Microsoft) was presented during E2EVC 2013 conference in Copenhagen. The presentation done by Benny Tritsch(@drtritsch) and Shawn Bass (@shawnbass) is available here:

ICA Functionality

ICA protocol operates at the Presentation layer of OSI Model, which prepares the received data to be presented in Application layer. Conceptually, ICA is similar to the UNIX X-Windows protocol. It also provides for the feedback of user input from the client to the server, and a variety of means for the server to send graphical output, as well as other media such as audio, from the running application to the client.

Source: http://www.escotal.com/osilayer.html

ICA traffic flows from the client device to the XenApp Server over TCP port 1494 or 2598 when Session Reliability is configured. Each ICA session then creates and uses a dynamically allocated TCP port for communications from the server to the client device. Within the ICA protocol, virtual channels are used to designate the various functionalities, such as client drive mappings, video, keyboard strokes, etc. Layer 3 (IP) and Layer 4 (TCP) functionality of the ICA protocol can easily be viewed by using Microsoft Network Monitor or other network analysis tools such as Wireshark.

ICA Virtual Channels

ICA supports the concept of channels at a Session layer to encapsulate rich media redirection or USB extension within ICA. Very good explanation of ICA Virtual Channels can be found here:

http://support.citrix.com/article/CTX116890

I would recommend as well post on Andrzej Golebiowski blog regarding Citrix Multistream ICA: http://citrix24.pl/ – check for post “Citrix Multistream ICA explained”.

You can have up to 32 virtual channels. Seventeen of these are reserved for special purposes. Each channel has a counter-point on the server. These channels sit on top of the ICA Winstation Driver, on top of Protocol driver, on Transport Driver. Virtual drivers operate at the Presentation layer of OSI model. There can be a number of these protocols active at any given time by multiplexing channels that are provided by the WinStation protocol layer. Following is an overview of client-server data exchange using a virtual channel.

1. The client connects to the XenApp Server. The client passes information about the virtual channels it supports to the server.
2. The server-side application starts, obtains a handle to the virtual channel, and optionally queries for additional information about the channel.
3. The client virtual driver and server-side application pass data using the following two methods:
   1. If the server application has data to send to the client, the data is sent to the client immediately. When the data is received by the client, the WinStation driver de-multiplexes the virtual channel data from the ICA stream and immediately passes it to the client virtual driver.
   2. If the client virtual driver has data to send to the server, the data is sent the next time the WinStation driver polls it. When the data is received by the server, it is queued until the virtual channel application reads it. There is no way to alert the server virtual channel application that data was received.
4. When the server virtual channel application is completed, it closes the virtual channel and frees any allocated resources.

It is possible to define ICA virtual channels priority. The information how to do that and the full it of Virtual Channels might be found here:

http://support.citrix.com/article/CTX131001

Default ICA Virtual Channel Priorities

Channel Name	Description	Single Stream (XenApp 6.5)	Multi-stream (XenApp 6.5)
CTXCAM	Client audio mapping	0	0
CTXTWI	Seamless Windows screen update data (ThinWire)	0	1
CTXCTL	Citrix Control Virtual Channel	0*	1
CTXEUEM	End User Experience Monitoring	0*	1
CTXFLASH	Citrix Flash Redirection	0*	2
CTXGUSB	USB Redirection	0*	2
CTXSBR	No longer used. Previously: Citrix Browser Acceleration	0*	1
CTXSCRD	Smartcard	0*	1
CTXCLIP	Clipboard	1	2
CTXLIC	License management	1	1
CTXPN	Program Neighborhood	1	1
CTXTW	Remote Windows screen update data (ThinWire)	1	1
CTXVFM	Video server video (not ThinWire video)	1	1
CTXCCM	Client COM port mapping	2	3
CTXCDM	Client drive mapping	2	2
CTXMM	Citrix Windows Multimedia Redirection	2	2
CTXCM	Client management (Auto Client Update)	3	3
CTXCOM1	Printer mapping for non-spooling client (Thin client devices)	3	3
CTXCOM2	Printer mapping for non-spooling client (Thin client devices)	3	3
CTXCPM	Printer mapping for spooling clients	3	3
CTXLPT1	Printer mapping for non-spooling client (Thin client devices)	3	3
CTXLPT2	Printer mapping for non-spooling client (Thin client devices)	3	3
OEMOEM	Used by Original Equipment Manufacturers (OEMs)	3	3
OEMOEM2	Used by Original Equipment Manufacturers (OEMs)	3	3

Source: http://s3.amazonaws.com/legacy.icmp/additional/ica_acceleration_0709a.pdf

Session Reliability

Session Reliability keeps sessions active and on the user’s screen when network connectivity is interrupted. Users continue to see the application they are using until network connectivity resumes. This feature is especially useful for mobile users with wireless connections. Take, for example, a user with a wireless connection who enters a railroad tunnel and momentarily loses connectivity. Ordinarily, the session is disconnected and disappears from the user’s screen, and the user has to reconnect to the disconnected session. With Session Reliability, the session remains active on the server. To indicate that connectivity is lost, the user’s display freezes and the cursor changes to a spinning hourglass until connectivity resumes on the other side of the tunnel. The user continues to access the display during the interruption and can resume interacting with the application when the network connection is restored. Session Reliability reconnects users without reauthentication prompts. If it is enabled Session Reliability encapsulates ICA traffic through TCP port 2598. Graphical explanation of Session Reliability is shown below:

Source: http://blogs.citrix.com/2013/10/16/is-session-reliability-good-or-bad/2-46/

Session Reliability relies on Common Gateway Protocol (CGP). Very good explanation of Common Gateway Protocol can be found here:

http://blogs.citrix.com/2013/01/23/session-reliability/

http://support.citrix.com/article/CTX104147

Interesting discussion about Session Reliability can be found here:

http://blogs.citrix.com/2013/10/16/is-session-reliability-good-or-bad/

ICA bandwidth requirements

I used to think for a long time that ICA protocol will work properly on any network connection that will have at least 14 kb/s. The ICA protocol is optimized for Wide Area Networks or WANs with high latency links. This shouldn’t be a surprise as ICA was developed when in everyday use were data-link connections via modems. The available bandwidth had only 56 kbps and ICA protocol had to be optimized enough to allow work on such a connection. ICA protocol supports also Quality-Of-Service (QoS) and other bandwidth optimization features. Key challenges of such an architecture are network latency and performance—a graphically intensive application (as most are when presented using a GUI) being served over a slow or bandwidth-restricted network connection requires considerable compression and optimization to render the application usable by the client. The client machine may be a different platform, and may not have the same GUI routines available locally—in this case the server may need to send the actual bitmap data over the connection. Depending on the client’s capabilities, servers may also off-load part of the graphical processing to the client, e.g. to render multimedia content. All that put some requirements on the bandwidth allocation for ICA protocol. It may depend also on:

• Use of video or audio applications
• Number of users
• User behavior
• Printing
• Other network traffic
• Aero redirection/desktop composition redirection

Number of factors that may affect bandwidth requirements is long. Don’t be surprised then when some of the users will be able to connect to Citrix published desktop or VDI machine and work normally while others will send a mass of tickets to support team with complaints about performance. For the first group the bandwidth tens of Kbps will be enough while the second group may require few Mbps bandwidth to stream their graphics or video.

In case of insufficient bandwidth ICA session may be dropped or users may experience choppy typing or screen paints. A possible workaround/fix for that might be configuration of Session Reliability.

In next post we will talk other features of ICA protocol and explain why HDX is the new ICA.

 Sources used:

http://apttech.wordpress.com/2011/08/23/citrix-xenapp-and-its-metaframe-roots/

http://www.slideshare.net/fdwl/citrix-internals-ica-connectivity

http://en.wikipedia.org/wiki/Independent_Computing_Architecture

http://www.citrix.com/content/dam/citrix/en_us/documents/go/citrix_timeline.pdf

http://citrix24.pl/

http://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/citrix-hdx-technologies.pdf