In Part 1, we talked about why EDT was needed, as well as its main features. In Part 2, which I am co-authoring with our HDX Product Manager Fernando Klurfan, we would like to switch gears and explain the configuration aspects of the protocol.
Even though we are turning HDX Adaptive Transport to Preferred by default in our next XenApp/XenDesktop Q4 release, there are a few details you need to be aware of.
Common Gateway Protocol (CGP)
In the figure below you will notice that the TCP and UDP stacks share one common component: Common Gateway Protocol (CGP).
Our old friend CGP has been with us since the days of Citrix Secure Gateway and Citrix Presentation Server. CGP is a general-purpose tunneling protocol with its own handshake and commands. CGP is the protocol upon which Session Reliability — “session recoverability” in case of broken transport — is built, but is more than just that.
CGP is also used as an authorization protocol via NetScaler: it carries the Secure Ticket Authority (STA) ticket. CGP is also critical for supporting High Availability failover from one Gateway instance to another.
Therefore, CGP is required for EDT connections via NetScaler Gateway. But CGP is optional on direct EDT connections between Receiver and VDA, e.g. corporate MPLS. So, if you have a NetScaler Gateway, EDT requires Session Reliability Policy to be enabled, which, in turn, enables CGP (since currently CGP and Session Reliability are coupled).
Insider Tip: Session Reliability is enabled in Studio and Storefront and it is on by default.
Do not confuse Auto Client Reconnect (ACR) with Session Reliability (SR). Both allow users to automatically reconnect back to their sessions after recovering from a network disruption. The difference is that ACR does not resume the ICA connection as seamlessly as SR does. ACR performs an automatic full reconnection to a disconnected session, whereas SR only reestablishes the transport beneath ICA without disrupting the session or the UX (as much as possible).
For example, when reconnecting with ACR, a file copy over Client Drive Mapping (CDM), which was ongoing when the transport was broken, would fail.
With SR, the file transfer would succeed because each side is buffering every byte sent in each direction.
Upon reconnection, the sequence-numbers of the last CGP packets received at both ends are exchanged, buffers flushed, and the file transfer is resumed where it was left off. The virtual channels are never aware of the disconnect.
ACR and SR are by default used in sequence: SR is the first line of defense, ACR is the last resort fallback.
Security: DTLS
Security is critical for every organization today. Network-level encryption with DTLS is an obvious choice with UDP. EDT with DTLS has been supported with NetScaler on the front-end (Receiver to NetScaler) since 11.1.51.21 and 12.0.35.6, yet we would strongly recommend to use 11.1.55.10 or 12.0.53.6, as those builds contain some important DTLS fixes.
You still need to manually enable DTLS on the NSG front-end VPN vServer.
Newer NetScaler 12.x builds in Q4 2017 will have DTLS = on by default for the front-end.
DTLS is a requirement for the front-end EDT connection to NetScaler.
In the Q4 2017 releases of XenApp/XenDesktop and NetScaler, DTLS is supported end-to-end. In other words, the back end connection between NetScaler and the VDA could optionally use DTLS. In addition, Receiver could optionally use DTLS in direct connection to the VDA. The required configurations for the back-end are the same as the existing TLS security policies in StoreFront and VDA.
Receivers for Windows (4.7, 4.8, 4.9), MAC (12.5, 12.6, 12.7), iOS (7.2, 7.3.x) and Linux (13.7) all support DTLS 1.0. Android Receiver 3.12.3 is limited to direct connections to the VDA (DTLS in Tech Preview).
You will have to work with your Networking team in order to get UDP 443 opened between your DMZ first Firewall and the NSG frontend vServer, and UDP 2598 between the backend vServer (SnIP) and the VDA through the second DMZ Firewall (confirm with them that there is no global rate-limiting UDP Policy applied, or EDT will be affected).
On the VDA’s Windows Firewall, the VDA MetaInstaller should have opened UDP ports 1494 and 2598, unless you selected to do it manually later.
CLI installs require /enable_hdx_udp_ports to be passed.
Troubleshooting Tips
- Open a command prompt in the VDA and type ‘netstat –a –p udp’, it will tell you if UDP sockets are listening.
Do you see 0.0.0.0:1494 and 0.0.0.0:2598 under ‘Local Address’? If not, restart ‘Citrix Desktop Service’ or reboot VDA. - The best way to test EDT is to launch an app from the internal network directly to StoreFront, bypassing NSG. First inspect the ICA file. There should be an entry that reads ‘HDXoverUDP = Preferred’. If it says ‘Off’ or the entry is missing, then HDX Adaptive Transport is not set to Preferred in the Studio policy, or the GP update has not been applied at the VDA yet. Note that in the Q4 release of XenApp/XenDesktop, HDX Adaptive Transport is Preferred by default and there is no explicit requirement to configure the Studio policy.
- After connecting to the VDA, run ‘ctxsession’ on the VDA command prompt and verify your session is using UDP. If that works, your VDA is ready for EDT connections from the outside, too.
- Now try to launch a session through NSG. First inspect the ICA file just like in the direct connection case.
- After you launch an app/desktop via NSG, run ‘ctxsession’ on the VDA command prompt again and verify your session is using UDP. If it says TCP, then most likely something went wrong between Receiver and NSG and the connection fell back to TCP. Then a Wireshark trace on NSG is your best troubleshooting tool: Are UDP packets reaching/leaving the NSG frontend and backend vServers (VIP and SnIP)? Wireshark Dissectors will misinterpret EDT as ‘QUIC’.
- In addition, you can check Director → Session Details → Protocol → UDP.
Citrix Receivers kick-starting EDT
Existing Receivers supporting EDT use a sequential logic for HDX Adaptive Transport: If the policy is Preferred, Receiver attempts EDT first and, if it fails or times out, Receiver falls back to TCP. As explained in Part 1 of this series, the assessment of UDP vs. TCP use happens only during initial connection and after a scenario involving a transport break. With these Receivers during the lifetime of the HDX session, a transport switch does not occur unless the transport breaks.
The upcoming Q4 2017 Receivers for Windows, iOS and MAC attempt EDT and TCP in parallel, always favoring EDT if both are able to connect, but still falling back to TCP if EDT is not available. In addition, if the transport happens to be TCP, Receivers proactively continue to seek UDP in the background and if it becomes available, a seamless switch to EDT is performed without affecting user experience. In this case there is no network disruption that triggers the switch to UDP, there is only a forced termination of the TCP connection by Receiver. CGP protocol is required for the parallel connect and proactive switch to UDP to work.
The benefits are:
- Fast connect time: no timeouts when UDP is unavailable before falling back to TCP
- Always use UDP whenever it becomes available: any time in the lifetime of an HDX session. For example, when switching from data plan to WiFi, or between network subnets with different access policies, etc.
Fall-back to TCP or proactive switch to EDT is never triggered by a network metric such as low round-trip time [RTT] or high packet loss, but rather by the mere availability of TCP or UDP. Varying network conditions are dealt with by the congestion control algorithms of EDT.
In short, if HDX Adaptive Transport is Preferred, the use of EDT vs. TCP is driven by Receiver.
Performance metrics
So, what performance benefits can you expect from EDT?
If you have users connecting to your Site over the public internet, or have branch offices across the country/world, then without a doubt EDT will improve the user experience significantly! We have seen customers already being able to consolidate Sites and serve distant offices from only one Data Center.
Do you have a challenging 3D App that requires fluidity? Put EDT to the work, and give yourself extra breathing room by enabling hardware encoding on the VDAs for Desktop OS with HDX 3D Pro policy.
WAN Environments (from 50 to 250msec RTT, and 0 to 1% packet loss):
- Client Drive Mapping: Up to 10x improvements
- Thinwire Interactivity: Up to 2.5x improvements
- Printing: Up to 2x improvements
- Generic USB: Up to 35% improvements
Closing words: ICA’s Future
Last but not least … where are we heading? We have the best engineers working on EDT today, across HDX, Receivers and NetScaler, and the roadmap is looking better than ever. But we don’t want to get into trouble with our legal department, so we will give you only a teaser: Enlightened Virtual Channels!
Follow @CitrixFerK Follow @CitrixGeorgyM
Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more TechBytes and subscribe.
Want specific TechBytes? Let us know! tech-content-feedback@citrix.com
