Anyone out there have experience with Riverbed Steelhead products? Do they improve TCP performance over WAN links? is it worth the price? mike
-----Original Message----- From: harbor235 [mailto:harbor235@gmail.com] Sent: Thursday, April 21, 2011 2:50 PM To: NANOG list Subject: riverbed steelhead
Anyone out there have experience with Riverbed Steelhead products? Do they improve TCP performance over WAN links? is it worth the price?
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
-----Original Message----- From: Stefan Fouant [mailto:sfouant@shortestpathfirst.net] Sent: Thursday, April 21, 2011 2:58 PM To: 'harbor235'; 'NANOG list' Subject: RE: riverbed steelhead
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
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 -----Original Message----- From: Stefan Fouant [mailto:sfouant@shortestpathfirst.net] Sent: Thursday, April 21, 2011 1:58 PM To: 'harbor235'; 'NANOG list' Subject: RE: riverbed steelhead
-----Original Message----- From: harbor235 [mailto:harbor235@gmail.com] Sent: Thursday, April 21, 2011 2:50 PM To: NANOG list Subject: riverbed steelhead
Anyone out there have experience with Riverbed Steelhead products? Do they improve TCP performance over WAN links? is it worth the price?
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
On Thu, Apr 21, 2011 at 12: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?
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. :) -- Joel Maslak
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
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 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
-- Andrey Khomyakov [khomyakov.andrey@gmail.com]
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
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 On Mon, Apr 25, 2011 at 12:30 PM, James Michael Keller < jmkeller@houseofzen.org> wrote:
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:
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
Anyone out there have experience with Riverbed Steelhead products? products. Both have a very short ROI. I think either are well worth the price.
Jon
participants (8)
-
Andrey Khomyakov -
Eric Cables -
harbor235 -
James Michael Keller -
Joel Maslak -
Jonathan Fernatt -
Stefan Fouant -
Stephens, Josh