Many of the WAN acceleration vendors (Cisco, Riverbed, Expand, Packeteer, Cisco WANscaler, Exinda) are sprouting some amazing statistics for improvement of VDI performance over a WAN. However are these claims realistic? How does one navigate the VDI and WAN acceleration space?

Here is a claim from one vendor. 

Expand’s VDI solution can can provide acceleration by an average of 300% with peaks of up to 1000% for virtual desktop user traffic.

Is this realistic? Sounds like a lot of sales and marketing to me. I remember reading a white paper from one vendor sprouting their lead in the acceleration of VDI, which consisted of the argument that by reducing the bandwidth of the other protocols over the link VDI would magically get faster. Whilst true, if that’s all there is it’s not really an improvement on RDP is it? I am sure this was Riverbed but I can’t find the paper and its not on their website anymore. Instead on the page about virtualisation they talk about ACE in the desktop space, good grief, get with the program, no mention of VDI at all.

So how do we make some sense of this space?

Firstly there are two areas that need addressing, RDP and printing.

Lets start with RDP, it’s a protocol that could do with some assistance over the WAN.

RDP as a protocol is chatty, by which I mean there are lots of smaller size packets which go back and forth, rather than a large data steam that goes generally in one direction like a file transfer. This makes RDP more affected by latency and packet loss. It needs some bandwidth but not huge amounts for normal workloads. As a guide I always use 30k to 100k bps per user with 150ms or lower latency. The bandwidth is going to depend on screen size, colour depth and the type of work you are doing. Also remember that as you add users its not a simple multiplier of bandwidth required, as you are more concerned about concurrency than number of users, not everyone is banging on their keyboards and refreshing their screens constantly or at the same time.

The WAN acceleration providers have three basic techniques for improving RDP itself.

1. Improving the delivery and flow of TCP/IP. Riverbed call this Transport Streamlining and Cisco call it TCP Flow Optimization (TFO). Through lots of clever tricks at the TCP/IP layer to minimize effects of latency, fill packets, adjust window sizes and improve startup times these techniques can have a good impact on perceived and measured performance. The good thing here is that this occurs irrespective of the application protocol being transported, but different protocols will give different results.
2. Compression. All the vendors use compression to reduce the amount of traffic. However the important point here is that if the traffic is already compressed or if it’s encrypted the effectiveness of this compression may be negligible. 
3. Prioritization. If there are different protocols or even different sources or destinations, certain traffic can be prioritized over others. By jumping the queue time sensitive protocols such as RDP can show improved performance from the user perspective. However it’s important to remember that if the majority of traffic is all the same priority, improvements are not going to be achieved. If all the traffic over the WAN link is now just RDP traffic, it’s hard to make any improvements via prioritization.

There is another technique that the vendors sprout, which is application protocol specific acceleration, such as for CIFS or HTTP. By understanding the protocol and placing in optimizations to handle it specifically, dramatic gains can sometimes be achieved. However I have yet to see a vendor who when you dig deep, actually has techniques for improving RDP specific to its protocol. For RDP, it always falls back to the above categories of generic improvements around flow, compression and prioritization.

So how can this be put to advantage in VDI deployments? Here are my tips to give your WAN accelerator every chance at success.

• If you do have a mix of other traffic over the same link you may get some good results. With other traffic bandwidth reduced and prioritization applied you should see some improvement in your RDP traffic.
  
• Remove encryption from the RDP sessions. For your XP desktops you want to be installing the Microsoft patch http://support.microsoft.com/KB/956072 to allow the registry changes for turning the encryption level of RDP down or off. Of course you will need to take into account the security considerations and you may use some techniques in your WAN accelerator to add some encryption back in (after the fact). However removing the encryption allows for much better compression and caching of the data.
  
• Turn off compression of the RDP sessions. This is described on page 152 of the View Manager 3 manual, the setting is “Enable compression” and it’s enabled by default.
  

Now let’s turn our minds to printing.

Moving to server based computing and therefore moving print jobs from the LAN to the WAN often causes headaches. Print jobs have a tendency to become large, which is not usually a problem when there is a 10 Mb or 100Mb link between the users machine and the printer. However put a number of users behind a much smaller link and print jobs start queuing up. The printer can sit their slowly receiving a large job over the small link, and nothing else prints until its all finished. That one small job of a single page right at the end of the queue has to wait and wait, as does the user who printed it. This is nothing new, it has been an issue in the Citrix world for a long time and vendors like ThinPrint have come out with some fantastic technologies to compress and prioritize print jobs, with some amazing results.

Where does WAN acceleration come into the printing issue? Today many WAN acceleration vendors include specific printing acceleration services within their solutions. Yes, VMware View Client for Windows comes with a version of ThinPrint but that is only for printing to a local printer through the client. This can provide part of the solution but most Enterprise customers in my experience will have networked printers in the remote offices run off central or remote servers, and with VDI the print jobs will not go via the client. Therefore you may find that your WAN acceleration solution also solves much of your new printing problems too. It may not provide a Universal Print Driver or have all of the nice features like prioritization (or it may) but it may be good enough.

So don’t be fooled by all of the marketing by the WAN acceleration vendors, they are all attempting to jump on the VDI bandwagon and it is causing some confusion. Try to understand where the improvements are actually happing, are they a primary improvement to the actual protocols or are they simply secondary effects of fixing other data going over the link? How will you be able to integration printing? Armed with some knowledge you should be able to evaluate vendors products based on their presented information plus also be able to conduct some good testing.

I plan to get some tests done with Cisco WAAS and VDI over the Christmas period if I can, I will let you know how I get on.

On a side note, the VMTN Community Round Table this week has Jerry Chen, Senior Director of Enterprise Desktop Virtualization as a guest this week. If Jerry runs out of things to talk about lets see if we can get him to give a view on acceleration of RDP and what he knows or has seen in the market? Maybe even some futures stuff or who VMware is working with.

Rodos