Who has the fastest CIFS acceleration? Who compresses TCP traffic best? Customers are sometimes surprised that I am relatively uninterested in these questions. But the reality is that these are not (usually) meaningful differentiators between WAN optimization products. Both CIFS acceleration and generic TCP deduplication are areas that are relatively mature, with multiple independent implementations. When customers report comparisons between competitors for these areas, the differences are typically small. While Riverbed (or some other vendor) may be able to demonstrate advantages on particular workloads, that advantage is unlikely to be large and is unlikely to apply consistently across other workloads.
So does this mean that WAN optimization is a commodity? Not at all. The largest differences appear when we look at the set of protocol-specific optimizations available and when we consider the scale and scope supported by the system. For the rest of this post, I’ll focus on how to think about protocol-specific optimizations.
Protocol-specific optimizations are particularly valuable for encrypted protocols, chatty protocols, and multiplexed protocols. In all of these cases, you can see large differences between a system that understands the protocol and one that doesn’t.
An encrypted protocol isn’t helped (much) by generic TCP compression because even when the underlying (cleartext) traffic is highly repetitive and compressible, the encrypted stream looks random and non-repeating. To get good compression, a WAN optimization system has to be able to undo the encryption, transform the cleartext, and re-encrypt the transformed traffic. Handling this transformation well requires a number of facilities beyond the protocol-handling itself: there need to be provisions made for handling keys securely, and there needs to be some protection of the decrypted traffic – typically this involves having a separate form of encryption on the data store used to hold the vocabulary, so that an attacker can’t actually learn anything of interest from stealing an appliance or its disks.
Common encrypted protocols supported by Riverbed include SSL, encrypted MAPI, encrypted Lotus Notes, and encrypted Citrix ICA (which is actually 5 combinations of encryption scheme and transport). No other vendor supports all of these. Sometimes competitors get creative in trying to hide their weakness: for example, we have encountered situations in which a requirement for “encrypted MAPI” was addressed by claiming that simply meant using SSL as a transport – not true.
A chatty protocol isn’t helped (much) by generic TCP compression because the performance is often limited by the frequency of message exchanges between the two ends. CIFS is the most common example of a chatty protocol, and for some products CIFS is the only chatty protocol they can improve.
Common chatty protocols optimized by Riverbed include unencrypted MAPI, Citrix CDM, signed CIFS, and SMB2 (signed or unsigned). No other vendor supports all of these. It’s also worth mentioning that only Riverbed optimizes Outlook Anywhere, which is often misunderstood as MAPI over SSL. In fact, other vendors have been known to imply that their support for MAPI and support for SSL simply combine to provide optimization of Outlook Anywhere – not true. (That MAPI over SSL combination seems to be versatile as a substitute!)
A multiplexed protocol has an internal structure consisting of more-optimizable and less-optimizable parts. Generic TCP compression works OK on a multiplexed protocol, but a protocol-aware mechanism works better because it can focus resources where they are most useful. Even apart from efficiency considerations, understanding multiplexed protocols means that it’s possible to use more sophisticated control and reporting than is possible when simply viewing the traffic as data carried by TCP.
Common multiplexed protocols supported by Riverbed include Citrix ICA, EMC SRDF/A, and FCIP. Riverbed can “optimize around” parts of these protocols. In addition, for ICA and SRDF/A, Riverbed can set policy for elements internal to these protocols (virtual channels or replication groups) that are not even visible to most other vendors.
When we look at the top five WAN optimization vendors by market share, it turns out that most of us agree on this approach: Riverbed, Cisco, Citrix, Blue Coat all have a variety of protocol-specific optimizations and collectively represented about 82% of the market in Q1 2012. We might differ in our assessment of who’s ahead or which optimizations are most important, but we are all operating with a similar view about the merits of protocol-specific optimization... and the players who are behind are trying to catch up.
The one conspicuous dissent comes from Silver Peak (slightly less than 8% share), which supports only CIFS and SSL. And Silver Peak’s SSL optimization is itself strikingly weak: it’s not the sophisticated split-proxy approach introduced by Riverbed (with variants subsequently offered by other vendors). The Silver Peak version is a simple-minded brute-force approach with server keys installed on both ends, which means it might be workable for a datacenter-to-datacenter deployment but will likely be judged insecure for any kind of branch/remote office scenario.
Strangely, Silver Peak is not only further behind but actually argues against the merits of protocol-specific optimization. They clearly recognize the problems posed by encrypted protocols and chatty protocols, thus their features for CIFS and SSL. But their competitive material focuses on ideas of “future-proofing” your optimization and having “optimization at the network layer.” As a matter of marketing, I can understand the need to put the best possible spin on a poor situation – they are a small company competing with much larger organizations, and admitting that they are far behind on optimization technology could be discouraging to potential buyers. But it requires a remarkably flexible attitude to simultaneously deliver features performing protocol-specific optimization for CIFS and SSL and argue that protocol-specific optimization is a bad idea.
Now, to be generous to Silver Peak (and to our other major competitors... who aren't quite as far behind), we can acknowledge that being best in this dimension isn't the only issue in WAN optimization. But it is an important one, and worth understanding.
We're also happy to compete in other dimensions, like scale and scope. We are in the fortunate situation that our market leadership position and technology leadership position reinforce each other, so there are lots of ways in which we can identify capabilities and/or reference customers that others can't match. But sometimes it's enough to just dig into protocol-specific optimization to see the Riverbed advantage.