NETWORKING

  • 01/06/2016
    7:30 AM
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

The Top 4 SD-WAN Myths

Software-defined WAN is hot, but there are misconceptions about the technology. We cut through the hype.

Software-defined WAN has received a lot of buzz of late, for good reason: After all, its slogan is essentially “No more MPLS."  That's enough to catch most IT pros' attention. However, one should look beyond slogans to see what the technology can actually deliver.

I've spent a lot of time talking with different SD-WAN vendors to know more about the technology, their products and capabilities. I do see a lot of benefits of this technology, but at the same time I see a lot of marketing mixed with the technical stuff, promising the moon to customers.

This blog, therefore, aims to clear up some misconceptions and myths about SD-WAN.

But before we dig deeper, let's define what SD-WAN is. SD-WAN makes it possible to bond multiple WAN connections -- Internet, MPLS or any other transport pipe --  effectively making the best use of bandwidth and reducing dependency on expensive MPLS links. This is done by placing edge devices at customer sites that are managed centrally. Overlay tunnels are created on top of the available transport links. SD-WAN is transport agnostic, so it does not care about whether the transport is MPLS, broadband or a 4G connection.

There is a direct business case here: Use the Internet pipe to deliver what the MPLS pipe would otherwise deliver. Why purchase a big pipe for MPLS when one can buy a small pipe with a parallel Internet/ broadband (best effort) link? SD-WAN will put the critical, real-time data on the MPLS link and the rest on broadband, thereby reducing the need to have a big pipe of MPLS to carry both kinds of data..

Now let’s start discussing the myths.

Myth 1: SD-WAN will replace MPLS.

SD-WAN proponents often claim that the technology will replace MPLS and extremists go as far as saying that one should completely forget about MPLS. Nothing is further from the truth. As long as guaranteed QoS is needed, there will be a need for reliable transport. It can be MPLS or any other transport, but not SD-WAN with pure Internet links.

There's a big difference here. MPLS is a WAN technology where a user has full control over traffic engineering. SD-WAN, on the other hand, is an edge technology; all the intelligence in the SD-WAN lies in the edge. To an SD-WAN, the network is a cloud and a black box.

Therefore, an SD-WAN can make decisions based on measurements at the edge, but it has pretty much no control over what is in the cloud. Even SD-WAN vendors would tell you to keep an MPLS link in parallel to the broadband link to ensure QoS for real-time traffic like voice and video.

Truth: SD-WAN can reduce a company's dependency on MPLS, but cannot eliminate MPLS.

Myth 2: SD-WAN can guarantee QoS.

Actually, this is a misconception stemming from  successful marketing by SD-WAN vendors. The marketing says that SD-WAN can measure packet loss, jitter and latency and compensate them.

However, consider the following:

  • Compensating for packet loss may be easy by using technology such as forward error correction; this is what some vendors do.
  • Compensating for latency coming from distance (think about Internet links) is NOT possible for the same path, at least by physics.
  • Compensating for jitter may be possible by using buffers, but this would create delays and would destroy the QoS for real-time applications like voice and video rather than compensating it.

So then why myth 2 is so pervasive? Because the vendors mean something else when they mean QoS compensation. What they actually mean is that they can select the best path among the paths available, so if a connection has bad performance indicators like packet loss, jitter and delay, they will switch you to another path that has better performance indicators.

Truth: SD-WAN can detect and measure latency, packet loss and Jitter. It can compensate for packet loss but not for latency and jitter. It can switch you to the best paths among the paths available. If all paths are bad, it cannot guarantee you QoS.

Myth 3: The only benefit of SD-WAN compared to MPLS is cost.

It’s not only cost savings. SD-WAN can provide other things which MPLS cannot, or at least not easily. The management and orchestration of SD-WAN is what differentiates the technology from its competitors.

The plug-and-play concept of the edge device and the point-and-click provisioning of the services are tremendous advantages. Everything is centralized, GUI based and much easier to work when compared to MPLS. In fact, you don’t need to be an expert to run an SD-WAN and that is its biggest selling feature.

Truth: SD-WANs are not only cheaper but much easier to manage, operate and maintain.

Myth 4: SD-WAN is same as WAN optimization.

SD-WAN is more than just WAN optimization. WAN optimization is designed to reduce bandwidth consumption using a variety of techniques like compression, caching, and deduplication. The result is the effective use of the available limited WAN bandwidth.

WAN optimization is designed for TCP traffic that is not delay sensitive.. However, the indirect benefit of reducing TCP bandwidth is the creation of more room for VoIP traffic (delay sensitive), which may benefit the call quality.

SD-WAN deals with the delay sensitive and real-time traffic in a more direct way. It measures jitter, delay and packet loss at the end nodes and can seamlessly switch the traffic to the best path available among the bonded links.

We can say that WAN optimization and SD-WAN are complementary since they can be used together to provide the best treatment to all kind of data available. There are vendors that offer WAN optimization as one of the options in an SD-WAN product.

Truth: SD-WAN and WAN optimization are different; they can be used independently or combined together for optimum bandwidth utilization.

So in conclusion, SD-WAN is a good technology and holds great promise, but it should be looked from a deep technical perspective rather than pure marketing statements that can be misleading.

What do you think? Have you encountered these SD-WAN myths? Are there others you'd add to my list? Let me know in the comments section.

(Image: stuartmiles99/iStockphoto)


Comments

SD-WAN

Thank you Faisal for providing this realistic perspective on SD-WAN, and welcome to Network Computing! For organizations interested in SD-WAN, what would you recommend as their first step?

 

Re: SD-WAN

Hi Marcia NWC,


Thanks, The organisations going on SD-WAN need to set the expectations correctly.

SD-WAN as a technology has future but also there is a lot of hype created by marketers. Organizations will find the entry price very attractive for SD-WAN. This will reduce their dependancy on the MPLS. However keep in mind that it is still a very proprietry domain in terms of how vendors implement SD-WAN. I feel that organizations ( the small enterprises) would accept this weakness as the CAPEX /OPEX benefits are fast, direct and very visible.

 

Faisal

Re: SD-WAN

Thanks Faisal! I've heard that vendor lock-in is an issue with SD-WAN products since they're all different and incompatible. 

Re: SD-WAN

Yes Marcia,


Vendor lockin is inevitable here ! but my personal opinion is that small enteprises would ignore this weakness as the cost savings are immidiate and very visible.

Faisal

SD-WAN will replace MPLS

I guess there has been agreesive discussion on this about SD-WAN will replace MPLS, although i dont find my self in situation to comment on this seeking to fact that picture today is currently little blurred with limited knowledge. Although many tabloids/ blogs/experts comment and expect that there to be a big shift from MPLS to SD-WAN, not to the total exclusion of MPLS, but starting with a hybrid model and eventually supplanting a lot of the MPLS connectivity today.

Re: SD-WAN will replace MPLS

@adilshar1, I agree with you. SD-WAN will suppliment MPLS or any other transport technology but would not replace it completly.

 

Faisal

Myth 5: I will save money with SD-WAN vs MPLS

I really enjoyed this article! and it was very insightful, I'll point out a couple of nuances that occured to me as I read it:
(M1) IMO, both are edge technologies, if you don't believe me, take a look at the SLA's for most MPLS providers. SD-WAN can provide the user more control in the areas that cause them the most pain if implemented correctly. Depending on how you are using your network; SD-WAN can augment or entirely replace your MPLS network, and any SD-WAN vendor that tells you to keep MPLS for 'real-time' traffic might not have the right solution for you.

(M2) I think you nailed this except for the implication that MPLS guarantees QoS - if latency is an issue on MPLS, you might get a couple of bucks back. Users would rather get their date through.

(M3) This article would be right on point if it were titled the "The Top 4 SD-WAN Myths when Implemented to Reduce Cost". I never approach SD-WAN that way. The #1 benefit is the increased serviceability/control. My personal favorites are getting rid of BGP and taking back you DNS for providers that offer those features. Typically you get a lot more control for the about same amount of money. The #1 detractant is the accountability because now that you can affect so much change, you can't blame the vendor or carrier.

(M4) Any way you look at this, it is a dead on awesome point. Furthermore, load balancing is not WAN optimization which is not CoS nor does it guarantee QoS.

My additonal myth would be (as alluded to above):
(M5) SD-WAN is less expensive than MPLS

Thanks for sharing Faisal, let me know what you think of my remarks.

Re: Myth 5: I will save money with SD-WAN vs MPLS

Thanks, @exectechpro. for detailed analysis of the points. I really enjoyed your perspective and insightful comments.

For the myth 5, do you want to say that SD-WAN is more expensive than MPLS ? Can you elaborate.

For the other, please see below :

(M1)MPLS is not an edge technology , it is very much a WAN technology totally different than what SD-WAN is. In SD-WAN, the intelligence is pretty much in the edge and once packet leaves the site, the technology has no control over the packet inside the WAN. Almost all vendors I talked to are recommending to keep some scale of MPLS.

M2) With MPLS, i have control over how to engineer and route my traffic, thereby complete control over the latency and guarantee that latency to the customer. With the SD-WAN , i cannot. Lets take an example to clarify this. A customer buys a single link on SD-WAN over broadband ( i am using one link to clarify the concept). Now let's say the latency and jitter worsens on the link. SD-WAN would be able to show you that jitter and latency have worsened but it cannot do anything to reduce that latency and jitter. This is why, I refereed to it as an edge technology. However this is wrong perception in the market that SD-WAN can do some magic on the same link where quality has worsened.

(M3)The customers that I talked to are using cost as the main driver for going for SD-WAN and orchestration as the secondary driver.

(M4) Agreed

Thoughts

"For the myth 5, do you want to say that SD-WAN is more expensive than MPLS ? Can you elaborate."

I'll preface all of the below in saying no one can replace MPLS with SD-WAN on a ckt for ckt basis and maintain the same data integrity. Most SD-WAN vendors can support 4 or more ISP connections.

So, SD-WAN can be more expensive in considering the TCO, for 2 primary reasons: 1 - the cost of the equipment, software, maintenance, training, etc..
2- may need multiple ISP circuits to replace a single MPLS ckt (which also explains my response to M1 & M2):

(M1) MPLS is a WAN technology but carriers control the core the customer doesn't. The customers usually only have limited to no visibility to the core (depending on the carrier). My reference to it being an edge technology was a sarcastic reference to the fact that MPLS clients can really only affect the edge traffic which is where SD-WAN is more flexible and versatile.

SD-WAN takes the approach of 'I don't care what is happening in your network (no visibility), I just want my data to get through.' MPLS clients sometimes have issues getting data through and they don't know why. They may have recourse in submitting an RFO (Reason for outage) request with their carrier and hearing some number of days/weeks later what caused it (which they probably could not control) and possibly, with certain thresholds met, recoup some if not all of the monthly costs associated with the affected components. Businesses are becoming increasingly intolerant of this reactive network approach (at least in the US). Any vendor recommending, keeping MPLS for real-time traffic, I suspect, would likely be looking at a single ISP connection for
SD-WAN. I would recommend that anyone needing real-time traffic and looking at SD-WAN implement 2 ISP fiber connections with different carriers or multiple ISPs, whether fiber or not, if it is not mission critical real-time.

(M2) you are absolutely correct if the carrier is delivering on is latency, jitter and loss commitments without fail - never having an outage. Use your example to walk through a scenario where someone is having the same issue with MPLS. Jitter or latency is preventing your app from responding or impacting VoIP. In this case you are "cooked"; call your vendor, reboot your edge equipment; wait for an explanation - trust they will address it and it won't happen again - because they always do and there are never any chronic issues (sarcasm again).

Say in that scenario you have 3 SD-WAN links- latency occurs on the 1st, the appliance analyzes the remaining 2 and determines the best route to get the data through because that is the priority - not figuring out what is wrong. Let IP do what it does best - without BGP, et. al. route traffic. Ironic too that some of the biggest global MPLS providers are layer 2 at the core.

(M3) and while I don't discount that many/most if not all are using cost as the driver, they can't do so without sacrifice. That said - there is a place for 1 to 1 replacement to reduce cost in moving to SD-WAN; maybe they don't have delay sensitive data or nothing is really mission critical, or there virtual environment or cloud would suffice but nobody took the time to decommission MPLS.

In the US, many businesses went to MPLS for regulatory reasons, not because they needed guaranteed network performance. SD-WAN might appeal to these folks. Remote/branch office is another use case. I need MPLS at HQ but not my remote offices. Look at Pt-Pt Ethernet (VPL/EPL) as an augmentation to those designs.

Cheers!

QOS Differentation

Thanks Faisal,

I found this article very insightful and it left me with a better understanding of what SD-WAN can, and cannot do.

I work for TelePacific Communications and after our recent purchase of DSCI, we have now partnered with VeloCloud to provide SD-WAN as part of our Managed IT, Cloud, Voice and Internet Services.

What I found most interesting in your article was the question of what is true QOS and whether SD-WAN can actually allow vendors to guarantee it. We offer a 100% SLA on our QOS and that is regardless of the type of transport, or whether we are providing it or not. Now when I first heard this and about SD-WAN, I honestly had a hard time believing it and it took a second to get my mind wrapped around it. We’re able to this for several reasons. The first is that we do use forward error correction which is the process of sending test packets out in advance of the real data. Think of them like scouts that go out ahead to flush out which pathways are the best, this way we can significantly prevent packet loss. The other way we do that is that if we are not the circuit provider, we aren’t liable if the circuit fails. On top of all that, if voice quality degrades, we do begin to compensate the customer. But this becomes a non-issue when we look at the solutions we provide for our customers. With all the different types of transports available for our customers like fiber, Ethernet over copper, fixed wireless, or 4G/LTE backups, down-time really is preventable if the overall solution is done correctly. If you put SDWAN on a bare-bones Comcast circuit 25/5Mb in an area complaining of frequent drops, and put 200 callers on that circuit, QOS can’t be guaranteed because there just aren’t enough paths on the circuit. But if you put an office of 20 people on a 50/50Mb fiber circuit with a 4G/LTE redundant failover, QOS would be totally guaranteed. It would be guaranteed on even a single unbonded T1 (1.5/1.5Mb). They wouldn’t get much bandwidth for internet browsing, but they’d still have QOS. So in the end, it comes down to your point that although it can detect latency, jitter and packet loss, it can only truly prevent packet loss. It doesn’t prevent jitter and latency, it just side-steps them by finding the best paths to send the info through. If there are no good paths, then there is no QOS. But if there are no good paths, that’s the same thing as saying there is no circuit. So it’s like saying the Voice Over part isn’t good quality when the Internet Protocol is down. VOIP is Voice Over Internet Protocol. Of course you can’t guarantee the quality of service on the “voice over” part if the IP part is down. . It’s because we make this differentiation that we can provide our 100% SLA on our voice (and if the internet goes down and we’re not providing it, it’s not our damage). If we do also provide the transport, we offer 100% SLA on the voice and 99.999% SLA on the data.

Thanks again for sharing!

If any are interested in learning more about Unified Communications and how SD-WAN can help you reduce cost and improve communication, feel free to reach out :)

Elliott FitzGerald
efitzgerald@telepacific.com
415.484.9588

SD WAN direct cloud links

Why couldn't you hand-off any production and disaster recovery sites directly to cloud providers via layer 2 links? Wouldn't this remove the MPLS needs at the production and disaster recovery sites? Isn't this what these sites have MPLS for? If from the production facility and the disaster recover site, you private line (protected or unprotected) back to a data center where any cloud services provider (Google, AWS, Facebook, Microsoft, etc) has a presence, you could handoff traffic and security to them there and establish a VPN/SD WAN. Why do you need MPLS if you're handing off via SD WAN dual Internet connections at all production and disaster recovery sites rather than MPLS? Again, you're layer 2 (protect and/or unprotected) to your cloud services providers at any production and or disaster recovery sites.