The ‘remote desktop user experience gap’ is essentially the perceived difference between local and remote desktop and application response times. So far as typical desktop applications are concerned, the user cannot determine that a desktop is hosted remotely until click and keyboard lags consistently exceed a few hundred milliseconds on a round trip basis. This audio visual perception of lag comparable to the lag tolerances in VoIP or V2IP video teleconferencing applications, and it’s a very important metric to track in terms of remote desktop QoE.

And so ever since the acquisition of Calista by Microsoft, we’ve been watching and waiting for the delivery of server side acceleration technologies to improve perceived client side user experience. And so it arrives with RemoteFX, beginning in the Server 2008 R2 SP1 beta towards the end of July. According to what I’ve read, it’s unclear whether the RDP client required will be delivered in anything other than the companion SP1 release of Windows 7, but we can all hope it at least finds its way to Vista. Given the number of thin client machines we have deployed on XP, I would have to hope a version finds its way there too — XP OS technology limitations not withstanding.

All this said, my deepest interest beyond enhanced individual VDI or presentation virtualized desktop performance, is how that improved performance will actually shift remote desktop usage scenarios. For example, flash streaming is a virtual non-starter in our present infrastructure. It’s too slow and choppy over the WAN. Over the LAN, it’s passable. But the WAN is a generally a bust. Now, with the transformation forthcoming with SP1 and RemoteFX, that might all change. And with it, the user’s desire to engage in rich streaming and other interactive multimedia content. In essence, the moment you close that ‘remote desktop user experience gap’ sufficiently, usage scenarios expand and rapidly equate to the full local desktop experience. Which is great, at first blush. But how will this influence desktops per core?

In our infrastructure, usable desktops per core is all about the statistics of typical workloads given the usage scenarios required of the typical law firm. Reliably and without processor saturation, we can achieve double digit desktops per 2+ GHz Xeon core with presentation virtualisation (Terminal Services and now Remote Desktop Services in 2008 R2). Now, some of  you may not be huge fans of the desktops per core metric, but bare with me for a moment. What happens when you add significant multimedia workloads to this figure? In our case, lawyers and staff are generally relegated to a local browser when they are immersed in any kind of streaming online education, for example. But if RemoteFX lives up to its promise, users will no longer be compelled to manually cut and paste those browser links from their remote desktop and into their local browser address bar to fire up streaming media sessions. Instead, they’ll just point and click; for the first user, the experience may be so good that they simply keep rolling. But what about the 10th user on the same pool of core(s)?

Now, I might suggest some kind of dynamic cluster VDI load balancing makes sense here. And yes, those technologies are out there in the form of intelligent connection brokers and so forth — although load balancing decisions are generally made at connection time rather than considering the live migration of desktops at run time to handle compute overload conditions. The brute force method is to over provision cores, of course. And finally, I may simply be missing a trick here — that is, depending on the extent to which the or server sides are able to take advantage of GPU acceleration, this issue may simply not exist.

Regardless, we’re looking forward to pushing on RemoteFX in SP1 to find out how it changes the game.