Each Mobile client is essentially the same Riverbed operating system found on the appliances, just in miniature. It provides all of the same optimization features, such as TCP/IP optimization, CIFS and MAPI specific optimizations, and Sequenced Data Reduction. SDR proved to be very effective and, as with the appliance, is shared across applications. So if a user FTPs a file to their laptop, then copies it back to the datacenter using CIFS, only the changed part of the file is sent across the WAN.
Steelhead Mobile gives users local control over some optimization features, and also shows how the client has impacted performance.
As great as Mobile sounds, there are a couple of shortcomings. Steelhead Mobile can't accelerate NFS and encrypted traffic such as SSL. Remote users logging into the corporate portal using SSL or accessing files on an NFS server won't see any real benefit from installing Mobile. It takes a Steelhead appliance to accelerate this traffic. Also, whereas the Steelhead appliance shares a cache with all users, each Mobile client has its own unique SDR cache. This means that one user can't take advantage of data cached when previously accessed by another user.
Reporting is very well done with statistical information and traffic reduction information available in the client software as well as aggregated in the Steelhead appliance. Each Steelhead Mobile client appears as an appliance in all reports generated by the Steelhead.
Steelhead 1520 with RiOS 4.1
For situations where a permanent end-to-end solution is required, Riverbed's Steelhead family of appliances fits the bill. Now in release 4.1, the Steelhead RiOS software just keeps getting better and better, showing increased overall performance from last release (see my review of Version 3.0) and new application optimizations for HTTPS and Oracle Java Initiator. The new release also improves HTTP acceleration and introduces MX-TCP, a method of handling packet loss on the WAN.
This round of appliance testing consisted of a pair of Steelhead 1520 appliances and the Shunra WAN simulator. To stay as consistent as possible, I used the same test set as in my previous appliance reviews and found the results to be overall better than with release 3.0. All CIFS-based file copies, whether of many small files or a single large ISO, came in with much reduced transfer times. The Steelhead was at its best when handling the large number of small files, reducing the time from just over 4 hours without optimization to an acceptable 23 minutes on a first pass.
FTP traffic showed good improvement over last year's release, with an FTP of a single large file showing a reduced transfer time from 2 hours, 40 minutes nonoptimized to just under 11 minutes on the first pass (20 minutes faster than the last release). Subsequent FTP gets of the same file clocked in nearly identically to the times recorded with release 3.0, just a tick under 1 minute.
One new feature in release 4.1 that made a big difference in packet loss is MX-TCP, a proprietary TCP optimization method for dealing with congested or "dirty" links. Normally, when TCP detects a dropped packet, it reduces the congestion window by half and slowly starts ramping back up to full speed, at least until it detects another dropped packet. This creates the classic sawtooth network performance graph. MX-TCP turns off TCP congestion control, so when packet loss occurs, instead of backing off dramatically as TCP does, MX-TCP backs off only a little.
One of my Shunra test scenarios includes 0.5 percent packet loss. I tried this in two test runs of my FTP test, one with MX-TCP off and the other with it enabled. The result was remarkable. MX-TCP proved to be a major factor in improving test results over Version 3.0. For example, a first pass without MX-TCP took longer than 51 minutes to complete, compared to just under 11 minutes with MX-TCP enabled. MX-TCP is application agnostic; a similar test using CIFS showed roughly the same improvement.
RiOS 4.1 also boasts two new application-specific optimizations. First, the Steelhead can now accelerate HTTPS traffic between appliances. Like the SG family of appliances from Blue Coat Systems (see my review), Steelhead intercepts the HTTPS session from the client, decrypts the traffic, optimizes it, and re-encrypts it over the WAN, where the process is reversed by the second appliance. This "man in the middle" approach requires IT to install the appropriate certificates on each appliance, but the end-user's experience doesn't change. Setup and configuration of the SSL encryption and decryption is a bit involved, but not so difficult that this highly useful feature should be ignored. My pair of Steelhead's handled HTTPS traffic well in the lab, though I was not able to measure the performance. My seat-of-the-pants view is that users will not notice any slowdown during initial setup, and will experience better overall performance for secure traffic.