At their Build conference this past September, Microsoft spend a fair amount of time discussing and demoing their plans for RDP and RemoteFX in Windows 8. I finally took the time to watch the videos from the conference, and I gotta say: RemoteFX and RDP in Windows 8 look AWESOME!
In fact my first reaction after watching these videos is "RemoteFX on Windows 8 is so cool! Citrix HDX and VMware PCoIP don't have a chance!!" But of course that's a topic that we've been discussing for almost ten years.
In recent years, when people have asked me about the best remoting protocol, I've always given an answer that was some variation of "Meh. They're all... fine." And I don't want to come out and say that what Microsoft is building into Windows 8 is going to blow away anything from Citrix or VMware. But I will say that the remoting protocols in Windows 8 look to be very, very strong, so anyone choosing Citrix XenDesktop, VMware View, or Quest vWorkspace on top of pure Windows 8 will do so based on more than the protocol.
So speaking of the protocol, that's what I want to dig into in this article. Microsoft shared some fairly in-depth details about RDP and RemoteFX in Windows 8 at Build, and I'd like to share what I learned with you. Most of the information this article is based on is from Build Session 642, hosted by Microsoft employees Gaurav Daga and Nadim Abdo. You can watch a video of their session or download the PowerPoint files here.
RemoteFX is basically the new name for RDP
Ok, so Microsoft isn't officially claiming that the word "RemoteFX" replaces the word "RDP" in every use case. But they have pointed out that RemoteFX is the official name for the "full fidelity" desktop experience. And it seems like every one of the slide shows and demos I've seen only mentions RemoteFX. So just like HDX kinda replaced ICA, RemoteFX is kinda replacing RDP.
RemoteFX Adaptive Graphics
In Windows 8, RemoteFX's job is to take the apps and desktop running on the remote system and optimize them for the network, regardless of what it is. So Microsof evolved everything--codecs, progressive rendering, optimized text codecs, media remoting--and packaged them all into a system that dynamically evaluates how it's encoding everything on the fly.
For example, RemoteFX will now use different encoding and different techniques for different regions of the screen. The example Microsoft gave at Build was based on the MSN home page. They explained that for text content, they'll use a codec for text that will send it down clear and sharp and perfect with very little bandwidth. (Even if they're not working with client-side font lists, they can still encode text content with high quality and low bandwidth.)
Then for image content, they'll use a progressive refinement technique where the base image gets down there instantly and then the image is refined as the network can handle it. (This is like VMware PCoIP's "build to lossless" capability, except it only affects the images and not the text. So actually it's like web browsing in the nineties.)
Finally, for any regions of the screen with lots of fast-moving changes (Flash, banner ads, video, etc.), they'll re-encode that with H.264 and send that stream down to the client.
All of this is done dynamically and changes constantly, and they can break up a single screen into as many different regions as possible:
What's also cool is that RemoteFX in Windows 8 will change which techniques it's using and how agressive it needs to get with stuff based on network and client characteristics. For example, if not too much bandwidth is available, RemoteFX can dynamically decide to start using more CPU on the host to do more compression. That will lessen the bandwidth required but increase host CPU consumption. And if the network is wide-open and there's plenty of bandwidth, the remote CPU doesn't have to work as hard. (This feature, and the limits in both directions, will all be controllable via GPOs.)
This is awesome. Remember the article I wrote "Remote display protocols: low bandwidth, good user experience, low CPU... pick any two." Now we can pick one as "good user experience" and let the system work out the balance between "low bandwidth" and "good user experience." Brilliant! (This also addresses my commentary on the fight Citrix and VMware got into about bandwidth consumption. I always believed that if the network was wide open that the protocol should be allowed to take as much bandwidth as it needed to deliver an experience that was as perfect as possible.)
Delivering RemoteFX via UDP in addition to TCP
By now most of us are aware of the "UDP versus TCP" conversion when it comes to delivering remote computing protocols. (I wrote a primer last year for SearchVirtualDesktop if you don't know what I'm talking about here.)
Long story short: Microsoft is jumping on the UDP bandwagon for RemoteFX in Windows 8. Now this doesn't mean that UDP is replacing TCP. It just means that if UDP is available, and if the characteristics of the network are favorable for it, then RemoteFX will use UDP for some of the virtual channels. (Some, not all.) But RemoteFX will also happily work via 100% TCP. It just depends on the scenario and connection. (This is also controllable via GPOs.)
RemoteFX will also pay attention to what kind of content is being remoted so they know if they have to retransmit any packets (since UDP doesn't retransmit). For example, if they're sending down an H.264 video stream, that codec will heal itself so they don't have to worry about missed packets. But if they're sending down some other screen element via UDP, they'll retransmit if needed.
The new Remote Desktop Gateway also integrates the new UDP option, so it can easily be extended across the Internet.
RemoteFX Media Remoting
RDP and RemoteFX have long supported multimedia "redirection" for certain types of video content. (This is where the remote host identifies a media stream and simply redirects that stream in its original and unmolested format, down to the client where the client decodes and displays it locally. This is much better than decoding and rendering it on the remote host and then immediately trying to re-encode it with RDP to send it down to the client. Citrix HDX has a similar feature.)
In RemoteFX on Windows 8, the media remoting capability will work exactly as it did in the past, and Windows Media Foundation and DirectShow content will be sent from the host right down to the client without transcoding. So that's all the same.
The problem with media remoting in the past was that it only worked for those certain types of Windows media. So if you were watching a QuickTime AVI or Flash video in the session, good luck!
So what's new in RemoteFX for Windows 8 is that if there's a video format that RemoteFX can't redirect natively, the remote host will use an H.264 codec engine to re-encode those moving graphics into an H.264 media stream which is then redirected to the client where it can be rendered locally. So now you can essentially say that RemoteFX can redirect any media format. Of course this H.264 encoding will require a bit more horsepower on the host, but again that's a balance between user experience and host processing, and something that can change dynamically in Windows 8.
Putting it all together for real WAN support
You can imagine that all of these capabilities (adaptive graphics, UDP option, and media remoting) can work together to create a kickass WAN solution, and that's Microsoft's plans too! In fact they specifically called out the WAN use case as a goal for RemoteFX in Windows 8. (RemoteFX in Windows 7 was famous for consuming a ton of bandwidth and was thus limited to LAN-only. Well, unless you used it with something like Quest EOP.)
For the WAN in RemoteFX, Microsoft explained that even "WAN" means different things to different people and encompasses a lot of different experiences. WAN could be remote offices across the country or world, it could be 3G anywhere, it could be various qualities of public WiFi, it could be high-speed home cable modems that are faster than the office connections, it could be airplanes... So rather than trying to identify and work with specific scenarios, Microsoft is going back to the basics in RemoteFX for Windows 8 and focusing on three areas of the network: latency, packet loss, and limited bandwidth.
When it comes to latency, Microsoft believes that the physical speed of light issue is usually not the problem. The main problem is that TCP is not efficient in environments with low bandwidth and packet loss, so being able to use UDP should help with that. And even when using TCP, RemoteFX in Windows 8 is smarter about it. The protocol will now change how it multiplexes packets, for example, based on the network conditions at a given moment.
Again, Microsoft understands that in the world of TCP, packet loss really just means higher latency. But moving to UDP for the stuff that can handle loss should help them ride it out. And adding UDP support to the Remote Desktop Gateway is huge, so users can actually use UDP wherever they are. (Of course with auto fallback to TCP if UDP is not available.)
The adaptive graphics stuff mentioned above will be great for scenarios with limited bandwidth. Really anything that takes data off the wire is great. At Build Microsoft showed a demo where they compared RemoteFX on Windows 7 and Windows 8 side-by-side (Benny and Shawn style) to watch a YouTube video (not full screen). Windows 7 consumed 30-50mbps, while Windows 8 only used 3-5mbps. The user experience looked about the same on both.
So combine that with the fact that Windows 8 will dynamically choose between host-side processing and bandwidth, and it looks like RemoteFX could be a great WAN solution!
RemoteFX on Windows 8 will support true multitouch. (So this is not just controlling the pointer with your finger.) They can support as many simultaneous touch points as your client device supports, and they can support them with full pressure sensitivity.
RemoteFX USB Redirection for Terminal Server sessions
RemoteFX running on Windows 7 in a VDI scenario was always able to support USB device redirection, but Windows 8 will add USB support for sessions. They've also figured out how to do it with full security, so that one user is not able to access the USB devices or data from another user.
Metro Style Remote Desktop App
This is something I wrote about on ConsumerizeIT.com last week, but if you haven't seen it (and judging by the numbers, you haven't), Microsoft is building a Metro style Remote Dekstop client. This isn't replacing the classic MSTSC client, rather, it's just a second client option for tablet users. The Metro style and the traditional Windows client will have the exact same features. (They'll both support multitouch, for example.) The tablet client is just easier to use on tablets and will be nice if you want to remote Metro style apps.
More information on the Metro style client and remoting Metro apps is in that article from ConsumerizeIT "Windows 8 "metro" apps & the remote desktop client: how will these work together?"
RemoteFX on Win8: the same experience no matter what GPU or platform
The final cool thing about RemoteFX on Windows 8 is that ALL of these features and capabilities are available anywhere Windows 8 runs. So you have the choice of having a physical GPU, a virtual GPU, or no GPU at all. Regardless of what you use, you can still have all of this--full DirectX support, media encoding, etc. (Obviously some of this is more efficient with a GPU, but if you want to do it all in software on a CPU instead, that's your GPO-controllable option). The same is true for physical or virtual. It doesn't matter whether your remote host is physical or virtual, workstation or server--it's all available.
RemoteFX on Windows 8 looks awesome. Are Citrix and VMware dead?
As I've been writing for years, it's really not a protocol War anymore. HDX and PCoIP are both fine protocols with advantages and disadvantages. Maybe now we can add RemoteFX to that list. Worst case this just raises the bar for everyone and the whole world gets a better remoting experience.
The main limiting factor of RemoteFX is going to be a limited set of client platforms and the complexity of a Microsoft-only solution. Citrix, VMware, Quest, and others can take care of those issues. The other limiting factor will be that RemoteFX is a designed for Remoting Windows desktops. So yay! Microsoft is finally awesome at that in 2012 while the rest of the world is moving beyond Windows. So we might see Citrix/VMware/Quest defer to Microsoft more and more for the Windows remoting protocol while these companies look at the other issues (app stores, HTML5, identity management, data sync, etc.).
If you're interested in learning more about RemoteFX on Windows 8, check out the following three sessions from Build. The videos and PowerPoint downloads are all available for free:
SAC 642T, Remote desktop experience in Windows 8
SAC 217T, Graphics on the server
SAC 428T, RemoteFX thin client & partner opp