Over The Top Service?

Most consumers are familiar with the availability of over the top (OTT) content. Examples are Netflix, Amazon Prime, Hulu and we could even include gaming services in the description. The model for an OTT content provider like Netflix is to ride over a user’s data plan, and that data plan can be DSL, FTTH as well as wireless to deliver content. The consumption model is disaggregated between the data plan (i.e. internet) provider and the content (i.e. service) provider. This is also the point at which there is tension between both parties in terms of the cost to deploy bandwidth and which party profits from the services that ride over the bandwidth. That is not a topic for this post.

If you where to start a cloud service provider or some variation of a managed service provider today, would you build pipes or buy the pipes? Most likely you would buy or lease the pipes, but you would still need to deploy a network across the underlying pipes made up of some set of devices that would provide a control plane across the pipes. Most network architects would think in terms of engineered links, backup links and autonomous devices that determine state and provide traffic engineering. A new 2015 Plexxi customer took a different approach to building a global network footprint, but it took a European PTT, think old world carrier, to show me the significance of this new design approach.

Frame 1

Before describing my learning moment, here is a single slide from a Google presentation about network protocols. I point out this slide because I am going to call out in a future post (almost written) how network design iterations are conflated with network design evolutions and the vast majority of people miss the forest to opine about the tree before them. This one simple slide from 2010 is really at the core proposition of SDN, yet it has been missed by so many. Here is a link to the presentation and I am referring to slide #31:

Over the holiday break I read this article on SD-WAN. The interesting part of the article to me was the three categories of SD-WAN solutions, which I pasted below:

There are currently three categories of SD-WAN vendors, each with a particular focus and strength. In general, they can be classified as follows:

1. Controller-based solutions that can auto-discover and configure network devices
2. Appliance-based overlay solutions that create a virtual IP network between the vendor’s appliances across any network, combined with vendor-specific management tools
3. Advanced automation and change control solutions that can enable and manage SD-WAN and the underlying infrastructure through existing hardware.

None of the three categories make any reference to underlying protocols and forwarding topologies. The following is some text from a future post, but I am going to include it here because it is worth stating twice “the network is defined by protocols. I often suggest to people to watch this video from ONS 2012 and not to get trapped that is about using OpenFlow, it is really about constructing a network that operates differently. It is about (i) managing network bandwidth as a pool, (ii) managing the needs of applications, (iii) not managing each network box, (iv) not being at the mercy of how traditional protocols interact and re-compute topologies which sometimes find the optimal state, and sometimes not, and sometimes they are fast to find optimal state, sometimes they are not fast and (v) in general how distributed state systems are really hard to tweak to create a desired and deterministic outcome. It is about designing a network that operates differently with the infrastructure and the applications.”

Take some time to go through this presentation from Google circa August 2012.   To save you from the click out, I have reproduced a few pertinent slides. The idea is that it is possible to build a network that is global in scale using a Controller architecture by stripping away the unnecessary and focusing on the necessary. This brings me back to the Plexxi customer who built a global Controller based network in 2015.

Frame 2

I had a recent opportunity to present to a traditional European PTT, with a global MPLS network. Traditional service providers have always been tricky customers for Plexxi to sell to. On one hand we would like to sell to them, but on the other hand the R&D required to match legacy features and system requirements would put us out of business. I decide to go into the presentation with the plan to tell them about the Plexxi customer who built the large (geographic) network from the US to Asia and EMEA. About an hour in, I am getting the expected opposition from the traditional network engineers, which is mainly center on the sunk cost of their global MPLS network, customer SLAs, how would they migrate customers from their current network to a Plexxi network and why would they do this when they can kind of do it today with MPLS traffic engineering? These are all code words for “…we are not taking on the risk that a new technology change brings.”

Frame 3

I pause here and bring up a story from eleven years prior. At the time I was working at Ciena and we had a strategy off-site to start the year and one of the exploratory topics was what would happen if OTT services exploded and our primary customers became confined to the business of offing only pipes (i.e. Bits R Us)? I even took the time to write a book on the subject, which predicted the demise of the programming packages and rise of individual content selection and as you can see from the current rank on Amazon sales I am retired and living in the Turks and Caicos. Joking aside, we really did ponder the question of how service providers would evolve if they were relegated to selling pipes (data plan only) with no content (i.e. services) programming.

Frame 4

Back to my sales call story, I am about 90 minutes into the sales call and I am getting all means and methods of customer push back, when the CTO of the PTT stops the objections of his team.

He asks me how long did it take this Plexxi customer to deploy a network that is an alterative to an MPLS network? I tell him less than 30 days and it is a collection of pipes from a number of underlying providers. In some locations it is dark fiber, in others it is leased circuits or 10G waves, anywhere from 500MB to 10G. When it is connected, it forms a fabric, global in nature that allows our customer to deploy services in matter of seconds using a Controller based architecture. He tells his team they need to look at what we have to offer and this is the point that a potential customer taught me how to sell my solution. What this CTO realized was if a competitive service provider could buy a collection of pipes and stretch a fabric across these pipes and deliver services within 30 days, the possibility now exists to for new entrant service providers to build global fabrics with zero down time SLAs that relegate traditional carriers to the Bits R Us category. It is possible for new entrant providers to deliver services over the top of traditional carriers because they build a network that operates like the Google network described in Frame 1. Ten years later, my career had come full circle in two-hour presentation.

The lesson I learned during this sales presentation was not to try to sell an incumbent carrier new technology, but rather to show them how a new entrant can use new technology to be a disruptive threat to their business. In the hands of an over the top service provider, a Controller architecture allows for an extension of computed fabric over a collection of pipes. The data plane is just a series of pipes as in the Bits R Us what if scenario from 2005. The Controller and switches forming a resource pool becomes the control plane and the higher margin business is delivered at the services layer. This was the disruption threat the CTO of the PTT realized in meeting and he told his team they needed to understand this technology and solution not because they were going to replace their global network, rather they needed to have both methods in their solution kit to offset the exogenous threat posed by a network that operates different.

/wrk