The story of ICA graphic modes and how it became HDX

I talk with a lot with people about the ICA graphic modes and sometimes I sense some confusion. So, I decided to write an article about the story of ICA to get some clarity on the subject. So, here goes…

Back in the days, we didn’t talk a lot about ICA. The reason for that was that ICA just worked out-of-the-box. Today ICA can do a lot more.

ICA Virtual Channels

ICA is built up of virtual channels. Each channel has it’s own function. Anything from:

• Local drive mapping
• Flash Redirection
• Lync Optimisation
• Smartcard

As you can see on the picture above, there are three graphic channels. These are the ones that we are going to focus on in this article. But first we need a little history.

ICA and OS/2

Citrix, first developed the ICA protocol for a product called Citrix Multiuser. It was developed for OS/2 back in 1991. A few days before the release, Microsoft announced, that they would rather bet on Windows instead of OS/2. This meant that the whole product needed to be coded to be compatible with Windows and DOS. This was only made possible, because of investments from investors, among them was Microsoft.

ICA and Windows

The first Citrix product was released in 1995 and was called WinFrame and was build for Windows NT 3.51. It was made possible, because Citrix was given access to the Windows source code. Since, the first version of ICA was made for OS/2, the ThinWire channel was now a version 3.0. Back then, graphics in Windows  was made with GDI (Graphic Device Interface). A program could draw a window on the screen by calling GDI-commands to the Windows Operating System. ICA was intelligent, so it could do one of two things, when i was sending the pixels to the end user. Either it could intercept the GDI commands and send them to the end user or it could take the current screen buffer and compress it into a bitmap and send it to the end user. It all depended on the complexity of the image.

This was ICA for many years. ICA did not really change because graphics in Windows stayed the same. Features was added along the way, such as Super Cache and Progressive Display, because of increasingly use of graphic applications.

ICA and VDI

In 2009 VDI was introduced and ICA needed to do so much more then just send graphic, keyboard strokes and mouse clicks. A lot of new features was put into the ICA protocol and that was also the time where it was renamed HDX. HDX is the marketing name for all the features or all the virtual tunnels that are inside the protocol that you use when you deliver applications and desktop using XenApp and XenDesktop. At the same time, Citrix also released the first version of HDX 3D Pro. HDX 3D Pro was used for customers that needed to deliver 3D application for users in the engineering and health sector. A new thing also happened when HDX 3D Pro was introduced. When HDX 3D Pro was used, instead of using the normal pixel remoting, an X.264 stream was used to present the picture to the user.

With all of that said, let us take a look at the ICA graphic modes that we have today.

Legacy Mode

This is the mode that you know from XenApp 6.5 and before. Good old Thinwire that we have been using for years and years. But, you have to move away from Legacy Mode if you want to use newer versions of Windows. The reason for that is because Microsoft is moving away from GDI to DWM (Desktop Window Manager). DWM is the new graphic engine in Windows that enables the Windows Aero user experience. Legacy Mode are build for GDI, it will not or work poorly with newer versions of Windows.

DCR (Desktop Composition Redirection)

DCR is build offload DirectX commands to client. By doing that you save a lot of CPU usage on the server, because you are using the power on the endpoint. If the server has a GPU installed, you can also choose to let the server do all the work. This requires that the client has a GPU installed in order to get this to work. This was originally only supported on Windows end point. But this has also been support Mac computers since Receiver 11.9. DCR is one of the graphic modes that takes a lot of bandwidth and it is only supported by the Desktop VDA. This is currently the default encoder on the Desktop VDA

H.264 Codec

This codec was originally made for HDX 3D Pro. When it was originally developed, it used the GPU in the server to do the encoding. But now, the VDA can also use the CPU. Some people wonder why there are two different VDAs, one without HDX 3D Pro and one with HDX 3D Pro. H.264 is the default encoder for the server VDA and is the default encoder when DCR is disabled for desktop VDA. Instead of sending the commands and bitmaps to the endpoint, a video stream is send to the endpoint. The H.264 codec is really good to utilize the bandwidth when it comes to video and multimedia, but it comes with a cost. This encoder can have a high cost on both bandwidth and CPU. The X.264 stream are being encoding by the workload using CPU. If you are using a low bandwidth connection, the workload will try to compress the stream even harder, which means it will use more CPU, both on the workload and the endpoint. Another thing to consider is also that X.264 can hog the network, depending on the resolution that you push to the end point. The bigger resolution, the more bandwidth you are going to use.

Compatibility Mode

Compatibility mode is build as a fallback solution. If the Receiver on the endpoint doesn’t meet requirements for the X.264 codec, you can configure Compatibility mode if you want to make sure that the session still launches. Compatibility mode will work with any VDA and OS. The penalty is that Compatibility mode runs in Lossless. This means that it will not compress the traffic in any way. This means that it will use a lot of bandwidth. Compatibility mode should only be used as a fallback solution and not used for everyday use.

Thinwire Plus

Thinwire Plus is the latest encoder for XenApp and XenDesktop. Thinwire Plus is the encoder where you get all the features from Legacy Mode plus all the features that comes with the new versions of Windows. One of the reasons that Citrix came with this new ICA graphic mode was because a lot of thin clients was not powerfull enough for the X.264 stream. Many of them was linux based, so DCR was not an option. Thinwire Plus is backwards compatible with older thin clients and Citrix Receivers. So, with Thinwire Plus you sort of get the best from both worlds. You get the low bandwidth protocol with great users experience, but build for DWM in the new versions of Windows.

Framehawk

Framehawk became part of XenApp / XenDesktop through an acquisition. Framehawk is a UDP based protocol that is build for high latency and data loss connections. What happens is that Framehawk expects, because of poor connection quality, that it will loose network packages. To compensate for that. it retransmit some of the packages. Since it is a UDP protocol, it does not check for acknowledge packages. It just expects that some of the packages will be lost. Another thing is that Framehawk is made for the user. Let us say that the clicks on a button and nothing happens. Th user will eventually click on the button again. Framehawk will drop that second click, because it knows what the user wants. At the same same time Framehawk drops anything else. If the user asks for something or click on something, Framehawk will drop anything else and try to give the users the best experience. Like anything else, all of this comes with a cost and that is bandwidth. The first user will use about 5mbit of bandwidth. The next additional users will consume 150kb – 250kb. I have heard people trying using this to compensate for bad performance. This will not help you. You have to use Framehawk only when you have challenges with extreme high latency and data loss. An example could be a satellite connection.

With that i hope this can help to choose the right graphic mode for you.