Software-defined WAN, or SD-WAN, is surely a hot topic, and recently the application of SD-WAN to UC/UCC has become even hotter. Can SD-WAN really improve UC, making voice and collaboration more reliable? As is often the case, the answer isn’t as simple as it might seem. SD-WAN really can’t solve some network problems, and the solution to others may depend on the SD-WAN implementation you pick.
Virtual private networks (VPNs) are a fixture in the connectivity planning of enterprises, but for decades they’ve been challenged to provide uniform support across satellite locations globally. In some areas, the dominant VPN technology, MPLS, simply isn’t available; in other areas, the cost limits the bandwidth to something even today’s consumers would consider substandard. Some sites can’t be made cost-effective at any speed. SD-WAN offers businesses a way to use the Internet to supplement MPLS at “thin” sites, and also to use the Internet to back up traditional MPLS VPN connectivity. No wonder it’s exciting to many businesses.
This cost-and-connectivity value proposition isn’t enough to differentiate the two or more dozen SD-WAN solutions, though. That’s in part why SD-WAN providers (vendors, managed service providers, and even network operators) are increasingly looking at SD-WAN support for specific applications, and that’s where UC/UCC comes in. The challenge for users is that differentiation is about marketing, not about strict truths, so let’s look at some of the UC/UCC claims made by SD-WAN implementations to see if they hold up.
True or False?
The first claim is that SD-WAN will improve voice call quality, and the truth of that depends on what’s causing the call quality problem. There are a lot of quality-of-service variables on the Internet, and none of these are really subject to SD-WAN control. If the Internet gets congested, then call quality will suffer, which makes this claim false.
A related claim is that SD-WAN can prioritize real-time traffic such as UC/UCC. Will that help your call quality? It depends on how much traffic you’re giving a priority. If everyone gets to move to the head of the line, priority means nothing. Many SD-WAN implementations can prioritize calls, and so if network capacity is adequate to handle priority traffic, this claim is probably true.
A final call-quality claim is that SD-WAN monitors call quality and takes steps to remedy problems, and this one has to be parsed in the two pieces of the claim. First, not all SD-WAN implementations monitor call quality and those that do use different metrics and thus identify different faults. Second, as noted above, SD-WAN can do little to impact underlying Internet issues. If there’s excessive transport delay on the Internet, SD-WAN can’t push packets faster. Yes, a failover to an alternative network like an MPLS VPN might be available, but that could defeat the cost-saving benefits that justified SD-WAN in the first place.
A counter-truth here is that some SD-WAN implementations can actually hurt call quality. SD-WAN is a logical network built on top of a physical one, and that process creates some overhead depending on what technology the SD-WAN implementation uses. Tunnel protocols are widely (but not universally) used, and those protocols add an additional header to each voice packet. Voice packets are often small to reduce the delay while you accumulate voice samples, and this can mean a very large overhead. Some users report that tunnel header overhead can exceed 30%. That reduces your effective network capacity, which means congestion and speech glitches are more likely, not less, even with prioritization.
The next claim that’s often made is that SD-WAN will reduce dropped calls. The truth of this claim totally depends on the implementation. Remember that SD-WAN creates a virtual network “above” the real network connection, usually the Internet. If the SD-WAN keeps track of the status of these overlay connections, it can recover them if they’re lost because of a network failure, but only if an alternative route is available. If the SD-WAN is aware of individual voice sessions, it likely can recover them quickly. If it uses tunnels to carry multiple traffic types, it may or may not “see” a specific voice session problem, so check how your prospective providers of SD-WAN work if this capability is important to you.
One claim that’s as close to absolutely true as you can get is that SD-WAN improves thin-site communications. By bringing everything onto the corporate VPN, an SD-WAN allows all applications, including UC/UCC, to work the same way for workers in all sites. That tends to eliminate the variations in worker productivity enhancement available in sites without MPLS connections, and it also makes the management of application connections with workers easier by creating a single VPN for all.
Want some general hints? Generally, SD-WAN solutions offered by or through MSPs or network operators are more likely to offer some service guarantees, because these players can control the service quality in the transport networks. Generally, SD-WAN implementations that provide for explicit connection control, meaning that you describe exactly who’s allowed to connect to what, are more aware of UC/UCC applications and better equipped to manage their performance. Also remember that SD-WAN can’t help in sites where it’s not used, so watch out for connection problems that occur outside the SD-WAN, in the MPLS VPN.
Finally, look at your SD-WAN vendors closely, and demand that any assertions they make about their UC/UCC support be written into the service-level agreement. Marketing is just marketing unless it’s formalized in a contract.