We have seen the telephone network evolve from usage-sensitive to flat-fee billing, and now we're seeing the enterprise WAN do the reverse -- moving from flat-fee to usage-sensitive billing. The "Third Network" is the delivery mechanism.
As discussed in last week's post, the Third Network is a network that will be able to change its resources to meet an enterprise's real-time requirements in a way that would allow a network provider to manage its resources profitably. Network providers and enterprises using such services will face issues and challenges related to service-level agreements (SLAs) and billing for dynamically changing services.
The Third Network Implementation
The Third Network vision centers on the idea of network as a service, or NaaS (see related post, "Is NaaS the End of Networking, or the Beginning?"). Dynamic resource allocation would allow network services to align with UCaaS and other on-demand cloud service capabilities. In a Third Network implementation, UCaaS applications would automatically specify their requirements for bandwidth, packet loss, jitter, and latency through a standard API. With NaaS, enterprises would no longer need to provision static classes of service for their applications.
The Third Network is designed to be flexible. The UCaaS application would be able to enable features dynamically, before or during a session. The Third Network automatically would adapt to the application's session requirements. The enterprise would allocate WAN resources as needed, not in advance.
End-to-end Third Network services would comprise network resources from an interconnected number of network providers, as shown above. (For information on how Third Network architects intend to ensure seamless end-to-service, read the MEF Forum whitepaper, "An Industry Initiative for Third Generation Network and Services.")
SLA Issues
An enterprise's capacity requirements will change in real time, and it will need assurance that the services deliver the agreed-upon performance. The provider will need to deliver to and report on its SLAs in a form that does not mask network performance issues. Measuring an SLA over 24 hours is useless. With today's real-time applications, even a minute may be too long. In their performance reports, providers would need to display any fluctuations that exceed the SLA for more than one second. Each of the interconnected service providers will have agreed on the SLA and deliver it end to end as a single deliverable for the enterprise.
Do you trust the SLA reports you receive today? Many organizations have their own network management systems measuring and independently reporting on SLA delivery. They will need to update those to reflect on-demand network fluctuations. SLA reporting will require new measurement data points and expanded software for the enterprise and service provider alike.
Network traffic can change dramatically during a real-time session, with bandwidth usage fluctuating widely and endpoint application requirements evolving during a session -- a voice call escalates to a video session, for example. When the network isn't able to respond to changing requirements dynamically, real-time applications can suffer from latency. Voice and video sessions can be impaired by packet loss and jitter.
Full service availability must essentially be always available, and Mean Time To Repair (MTTR) is not an adequate measure. What counts is how quickly the network service, should it fail, restores to a fully acceptable level. Is availability measured statistically (which means little) or by endpoint? The broader the measure, the less valuable the measurement. The user wants no impact at all when a failure occurs, or at worst restoration in seconds.
The big question is, "What does the provider do when the SLA isn't met?" Many of the SLA agreements I have seen provide for minor penalties and do little to compensate for any damage incurred. An enterprise may be forced to independently develop reports and argue the results with the provider. And the cost of that internal SLA analysis could exceed the financial penalties paid out by the provider, and so enterprises are discouraged from pursuing that route. What constitutes an SLA breach? Can the enterprise terminate a contract if the SLAs are not met? Bungled Billing?
When an enterprise is billed for on-demand changes, would it have any control? There are four scenarios that could occur that affect the bill:
No matter what scenario an enterprise follows, it should want to know how the bill is determined. Questions to ask a service provide include:
These are important questions to consider when trying to budget for on-demand services such as those envisioned with the Third Network. But SLA and billing aren't the only issues. Others to consider are procurement, control, operational, and interoperability concerns.
