Skip Links

Network World

Peter and Rebecca

Time for Interoperability among WAN Optimization Vendors

By Sevcik and Wetzel on Mon, 06/01/09 - 10:09am.

Here's the problem. A user behind a Riverbed Steelhead can't communicate with a server behind a Cisco WAAS.  This is nuts!  The Application Delivery System (ADS--aka WAN optimization) market is mature enough to fix this.  The time has come to standardize how ADS technology works so enterprises can build multivendor solutions.  We have done this with every other network technology.  Why should ADS technology be different?

Think about it from a practical standpoint.  If your company acquires another company and both companies use different vendor's routers, you can interconnect both networks at the IP layer. With modest address management, all users can communicate from anywhere to anywhere.  You can then choose to keep two router vendors, or migrate to a single vendor over time. 

But if the merged companies use ADS technology from two different vendors, you can't interconnect the two worlds AT ALL!  Dual-ended (symmetrical) ADS solutions are completely proprietary, and how they work is a big trade secret shrouded in marketing mumbo jumbo. 

ADS solutions are very effective and clearly needed.  But if all traffic from a remote site is treated by one vendor's ADS box that colors it say, "blue," and the other vendor's solution colors all its traffic "red," you must never let blue and red mix.  Even though you can mix the traffic streams in the routers, you can't mix them now--period.  This makes integrating the two networks a long protracted complex ordeal.

This incompatibility also applies to other situations such as when you need to connect with business partners or transition from a legacy ADS vendor to a newly selected vendor.  We predict that this will become a big headache for the ADS industry, and will limit market growth.  

Peter called publicly for an interoperability standard in an article back in September 2006. This new standard can be simple and build on successful precedents.  We think it is a form of session protocol, which has the two ADS machines negotiate what they support and how they choose to handle the traffic between them.  It starts with a clear definition of ADS functions, and each box can say "I do that" or "I don't do that."  Features not supported by both devices will not be turned on.  Features that are supported can be negotiated as appropriate. 

Many of the features used by ADS vendors are in fact common and sometimes exactly the same--like using GZIP for dynamic TCP content compression.  Vendors that want to keep a particular feature secret can put it on the list of features that no other vendor box can support.  But in such a case, at least two companies with products from the same vendor can communicate.  This is not rocket science--it is a matter of market will.

The economic downturn, the need for enterprises to be more flexible, and plain old common sense, will force vendors' hands.  We call on the vendors to voluntarily lead the charge and address this issue responsibly, rather than stonewall.

About App Performance View
NetForecast is an internationally recognized engineering consulting company that benchmarks, analyzes, and improves the performance of networked data, voice, and video applications.
 

Most Discussed Posts