Thread: Riverbed StealHead 1020 WAN Accelerator

AN connectivity has always been a concern for every enterprise. The bandwidth in India is not too costly today but it's not that cheap yet either. The availability of high speed bandwidth in India is still limited and is mostly restricted to Class A and B cities. Being a vast country geographically. whenever we talk about multi-city connectivity. the latency due to the distance becomes a major concern. We might keep spending money and upgrading bandwidth. but we generally tend to forget that we cannot reduce the distance between the two disparate locations and hence cannot reduce the latency between them.

Our experience suggests that if you double the link speed and at the same time increase the latency to five times. then the ac¬tual data transfer speed remains near about the same. So. there are two critical factors responsible for a slow WAN: bandwidth (if it's not enough for the requirement) and latency. This WAN accelerator is capable of managing both. It uses different tech¬nologies. such as Application/protocol independent Caching, Protocol optimization (to reduce the chattiness of applications to combat latency), Compression, WAFS (Wide Area File system). and Web Application Accel¬eration to enhance data access over WAN.

We received two boxes of the RiverBed StealHead 1020 WAN accelerator for review. They were essentially standard 1 U rack mountable servers running dual Xeon processors. Configuring them was not difficult. You can directly connect a monitor and a keyboard to these boxes and boot into Stealhead's OS, which drops you into a shell with a set of configuration commands; this pretty much resembles the CISCO router interface. From this in¬terface you can configure the IP addresses of the box's WAN and primary interface. And once you do that you can use the Primary port's IP address to connect the web based interface of the device for configuration and for monitoring the box graphically. As the name suggests, the WAN port is used to terminate the WAN link to the box. You would also find a port called the 'LAN' just next to the WAN port. This port doesn't require any additional IP ad¬dress and again as the name suggests, is used to connect the LAN to this device.



To test this device thoroughly, we connected both WAN ports of the device to each other through a WAN emulator and kept the subnet of both WANs as the same. We configured the WAN em¬ulator to emulate a network with 256Kbps of bandwidth and 100 ms of latency. We then con¬nected one of the WAN accelerator's LAN port to our test net¬work which had a couple of servers (Web, CIFS, FTP, etc). We then connected the LAN port of the other box to a standard Core 2 Duo machine with Windows XP SP2. One good feature of the device is that even if it completely fails (due to power or hardware failure) it still doesn't disrupt WAN connectivity; the data still passes through the device but of course un-accelerated.

Once the setup was done, we first tried copying some data from the CIFS server to the XP client. We first tried copying a 10MB folder with different types of files, mostly zipped, so the scope of compressing it was negligible. It took around 420 seconds to copy the entire data. Then we tried to copy the same file again and the process happened in less than 5 seconds. The devices use caching techniques to reduce the time taken for copy¬ing a file.

We then checked the time taken for the same 10MB file to get copied without the WAN accelerators in place. We removed both the accelerators from the network and repeated the copying process again. This time the file took around 702 seconds to copy which is around 1.7 times more. This shows that. the device can easily increase the speed to near about double even the first time data is copied. which is commendable as the folder already con¬tained zipped files that could not be compressed any further.

Next. we decided to check how well this device works with text docs. We created a single 4 MB text file and copied it without the accelerator. The file took 229 seconds to get copied. Then we placed the WAN accelerators back in the path and did the test again; this time it just took 17 seconds. Which is around 13.5 times faster. We copied it again through the accelerator and this time it just took a second to copy.
Then we created a single 10MB text file with the same line written 1000 times and tried copying with and without the accelerators in place. This time the device easily detected that the file is highly compressible (as ithad the same text lines repeated) and it copied the complete 10MB file in 2.5 seconds. which with¬out the accelerators took somewhere around 700 seconds to get copied.

Then we tried modifying some part of the files which was once copied. or renaming or changing their location. The device was smart enough to understand each time that this is the same file and copied only the modifications instead of copying the full file again and again and completed the copying process in a few seconds. We even tried copying the same file through different protocols (such as HTTP and FTP). but in this case also the de¬vice identified the files as being copied earlier and just copied the modifications wherever necessary.