Re: riverbed steelhead

[James Michael Keller <jmkeller () houseofzen org>]

On 04/25/2011 01:55 PM, Andrey Khomyakov wrote:
> 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

> 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
>
> On Thu, Apr 21, 2011 at 10:36 PM, Jonathan Fernatt<fernattj () gmail com>wrote:
>
> > On Thu, Apr 21, 2011 at 2:49 PM, harbor235<harbor235 () gmail com>  wrote:
> >
> > > 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 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