As part of XenApp and XenDesktop 7.6 Feature Pack 2, our first release of Framehawk technologies is now generally available! Framehawk introduces a new ICA virtual channel and supporting HDX technologies that dramatically improve the user experience on broadband wireless connections, initially for Windows Receiver users on the corporate network. [August 14 update: Framehawk is now also available to iOS Receiver users and, via NetScaler Gateway 11.0-62.10, to remote workers.]
Today’s workers are much less likely to be chained to their desk with a high quality wired network connection. We’re mobile, moving around the building or campus with our laptops, ultrabooks and tablets, accessing our workspace on XenApp or XenDesktop over Wi-Fi. Some of us don’t even bother plugging in when we get back to our office or cubicle.
But even with a full set of bars on the signal strength icon, our computing experience frequently suffers from the effects of packet loss, congestion, latency and jitter. We notice scrolling through web pages and documents becoming sluggish in certain locations, even the echoback of characters as we type.
Whereas limited bandwidth used to be the predominant source of network issues impacting user experience, for today’s mobile worker the biggest issue is spectral interference. Quoting from a Cisco whitepaper, “The many wireless technologies and commonplace electric devices already in use and newly emerging impede wireless performance. RF interference can be a major inhibitor to wireless performance, creating security vulnerabilities and wireless network instability.”
In a downtown office building, there are Wi-Fi networks on the floors above and below you and across the street, all creating constructive and destructive interference patterns that result in dead zones, high packet loss and degraded interactivity. Add to that the electromagnetic energy from 3G/4G/LTE, radio and television, microwave ovens, fluorescent light ballasts, Bluetooth devices and so on, and it’s no wonder that the mobile user experience has often been unsatisfactory. After all, the biggest factor impacting the quality of your experience with a virtual app or desktop is the end-to-end network connection back to the XenApp or XenDesktop server. The “last room” (your Wi-Fi connection) is often the weakest link in that chain.
The 7.6 Feature Pack 2 release introduces a new Framehawk virtual channel and enhancements to the HDX software stack in the Virtual Delivery Agent (VDA) for XenApp and XenDesktop and in the new Citrix Receiver for Windows version 4.3. The Framehawk enhancements to the 7.6 VDA come in the form of a VDA add-on delivered as an MSP (Microsoft Windows Installer patch file).
Framehawk raises the bar on user experience
Since HDX is all about High Definition Experience and Citrix is the leader in this space, it shouldn’t surprise you that we are raising the bar in the actual definition of User Experience. Generally, we have focused on frame rate and visual quality as a basis for a user’s enjoyment. But with this addition to the family, we are increasing the definition to account for linearity. Users need to enjoy the experience, not be distracted by it. Under degraded network circumstances, we have seen 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 “this time” resulting in extra errant clicks by the user, creating more and more undesirable results. Framehawk is an investment to smooth out those experiences, especially under strenuous network conditions.
On the VDA side, you can 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 will quickly be overwritten with new data.
But when it comes to static areas of the screen, like the icons in the systray or a toolbar, or text after we’ve scrolled to where we want to start reading, the human eye is very fussy; we expect those areas to be pixel perfect. Unlike protocols that aim to be technically “right” from a 1’s and 0’s perspective, Framehawk aims to be relevant to the human being who’s using the technology.
Framehawk includes a next gen QoS signals amplifier plus a time-based heat map for 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. And the 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 since the channel is clogged).
Framehawk understands human intent and compensates for human behavior
On the user device, Framehawk adds an Intent Engine to the Citrix Receiver that takes into consideration what the user is trying to do. On a poor network connection with high latency and jitter, human beings tend to respond inappropriately; users will often swipe the screen of their tablet multiple times, as if that’s going to let the host computer know that it should send updates more quickly. Or they’ll click three or four times when one click would have been sufficient, because they’re not sure if the system “heard them.”
Framehawk’s Intent Engine, while not quite able to do a mind-meld with the user, 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 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 needs to 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.
Happily, the Intent Engine doesn’t require a lot of processing power, so Framehawk can be used with IoT (“Internet of Things”) devices. And Citrix Receiver 4.3 supports Windows IoT Industry, the successor to Windows Embedded.
Framehawk use cases and performance comparison to Thinwire
What are the initial use cases for Framehawk? The primary target for this first release of Framehawk technologies is Windows device users on corporate wireless connections (e.g. Wi-Fi and broadband satellite and microware links). We encourage you to experiment with the new Framehawk virtual channel under a variety of access conditions and see where it outperforms Thinwire and where it doesn’t.
This is just the beginning of our journey with Framehawk, and soon we will introduce Framehawk interoperability with NetScaler Gateway 11 to extend this technology to remote workers. Additionally, new Receiver versions are planned that will make Framehawk available to users on other device types. Some of you have participated in our private Tech Preview of the iOS Receiver with Framehawk support and we plan to release this update shortly.
Let’s consider some additional scenarios where Framehawk can be expected to outperform the Thinwire virtual channel. 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 efforts” 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.
Now consider a scenario where the user is connected back to a distant data center over a combination of high quality MPLS wired circuits and, in the “last room”, a Wi-Fi connection. Any packet loss on the Wi-Fi connection will, without Framehawk, greatly amplify the network latency. So long-haul WAN connections with Wi-Fi in the branch office are a perfect opportunity for Framehawk.
Please experiment with Framehawk on lossy wired connections, too. Perhaps Framehawk will save you money by providing a good user experience over less expensive circuits. MPLS provides outstanding service levels, with just 0.01% packet loss, but that comes at a cost.
As we add support for Framehawk interoperability with NetScaler Gateway 11, that will open up many more use cases. High-speed home Internet connections frequently exhibit performance issues, whether due to congestion on the “last mile” when the neighborhood kids come home from school or flaky Wi-Fi (plus you can often add the impact of cordless phones, baby monitors and vacuum cleaner motors). More and more of us are connecting to hosted apps and data via 3G or 4G/LTE cellular networks, or using inflight Internet services. And many of us like to take advantage of public Wi-Fi hotspots while stopping for a coffee break or snack, or at hotels; very few hotspots get much better than 1% packet loss (5-10% is not unusual) and congestion is a common problem.
Speaking of network congestion… A report might tell you that the average congestion on a link is very low. But if you correlate when users call the Help Desk complaining about slow performance you may find that the issues are bunched up at the start of the work day and just after lunch. Periods of very low use will skew the average significantly. But during those periods when the network is more than 30% utilized, the Ethernet protocol will degrade, and at about 45% it becomes very slow. If it hits 70% then the user experience becomes intolerable. Another opportunity for Framehawk.
What is the typing experience like with Framehawk? Keyboard input is generally more interactive with Framehawk on lossy, high latency networks than with Thinwire. Keyboard input is sent over UDP so there’s no wait for an acknowledgment before sending more characters. Framehawk will recover lost keystrokes even on a very lossy connection but it will only resend a keystroke when requested by the server. The first keystroke you type will exhibit latency, then you will notice a more interactive experience (a more linear echoback of characters) compared to Thinwire at high latencies.
How much bandwidth does Framehawk require?
What do we mean by “broadband” wireless? It is actually a difficult question to answer precisely. And we expect to learn much more as customers deploy the Framehawk virtual channel on real world networks and compare its performance with Thinwire under a variety of conditions. 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.
Our bandwidth recommendation for Thinwire is generally a base of 1.5 Mbps plus 150 Kbps per user (for more detail, see /blogs/2014/04/16/from-the-field-xendesktopxenapp-bandwidth-update/), but at 3% packet loss you’ll find that Thinwire needs much more bandwidth than Framehawk to maintain a good user experience.
Framehawk is not replacing the Thinwire virtual channel
Thinwire remains the primary display remoting channel in the ICA protocol and, as announced at Synergy, we are continuing to enhance it with innovative new HDX technologies for highly-scalable bandwidth-efficient remoting of applications and desktops hosted on Windows Server 2012, Windows 10 and Linux. Framehawk is off by default; we recommend enabling it selectively using Studio policies to address the broadband wireless access scenarios in your organization.
How will IT personnel be able to monitor the performance of Framehawk? Feature Pack 2 includes an update to the HDX WMI Provider and a new version of Citrix Director (7.6.300). The HDX Virtual Channel Details view in Director provides Help Desk personnel with useful information for troubleshooting and monitoring the Framehawk virtual channel in any session.
It is very exciting to see this first release of Framehawk technologies for XenApp and XenDesktop, and I see it as just the first leg of a journey that will take high-definition user experience to new heights. As you have probably observed, we are taking our time to do it right, one step at a time. We hope you will soon enjoy the benefits of Framehawk and give us your feedback on the new use cases and access scenarios that it opens up for you, and where you’d like to see us go next as we continue to evolve this capability.
Director of Product Management, HDX