The Framehawk virtual channel optimizes the delivery of virtual desktops and applications to users on broadband wireless and lossy long-haul broadband network connections, when high packet loss or congestion occurs. You can use Citrix policies to implement either Framehawk or Thinwire for a set of users in a way that is appropriate for your network characteristics, and is aligned with overall scalability and performance expectations.
Generally, user experience has focused on frame rate and visual quality as a basis for a positive user experience. Framehawk enhances the definition to account for linearity. Users need to enjoy the experience, not be distracted by it. Under degraded network circumstances, users struggle with the “rubber band” effect that plagues all protocols. This effect includes the tapping-waiting-tapping syndrome where a user isn’t sure if the screen will respond, resulting in extra errant clicks by the user, creating more and more undesirable results. Framehawk smooths out those experiences, especially under strenuous network conditions.
High-speed home Internet connections frequently exhibit performance issues, whether due to collisions with neighboring Wi-Fi signals or spectral interference from cordless devices, among others. More and more users are connecting to hosted apps and data via 3G or 4G/LTE cellular networks, or using inflight Internet services. Others like to take advantage of public Wi-Fi hotspots while stopping for a coffee break or at hotels where congestion is a common problem.
With Framehawk, users notice a more interactive experience (a more linear echoback of characters) compared to Thinwire at high latencies.
Think of Framehawk as a software implementation of the human eye, looking at what’s in the frame buffer and discerning the different types of content on the screen. What’s important to the user? When it comes to areas of the screen that are changing rapidly, like video or moving graphics, it doesn’t matter to the human eye if some pixels are lost along the way because they are quickly overwritten with new data.
But when it comes to static areas of the screen, such as the icons in the systray or a toolbar, or text after scrolling to where the user wants to start reading, the human eye is very fussy; a user expects those areas to be pixel perfect. Unlike protocols that aim to be technically accurate from a ones and zeros perspective, Framehawk aims to be relevant to the human being who is using the technology.
Framehawk includes a next-generation QoS signal amplifier plus a time-based heat map for a finer-grained and more efficient identification of workloads. It uses autonomic, self-healing transforms in addition to data compression, and avoids retransmission of data to maintain click response, linearity and a consistent cadence. On a lossy network connection, Framehawk can hide loss with interpolation, and the user still perceives good image quality while enjoying a more fluid experience. In addition, Framehawk algorithms intelligently distinguish between different types of packet loss; for example, random loss (send more data to compensate) versus congestion loss (don’t send more data because the channel is already clogged).
The Framehawk Intent Engine distinguishes between scrolling up or down, zooming, moving to the left or right, reading, typing, and other common actions, and manages the communication back to the Virtual Delivery Agent (VDA) using a shared dictionary. If the user is trying to read, the visual quality of the text needs to be excellent. If the user is scrolling, it should be quick and smooth. And it has to be interruptible, so that the user is always in control of the interaction with the application or desktop.
By measuring cadence on the network connection (which we call “gearing”, analogous to the tension on a bicycle chain), the Framehawk logic can react more quickly, providing a superior experience over high latency connections. This unique and patented gearing system provides constant up-to-date feedback on network conditions, allowing Framehawk to react immediately to changes in bandwidth, latency, and loss.
While Thinwire has led the industry in bandwidth efficiency and is well-suited to a broad range of access scenarios and network conditions, it is TCP-based for reliable data communications and therefore must retransmit packets on a lossy or overburdened network, leading to lag in the user experience.
Framehawk is UDP based, taking a best-effort approach at data transmission. UDP is just a small part of how Framehawk overcomes lossiness, as can be seen when comparing the performance of Framehawk with other UDP-based protocols, but it provides an important foundation to the human-centric techniques that sets Framehawk apart.
How much bandwidth does Framehawk require?
The meaning of broadband wireless depends on several factors, including how many users are sharing the connection, the quality of the connection, and apps being used. For optimal performance, Citrix suggests a base of 4 or 5 Mbps plus about 150 Kbps per concurrent user. However, you may find that Framehawk greatly outperforms Thinwire on a 2 Mbps VSAT satellite connection because of the combination of packet loss and high latency.
The Citrix bandwidth recommendation for Thinwire is generally a base of 1.5 Mbps plus 150 Kbps per user (for more detail, refer to XenApp/XenDesktop bandwidth blog), but at 3% packet loss you will find that Thinwire needs much more bandwidth than Framehawk to maintain a positive user experience.
Note: Thinwire remains the primary display remoting channel in the ICA protocol. Framehawk is disabled by default. Citrix recommends enabling it selectively to address the broadband wireless access scenarios in your organization.
Framehawk requires minimum VDA 7.6.300 and Group Policy Management 7.6.300.
The endpoint must have a minimum Citrix Receiver for Windows 4.3.100 or Citrix Receiver for iOS 6.0.1.
By default, Framehawk uses a bidirectional UDP port range (3224-3324) to exchange Framehawk display channel data with Citrix Receiver; the range can be customized in a policy setting called "Framehawk display channel port range". Each concurrent connection between the client and the virtual desktop requires a unique port. For multi-user OS environments, such as XenApp servers, you need to define sufficient ports to support the maximum number of concurrent user sessions. For a single-user OS, such as VDI desktops, it is sufficient to define a single UDP port. Framehawk attempts to use the first defined port, working up to the final port specified in the range. This applies both when passing through NetScaler Gateway, and internal connections directly to the StoreFront server.
For remote access, a NetScaler Gateway must be deployed. By default, NetScaler uses UDP port 443 for encrypted communication between the client Citrix Receivers and the Gateway. This port must be open on any external firewalls to allow secure communication in both directions. The feature is known as Datagram Transport Security (DTLS).
Note: The Framehawk virtual channel is supported on NetScaler Unified Gateway version 22.214.171.124 and later.
Consider the following best practices before implementing Framehawk virtual channels:
Caution: Citrix recommends that you enable Framehawk only for users experiencing high packet loss. It is also recommended that you do not enable Framehawk as a universal policy for all objects in the Site.
The Framehawk virtual channel is disabled by default. When enabled, the server attempts to use the Framehawk virtual channel for users’ graphics and input. If the prerequisites are not met for any reason, the connection is established using the default mode (Thinwire).
The following policy settings affect Framehawk:
HDX Framehawk virtual channel is supported on NetScaler Gateway minimum 11.0 build 62.10. It is also supported on NetScaler Unified Gateway version 126.96.36.199 or later.
To enable Framehawk support on NetScaler Gateway, the DTLS parameter on the Gateway VPN vServer level must be enabled. After the parameter is enabled and the components on XenApp or XenDesktop are updated correctly, Framehawk audio, video, and interactive traffic is encrypted between the Gateway VPN vServer and the user device.
NetScaler Gateway, Unified Gateway, and NetScaler Gateway + Global Server Load Balancing are supported with Framehawk.
The following scenarios are not supported with Framehawk:
This configuration is required if you are enabling UDP encryption on NetScaler Gateway for remote access.
When configuring NetScaler for Framehawk support:
To configure NetScaler for Framehawk support:
Note: Steps 6-10 are not required if you are using Unified Gateway version 188.8.131.52 or later.
To configure Unified Gateway for Framehawk support:
To configure Citrix Receiver for iOS to support Framehawk, you must manually edit default.ica.
This allows Framehawk sessions to be established from a compatible Citrix Receiver on iOS devices.
|NetScaler + Global Server Load Balancing||Yes|
|NetScaler with Unified Gateway||
Note: Unified Gateway version 184.108.40.206 and later is supported.
|NetScaler Gateway in IPv6 mode||No|
|NetScaler Gateway Double Hop||No|
|Multiple Secure Ticket Authority (STA) on NetScaler Gateway||No|
|NetScaler Gateway with High Availability (HA)||No|
|NetScaler Gateway with Cluster setup||No|
You can monitor the use and performance of Framehawk from Citrix Director. The HDX Virtual Channel Details view contains useful information for troubleshooting and monitoring the Framehawk virtual channel in any session. To view Framehawk-related metrics, select Graphics-Framehawk.
If the Framehawk connection is established, you will see Provider = VD3D and Connected = True in the details page. It is normal for the virtual channel state to be idle, because it monitors the signaling channel, which is used only during the initial handshake. This page also provides other useful statistics about the connection.
If you encounter issues, see the Framehawk troubleshooting blog.