Making VDI Work: Choosing A Display Protocol

This post is part three of the “Making VDI Work” blog series by Leostream CEO Karen Gondoly. Click here to read part two “Things to Consider About Client Devices” or part four “How To Mobilize Your Workforce With VDI and Hosted Resources“

It’s time for volume three of our “Making VDI Work” series. In this series, we highlight various
infrastructure components that make up your hosted desktop solution, whether you’re hosting virtual or physical desktops in your data center or in a cloud. In our first installment, we talked about your client devices, and the users who are attached to them. Now, let’s look at how you get a client device connected to the user’s hosted resource.

Often, when we speak to people who are new to the world of hosted resources, our question of, “What display protocol are you considering?” is met with a blank stare. As I think about it, I can understand why. Full stack solutions come bundled with a display protocol, and the fact that there is a separate and important technology that transports the user’s remote desktop to their client device is hidden from view.

But, the display protocol defines much of the user experience, and if you want to build a hosted desktop solution that doesn’t lock you into a particular full stack solution, you need to consider it independently. So, now, let’s do just that.

First, what is a display protocol?

A display protocol is a set of technologies that, in essence, make the remote desktop feel as if it is running on the local client device. It is responsible for transporting and rendering the remote display to the local client device, as well as often handles other aspects of the end-user experience, like redirecting USB devices. Therefore, it sits in the middle of the user’s connection to their remote resource, as shown in the following high-level architecture diagram.

A display protocol typically, but not always, comprises two parts: 1) a “server side” component that lives on the remote desktop and 2) a “client side” component that lives on the user’s client device. The exception to the rule are HTML5-based display protocols, which do not include a client-side component, instead running within the Web browser located on the client device.

How do I choose a display protocol?

Choosing the right protocol requires a balance between good end-user experience, the bandwidth available on the network, and the compute power supplied by the hardware. Every display protocol balances these requirements, which form what we call the Protocol Triangle, discussed in our Choosing and Using Display Protocols guide.

Let’s look at each point in the triangle. First, defining a good end-user experience is a balance between giving the user’s what they require (access to the right type of resource with the required level of performance) with what they desire (connecting from their client device of choice.)

Therefore, start by inventorying all the device types your end users have, and all the tasks they need to accomplish, including what they need to connect to. Will you have Windows and Linux operating systems on the remote side? Do you have to support Chromebooks? Look for outlying cases both on what the users connect from and to, so you have a firm understanding of the workflows you need to satisfy and the level of performance required.

Next, consider your network. And, not just your network, but all the networks that your users might connect from. If all of your users are connecting from within your corporate network to resources in your datacenter, you have a certain amount of control over the latency and bandwidth you’re working with. But, what if they are outside your network, or connecting to a resource in the public cloud?

Over the years, display protocols have improved how they work over networks with low bandwidth, and generally network bandwidth has increased. That said, know what you are working with at the beginning, so you can test different scenarios with different display protocols to find the best fit.

Finally, consider the remote resource and the compute it provides. Will you invest in hardware that provides GPU passthrough for virtual machines? If so, make sure you also invest in a display protocol that can leverage that technology, and that you are dedicating it to workflows that require the performance. Do you have task workers who need very limited resources? If so, maybe RDS is for you and you can just stick with RDP.

So, what are some options?

After you take stock of what’s important for your deployment on each corner of the display protocol triangle, next you want to just start testing out options, and there are many. If you have any familiarity with VDI, you know Citrix provides HDX and VMware has PCoIP and Blast. But, outside of those stacks, what are your options?

In no particular order, other than alphabetical, here’s a few:

Check out your options, evaluate them in your environment, and remember that you may use more than one display protocol in your design.

Key take aways

Again, each week, I’ll make sure to summarize everything for the skimmers amongst you. This time around, what are the important points when choosing a display protocol?

What client devices and remote resources are you working with? Make sure you understand all the devices your end users have, and all the different resources they will connect to, so you can choose the display protocol, or protocols, that satisfy for every workflow.

What type of bandwidth and latency constraints are you working with? Display protocols are constantly improving their performance for low bandwidth networks, but you still may want to test out different options to see which works best for you.
Are you investing in hardware with GPU passthrough capabilities for virtual machines? If so, make sure you not only choose a display protocol that can utilize those capabilities, but limit the user workflows on those VMs to tasks that warrant the extra performance and cost.

The final point I want to leave you with is this:remember, when it comes to display protocols, one size does not fit all. After you inventory the client devices your users have, the workflows they need to accomplish, and the resources they need to connect to, look for the best protocol for each scenario, instead of over-paying for a best-in-breed display protocol for user’s who work with text files.

→Read Part Four “How To Mobilize Your Workforce With VDI and Hosted Resources“