Is SD-WAN Simply WAN Optimization Evolved? Not Exactly.


Software defined WAN has efficient use of disparate links as a core value proposition. Build a hybrid WAN — some combination of public and private links — and abstract the physical links themselves, most likely in an overlay. Then let software decide which link to use for a given application at a given point in time based on policy, SLA, and real-time measurements.

In that context, let’s ponder the WAN optimization value proposition. WAN op’s goal is to make the most efficient use of a given link using techniques like TCP optimization, de-duplication, and compression. In other words, WAN optimization wants to make the greatest use of available bandwidth. No bits should cross the slow, (and probably expensive) WAN link needlessly, while still communicating the essence of a payload.

Therefore, SD-WAN and WAN optimization have related, but somewhat different, goals. I raise the comparison because some analysts have lumped SD-WAN into the WAN optimization bucket. However, I believe that’s a coarse lumping. Consumers evaluating SD-WAN shouldn’t think of it as a WAN optimization replacement, at least not exactly — I’ll explain as we proceed. These are different technologies, although it might be fair to think of SD-WAN as the successor to WAN optimization. SD-WAN and WAN optimization are compatible technologies, but not interdependent technologies.

Does WAN optimization have a future?

WAN op’s future is tied directly to the nature of the data traversing our networks. Data will increasingly be encrypted. Think HTTP/2 — while encryption is not required per the HTTP working group, it seems likely that the majority of HTTP/2 traffic will be encrypted. Plus, many application data streams have moved or will move towards HTTP. Encryption is anathema to WAN optimization, but we’re likely to see it more and more.

Encrypted payloads are difficult to optimize. The bit sequences are hard to de-duplicate or compress. Yes, it’s possible to stick a WAN op appliance in the middle of an encrypted conversation and, with the right certificates, decrypt, optimize, and re-encrypt an encrypted data stream. But how many apps are still served in-house? And how many of those apps have turned to SaaS?

The challenges of optimizing encrypted data streams aside, how many custom application proxies found in many WAN optimization engines are still critical for end users? Over time, many apps have moved over to HTTP for at least the client/server communication protocol. As more and more formerly custom apps migrate to HTTP, WAN optimization’s value will continue to diminish to the market as a whole. I see WAN optimization of specific applications using custom proxies becoming less and less interesting to the market over time. The need just won’t be there.

That leaves TCP optimization as WAN optimization’s remaining clever trick, but I have noticed that generic TCP optimization is popping up in all sorts of software, and not just in WAN optimization appliances. No one’s buying a WAN optimization infrastructure just to get TCP optimizations. Depending on what other products are being investigated, TCP optimization might be built right in.

The question now is whether or not WAN optimization is a compelling technology in the long run. Yes, WAN optimization adds value today. The more an organization houses its own applications, the more valuable it is. But that technology can function independently of any SD-WAN technology an organization might consider. They are not interdependent.

Considerations for WAN optimization owners evaluating SD-WAN products.

  1. Does the SD-WAN solution being considered measure link quality (jitter, latency, loss, etc.) generally or in the context of specific applications? Imagine an SD-WAN appliance, followed serially by a WAN optimization appliance, followed by the WAN. The SD-WAN application should be measuring how well a link delivers a specific application — not how well it delivers contextless packets. Why? A specific application could be impacted by the WAN optimization appliance. If the SD-WAN is measuring link quality without application context, then the measurement is naive. This is a good scenario to whiteboard when doing an SD-WAN POC with a vendor.
  2. Some SD-WAN vendors include WAN optimization capability in their product, or at least WAN optimization capabilities as part of the suite. For example, Cisco IWAN can leverage WAAS, although WAAS is not tightly integrated with IWAN. IWAN is not a single product as such. WAAS is a specific technology, and IWAN is a collection of several technologies bundled under the IWAN name. On the other hand, Silver Peak Unity can be licensed to include WAN optimization for those customers that need it as “Boost.” That’s a tighter integration.
  3. A driver diminishing the usefulness of WAN optimization is cost. SD-WAN promises to make hybrid WAN easy. Buy lots of cheap broadband. Layer on the overlay. Control with a central policy. “Cheap broadband” are the words to pay closest attention to. What does WAN optimization’s ROI look like if the bandwidth constraint can be solved more easily with a bigger pipe that comes cheap? All of a sudden, it has become harder (not impossible, but harder) to justify the cost of WAN optimization capex, opex, and operational complexity. For some, it could be that SD-WAN coupled with a radically re-architected WAN means that specific WAN optimization infrastructure is no longer important and can be retired.

Parting points.

WAN optimization will become a point solution over time, solving specific problems for specific customers. Customers can have SD-WAN without WAN optimization, and many will. Existing WAN optimization customers will evaluate the remaining value of their WAN optimization infrastructure by monitoring application performance reports. That data will help determine their new WAN architecture going forward. I think the likely choices are between SD-WAN alone and SD-WAN with WAN optimization.

Re-architecting the enterprise WAN today is a forward-looking business. There are two aspects to consider. One is the data that will be traversing the WAN — assume more encryption, more SaaS. The other is the budget that will be available going forward — this will vary by company, but I would assume that saving money on WAN will be an expectation of the executive suite in upcoming cycles. There’s been too much press on hybrid WAN and SD-WAN to have been missed by CIOs paying attention. The ROI messaging (accurate or not) is too strong to be ignored.


  • Great read. For the folks I talk to, I’ve been explaining SD WAN as the evolutionary (not revolutionary) step of both WAN op and Hybrid WAN, repackaged and delivered as a single solution. You can have both, but you can also have one, or the other. This sounds in-line with your post, but would love your feedback if this messaging requires adjustment.

    Specifically, there have been some who are still only interested in WAN op (because they lack multiple links at their site, but need to make efficient use of their MPLS link. Others that are only interested in Hybrid WAN features because they *only* use broadband and aren’t as concerned traffic reduction over the expensive links.

    What seems to be the most attractive feature about SD WAN over traditional WAN op / Hybrid WAN point solutions is the OPEX-only monthly pricing model that the newer vendors are offering. No hardware therefore no CAPEX spend. Just a software forwarder and cloud controller with a monthly subscription. As neat as the techno-wizardry behind SD WAN can be, sometimes financial engineering beats network engineering.

By Ethan Banks

Ethan Banks is a podcaster and writer with a BSCS and 20+ years in enterprise IT. He's operated data centers with a special focus on infrastructure — especially networking. He's been a CNE, MCSE, CEH, CCNA, CCNP, CCSP, and CCIE R&S #20655. He's the co-founder of Packet Pushers Interactive, LLC where he creates content for humans in the hot aisle.