Tuesday, March 22, 2016

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.

Disruptive Analysis Workshops

- Mobile broadband traffic management strategies- Technology and market evolution- Business model development & unique propositions- Pre-launch feedback on new products and services- Business plan due diligence- Leadership team development