Microsoft RemoteFX: The problem we are solving …

[MicrosoftSecurityandComplianceTeam]

First published on CloudBlogs on Mar, 26 2010

My name is Tad Brockway.  I am the Product Unit Manager for the Remote Desktop Virtualization (RDV) Calista (now RemoteFX ) engineering team. We’re located on the Microsoft Silicon Valley campus in Mountain View, California.  I have been passionate about desktop centralization for many years, going back even before I joined the Microsoft Remote Desktop Virtualization team in 1998.  Prior to joining Microsoft, I was a UNIX developer.  We didn’t call the scenario desktop centralization at that time.  We called it X Windows ;)

I feel fortunate to now be running the engineering team that resulted from the acquisition of Calista Technologies in January of 2008.  This is the engineering team that is delivering RemoteFX, a set of technologies that will change the way that the industry thinks about Windows desktop centralization, remote graphics, and thin client computing scenarios.  This blog post explains our goals for remoting, where we started, and the basic approach we’ve taken.

The Promise of VDI

The promise of Virtual Desktop Infrastructure (VDI) is that end-user desktops can be centralized in such a way as to move complexity and state from the desktop into the datacenter. To execute on this promise, we needed to allow people to use a broad range of endpoint devices without compromising on the end-user experience. To this end, we are developing a remoting approach that complements traditional graphics remoting capabilities and works for endpoint devices ranging from PCs to the most lightweight of thin clients.

Client-Centric Remoting

Traditionally, graphics remoting protocols like RDP have approached remoting in a client-centric way.  These protocols intercept graphics on the host device and then efficiently forward the intercepted graphics ‘primitives’ (e.g., “Draw Rectangle”, “Draw Line”) to the client device.  The client endpoint renders the primitives using a client-side counterpart for each graphics intercept point on the host.

This style of remoting is client-centric because the architecture relies heavily on the rendering capabilities of the client software and hardware.  There are benefits to client-centric remoting.  Chiefly, the bandwidth utilization is very good for graphics types that can be intercepted high in the software stack and sent as primitives.  But, when the client and host don’t both support a particular graphics type, either the application fails to run properly or the two sides negotiate down to a least common denominator graphics construct: a bitmap.  Bitmaps require more bandwidth than primitives.  For example, the primitive representation of ‘Draw Line’ would simply include the x, y coordinates for the line start and the line finish. The bitmap representation of the line would have to describe, minimally, the X and Y coordinates for every single point on the line.

If you have a powerful client device with a rich software stack and your host has all the right graphics intercept points, you can have a great user experience over a relatively low-bandwidth connection with a client-centric graphics solution.  But, if you have a less complex client device and/or are missing some important graphics intercept points on the host, client-centric remoting will result in gaps in the experience, such as choppy video or missing graphics.

Client-centric remoting originated when there was limited bandwidth from the datacenter to the end-user desktop and when the vast majority of applications were developed on top of the same Windows graphics APIs, GDI .

Host-Centric Remoting

Today, bandwidth is less expensive and in many places widely available.  Today’s modern Windows desktop includes rich media and 3D graphics content.  Additionally, a wide array of graphics types (for example, Silverlight, Adobe Flash, DirectX, Aero Glass, Windows Media, etc.) is now relevant to Windows users. These changing conditions call for the addition of a new model that can support all graphics types, including 3D, by sending highly compressed bitmaps to the endpoint device in an adaptive manner. We call this host-centric remoting .

You can ensure a consistent end-user experience for a wide array of devices if you follow the VDI model and enable movement of a large portion of the client software and hardware into the datacenter. With host-centric remoting, all the graphics can be intercepted on the host at a very low layer in the software stack. All graphics are rendered on the host into a single frame buffer (a temporary holding station for graphical updates) that represents the end-user display.  Changes to the frame buffer are sent to the client at a frame rate that dynamically adapts to network conditions and the client’s ability to consume the changes. The changes are sent to the client endpoint as highly compressed bitmaps by using an encoding scheme optimized for Windows desktop content. The basic graphics requirement for the client endpoint is that it supports the ability to decode and display the highly compressed bitmaps that it receives from the host. At a minimum, the client needs the decoder counterpart to the encoder that was used on the host as well as a basic graphics display capability.

The downside to host-centric remoting is that it requires more bandwidth than client-centric remoting. However, it delivers a consistent experience for every aspect of the modern Windows desktop projected out to an amazing diversity of client devices.

It’s Additive!

If you have a client device with a rich software stack and advanced processing capabilities, client-centric remoting makes sense. But, to completely deliver on the promise of VDI, you also need host-centric remoting.

RemoteFX is Microsoft’s first big step into the world of host-centric remoting. But, the obvious relationship between client-centric remoting and host-centric remoting is that you need both sets of capabilities in your remoting protocol. We are adding RemoteFX as a new capability or ‘payload’ to the RDP platform, while continuing to support and enhance our existing client-centric model. We offer our customers the best of both worlds in one solution. Host-centric remoting takes advantage of environments with ample bandwidth for content- and device-independent remoting, and client-centric remoting works well for network-constrained environments with richer, more powerful client devices. The fundamentals of RDP are unchanged. RDP includes the same authentication, encryption, device redirection, and transport capabilities independent of the remoting model being leveraged.

This has been a quick overview to explain our goals and the models we’ve employed to meet them. Please check back with this blog as we will talk more about what makes RemoteFX as part of RDP so special.