HDX Enlightened Data Transport is a new HDX virtual channel data transport engine currently in evaluation that is designed to combat challenging WAN access to published applications and desktops. Think scenarios where your resources are placed on public cloud or you simply have access back to the datacentre hosting your Citrix resources, but with WAN performance that is limited due to forms of packet loss and high latency.This new data delivery method boosts performance of all ICA channels such as your Thinwire display protocols (ThinWire+, H.264), printing, client drive mapping (file transfers), audio and video.
You are probably aware that Framehawk was released on Citrix XenApp and XenDesktop 7.6 FP2+ and that protocol runs over UDP instead of TCP such as ICA TCP 1494 or Session Reliability TCP 2598. I did my own testing of Framehawk and found that it could fight back against some really high latent WAN links, even providing good experience during packet loss. Some of the techniques used with Framehawk have been selected and used with this new transport engine.
Note: This technology is currently available for evaluation on NetScaler Gateway version 11.1 build 50.10. DTLS must be enabled on the NS Gateway vServer.
To enable HDX Enlightened Data Transport you need configure a Citrix policy setting, specifically the HDX Enlightened Data Transport setting which contains the following options:
- Off – This is simply off and you will continue to use TCP 1494 or TCP 2598 as normal.
- Preferred – HDX Data Transport engine uses UDP as preferred, with fallback to TCP.
- Diagnostic Mode – Fallback to TCP is disabled.
![]()
What else is required?
- XenApp or XenDesktop 7.12+
- Server OS or Desktop OS VDA 7.12+
- StoreFront 3.8+
- Citrix Receiver 4.6+ for Windows
- Citrix Receiver 12.4+ for Mac
- Manual firewall rules incoming on VDA for UDP ports 1494 and 2598.
Note: IPv4 VDAs only at this time. No IPv6/mixed VDAs.
The first thing I’ll do is specify HDX Enlightened Data Transport = Preferred inside a Citrix policy. I’ve not opened UDP 1494 or 2598 so the session falls back to TCP 2598 using Session Reliability. We can confirm that by launching a session (it connects which is a obviously a good sign) and launching CMD. Next change directory to C:\Program Files (x86)\Citrix\System32. Now run CtxSession. You can see that TCP is being used with CGP (Session Reliability) and Session Reliabilty encapsulates the ICA protocol.
Run CtxSession /v for a verbose output. Here you can see the port 2598 being used on the VDA. 
Next with UDP 1494 and 2598 ports open on the VDA I connect back to the Citrix desktop, run CtxSession /v and receive confirmation that we are now using UDP 2598. This means that HDX Enlightened Data Transport is being used with Session Reliability.
At this stage we are ready to do some file transfer testing!
First up I am copying a 45MB file across the VDA client drive mapping virtual channels. Nothing is tweaked, simply using TCP 2598 to perform the first copy on a network with low latency.
And then UDP with the HDX data transport engine to perform the second copy. 
Similar copy times, nothing major going on here but gives a baseline. 
The second copy is on a link with 100ms latency. The first copy is TCP ICA 2598. 
The second copy is using UDP. A generally higher average speed is captured using UDP. 
UDP copies the file twice as fast as TCP! Remember this is over a 100ms line. 43 seconds is rather impressive and shows the potential of this new delivery method. 
The next copy compares 100ms latency to 200ms. Remember the 100ms copy took 43 seconds, the 200ms copy takes 60 seconds. Even though we added an extra 100ms round-trip latency to the line the results show a copy of a 45MB file over a 200ms line is still an incredible 36 seconds faster than the 100ms TCP copy. 
How about 300ms? Just to confirm, look at that awful latency. 
Citrix Director showing the high latency also. At this stage TCP is barely able to cope and I abandon any thoughts of file copy testing using TCP altogether. 
However, UDP keeps going on by copying a 45MB file over a 300ms line in 79 seconds. Yes, it STILL is faster than TCP on a 100ms line. Also note we are seeing some linear scalability here, as each 100ms of latency added on is seeing roughly a 15-20 second increase in copy times.
Let’s add some packet loss and reduce the latency. We are back down to 100ms-200ms latency but with 1% packet loss. This is the UDP copy over 100ms latency and 1% packet loss. 
And the 200ms latency 1% packet loss copy. The throughput is slighly less as expected. 
A 45MB file copy over 100ms line with 1% packet loss takes 117 seconds. You need to wait 23 more seconds when copying over a 200ms line. 
The next set of tests are video based, playing a 30 second YouTube video and recording the throughput both using TCP and UDP. ThinWire+ was used during testing, H.264 was completely disabled.
On the first test over 200ms both protocols play back the video quite well. Not any difference in results.
At 400ms HDX data transport starts to make ground on TCP. The video over TCP is pretty much unwatchable. 
600ms latency on UDP gets more throughput than TCP running over 400ms latency. Whilst both videos are barely watchable it’s good to know that HDX Enlightened Data Transport punches at a higher weight and with this technology only being in preview it will get better. 
Marius has also wrote a good blog article on this new protocol around the networking level and how we can fallback to TCP during the middle of a session http://msandbu.org/benchmarking-adaptive-transport-for-hdx/