The Riverbed Blog (testing)

A blog in search of a tagline

Archive for September, 2009

Different Country…Same Decision

Posted by riverbedtest on September 28, 2009


The effects of jet lag wake me up…it's now 2am in Mumbai, India as I begin to write this blog.  On this trip I have met with some large potential customers who are evaluating Riverbed.  Although the cultural surroundings of these meetings are different, the topics we discussed are very much the same as in meetings I regularly have with customers in the US–specifically, the customers want to know what the differences are between Riverbed, Cisco WAAS, and other competitive offerings.

Every week I meet with IT organizations who wrestle with these same questions.  I remember a number of months ago meeting with executives from Lantmannen.  After a careful evaluation process, they ultimately chose Riverbed.  As a result of their decision, Lantmannen executives now estimate that they will save more than $60 million over five years.  More details about Lantmannen's Riverbed experience can be found in CIO Magazine.  The online edition of the article can be accessed here:

Many other customers have experienced benefits similar to what Lantamannen has received with Riverbed.  You can read about some of their personal accounts in Riverbed's community forum ( 

But not every prospective customer chooses Riverbed.  Some are attracted by the lower pricing of competitive offerings.  Often brand loyalty plays a part, and the purchase rationale often involves an assumption that Cisco's WAAS product is "good enough."  I also have regular opportunities to meet with these customers, often months or years after their fateful decision to purchase WAAS.  The experiences they relate to me are not pleasant.  A common theme is that while they were able to get a small number of WAAS devices working, complications arose as the size of the deployment grew.  What was originally envisioned to be a 60-site deployment had to be scaled down to something significantly smaller.  After struggling through many months of frustration and futility, real-life WAN performance requirements forced them to take another look at Riverbed.

The customers I have met in India face the same decision.  Having tested Riverbed, they clearly want the Steelhead solution, but they are being tempted by Cisco's offer of 80% or greater discounts for WAAS.  It is the same situation to that faced by many other customers around the world.

Posted in Uncategorized | Leave a Comment »

The difference between a lightning bug and lightning bug – linking access and performance with mobile workers

Posted by riverbedtest on September 23, 2009

The advent of "internet everywhere" is reflective of the interconnectedness of global business and like laces in a shoe serves to draw the world and business opportunities closer, while simultaneously increasing competition. Supporting workers while they are away from the office and looking to capture these opportunities can be the difference between IT acting as a competitive edge and IT acting as an impedance to business success. The difference between the two is not merely access but performance.

Forrester Research Analyst
Chris Silva recently wrote a piece on the ZDNet Blog "It's Flue Season: Connect and Optimize Your Workers" about the importance of considering both access and performance when supporting mobile workers. Composed at 30,000 feet while on a flight from St. Louis to San Diego Chris's experience working over a 5.5 miles in the air is by no means unique and underscores how varied the locations are where work is gets done.  As he points out, continuity of operations and disaster recovery plans only focus on access and not performance, when in truth access and performance are two sides of the same coin. Both are equally to important consideration to ensure that mobile workers operate as effectively away from the office as they do when they are in it.  

Workers maybe able access resources from variable locations, but when away from their carefully architected IT environments they face inconsistent connection types, costs and user volumes, low bandwidth links (eg 3G data cards) which are easily overwhelmed by application usage, and high latency all of which conspire against mobile worker performance. Silva refers to mobile WAN optimization products like Steelhead Mobile playing a crucial role in bridging the gap between merely allowing someone to work away from the office and enabling them to perform. As our always on society introduces greater competition between firms and the threat of any interruption in work demands well designed business continuity and disaster recovery plans Steelhead Mobile and its ability to ensure both access and performance become even more crucial.  

I thought that Chris Silva did a fantastic job articulating this point and encourage everyone to read this and all of his posts on the ZDNet site. For more information about how Steelhead Mobile can help you provide your mobile workers with both the access and performance that they need when they are away from the office check out

Posted in Mobile | Tagged: , , , , , | Leave a Comment »

Riverbed thanks Cisco for their great QA work on the Steelhead

Posted by riverbedtest on September 17, 2009

At Riverbed, we are committed to improving the Steelhead product by adding new features and capabilities.  As with any software product, an unfortunate side-effect of our efforts to improve our product is that software bugs can result. Our QA and engineering teams do their best to identify and resolve every known bug in the Steelhead software before it is released, but on occasion bugs can be discovered by our customers in their network environments.  After all, the Steelhead solution is tested daily in very demanding environments by thousands of Riverbed customers, including in some of the largest and most complex IP networks in the world. 

When bugs are reported to Riverbed, we take them very seriously.  However, imagine our surprise earlier in the summer of this year when we received a report of a bug that was discovered not by a Riverbed customer, but by Cisco Systems!  Well, like I said, we're happy to improve our software, even if by taking a clue from a competitor, so we took this bug report very seriously.

Perhaps a little bit of background is in order here.  Although the bug was discovered by Cisco, it was actually reported to Riverbed by a customer who was being shown a demonstration of the bug over a webex session.  You see, Cisco was trying to convince the customer that Riverbed's product couldn't handle high traffic loads because of a failure that occurred when the Steelhead 6020 is exposed to 5000 TCP connections generated by a Spirent tester using a specific traffic profile (i.e., HTTP connections).  Cisco ignored the fact that Riverbed already has hundreds of customers using the same Steelhead 6020 to optimize as many as 40,000 TCP connections, and they attempted to characterize this problem with the 5000 connections not as a bug, but as an overall Riverbed limitation.  The customer was suspicious, and alerted us as to what Cisco was doing.

We received enough clues to reconstruct how Cisco contrived the test, and were able to replicate the bug event in our own labs.  Here are some additional details on what we found about the bug:

  • No Riverbed customers have reported this bug to Riverbed.  It doesn't show up in real-life networks.

  • The bug ONLY occurs with HTTP connections, because it is specific to Riverbed's HTTP optimization feature, whereas Cisco WAAS has no comparable HTTP optimization feature.

  • The bug only occurs when a large number (~5000) of HTTP connections all simultaneously issue GET operations for large web objects, in this case web objects that are 1MB in size.  In a normal real-life environment, web objects are typically only a few KB in size.

  • For those environments that do involve large web objects (e.g., Sharepoint files), the bug will not be triggered as long as GET requests do not happen simultaneously across all 5000 active HTTP sessions.  Since in real-life applications do not exhibit this behavior, no Riverbed customers have complained about this bug.

  • If the HTTP optimization blade is disabled, then the bug will not occur.  Any customers who are concerned could simply disable the HTTP feature (and Cisco WAAS has no equivalent feature), and the bug will not appear.  They can re-enable HTTP optimization when the Steelhead is updated with the bug fix from the Riverbed support website.

I would like to inform concerned parties–including our competitor Cisco–that the bug has been resolved, and the fix is now available on the Riverbed support website, in the recently-available RiOS 5.5.5 release.  Following our stringent quality standards, we have spent the last several weeks testing and validating the fix, and are now comfortable-enough to release it.  But once again, the credit goes to Cisco for finding this obscure and difficult-to-find bug, and we thank them for their diligent efforts.  For those who don't intend to run Cisco's contrived tests, this software upgrade is purely optional and not required.

In an attempt to legitimize their contrived test, Cisco has "commissioned" Miercom to document this obscure Riverbed bug.  The Miercom document (document number 090815B) can be accessed here:

For anyone who has any illusions that Miercom's reports are objective in any way, you may also want to consider other Miercom reports that favor other WAN optimization solutions:

Citrix WANScaler:

Silver Peak:

Blue Coat (formerly Packeteer):

With all of the above reports from Miercom each recommending a different vendor, how is one to determine which is truly the vendor that they recommend for WAN optimization?  Rather, it appears that Miercom recommends any vendor that has recently paid them a "commission." 

At Riverbed, we're flattered by all the attention Cisco is devoting to their chief competitor in WAN optimization.  And we appreciate the help they are giving us in finding bugs to improve the Steelhead solution. But on the other hand I'm sure Cisco's existing WAAS customers might be somewhat dismayed by all of the resources that Cisco is placing into their competition's product.  Why is Cisco spending their precious QA resources testing and identifying bugs in their competitor's product, when their own customers suffer and struggle with the poor software quality that afflicts WAAS? And why is Cisco focusing on finding obscure bugs in simulated WANs when their own WAAS customers are suffering from WAAS bugs and that happen in real WAN environments? 

Click on the following link to view Riverbed's full response to Cisco's paid-for Miercom report:

>>Download Riverbed response to Miercom report 090815B<<


Posted in Uncategorized | 6 Comments »

10 Key Questions that Blue Coat doesn’t want you to ask them

Posted by riverbedtest on September 9, 2009

In any emerging market there are vendors who are technology innovators, and there are incumbent vendors in neighboring spaces who attempt to claim leadership in the emerging area through innovative marketing.  WAN optimization is no exception to this observation.  While it is easy to update web sites and data sheets with the "correct" marketing message, and to add superficial features that mimic a competitor's product, it is far harder to build a truly innovative product that creates value for customers.

Although Blue Coat has a 10+ year history focused on web caching and web security, they have recently made aggressive claims regarding market leadership in WAN optimization.  To validate these claims of leadership, I have listed 10 key questions that are important for any Blue Coat customer to explore:

10)  How can Blue Coat scale WAN optimization deployments if their ProxySG product uses a per-peer data store architecture for the Byte Cache?  In an earlier blog, I discussed this important issue that affects both Blue Coat and Cisco WAAS:

9)  If the write-back setting for CIFS acceleration involves data integrity risks, then why would Blue Coat enable this feature by default?  Page 70 of Volume 2 in the Blue Coat SGOS 5.4 manual warns that data loss can occur if the WAN experiences a disconnect while using Blue Coat's CIFS write-back feature.  Personally, I would think that risk of data loss is serious-enough of a consequence that this write-back feature should be disabled by default.  Note that unlike Blue Coat, the Riverbed Steelhead does not use a cache architecture, and therefore does not add any new risk of data loss or corruption for CIFS acceleration.  This is certainly proven out by the thousands of Riverbed customers who are actively using the Steelhead solution in its default configuration for CIFS acceleration.

8)  How many Blue Coat customers are using ProxySG for WAN optimization of non-web traffic?  This is a question that Blue Coat has steadfastly refused to answer, as if they didn't know (and what market leader wouldn't know what their products are being used for?).  But in a 2 June 2009 teleconference, Blue Coat CEO Brian Nesmith gave a clue by stating, "In [pure] WAN optimization, we win deals based on our ability to accelerate two key application areas — secure web applications and video streaming."  Associating web applications with WAN optimization is a clever word-play, because it allows Blue Coat to claim leadership in WAN optimization on the basis of legacy web caching features and capabilities that they have offered since the 1990's.

7)  Why is there so little discussion about WAN optimization on Blue Coat's community forums?  If Blue Coat is truly the leader in WAN optimization, then I would expect their customers to be actively discussing WAN optimization topics in Blue Coat's community forums.  This is certainly the case with Riverbed's community forums (, and you also see some discussion about WAAS and WAN optimization in Cisco's NetPro forums.  But in the case of Blue Coat's community forums (, the discussion seems exclusively focused on web security topics such as how to filter You Tube.  There is almost no discussion at all about WAN optimization (or at least how the general market would define WAN optimization).

6)  How does Blue Coat's dual Object Cache/Byte Cache architecture affect ProxySG's ability to scale throughput and performance?  Most computer systems bottleneck performance on disk I/O, unless you're talking about an embedded disk-less system.  After all, disk seek/read/write times are much slower than RAM memory access times, and I would think the same to be true for Blue Coat's caching systems.  But the difference with Blue Coat compared to Riverbed is that ProxySG must read and write cached data on disk twice–once in the Object Cache, and again in the Byte Cache.  Having to read and write the same data to disk two times should raise throughput/performance scalability concerns.  In contrast, with Riverbed data is only represented once on disk, in the byte-level SDR data store.

5)  Why is Blue Coat's user manual 3000 pages long?  Does this indicate that the product is difficult to use?  Ease-of-use and simplicity are key elements of a solution that can be deployed and maintained in large networks.  A complex product breeds more complexity and frustration.

4)  Why would Blue Coat as a "security" vendor offer a product lacking disk encryption for persistent disk data?  Any vendor with substantional deployments in WAN optimization would know that customers will be using them in all types of office locations, including small branch offices which may lack adequate security over weekends and evenings.  An intruder can easily steal the disk drives of the ProxySG device, which store in cleartext passwords, security certificates, credit card numbers and any other data that users send over supposedly-secure SSL connections.

3)  When will Blue Coat deliver a one-box solution for WAN optimization/web security/QoS/traffic monitoring?  This was the original promise of Blue Coat's acquisition of Packeteer, but it appears the long-awaited integrated one-product solution will not happen at all.  In contrast, Riverbed's RSP provides the framework to deliver WAN optimization, web security, QoS enforcement, and traffic monitoring capabilities, all in a single Steelhead appliance.

2)  Why are PacketShaper revenues declining?  According to SEC documents, historic PacketShaper product revenues (not including support or services revenue) from before their acquisition by Blue Coat exceeded $25M per quarter over several quarters in 2006 and 2007.  But Blue Coat's most recent PacketShaper quarterly product revenues amounted to only $15M.  It appears PacketShaper is losing significant revenue.

1)  Can Blue Coat scale WAN optimization for non-Web traffic?  As noted in question 8 above, it seems Blue Coat is largely claiming leadership in WAN optimization based on their legacy ability to cache web traffic.  And I have no doubt that Blue Coat can deploy web caches and proxies to 100's of sites.  But my question is can Blue Coat's WAN optimization features for CIFS and Exchange be scaled for full deployment in large networks?  There is no evidence to support that they can.  Rather, the evidence indicates that when you exclude web cache deployments, most Blue Coat WAN optimization deployments are quite small–three to nine boxes according to Blue Coat CEO Brian Nesmith in a 25 Aug 2009 teleconference.

Posted in Uncategorized | Leave a Comment »

Technology company boosts 3G performance to 5G speeds

Posted by bobegilbert on September 1, 2009

As is the case with millions of remote workers, I rely on my 3G network card for network connectivity when I travel with my laptop away from the office.  I would probably be considered by many as an extreme road warrior as I spend up to 50% or more of my time traveling to customer locations, marketing events, and speaking opportunities throughout the US and around the globe.  My 3G connection is my lifeline when I am away of the office and need to access my email, need to work from my company's corporate intranet, or when I need to grab the latest office documents or creative assets from one of the central file servers.  While 3G provides the remote connectivity I need, there is one little problem…

Read the rest of this entry »

Posted in Uncategorized | Tagged: | 7 Comments »