Now with the release of XenDesktop 7.12 I’ve been quite busy testing the new preview of Adaptive Transport for HDX. Now one thing that it took some time for me to understand is that as it states “Transport Protocol” so you can still use ThinWire for instance over Adaptive Transport just like you did before. So for instance you can do NVENC with full-screen H.264 encoding on GPU , and deliver that via Thinwire over Adaptive Transport Protocol.
Now this new protocol unlike ALL other versious of HDX uses UDP as the default transport layer, and is aimed at where you have high latency / low packet drop scenarioes. So for instance if you are moving to cloud based infrastructure and your Citrix setup sits about 100+ MS away from your endpoint, chances are that this new transport protocol will improve the end-user experience. Now for information this next-gen protocol uses UDT.
UDT uses UDP to transfer bulk data with its own reliability control and congestion control mechanisms.
So how does it far against native TCP setup?
This is a comparison between TCP & UDP usage of a Youtube clip against a low-latency connection. The bandwidth is pretty much the same.
So what if we add 100 MS latency between the sessions and try again?
Default-TCP setup, with the added latency TCP has alot of issues keeping track and getting retransmits and is never able to leverage the window scaling features properly as well, therefore the maximum level never gets to a high value. Since it has alot of retransmissions there will be more packets going back from the client to sent information about which packets were lost in the process.
UDP Setup (Adaptive Transport for HDX) higher max value, and more data transferred across the wire.
Some interesting facts, if you have a session open against UDP it will constantly send out packets with 20 bytes which is used for keepalive.
Since UDT has its own reliability control and congestion control mechanism you don’t get the issue with artifacts when trying to browse video or other content inside a Citrix session, these keepalive sessions are smaller then TCP stack, since a TCP keepalive packet requires a SYN and ACK packet going back and forth which in a long run uses more bandwidth up and down the pipe.
Now the cool thing about this protocol is the fallback mechanism. So let’s imagine if we are roaming client moving from 4G modem where we can use UDP back to Airport Wifi where UDP is not allowed.
Now if Receiver is not being able to communicate with XenDesktop using UDP with missed heartbeats it will issue a shutdown command and fallback to TCP connection directly with the client.
And yes it can also failback from TCP back to using UDP as well
So I’ve covered some of the network aspects of this new protocol, George Spiers covered alot about other benchmark tests on it in his posts here –> http://www.jgspiers.com/hdx-enlightened-data-transport/