What WAN Optimizers Can Learn From Firewalls

Listening to the give and take about WAN optimizers made me remember another battle between networking giants. It was nearly 10 years ago, during the early days of firewalls, when it seemed Marcus Ranum, then with Network FlightRecorder, would go head-to-head with Check Point's Gil Schwed on a weekly basis. Ranum was among the early creators of the application proxy and was vociferous about the value of delivering a firewall that terminated and inspected every session before passing the contents onto the destination. It was very effective, very secure and yet ultimately eclipsed by competing approaches.

You see, organizations abhorred the complexity that was implicit in proxy-based firewalls. A separate firewall for every application was untenable for most, so when Check Point came onto the scene with a combination of a simple-to-use GUI and its stateful packet inspection technology, it quickly became a market leader. Yes, it may not have offered the same level of protection against application layer threats available in proxy-based firewalls, but the technology's ease of use and broad applicability appealed to customers.

Proxy-based firewalls continued to have a positive effect on the market, though. They underscored the security limitations of stateful packet inspection and, I believe, pushed Check Point to address the solution with deep packet Inspection technology. Yet it was the ability to address the breadth of applications simply that was the admission card for firewalls to enter the mass market.

I think there's a similar battle going on right now in the WAN optimization space. For the longest time, the WAN optimization market has been led by Riverbed, which is focused on optimizing and improving the performance of TCP-based protocols with application layer optimizations--namely, Microsoft SharePoint, SAP, Lotus Notes, FTP and others.

Increasingly, Riverbed is being challenged by innovative up and comers, including Blue Coat, NetEx and Silver Peak. At the same time, the market is shifting. While at one time branch offices might have benefited from Riverbed's all-in-one solution for branch office connectivity, increasingly there's a compelling argument to be made for placing a virtual machine host in the branch as a platform for virtual appliances that would be needed by the branch--such as WAN optimization, firewalls and anti-virus. Riverbed has even moved in this direction to some extent.There's also a growing need to provide broad application support, not simply a few specific TCP applications. Forget about in-house applications for a moment. Real-time applications are increasingly important to organizations, and these generally run over RDP/UDP, not TCP. So all of that corporate voice traffic, those telepresence streams, the videoconferencing streams, not to mention other applications, like VDI and desktop sharing, are all going to run over UDP, and none will be improved by your WAN optimizer.

Now optimizing a VoIP application is vastly different than not optimizing a CIFS application, for example. You can't play with TCP windowing (well, there is no TCP windowing to play with), but there is a lot you can do. You can dedupe the voice or video on streaming media, and eliminate things like silence suppression that are often used on live VoIP lines. Sadly, we cannot make ponderous windbags talk faster. You can prioritize voice and video to give it preference over applications on the line. You can also maintain packet ordering to prevent jitter from downgrading voice quality. Practically, it means that enterprises can get a better sounding voice system by using a wideband codec, like G.722, between sites instead of a narrowband CODEC, like G.711 or G.726, as well as a voice service that's more resilient to changes in WAN infrastructure.

I think enterprises will prefer a WAN optimizer that can improve the functionality of all applications--transparently. At the same time, as proxy-based firewalls have proven, vendors that ignore application-specific optimizations will be pressed to explain their case. If they're unable to show how they deliver the same level of performance to application-specific optimizations, they too will aim to improve the performance of applications at higher layers. But how this will be done is anyone's guess. If DPI serves as an example, a generalized engine for tweaking application performance of any TCP/UDP application would be my bet.