Feb 18, 2015
Riverbed and Silver Peak don’t usually agree when it comes to matters of WAN optimization scalability and for good reason. We’ve offered it; Riverbed hasn’t. But now in a recent blog, Riverbed has decided to tell us why its products don’t scale. Apparently, it’s because they’re like lattes. Let me explain.
There’s been this misconception amongst enterprise customers that the scalability of a WAN optimization appliance is determined by the amount of optimized WAN bandwidth. While that’s true to an extent, customers of competing acceleration appliances often find that their appliances need to be upgraded BEFORE reaching the maximum WAN bandwidth. The users generate so many concurrent flows that they exceed the capacity of the WAN optimization appliance, even though the amount of data transferred across the WAN only consumes a fraction of the available bandwidth. Silver Peak has discussed this point for years, which is why our appliances optimize an extremely high number of concurrent IP flows.
“The key parameters to selecting the right [Riverbed] model will generally be the number of outbound optimized connections and the optimized throughput,” writes Paul Griffiths, global consulting engineer and team lead for Europe, Middle East, and Africa (EMEA) and the Asia Pacific and Japan (APJ). (Connections and flows in this context are interchangeable.)
And there’s the rub, because Riverbed appliances — particularly at the low-end — are incredibly limited in their concurrent connection support. A 10 Mbps appliance from Riverbed, for example, optimizes just 700 concurrent connections. By contrast, the Silver Peak’s 10 Mbps appliance, the NX-2700, optimizes 64,000 flows for the same list price. (I’ve taken 10 Mbps at random, but a similar comparison can be made across the product lines.)
Of course, knowing the number of connections doesn’t tell us the number of concurrent users or applications that can be optimized, and that’s the point. Projecting the precise number of concurrent connections is critical when selecting a Riverbed appliance and near impossible. Griffith notes that 5-10 connections per user used to be average but, today it’s “…more likely that 10 connections per user are the starting point and possibly up to 15 connections in some cases.”Those averages are misleading, though. For one, the number of concurrent flows varies widely between users and frequently far exceeds 15 connections. This user, for example, has more than 60 concurrent connections, which alone would exceed the capacity of some Riverbed appliances (see figure 1). What’s more, Griffiths’ concurrent connection estimates ignores the number of UDP flows that Riverbed claims to now optimize, which also count against capacity of the Riverbed appliance.
Users can get a more accurate count by analyzing their network flows. He references additional Riverbed products, or one can hire Riverbed Professional services. But why should IT have to spend more for equipment or services just to figure out the right-sized WAN optimization appliance?
Griffith would like to spin to the limited number of concurrent flows and the resulting product range as a way of delivering more choice to consumers. “It is very rare to find that one size fits all…,” he writes, “…That’s why you can order your ‘skinny latte frappe with chocolate sprinkles’ from the barista in one, of many different coffee cup sizes, to suit you,” he says.
But forcing organizations to choose the right product based on the number of connections or flows is more like asking you to select your latte based on the number of coffee granules needed to fill your cup. It’s impossible or at least very difficult.
A more intelligent approach is to purchase your WAN optimization appliance based on what you know — the amount of WAN bandwidth – and trust that the vendor can give you more than enough flow-capacity to utilize the full bandwidth no matter the number of users or applications. This way, you avoid numerous engineering headaches and no longer have to pay for upgrades as application usage and architectures evolve.