Why do I love HDX on UDP in Citrix XenDesktop and XenApp? (HDX Enlightened Data Transport EDT)

Well, I’m mainly a network guy. So I’ll take a look at this brand new feature from networking perspective.I’ll start from scratch, so I don’t assume you understand network protocols.

But let me tell you a joke about UDP first:

I got a short joke about UDP, and I don’t care if you got it!

You may, or may not get my joke. Of course I care, so I’ll explain: TCP has guaranteed delivery. So every packet you send will be delivered. UDP doesn’t care if you got the packet, or not.

It also doesn’t care if packets arrive in the right order.

The situation with TCP

TCP uses so called sessions.

It takes 3 packets to establish a session:

client → server: Syn + sequencenumber (Syn means: let’s talk, the sequencenumber is a random number)
192.168.0.1 → 192.168.0.13: SYN, seq. 1000

server → client: Sync/ack + sequence number + acknowledge number (Ok, let’s talk. client’s sequence number is server’s acknowledge number, server’s sequence number is a random number too)
192.168.0.13 → 192.168.0.1 SYN/ACK, seq. 2000, ack. 1000

client → server: Ack  + sequence number + acknowledge number (Ok, I’ve heared, you agree about talking. The client increments his sequence number by 1 and uses server’s sequence number as an acknowledgement number)
192.168.0.1 → 192.168.0.13: ACK, seq. 1001, ack. 2000

This is a bit of overhead, but it’s overhead during session establishment only, so we don’t really care about it.

Sequence/acknowledge numbers are very important. If a client sends a packet (let’s say number 1001) it has to get an acknowledgement for this package (1001).

sending packets

My explanation is based on RFC 793.

This is a very basic principle all over TCP. It’s really great. Let’s say, a server sent packets 20001, 20002, 20003 to the client, however the cient only received packet 20003 and 20001 (so you see, wrong order here) the client will wait for a pre defined amount of time to get 20002. If it does not appear, the client will send an acknowledge for 20001 only. So the server will resend 20002 and 20003. This procedure is called retransmission. Simple like that. (Notice: we retransmitted 20003, even though it already arrived on client side.

To make file transfers fast, client and server both use a so called sliding window, a buffer to send and receive.

If a sender wants to send 10 packets, it’s buffer size is 5 packets, it will put the first 5 packets into the sending buffer and starts sending packets as fast as possible, starting from first packet.

The receiver (the client in my example) has a receiving window with a size of 5 packets as well. It will put all received packets into it’s buffer. As soon as it received the 3rd packet it will send an acknowledge for the 3rd package to the sender (confirming the 3rd package implies also package 1 and 2). The sender now deletes the confirmed 3 packets (the ones I coloured in pink) from it’s sending buffer, shifts all packets left by 3 positions, and add 3 more packets into the – now free – last 3 positions of the sending buffer (the pail pink ones), so they can get transmitted.

The client will receive the next 3 packets, and confirm as soon as the 3rd packet is received.

This mechanism guarantees smooth data transmission, the bigger the buffers are, the more latency we can tolerate without the need of an interruption of the sending process. TCP, therefore, is not very sensitive of latency. In internet we usually use big sending and receiving windows (buffers), so downloads stream smoothly.

The only delay here: If there are less than 3 packets left: The client will wait for more packets for a specified amount of time before confirming the already received packets. This delay does not matter if you think of a download containing of hundreds of packets.

Where is the problem about HDX/ICA?

I’m currently typing this blog article into a published Mozilla Firefox on XenApp. If I type an I, for example, my client sends an I to the server. That’s just one packet to send (less than 3!!!). The server now waits for 2 more packets to come, however I’m typing quite slowly (aprox. 60 strokes per second), so there won’t appear an other packet for a very long time (if you think in processor cycles). Server’s TCP has a timer. If that timer is down to 0 my server’s TCP will send an ACK to my client and, at the same time, forward my request to the Citrix services. So my Browser application just now receives my message! This is additional latency! And latency is not what we want to see!

So there are several delays: Network latency from client to server, the server waiting for more packets, the server processing my request, sending it and network latency (again) until the client finally receives the response. Oh, I forgot: A Citrix server’s response will be (in most cases) less than 3 packets, so my client’s TCP protocol stack will also have to wait for a 3rd packet to come. Unfortunately there won’t be a 3rd packet, so the client got some delay until it sends an ACK to the server and forwards the packet to my Citrx receiver.

The more interactive your application is the worse things get.

An other TCP problem

There is an other aspect I have forgotten to mention. I have to thank Marcus Kohlschmidt, he mentioned it yesterday.

TCP guarantees delivery. 100% correct delivery. There are checksums to make sure every single packet got delivered, delivered correctly.

Now there is no point in forwarding garbled packets. That’s obvious. Every single router will therefore check checksums to avoid forwarding corrupted packets. This router will discard corrupted packets, and cause packet loss. Mail problem here is not just silent packet loss, but much more important the overhead of calculating checksums. Every single router will have to do this, causing congestion on routers. The more hops we have to pass the more overhead it causes. UDP packets don’t contain checksums, so they are forwarded immediately, and may eventually overtake a bunch of TCP packets. So there may be less latency for UDP than for TCP. Unfortunately this is not true if we tunnel UDP inside SSL.

Why can UDP handle Citrix XenApp / XenDesktop HDX (ICA) better?

UDP, you remember?, does not have sessions at all. A client will send a packet to the server. The server will immediately process it, if it receives the packet. That’s good news.

If it did not it won’t. That’s bad news. Even worse: If packets appear in wrong order they get forwarded in wrong order. So let’s say I type “if”, but for some reasons (why? Ask the network guys) the f arrives in front of the i, my Citrix server will think of fi. That’s unusable.

Citrix had to build TCP functionality into HDX (former ICA) to overcome issues like that. So UDP based HDX packets need to get numbered. HDX won’t send an acknowledge, but instead it will send the server reply containing the acknowledge. In my example my server will receive packet number 2, the f, and packet number 1, the i, so it will know they are in wrong order. Or, if it won’t receive packet number 1 at all it will tell the client: I have received a packet number 2, but number 1 is missing.

If a client sends a packet, but does not get a response from server in a timely manner, it will have to resend. So you see, it’s TCP functionality, built into HDX/ICA, so it may be sent on UDP instead.

What about NetScaler Gateway in HDX/ICA proxy mode?

Well, we use SSL here. HTTPS. SSL is a tunneling protocol, so HTTPS would be HTTP tunneled in SSL. SSL will, always, be TCP based.

It’s a great advantage to go with standard protocols. It’s easy to use proprietary protocols using fancy ports like UDP/2598 or even UDP/443 in a closed environment. The only thing you have to do is: tell your firewall staff to permit this ports. But it’s a mess in internet. How can you talk to the firewall staff of your (possibly global) costumers? They will simply refuse. How can you talk to firewall staff of “all hotels in the world“? It’s impossible!

So we still have to go with a TCP based tunnel using 443. All advantages and disadvantages of TCP are true about this tunnel. But inside this tunnel we have light weight UDP packets. The effect of latency will be cut to half. We don’t have to wait for all these timers to count down to 0. HDX/ICA will be much smoother.

Requirements to use UDP-based HDX/ICA

There is a description by Citrix. Maybe you prefer that one over mine.

In Citrix XenDesktop 7.12 I found following paragraph:

New enlightened data transport layer (for evaluation only). IT administrators can evaluate a new HDX data transport layer designed for challenging long-haul WAN and Internet connections. This alternative to TCP delivers a superior user experience while maintaining high server scalability and efficient use of bandwidth. This new transport layer above UDP improves data throughput for all ICA virtual channels including Thinwire display remoting, file transfer (Client Drive Mapping), printing, multimedia redirection and others. In 7.12, this feature is for evaluation only and is disabled by default. It can be enabled in a non-production environment with a new policy setting, HDX Enlightened Data Transport. Set the new policy setting to Preferred to use enlightened data transport when possible, with fallback to TCP. In this release, this feature requires Citrix Receiver for Windows 4.6 or Citrix Receiver for Mac 12.4. For more information, see ICA policy settings.

So it started with 7.12, however it was for experimental use only. With 7.13 it is fully supported and implemented. Everything is there: The VDA installation opens firewall ports, Director is aware if UDP based HDX/ICA and much more. So it’s stable and ready to use with 7.13.

Enabling UDP based HDX/ICA in Citrix XenApp / XenDesktop

You won’t be surprised to hear: It’s a policy! So I open GPEdit.exe and select my GPO

We are looking for HDX adaptive transport. The official name would be HDX Enlightened Data Transport Protocol, but Citrix naming conventions are inconsistent here. The policy itself will look like that:

Default setting is Off. This means: we use TCP based transport only. I suggest changing to Preferred (so we prefer using UDP based transport, but we may use TCP based transport if a client is unable to use UDP, this would be true for an old client, or a fire wall blocking UDP/2598 or UDP/1494). Don’t use Diagnostic Mode. This will force UDP based transport. Elder clients won’t be able to connect.

My current session is UDP based. It is visible in Citrix Desktop Director

Unfortunately session details in connection centre does not show UDP transport (way to go, Citrix!)

Which Receiver?

It’s a brand new feature, so we need to use the latest version of Citrix receiver: 4.6. It is not supported.

What about the NetScaler side?

Well on NetScaler side we need at least NetScaler version 11.1 Build 52.13 (March 1st 2017). The release notes read like that:

The NetScaler Gateway appliance now supports the HDX Enlightened Data Transport (EDT) as a data transmission path. EDT provides a high definition in-session user experience of virtual desktops for users running a Citrix Receiver.

[From Build 51.21] [# 659795, 666135]

So that’s it. Upgrade to (at east) 11.1 Built 52.13 to enable HDX Enlightened Data Transport (EDT)! No policies needed. However you have to enable DTLS on your NetScaler Gateway and rebind certificates.

So let’s enable DTLS: (in my case DTLS already was enabled after upgrading, if your DTLS is enabled you should skip this section).

You’ll find this dialogue after opening your VPN vServer (NetScaler Gateway → Virtual Servers), and then click edit (the pen) with Basic Settings. The setting is hidden, you have to click › more.

After doing this you will have to unbind SSL certificates and rebind (I followed Citrix product documentation about that). I don’t understand why this step is necessary.

Your firewall …

… has to permit UDP 2598 and UDP 1494 from NetScaler SNIP to all your HDX/ICA servers (Citrix XenApp / XenDesktop servers).