Why do I love HDX on UDP in Citrix XenDesktop and XenApp?


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) → 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) → 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) → 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.

TCP-Sliding windows in action 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

enabling UDP based HDX/ICA

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:

enabling Citrix ICA/HDX UDP based transportDefault 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

UDP based HDX/ICA in Citrix desktop DirectorUnfortunately session details in connection centre does not show UDP transport (way to go, Citrix!)

A UDP based connection's roperties

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).

Enabling HDX UDP transport on NetScaler
You’ll find this dialogue after opening your VPN vServer (NetScaler GatewayVirtual 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).

About the author

Johannes Norz

Johannes Norz is a Citrix Certified Citrix Technology Advocate (CTA), Citrix Certified Instructor (CCI) and Citrix Certified Expert on Application Delivery and Security (CCE-AppDS).

He frequently works for Citrix international Consulting Services and several education centres all around the globe.

Johannes lives in Austria. He had been borne in Innsbruck, a small city (150.000 inhabitants) in the middle of the most beautiful Austrian mountains (https://www.youtube.com/watch?v=UvdF145Lf2I)


  • Nice work, Johannes. As we have some customers fighting network latencies, I definitely will check this with next 7.13 PoC I get my hands on -) Very interesting, indeed …


  • Johannes – Thanks for this article. However we are still using 7.6 and seem to have an issue with UDP. Within the policies of Citrix “UDP ports used by the host” and “RTP with client”. I”m confused as to what the “server” and “client” is exactly? We use Dell ThinClients to connect to our desktops. Desktops run on ESXi hosts. Does “host” mean ESXi server, thinclient, ?? I can”t work it out. Is client the virtual desktop, thinclient??

    • In this blog “client” refers to the client device (what ever it is: PC, thin client, mobile device, …). “Host” is the XenApp host (not VMWare, it’s independent from underlying “hardware”)

      Unfortunately this blog will not be of any use to you: HDX-UDP did not exist in XenApp 7.6. It had been introduced with only with 7.12 (experimental) and 7.13.

  • Hi, have you also verified how bandwith has changed wi th edt and how does it influence netscaler scalibilty?

    • No I didn’t measure, however I guess – different to framehawk – it would not change things very much. And because of this number of connections in NetScaler Gateway won’t change.

      I would give it a try, it’s just little settings in NetScaler (which would not affect the performance of a NetScaler, as long as XenApp / XenDesktop don’t request UDP), and then a single XenApp policy. You may turn it on and off when ever you like, so there is a quick way back. Turn it on in off peak hours and see if it changes performance (of both, NetScaler and HDX sessions).

  • Great article Johannes!!!

    We are running XenApp 7.15 and are having remote users (thousands of miles so of course latency) have 15-45 second disconnects to our hosts before the auto-reconnect function kicks in. We can see the event viewer is showing these sessions get suspended, closed, then opened again in the time frame mentioned. We currently do not have the Adaptive Transport policy enabled, would you say this could potentially help these sessions?

    • I’m sorry for my late response, I have been on vacation. To get back to your question: I guess, this would not help, but I’m just guessing. Adaptive transport changes the underlying protocol, so it might help, even though I’m pessimistic. The only reason I see for adaptive transport to be successful is the nature of UDP: All packet loss has to be handled on L7, so it will get handled differently.

      There has to be a reason for people getting disconnected. I know how hard it is to find this reason, as it is a sporadic problem.

Recent Posts

Recent Comments