Is SD-WAN a Quasi-QoS overlay for enterprise, independent of telcos & NFV?

In the last two weeks I’ve been at two events: EnterpriseConnect in Orlando (EC16), and NetEvents in Rome. The former is a midsize trade-show, mostly UC/cloud-comms providers and vendors pitching to business users. The latter is smaller: vendors and a few SPs briefing and debating in front of technology journalists and analysts, mostly about enterprise networks, or the carrier networks needed to support them.

An interesting divide is emerging. Both events involved a huge focus on cloud – especially for communications apps and security functions. But it is mostly only the “traditional” carriers and their major vendors which are really discussing “proper” NFV and SDN as a platform for delivering new customer-facing services to businesses. For other enterprise vendors and service providers, NFV is not even on the radar screen as an acronym.

EC16 was dominated by major players in telephony and collaboration – vendors like Cisco, Avaya and Microsoft talking about cloud-based evolutions of their UC and conferencing tools; UCaaS providers like 8x8 and RingCentral with their own hosted platforms, or others based on BroadSoft. WebRTC, contact centres and cPaaS made a good showing as well. A few traditional telcos were there too, such as Verizon which has an LTE-based UC solution, and Sprint talking about its partnership with DialPad (formerly Switch.co). Slack wasn’t there, but other workstream-style messaging and collaboration tools were pretty ubiquitous, usually with a heavy mobile bias.

There was also a decent turnout of comm-centric vendors that make SBCs, UC/telephony servers and related infrastructure elements – Oracle, Dialogic, Metaswitch, Sonus, BroadSoft and peers. But while these were definitely talking about virtualisation, it was mostly not in the guise of NFV as perceived by the telecoms industry. There wasn’t much discussion of MANO and service-chaining, unless I specifically asked about them in meetings. Their use-cases for virtualisation were all much more pragmatic, aimed at non-telco UCaaS providers, or in-house deployments by enterprises in private-cloud or hybrid cloud/on-premise configurations.

The general assumption was that enterprises will continue to buy their collaboration apps/services separately to buying their network connectivity. Even where a UCaaS provider also sells access or SIP trunking, they’re not likely to be tightly coupled. There might be some "dimensioning" to ensure sufficiently-reliable performance, a separate MPLS connection entirely, or some tweaking of prioritisation to the UC provider's cloud. But there was no sense that a customer-facing UC server would be “just another VNF” hosted in the telco’s infrastructure alongside its vIMS and vEPC.

In a nutshell – corporate telephony and collaboration and contact centres are not really seen as “network functions”, any more than SAP or Office or other line-of-business apps are. (It’s worth noting that security functions like VPNs and firewalls are more aligned with NFV, as they are often integral with access connectivity). There's no real "telco cloud" either, except as an equivalent of an ISP-cloud or SaaS-cloud.

Maybe this will change in future as we see more telco "distributed cloud" and "fog computing" architectures emerge - for example, the Mobile Edge Computing initiative. But to be honest, I've got my doubts about that as well - a topic for another post, though.

However another form of software-based infrastructure for enterprise got airtime at both events: SD-WAN (software-defined WAN). I am starting to think that SD-WAN may actually reduce the potential for some proposed NFV business models, because it could put a new layer of abstraction between telco networks and corporate applications and communications.

In essence, SD-WAN allows the creation of “Quasi-QoS” by various methods. Perhaps the most important is the blending together of multiple access connections to a company’s sites – MPLS, vanilla Internet (perhaps x2 or x3), LTE and so on – and then load-balancing, bonding or using them for backup or differential routing of traffic.There are also various approaches involving hacking TCP in some way, or various proprietary approaches to packet classification and scheduling. Typically, SD-WAN will involve some sort of server or dedicated box at each customer site.

The following illustration is from SD-WAN vendor Velocloud, and is given as an example

This could put mission-critical applications onto managed connections, with less-demanding traffic onto Internet access. Or it could be “Internet-primary” and use more expensive connections only when congestion seems to be causing problems. It can also link into major IaaS and cloud platforms (Amazon, Google, Microsoft etc) in different locations and with large-scale connections. Many other use-cases and permutations are feasible as well, especially when linked with UCaaS or other SaaS offers.
 

In other words, SD-WAN could be described as “Arbitrage-as-a-Service” or “Managed Least-Cost-Routing”. Where the SD-WAN is offered by a company which isn’t one of the access providers, it is essentially “OTT-QoS” – although I think that “Quasi-QoS” sounds better.

I see this as a conspicuous threat to various forms of NFV-based enterprise service, especially what gets called NFVaaS or NaaS. By putting an overlay around access connections, it reduces the ability for any extra capabilities to be offered from within their infrastructure.

My colleague Martin Geddes has been scathing about this type of “QoS” (link) – noting that the underlying “network science” doesn’t allow for performance to be accurately predicted or guaranteed, without some very clever maths in the access network boxes. The “failure modes” can be ugly, as sudden sub-second spikes and buffering issues can occur and disappear randomly, trashing sensitive applications before the SD-WAN can respond.

My sense is that while that might be technically true, the real-world problems are more prosaic. Either a fully-dimensioned MPLS connection is too costly, or something fails completely because a fibre is cut, or a network node crashes and reboots. Or, is is the case here, the economics are so compelling that it's cheaper to just buy two redundant connections rather than optimise one.

The bottom line is that SD-WAN is potentially a game-changer - and it potentially undermines the NFV argument, not just for UC services, but perhaps other functions too. While some vendors are working with telcos to offer hybrid solutions, that's because of customer pull. This isn't to say that it invalidates everything proposed by NFV believers - far from it, in fact - but it does act as a counterbalance to the view that virtualisation is all telcos need to dominate enterprise connectivity and communications. 

SD-WAN entrenches the idea that enterprise communications and apps are decoupled from access. It also empowers Internet-based UCaaS providers to offer SLAs and QoS guarantees without owning access connectivity themselves - for example, Vonage works with VeloCloud, and Star2Star has its own connectivity boxes that optimise "vanilla Internet" access.