So one of my more recent projects at work has been to get up to speed on the Cisco WAAS platform. We use WAAS quite heavily on the WAN side of things and it makes a considerable difference. Put simply, if we turn it off, the users complain.
I don’t have a ton of WAN acceleration experience but when you break WAAS down into it’s core components, it’s really not that hard to understand. So let’s do a couple of quick breakdowns.
WAAS hardware Components
There are a few main components to the WAAS solution. Namely, there is the WAE (Wide-Area Acceleration Engine) and the CM (Central Manager). The WAE’s do the actual WAN acceleration while the CM(s) provide the central management for the entire platform. When you receive a WAE, you can boot it up, type ‘setup’, answer a few questions, tell it where the CM is, reboot it, and never ever log into the WAE directly again. Once the WAE is joined to the CM, you can do all of the configuration from the CM going forward.
A WAAS appliance can server either the CM or the WAE role. That decision is made as part of the provisioning process. I’ll state the obvious here, you generally don’t buy a high end box to serve as the CM.
A more recent addition to the WAAS family is AppNav. AppNav is another appliance ‘type’ which can server as an advanced load balancer. We won’t talk much more about AppNav in this post but its worth mentioning at this point.
WAAS acceleration components
When you look at how WAAS does what it does, there are really 4 main pieces. In no particular order…
TFO – Transport Flow Optimization (TFO) is Cisco’s proprietary TCP optimization. Basically, TFO just takes TCP and optimizes it. You’d be surprised at how much this can speed things up.
DRE – Dynamic Redundancy elimination (DRE) is another Cisco proprietary way of eliminating duplicate pieces of data. What’s interesting about DRE is that it works on the binary level which means that it’s totally application agnostic. DRE works by caching the largest chunks of binary data it can find in the raw packet payload. It then looks for that same chunk in future packets. If it finds it, it can replace that chunk of binary data with a key. The WAE at the other end (client side) will also look for these same chunks and give the chunks of data it finds the same key. When the packet arrives at the client side the WAE can simply do a key lookup and replace the data back into the packet.
PLZ – Persistent LZ compression. Standard LZ compression applied to the packets payload.
AO – Application Optimizations. These are specific pieces of code written to optimize specific protocols. For instance, there’s one for CIFS and another for Citrix ICA.
So that’s really it. All optimization applied by the WAE can be grouped into one of those 4 categories.
I don’t want to cover a ton of info in this post since it’s just a intro, but I do want to show you the impact that WAAS can have by applying each of these 4 optimization methods.
Let’s look at the impact of each of these when applied to a client downloading a file from a server using HTTP. In my example, a Windows XP client will be downloading a 130 meg file across the WAN from an Apache HTTP server. Let’s see how long the download takes without WAAS…
So 3 minutes and 45 seconds. Let’s turn on just TFO and see what it does…
43 seconds just using TFO. Let’s try it with TFO, DRE, and PLZ…
29 seconds, and if we download it again now that the DRE cache has been populated…
Pretty impressive numbers in my opinion. In the next few posts I hope to talk a little bit more about the network side of things. Namely, how we get the traffic to the WAE and back in a transparent manner.