Changes to Windows Server 2012 Media Handling Reduce Bandwidth Requirements for Remote Desktop (RDP) and Terminal Services

RemoteFX Media Streaming Introduced

Over the years I have worked at both Internet Service Providers and server hosting companies. In both environments, customers have found thin client deployment and virtual desktop provisioning stymied by the bandwidth needs of remote desktop when used for day-to-day desktop computing style tasks. I can't remember how many times I have worked with a company whose entire network has failed or flapped because of employees downloading torrents or watching Youtube videos from a remote server. Other times, I have worked on Terminal Services capacity planning projects, and found myself impressed by the difficulty of giving reliable estimates even where good data is available.

Many companies have been completely unable to reap the rewards of hosted desktops (fast provisioning and restoring, centralized management, easy hardware replacement) because of the costs of reliable high-throughput internet connections to their office. Data center bandwidth isn't cheap, either. A number of companies have been founded (and a few, like Citrix, have flourished) around introducing appliances and applications to further compress the data on both ends of a remote desktop connection.

The rewards to the end user, then, of improving multimedia performance over RDP are huge. Microsoft is claiming to have done just that with Windows Server 2012.

Changes From Windows Server 2008 / Windows 7

Windows Multimedia Redirection (WMR) was the name for special multimedia handling in the last version of Windows. WMR had some positive innovations of its own - rendering takes place on the client side, and as a result, CPU load on the server is decreased. Under normal circumstances this is accomplished without a significant reduction in quality. There were a number of problems with the implementation - WMA, WMV, MP3 and DivX are handled, but unsupported protocols get handled without any special rendering (unsupported includes Flash, Silverlight and Quicktime - basically almost all video on the web). The client requires RDP 7.0 when connecting to take advantage of any of this. Bandwidth consumption is wholly dependent upon the bit rate of the original video. The frame rate sucks and becomes worse with scale.

Windows Server 2012 addresses the issues differently - WMR is replaced by RemoteFX. Through some secret mojo that has yet to be fully explained by Microsoft at this point, RemoteFX identifies regions of the screen that are to render video. The video content is encoded using H.264 codec and RemoteFX Progressive Codec. Audio is encoded by using the AAC codec. This is accomplished regardless of how the video is displayed - Silverlight, Flash - every protocol is supported. Because video behavior is consistent, capacity planning should become a more straightforward task, as the biggest variable for client resources finds a reduced range of possible values.

Microsoft is publishing some big claims on performance improvement. 90% bandwidth reduction claims should be greeted with skepticism, but other claims of frame rates over the WAN staying around 20 fps look promising. Testing demonstrates (I am working on embedding the video, should have it up shortly) that in a side-by-side comparison of Windows 7 and Windows 8 remote desktops using the same uplink - 2 Mbps throughput, 250ms round-trip latency, and 0.5% random loss - Windows 8 shows significant and noticeable graphical improvement, performing almost indistinguishably from a local display while playing the same Youtube video. Windows 7 struggles - several times a second, the video pauses to re-render a new image, making the display irritating and unwatchable. Keep in mind I have yet to test or see test results with multiple concurrent RDP connections, so at this point I would not recommend capacity planning using those numbers.

More testing is needed - what will be valuable is a greater understanding of the amount of resources (especially throughput) needed per RDP client, reliable maximum client per server numbers, and any additional provisos for virtual environments. If your projects are graphically intensive or involve unique image, audio or video handling, then running a few of your own stress tests is highly recommended.

When performing your own tests, note that WMR is still used for LAN connections in Windows Server 2012. Whether you are on a LAN or WAN is determined by latency - if your connection is under 30ms latency, WMR will be used. If your connection is over 30ms latency, RemoteFX is used. There are a lot of ways to control latency for testing - I am partial to NIST as Cisco's recommended WAN emulation software. Although NIST is Linux based, the previous link will take you to full installation media with detailed instructions (so you don't need to be an expert Linux administrator to get it working). That said, there are Windows-based WAN emulators too. Jperf (the java fork of iperf) and WANEM should do the trick, as well. Be sure to publish your results! Here is a link to the forums if after testing you would like to share your data with the community (I am also happy to publish your results here, or link to findings on your blog or website).

The tests so far I have seen look very promising - hopefully these changes continue to encourage the implementation of virtual desktops, as well as the adoption of Windows 8/2012 itself.