H.264 is a limited technology, where delta frames are transmitted per user, this means only changes are transmitted so on a single session it’s low on bandwidth but does require CPU or GPU resource to work out the changes between frames. CPU and GPU invariably also means power and on mobile devices that means your battery power.
H.264 is also fundamentally weakest on data users really care about such as text and hidden-line/wireframe data in CAD applications, it’s fundamentally a now quite old codec designed for static video compression (read more here and here).
Over the last year, recognising H.264 alone will never suffice; the HDX team at Citrix has been investing heavily in complementary technologies to H.264 as well as strengthening the H.264 portfolio. We thought long and hard about choosing technologies optimised for the data and applications our users use and how they use applications. We’ve done a lot of enhancements for CAD and 3D cursor support, build-to-lossless algorithms for perfectly crisp CAD line drawings and also focused heavily on text quality which is probably our users’ biggest concern.
Whilst doing this we always kept in mind what we are doing remoting potential 1000s of copies of applications and desktops to users who may not want to pay for bandwidth, have limited bandwidth and may be on battery powered devices or legacy hardware. So we came up with the thinwire compatibility technologies, you can read about here:
- A Big Leap in ICA Protocol Innovation for Citrix
- Why Should You Care About the New HDX Thinwire?
- Great real user feedback on thinwire compatibility mode (thinwire plus)!
Throughout this whole process though we designed for the network and networking from the ground up, which is where the Cloudbridge magic comes in… you don’t need a Cloudbridge to benefit from thinwire+ but whilst we were there, we built in technologies that allow Cloudbridge to do more than a single-session alone can.
I find it really peculiar that people seem to regard the Citrix Netscaler and Cloudbridge as if they exist in a parallel universe to “core” products such as Citrix XenDesktop and XenApp. I spend a lot of time working with the product managers, architects and engineering teams for those products, because no matter how good your remoting protocols are, the network will always be a huge factor and Cloudbridge and Netscaler sit in a powerful part of the stack with an overview of an entire Citrix or VDI deployment.
Close development and integration with Netscaler and Cloudbridge gives me a huge advantage over my competitors’ counterparts. If you are a serious enterprise, virtualising at scale – think about what you are doing, remoting 100s or 1000s of copies of apps or similar desktops. Every user might have an outlook icon, be using the same CAD package (with the same menus)…
Cloudbridge works in two main ways (read more here):
- It manages TCP packets to mitigate against packet loss, congestion, high latency and/or jitter
Careful management can lead to a 4x increase in effective bandwidth to WAN branch office, huge bandwidth savings avoiding network upgrades. This will work on any graphics remoting protocol, H.264 or thinwire+ technologies.
Cloudbridge can also perform de-duplication between multiple sessions, something a remoting protocol alone can’t.
This is where we designed the magic into thinwire+ from the ground up. Why resend parts of the screen common to multiple users’ screens? By ensuring we transmit the screen deterministically we have built the protocol in a manner that supplies the Cloudbridge architecture with data designed to be de-duplicated. Tests are showing up to 10:1 compression ratios on certain office workloads, read more here:
This is stuff we just couldn’t do with an H.264 only strategy. We are also looking at technologies and strategies to help users avoid sending unnecessary data that could consume bandwidth in the first place, again something you can’t do with off-the-shelf H.264, read here: An Unbeatable Combo: CloudBridge & XenDesktop Thinwire