5 Reasons Why WAN Optimization Has Evolved Beyond Application Proxies

Understanding Application Proxies
An Application Proxy was a piece of software that was inserted into the middle of an application data stream (generally operating between layers 4 -7 of the OSI model) as a shim to “fix” a characteristic of the application that caused it to perform poorly over a WAN connection. These “fixes” tended to come in two varieties:

• Those that helped to allow for data deduplication of the application data; or
• Those that helped to reduce the total amount of communication (“chattiness”) required by two application endpoints over a WAN connection.

Application proxies (used by traditional WAN Optimization vendors like Riverbed) are old technology, and are becoming less frequently used in the WAN Optimization space today.

And here are the top 5 reasons for this transition:

1) Application proxies have a high propensity to “break” many of the applications they purport to help.

This is by far the biggest reason that WAN Optimization technology has largely moved away from the “Layer-7 Proxy” model.

An application proxy needs to be written to the exact specification of the application protocol. This is generally fine for stable, lower level protocols such as SSL, but it becomes a problem for higher level, more proprietary protocols like MS-SQL, or Citrix ICA. These protocols change frequently and the changes are not published.

As so often happens in the world of the Network Administrator, a server somewhere gets upgraded, and the first clue that an application protocol has changed comes when the user complaints begin pouring in about the application no longer functioning correctly.

Once the application proxy is identified as the cause of the breakage, the proxy needs upgraded to be compatible with the new application version. And because these protocols often have to be reverse engineered by the proxy provider, the “fix” for this breakage can be many months or longer (depending on whether it is considered “widely used”) before it is available.

This leaves the Network Administrator with only two choices: 1) Tell the server administrator that the network doesn’t support the new application version; or 2) Set the application proxies to ignore (by-pass) the new application, essentially rendering the application without any optimization.

2) A particular protocol just slowly stops being used.

An example of this type of transition can be seen occurring today with some proprietary encrypted protocols, like MAPI. MAPI is Microsoft’s proprietary Exchange Server email protocol, but with the evolution of more cloud-based and SaaS applications SSL is rapidly becoming the corporate protocol of choice for SOHO and mobile users. And since Microsoft also supports SSL for their Exchange email delivery, many companies are moving away from MAPI toward non-proprietary SSL. As applications evolve AWAY from proprietary protocols, these types of proxies become obsolete.

3) WAN Optimization technology has evolved to the point that a specific proxy is no longer required.

NFS is a good example. NFS v3, as a file sharing protocol, had certain limitations in throughput and end-user response time related to WAN latencies. This was primarily because of the way the protocol was designed, limiting the amount of data that could be transmitted at one time without receiving application responses.

At the same time, existing WAN Optimization technologies primarily focused on data deduplication as a method of reducing total data needing to be sent back and forth over the WAN, and thereby removing congestion in order to improve response time. But these older WAN Optimization technologies used a form of block level deduplication that did not work very well on NFS traffic, because in order to match a data block, it helps to know where the data portion of a transmission begins. The location of the data portion within an NFS protocol transmission can vary.

The best solution at the time in order to “fix” the NFS WAN problem was to write an application proxy, which would artificially decrease the amount of communication required by the protocol and also figure out where the data portion of the NFS transmission was so that the block-level deduplication could be effective.

Traditional WAN Optimization vendors still require a shim for NFS optimization, because they are still using the older deduplication technology, but newer vendors can optimize NFS traffic without the need for an application specific proxy, and minimal proxy optimization means fewer things to break in your network!

4) Some applications or protocols that did not work well over a WAN connection 10 years ago have evolved or been re-designed so that they can work over a WAN without an intermediary shim.

Again, let’s look at NFS. Fast forward to today – the later versions of NFS v4.x fixed most of the protocol limitations related to chattiness and throughput. The remaining limits are resolved by generic TCP optimization, without the need for an application specific shim.

5) An “Application Proxy” technology architecture is not a sustainable model from a business and development perspective.

First, it is very expensive to maintain. New specific optimization mechanisms must be developed for the application proxy every time new versions of applications or their updates are released by the application vendors.

Take Citrix ICA for example – they own the protocol and are able to make changes to the protocol spec at any time; from release to release, or even within a service pack update. Keeping track of all of these application proxies, and continuing to support deprecated protocols is not a very efficient business model.

It also limits future scalability. The very nature of a proxy is to act on behalf of the remote server. In order to do this, the proxy must terminate and track each application session. This creates a very high overhead in terms of hardware requirements, resulting in the need for bigger and bigger boxes.

Fortunately, the problems once solved by application level proxies are now solved in more efficient manners, rendering some of the original benefits of the old proxy technology obsolete. There are still a few application layer protocols, like older versions of CIFS or SMB, which benefit from having a specific proxy for optimization over the WAN, but that list is constantly growing shorter. By reducing the dependence on specific application layer proxies, today’s technology can provide better optimization while improving reliability and removing potential points of failure.