SD-WAN’s Value Prop Conundrum

897 Words. Plan about 4 minute(s) to read this.

As it happens, software defined WAN is a hot technology right now. If you’ve been following Packet Pushers, you’ve perhaps noticed SD-WAN vendors sponsoring the show, as well as Greg and I talking about SD-WAN technology in general. This makes sense, because the space has suddenly become crowded, with two startups in particular coming out of stealth and making lots of noise — Viptela and CloudGenix.

With all the startup noise, the SD-WAN vendors that have been around (Talari, VeloCloud, plus Silver Peak charging up quickly) have been making noise as well, not wanting to miss out on whatever attention the market (you) might be giving to SD-WAN ideas. One challenge these vendors seem to be running into is a misunderstanding about value proposition. What is the specific value that SD-WAN solutions bring to networking?

The Conundrum

My interpretation of the SD-WAN value prop can be boiled down to cost savings, simplified operations, and improved application performance over inconsistently performing WAN links. Here’s the conundrum. An engineer might instinctively recoil at this sort of value proposition, due to the following logic — an appropriately cynical logic that is the result of years of industry experience.

  • A solution you have to spend money on doesn’t save money, and commercial SD-WAN solutions ain’t free.
  • Additional layers of technology tend to increase complexity, not simplicity.
  • Private WANs generally perform consistently, while the Internet is unreliable for critical traffic.

This is the battle SD-WAN vendors are facing as they get their message out. That said, I think the concerns are easy to address.

  • Cost savings (ROI) come when SD-WAN is used to make an Internet connection viable as a private transport. In many cases, Internet links are far cheaper for more bandwidth than leasing private infrastructure — MPLS — from large carriers.
  • Simplicity comes in making it easier to manage hybrid WAN architectures. Instead of several different WAN domains to deal with, an SD-WAN overlay abstracts those domains away. Yes, there’s still an underlay to be managed, but all that must be worried about is connectivity, and not also traffic management. The SD-WAN solution handles sending traffic across the hybrid WAN.
  • Improvements over time and rapid Internet growth has led to reliable public infrastructure.
    • The Internet isn’t entirely rubbish for important traffic (Skype / Vonage / B2B VPN / E-Commerce).
    • Conversely, private WAN is not 100% reliable transport. In practically all networks I’ve worked on, the private WAN had regular (perhaps not frequent, but regular) outages or performance problems requiring carrier intervention to resolve.

Yeah, But…

Now, the engineers reading my points above are rightly complaining that Internet is cheap and fat, but there are no guarantees of service — and SD-WAN can’t fix that. There’s also grumbling about having to still maintain the WAN underlay that the SD-WAN overlay requires. Both true. But if we look at SD-WAN more deeply, we find that the whole “software defined” part of SD-WAN means that there’s real-time intelligence monitoring link quality on a variety of parameters, such as utilization, jitter, latency, and loss.

Carefully measured link quality is used by SD-WAN solutions as a complex metric. The SD-WAN system looks at user-defined policy (how different traffic classes are to be treated), compares that policy with the link quality metric, and forwards traffic across appropriate links. Policy is used to describe the required network characteristics for different applications, and the software defines the network to best fit that policy. Put another way, software constantly analyzes the WAN, and then defines the WAN forwarding architecture based on the changing WAN environment in accordance with the business policy. For example, a badly performing link seeing 10% 3% loss and excessive jitter would be useless for voice traffic, but might be passable for a large file transfer.

What links an SD-WAN is actually using to forward traffic will frequently change, just depending on how individual links in the WAN are performing. There is no routing protocol that offers this level of granular flexibility. Routing protocols are used to find best path based on simple cost metrics or preferential weighting, and have no sensitivity to frequently changing link attributes like load, jitter, and delay.

More On SD-WAN

Now, let’s not kid ourselves here — there’s no such thing as a free lunch. Business will have to do some homework for the SD-WAN cost model to make sense. However, the benefits make sense to me, at least well enough to feel that SD-WAN warrants exploration as a real-world software defined network application. And besides, the core benefits I’ve discussed here leave out other key SD-WAN features. There are also security benefits, integration with public cloud, as well as application analytics that make SD-WAN even more interesting.

Greg Ferro and I will be moderating a discussion about SD-WAN in an ONUG after hours session on May 13, 2015. The format is food and a live podcast with network architects from some substantial networks. If you’re in town for ONUG or just in the NYC area, join us to see us record a show and have a Packet Pushers style discussion on SD-WAN. The event is hosted by Viptela, one of the startups I mentioned at the top of the piece, and the venue is limited, so you need to register. Greg and I enjoy networking in meatspace, so we hope to see you there. Just think…you’ll be able to tell us we’re wrong in person! ;-)


Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks


  1. Joel Halpern

    Your example of a link with 10% loss being used for large transfer actually demonstrates the problem, not the solution. TCP simply will not function over a link with 10% loss rates. It will slow to a crawl if it makes progress at all.
    So the question for the argument you are making seems to become whether there is a region of behavior of the WAN where intelligent traffic selection will actually help, and whether those conditions will arise often enough to matter.

    1. Post
      Ethan Banks

      Joel, I get your point, but you’re being a little pedantic. Considering what you do for a living, you’re entitled. ;-) I pulled 10% as a value at random to illustrate a larger point, as opposed to actually calculating the impact of that level of loss on TCP. A smaller percentage would have been better, and I should change that.

      “So the question for the argument you are making seems to become whether there is a region of behavior of the WAN where intelligent traffic selection will actually help, and whether those conditions will arise often enough to matter.”

      Yes. Exactly true, and I think that will be part of the SD-WAN conversation going.

  2. Mike Gonnason

    I think SD-WAN has the potential to save me a lot of time and headache, primarily in replacing the IPSEC backup and making it an active path that can be utilized instead of just for failover.

Comments are closed.