The Key Components of WDS

While numerous enterprises have begun deploying WDS solutions, the technology is relatively new.  Many in the IT community are still struggling to understand how WDS technology works.  Compared to say, routers and switches, and other mainstream solutions where technical expertise is readily available, there is a general lack of experts knowledgeable about how WDS solutions work.  Tragically, this has created an environment where seemingly all-knowing charlatans can spout their so-called wisdom to serve their own purposes.

This happens often, and one of our smaller competitors continues to blast out lengthly and technical-sounding emails, proclaiming that their WAN optimization products are somehow different from Riverbed's and the other vendors in this space.  These emails claim that their "Data-Centric" approach to WAN optimization is somehow superior to the "Application-Centric" approach used by Riverbed and other vendors.   I understand the desire by some vendors to disparage their competitor's products, but it is disappointing when the supposedly educational material is simply false and incorrect.  It is even worse when the false information attempts to validate itself through use of technical scientific-sounding terminology.  For that reason, I thought I would summarize the key technical components of WDS solutions here:

There are three separate and distinct performance bottlenecks that hinder data transfer performance over the WAN:  1) WAN bandwidth constraints, 2) the transport-level protocol chattiness issues associated with TCP, and 3) application-specific protocol chattiness issues.  Depending on the network environment, one or more of these issues is the cause of the poor performance that exists in your network when you attempt to download files and other data over the WAN.

To address all three performance bottlenecks, the WDS solution needs multiple tools.  In order to address the first issue dealing with WAN bandwidth constraints, the WDS solution must have a "Data-Centric" component that compresses and eliminates redundant byte-level data from the network.  Furthermore, in order to address application-specific protocol chattiness issues, the WDS solution must have an "Application-Centric" component that understands the application protocol, and can remove the chattiness that is specific to that application. 

So in fact, it isn't a question of being "Application-Centric" versus "Data-Centric"--rather, you must have both. In order to address the inefficient chatty protocol behavior that many applications use to access their data, you must have an "Application-Centric" component of the WDS solution.  In order to deal effectively with bandwidth constraints by eliminating redundant byte-level data, you must have a "Data-Centric" component to the WDS solution.  A solution that addresses one issue but not the other is an incomplete solution that will fail to address each of the performance issues experienced in the WAN. Finally and just as important, the WDS solution needs a third component--which is transport optimization--in order to deal with addressing the transport-level protocol chattiness issues associated with TCP.

So why did the startup company attempt to position themselves as a "Data-Centric" solution?  It is because they lack the application-specific optimization component, which is by far the most difficult component to engineer in a WDS solution.  It is very easy to perform TCP spoofing tricks to speed up TCP connections, in order to deal with the transport-layer issues.  It is also relatively-easy to implement basic data deduplication technology in order to compress and eliminate redundant bytes.  However, it is very difficult to engineer the capabilities needed to address application-specific protocol chattiness issues, because there are so many applications found in different enterprise environments, and each application behaves differently.  It takes a significant number of engineers and development resources--resources that our small competitor doesn't have--to engineer a product that understands the many applications in use at most enterprises.  These include applications such as CIFS, MAPI, MAPI2003, MAPI2007, NFS, Oracle 11i, HTTP/web, SSL, etc.  And in contrast to their claims, you can't simply ignore WAN latency and application-specific chattiness issues if you want to solve WAN performance problems.