Anyone out there have experience with Riverbed Steelhead products?
Do they improve TCP performance over WAN links? is it worth the price?
mike
I've had generally good experiences w/ Riverbed's Steelhead as well as
Juniper's WX Series product. For certain types of applications, like email
and database replication you can expect to see pretty dramatic reductions in
throughput because of the technique of replacing symbols for otherwise long
strings of repeatable characters. Also because of the local proxying
abilities with regards to TCP ACKs and such, you can also get better
pipelining of traffic...
As far as whether they are worth the price, this really boils down to a
proper Cost/Benefit analysis, but most of the ROI calculators show a return
after as little as just a few months.
Stefan Fouant
I'm sorry, this should have read "pretty dramatic increases", not
reductions. Sorry for the confusion.
Stefan Fouant
I've had good experiences with the Riverbed appliances as well. Definitely a leader in my mind when compared to Cisco and Juniper although there are some new niche players that have good solutions depending on the details of your traffic and topology.
One note on the Riverbeds, if you're trying to monitor their effectiveness and the traffic thru them via netflow you'll need to put them in "application port transparency mode". I may have the name of the mode a little off (going from memory) but effectively it forces the TCP ports to remain consistent as the flows are tore down and reconstructed.
HTH,
Josh
I'll let others answer the specific question about Riverbed. I've heard
plenty of good things about them though.
(forgive me if this is extremely basic) If the problem is that someone
downloading a big file slows the whole office down, there may be cheaper
ways of solving this. Assuming your WAN links are private connections (not
VPN over internet), I'd also suggest before spending money that you ensure
you are doing some sort of fair queuing with RED/WRED enabled. This will
ensure with on a network dominated by typical business TCP that one user
can't monopolize a circuit. I'd also ensure that you are not sending bits
faster than your provider will allow (beyond your burstable bit rate) by
ensuring your bandwidth selections on your interfaces are set correctly.
You might be able to fix your users' concerns/complaints just by a few lines
of router config (and if you're using anything beyond home routers, your
routers probably already support these things). In my experience, the
problem isn't that the line is too small for the workload, but rather that
bulk transfers keep everyone from doing work over it - that's where fair
queuing and WRED come in. If you've already done this, than please ignore
this suggestion. 
I've had good experiences with both Riverbed Steelhead and Cisco WAAS
products. Both have a very short ROI. I think either are well worth the
price.
Jon
I personally would take Riverbed over Cisco for one main reason that I have
discovered when I was researching them (that was good 3-4 years ago and
cisco may have "improved" since).
Cisco "accelerates" based on application. That is to say if it's not a well
known application protocol, they do not do anything with it.
So, they are probably good for HTTP/FTP/Samba etc.
Riverbed does not care for applications (they still support application
based acceleration, but they also support non standard stuff). They take
something along the lines of data hashes and store them (along with data of
course). They just store raw bytes as opposed to a let's say a file. That
played out well when I had to make a decision about which brand to purchase
for the company that had a homegrown application. So in a nutshell, Riverbed
improved performance of that application (as well as all the standard
players like HTTP/FTP etc), while cicso said outright that they won't.
After purchase, we saw a dramatic improvement in "user experience"
(basically the complaints stopped) from our EU site that was accessing
windows (samba) based file servers in USA. Those guys at the time were
connected to the US office over MLPPP (4 T1s). Samba sucked for them along
with everything else.
The only issue I had with Riverbed is their licensing model feels very
backwards. It took me a while to understand what we needed.
Andrey
I personally would take Riverbed over Cisco for one main reason that I have
discovered when I was researching them (that was good 3-4 years ago and
cisco may have "improved" since).
Yes, they have improved dramatically in the last few years since the 4.x release.
Cisco "accelerates" based on application. That is to say if it's not a well
known application protocol, they do not do anything with it.
So, they are probably good for HTTP/FTP/Samba etc.Riverbed does not care for applications (they still support application
based acceleration, but they also support non standard stuff). They take
something along the lines of data hashes and store them (along with data of
course). They just store raw bytes as opposed to a let's say a file. That
played out well when I had to make a decision about which brand to purchase
for the company that had a homegrown application. So in a nutshell, Riverbed
improved performance of that application (as well as all the standard
players like HTTP/FTP etc), while cicso said outright that they won't.
The current gen of WAAS works this way as well. The accelerators are configurable for defined services along with a default profile. There are several accelerators that are applied to each connection, starting with the most basic TCP session optimization for window sizes and other per packet modifications.
It then applies raw data optimizations such as the raw 'bit' database you mentioned, each WAE will attempt to find the largest unique run of bits and create a hash for that sequence and store it in it's local database which decays based on time and hit count. If both WAE's in the path have this hash that is all that needs to be sent, otherwise it sends the entire payload, which will then be cached on the second WAE going forward for repeat occurrences (cache expiration not withstanding...). It can also do LZ compression on the full payload when it needs to send it.
After that there are application protocol accelerators for common protocols like CIFS, HTTP, etc. These work on the session level and act as transparent proxies for the protocols and can include file cache's on the WAE. For other protocols like MS Video live streams, it can turn a uni-cast session from multiple clients into a single session up to the video server instead of multiple connections from each client.
You also have the option with these to push server certificates and private keys into the WAAS system with the Central Manager, which allows transparent SSL/TLS acceleration for internal applications along with encrypted local storage on the WAEs.
As an example, we had a commercial patch deployment system that would bog down on patch days or large updates like services packs. After the WAEs went in it improved a bit but was still a huge tax on the network even with sites that had local deployment servers for this application. After digging through the application traffic it was actually deploying with an HTTP server running on a high port. So we defined a new protocol in the CM for this port (you can also include src/dst in the configuration to narrow matching if needed). Now after the first download at an office location, the follow on requests as folks come into the office and power up are all served from local cache on the WAE.
Now that's if you are running something it does have an application level accelerator for, if it's some other protocol you can either take the default or enable or disable some of the packet level optimizations. For example, if your traffic is encrypted - it would make sense to disable the LZ and bit database processing and just leave the TCP session optimization enabled, since the processing time to do the compression will actually take longer then just transferring the original payload and also may be causing the packet to fragment and double the number of packets required, etc.
After purchase, we saw a dramatic improvement in "user experience"
(basically the complaints stopped) from our EU site that was accessing
windows (samba) based file servers in USA. Those guys at the time were
connected to the US office over MLPPP (4 T1s). Samba sucked for them along
with everything else.
Yes, deployment of most WAN accelerators that will do file caching will if not gain love from your users, it at least gets them off your back.
-James
Some other considerations for Cisco vs. Riverbed are:
Unified vs. Partitioned Data Store:
Riverbed's data store is unified across all connected appliances, whereas
Cisco partitions its data store across each connected appliance. This means
that a data pattern seen once on Riverbed will be "warm" for subsequent
transfers regardless of the destination office, whereas Cisco will need to
perform a cold transfer for each branch, to populate the respective
partition.
FIFO vs. LRU:
Cisco's data store expires patterns using FIFO, whereas Riverbed defaults to
LRU (Least Recently Used). I prefer LRU since it means that commonly
accessed data won't arbitrarily be deleted.
Encrypted MAPI support:
Riverbed supports it, and Cisco does not ("it's coming").
Central Manager:
Cisco requires a central manager, whereas Riverbed does not. Riverbed does
have a Central Management Console, but when the environment is <10
Steelheads, it's really not all that relevant.
On-box Reporting:
Cisco's on-box reporting is pretty terrible, whereas the Steelhead interface
provides a lot of easy to gather statistics & connection information.
Cisco's response to this was to invest in a NetFlow tool for visibility,
which most environments have, but sometimes running a quick report on the
box is easier, and this can add to the overall project cost if a commercial
product is used.
I'm sure there are more pros to Riverbed, but this is what I could think of
off the top of my head.
One thing I will mention is that Riverbed's v-Steelhead product, which is
their virtual Steelhead offering, may pair very nicely with Cisco's SRE "UCS
Express" offering for a single box solution.
-- Eric Cables