Well Citrix has released Framehawk with support for both enterprise WLAN and remote access using Netscaler. In order to setup Framehawk for remote access you need to basically one thing (Enable DTLS) and of course SSL certificate rebound) DTLS is an TLS extenstion on UDP. So basically means that Framehawk is a UDP protocol. So unlike RemoteFX where Microsoft uses TCP/UDP both in a remote session, which means that it uses UDP for graphics and TCP for keystrokes and such.
So what does a Framehawk connection looks like?
External, a client uses DTLS connection to the Netscaler and then the Netscaler will use a UDP connection to the VDA in the backend. The DTLS connections has its own sequence number which is used to keeping track of connections.
There are some issues that you need be aware of before setting up Framehawk.
Also some other notes which are important to take note of, and that Framehawk will not work properly in a VPN connection, since most VPN solutions will wrap packets inside a TCP layer or GRE tunnel which means that the UDP connection will not function as intended.
Now Framehawk is not designed for low bandwidth connections, it requires more bandwidth use then ThinWire so why is that ?
“For optimal performance, our initial recommendation is a base of 4 or 5 Mbps plus about 150 Kbps per concurrent user. But having said that, you will likely find that Framehawk greatly outperforms Thinwire on a 2 Mbps VSAT satellite connection because of the combination of packet loss and high latency.”
The reason for that is that TCP will try to retransmit packets which are dropped, while UDP which is a much simple protocol without connection setup delays, flow control, and retransmission. And in order to ensure that all mouseclick, keyboard clicks are successfully delivered Framehawk requires more bandwidth since UDP is stateless and there is no guarantee that packets are successfully deliver, I belive that the framehawk component of Citrix Receiver has its own “click” tracker which ensures that clicks are successfully delivered and to ensure that it requires more bandwidth.
Comments from Citrix:
While SSL VPNs or any other TCP-based tunnelling like SSH re-direction will definitely cause performance problems for the Framehawk protocol, anything that works at the IP layer like GRE or IKE/IPSec will work well with it. We’ve designed the protocol to maintain headroom for two extra layers of encapsulation, so you can even multiple-wrap it without effect. Do keep in mind that right now it won’t do well with any more layers since it can cause fragmentation of the enclosed UDP packets which will effect performance on some networks.
2) While it’s based entirely on UDP the Framehawk protocol does have the ability to send some or all data in a fully reliable and sequenced format. That’s what we’re using the keyboard/mouse/touch input channels. Anything that has to pass from the client to the server in a reliable way (such as keystrokes, mouse clicks and touch up/down events) will always do so inside of the procotol. You should never see loss of these events on the server, even at extremely high loss.
And one last comment for anyone else reading this: The Framehawk protocol is specifically designed for improving the user experience on networks with a high BDP (bandwidth delay product) and random loss. In normal LAN/MAN/WAN networks with either no or predominantly congestive loss and low BDP, Framehawk will basically start acting like TCP and start throttling itself if it does run into congestion. At some point, however, the techniques it uses have a minimal amount of bandwidth (which is hard to describe since we composite multiple workloads on differnt parts of the screen). In those cases other techniques would be needed, like Thinwire Advanced. As we move down the road with our integration into existing Citrix products and start leveraging our network optimizations with bandwidth optimized protocols like Thinwire and Thinware Advanced expect that to just get better!
Hi, my name is Michael Martin, and I’m one of the Framehawk team at Citrix. Since I’m one of the network guys in the group I thought I’d share a couple things with you. First off, this write-up is fantastic. You got most of the details exactly right. For your edification, here’s a correction and a clarification:
1) While SSL VPNs or any other TCP-based tunnelling like SSH re-direction will definitely cause performance problems for the Framehawk protocol, anything that works at the IP layer like GRE or IKE/IPSec will work well with it. We’ve designed the protocol to maintain headroom for two extra layers of encapsulation, so you can even multiple-wrap it without effect. Do keep in mind that right now it won’t do well with any more layers since it can cause fragmentation of the enclosed UDP packets which will effect performance on some networks.
2) While it’s based entirely on UDP the Framehawk protocol does have the ability to send some or all data in a fully reliable and sequenced format. That’s what we’re using the keyboard/mouse/touch input channels. Anything that has to pass from the client to the server in a reliable way (such as keystrokes, mouse clicks and touch up/down events) will always do so inside of the procotol. You should never see loss of these events on the server, even at extremely high loss.
And one last comment for anyone else reading this: The Framehawk protocol is specifically designed for improving the user experience on networks with a high BDP (bandwidth delay product) and random loss. In normal LAN/MAN/WAN networks with either no or predominantly congestive loss and low BDP, Framehawk will basically start acting like TCP and start throttling itself if it does run into congestion. At some point, however, the techniques it uses have a minimal amount of bandwidth (which is hard to describe since we composite multiple workloads on differnt parts of the screen). In those cases other techniques would be needed, like Thinwire Advanced. As we move down the road with our integration into existing Citrix products and start leveraging our network optimizations with bandwidth optimized protocols like Thinwire and Thinware Advanced expect that to just get better!