Home / Blogs

Who Will Crack Cloud Application Access SLAs?

The broadband industry doesn’t have an agreed-upon unit of supply and demand that meaningfully “adds up”. This is rather odd for a service that aspires to be a utility. It is also a barrier to a much-needed transformation from “bit pipes” to “digital supply chain management”.

The chart below ought to be in every basic undergraduate textbook on packet networking and distributed computing. That it is absent says much about our technical maturity level as an industry. But before we look at what it means, let’s go back to some basics.

When you deliver a utility service like water or gas, there’s a unit for metering its supply. The electricity wattage consumed by a room is the sum of the wattage of the individual appliances. The house consumption is the sum of the rooms, the neighbourhood is the sum of the houses, and so on. Likewise, we can add up the demand for water, using litres.

These resource units “add up” in a meaningful way. We can express a service level agreement (SLA) for utility service delivery in that standard unit in an unambiguous way. This allows us to agree both the final end-user delivery, as well as to contract supply at any administrative or management boundaries in the delivery network.

What’s really weird about the broadband industry is that we’ve not yet got a standard metric of supply and demand that “adds up.” What’s even more peculiar is that people don’t even seem to be aware of its absence, or feel the urge to look for one. What’s absolutely bizarre is that it’s hard to get people interested even when you do finally find a really good one!

Picking the right “unit” is hard because telecoms is different to power and water in a crucial way. With these physical utilities, we want more of something valuable. Broadband is an information utility, where we want less of something unwanted: latency (and in extremis, loss). That is a tricky conceptual about-turn.

So we’re selling the absence of something, not its presence. It’s kind of asking “how much network latency mess-up can we deal with in order to deliver a tolerable level of application QoE screw-up”. Ideally, we’d like zero “mess-up” and “screw-up,” but that’s not on offer. And no, I don’t expect ISPs to begin advertising “a bit less screwed-up than the competition” anytime soon to consumers!

The above chart breaks down the latency into its independent constituent parts. What it says is:

  • For any network (sub-)path, the latency comprises (G)eographic, packet (S)ize, and (V)ariable contention delay—the “vertical” (de)composition.
  • Along the “horizontal” path the “Gs”, “Ss”, and “Vs” all “add up”. (They are probabilities, not simple scalars, but it’s still just ordinary algebra.)
  • You can “add up” the complete end-to-end path “mess-up” by breaking each sub-path “mess-up” into G, S and V; then adding the Gs, Ss, and Vs “horizontally”; and then “vertically” recombining their “total mess-up” (again, all using probability functions to reflect we are dealing with randomness).

And that’s it! We’ve now got a mathematics of latency which “adds up”, just like wattage or litres. It’s not proprietary, nobody holds a patent on it, everyone can use it. Any network equipment or monitoring enterprise with a standard level of competence can implement it as their network resource model. It’s all documented in the open.

This may all seem a bit like science arcana, but it has real business implications. Adjust your retirement portfolio accordingly! Because it’s really handy to have a collection of network SLAs that “add up” to a working telco service or SaaS application. In order to do that, you need to express them in a unit that “adds up”.

In theory, big telcos are involved in a “digital transformation” from commodity “pipes” into cloud service integration companies. With the occasional honourable exception (you know who you are!), there doesn’t seem to be much appetite for engaging with fundamental science and engineering. Most major telcos are technological husks that do vendor contract management, spectrum hoarding, and regulatory guerrilla warfare, with a bit of football marketing on the side.

In contrast, the giant cloud companies (like Amazon and Google) are thronged with PhDs thinking about flow efficiency, trade-offs and protocols, and how to globally optimise the whole data centre to user device system. They also commonly own the environment that delivers the user experience (smart TV, smartphone, tablet, etc.) Plus there’s the hyper-distribution capability of app stores to reach all endpoints very quickly. So they are positioned well to drive an application-centric model.

There are big cost savings and quality of experience gains to be had by adopting “standard” metrics and “composable” SLAs. (Try delivering electricity or water without standardised units to see why!) For newer distributed applications, you can’t deliver them at all without adopting “proper” engineering and rigorous science: a rocket isn’t just a scaled-up firework. So whoever masters this very basic idea of a unit that “adds up” is in a better position to economically command the value chain.

The strategic questions are these:

  • Will telcos “get it” and take over the supply chain from the “inside, outwards”? Or will cloud companies “get it” and invade telecoms from the “outside, inwards”?
  • How will the profit pool get re-divided as a result? This is a bit like how things shifted between handsets and networks when power transitioned from Nokia to Apple.

My bet is that the answer is the “outside-in” case: whoever captures the end user experience using metrics that “add up” is in a position to then contract and command the rest of the supply chain to do its will. Telcos will not auto-transform; they will be forcibly transformed. The (enterprise and cloud) connectivity “buy side” has the incentives to tighten up the SLAs on offer; the “sell side” mostly seems pretty content with the status quo.

It is a bit like in the 1990s when there was a big debate about how best to deliver mobile coverage through building walls. In the battle between macrocells vs. microcells, “outside-in always wins.” You don’t try to cover outdoors from indoors; you do try to cover indoors from outdoors. Indeed, everything was configured to meet the most “outdoors” condition. We call them “mobile” networks for a reason!

So are “cloud SLA networks” the “new mobile networks”? We will find out! I think so. You can tell who really “gets it” by who adopts a “unit” of supply and demand that properly “adds up.” This is the essential prerequisite for a new “digital supply chain management” industry to emerge. Because at the end of the day, if you can’t “add up” your cloud application demand, and build a matching network supply SLA, then that’s a big strategic minus.

By Martin Geddes, Founder, Martin Geddes Consulting Ltd

He provides consulting, training and innovation services to telcos, equipment vendors, cloud services providers and industry bodies. For the latest fresh thinking on telecommunications, sign up for the free Geddes newsletter.

Visit Page

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byVerisign

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API

IPv4 Markets

Sponsored byIPv4.Global


Sponsored byDNIB.com