Do you UDP your Citrix traffic with HDX Adaptive Transport?

HDX Adaptive Transport picks up where Framehawk left off, and can be the silver bullet to improving the user experience. Jo Harder explains why.

Fast, efficient communications are required for an optimal Citrix user experience, and the user shouldn’t know or care exactly what happens behind the scenes, regardless of the device type in use. Should administrators continue to use traditional ICA/HDX, or should they consider a UDP-based option for user session traffic? 

First, we’ll discuss whether UDP or TCP provide the better user experience, and then we’ll delve into the technical aspects of HDX Adaptive Transport. Last, we’ll consider what is realistically the optimal transport mechanism.

Citrix user session traffic via UDP—Is that good or bad?

Networking 101 taught us that UDP traffic is based on one-time best-effort communications, whereas TCP traffic includes error-checking functionality. Since UDP is comparable to a letter delivered via regular postal service, and TCP is likened to a tracked, signature-delivery service, TCP is viewed as more reliable, but realistically, UDP is faster.

Traditional TCP-based ICA/HDX uses TCP port 1494 (default) for user traffic inbound to the XenApp or XenDesktop resource. Also by default, this traffic is encapsulated within the Common Gateway Protocol (CGP) and traverses the inbound network via TCP port 2598; this is known as Session Reliability. CGP causes user communications to queue for up to three minutes by default when the network is temporarily unavailable.

TCP-based ICA/HDX provides an excellent user experience, but when packet retransmissions are necessary due to congestion, latency, or minor failures, users become frustrated. For example, if the user needs to scroll down a lengthy spreadsheet or PDF document when the network is congested, the user may click repeatedly because the session appears to be unresponsive. When all the retransmissions are complete and the network stabilizes, the user is frustrated when all those clicks place him in an unexpected area of the document.

Framehawk was introduced in 2015, and it was touted to address extreme packet loss and self-healing, as well as a “roughly right” screen display. Framehawk was based on UDP ports 3224-3324 by default. UDP? Yes!

Using UDP for Framehawk was viewed as an optimization because it was found not every packet must successfully traverse the network in order to provide a very suitable user experience. The numerous clicks that a user might initiate when scrolling down a document within what appears to be an unresponsive session are discarded, and a few pixels may not be perfect on the screen. Nonetheless, it provided a better experience for the average user.

But Framehawk was an on or off transport solution; it couldn’t adapt to situations where UDP wasn’t enabled or network conditions changed. Although Framehawk has been excluded as a go-forward feature of XenApp/XenDesktop 7.15 LTSR, it conceptually and technologically laid the groundwork for HDX Adaptive Transport.

What is HDX Adaptive Transport?

HDX Adaptive Transport is based on the Enlightened Data Transport protocol, which was introduced early in 2017. Once HDX Adaptive Transport is enabled within Citrix policies (the recommended setting is Preferred), as well as on the NetScaler, UDP is available to transport user session data.

One of the most appealing features of Adaptive Transport is that it responds to changing network conditions, something that Framehawk couldn’t address. User sessions can intelligently fall back to ICA/HDX, based on TCP, if that provides the optimal user experience. For example, if the necessary UDP ports are blocked or network connectivity changes, user traffic could fail over to ICA/HDX (TCP). Further, within Citrix Director, the Session Details pane clearly identifies whether the user connection is traversing the network via UDP or TCP.

Most recently, HDX Adaptive Transport has been embedded into the latest release of Receiver for Android (v3.12.x). Adaptive Transport is now included with Receiver for Windows, Linux, Mac, iOS, and Android, thus supporting the most common user device types.

But really, should Adaptive Transport be enabled?

When using TCP-based ICA/HDX, the best user experience is based on a consistent network with latency below 100 ms. When users are in the office, an excellent network connection is the reasonable expectation. However, with more users accessing Citrix resources via mobile devices over 4G networks—and still expecting a great user experience—Adaptive Transport is the silver bullet. Adaptive Transport has been available for several months, and the overall feedback is positive.

The new Receiver for Android capability is extremely relevant: Android rules the mobility market. Devices such as the Samsung Galaxy S8 series can transition into a desktop computer via a 4G network and enable users to fully engage with full-screen Citrix-based applications, not just the simple ones. And with Adaptive Transport, that translates to a better user experience.

If the concern about Adaptive Transport is UDP itself, consider that Citrix has been using UDP for various traffic types for quite some time. For example, audio within user sessions and Skype for Business utilize UDP.

Wrap up

If you’ve overlooked Adaptive Transport within your XenApp/XenDesktop 7.13 or higher environment, you may wish to consider it, especially now that Receiver for Android is supported. Further, XenApp/XenDesktop 7.16 will change the default HDX Adaptive Transport setting to Preferred. This UDP-based protocol just may be just what you need for improving the user experience!

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

It's nice to see that they're continuing this work. I was one of the Framehawk guys and we did spend a lot of time with the architecture teams talking about how to really integrate UDP into the existing stack right before they let us all go. I was kind of afraid they were just going to pull their head into their shell and pretend there wasn't a need. Bravo, Citrix!
Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close