Imagine you are walking out of the elevator on the 57th floor of a skyscraper. You turn to the right, and in front of you is the glass wall of the building. Beyond that is a magnificent view of the city, and many other tall buildings around.
How do you feel? Inspired? Awed? Or absolutely terrified?
Unless you suffer from extreme vertigo, you probably feel quite comfortable. The floor is solid, the view is good, and what is there to worry about? After all, skyscrapers have been around a long time, and they are built to high specifications. They don’t just fall over for no reason.
That is because in the world of construction, we have mastered the art of structural engineering. Hundreds, if not thousands, of years of construction have resulted in a deep understanding of the load-bearing properties of the materials, and how they behave when assembled. An architect is able to design a building, a structural engineer turns that into a plan, and a quantity surveyor obtains standardised parts. The result is a structure with predictable performance and safety margins.
The key to this predictability is a composable resource model. “Weight” is a simple example of such a resource model. The weights of the girders, glass and concrete add up, and we know how that load has to be distributed. We also know how to model dynamic loading effects, like wind or earthquakes. Hence structural engineers for skyscrapers can do their job.
In telecoms, we have this level of predictability and safety when building both analogue and digital (TDM) circuit-based networks. Their properties have been studied, and there are accurate models of how they will behave under load. Indeed, A.K. Erlang cracked the core mathematics back in 1909, and we name the resource model for telephony after him: “Erlangs”. You tell a telecoms “structural engineer” what kind of load you want to apply, in Erlangs, and she will tell you what kind of supply to construct to give a particular likelihood of a call not getting through. When lots of circuits are aggregated, the Erlangs “add”, and we can “divide” them again when the circuits are disaggregated.
When we went from circuits to packets, we lost that predictability and structural engineering capability. Instead, we adopted a series of heuristics (“upgrade the network when it reaches 40% average load over 15 minutes”) and work-arounds (e.g. by keeping networks very, very empty). There has, until recently, been no way of taking the requirements of a set of applications, turn them into general “application Erlangs”, and constructing a supply to make them work with predictable rates of failure.
That places the sophistication of broadband engineering somewhere between mud huts and medieval cathedrals. The resource models we use – “bandwidth”, “jitter”, “loss rate” – lack the composability feature that is the core of engineering. How can you know what the properties of the whole will be, if you can’t “add” the properties of the parts, and compare them to the required load and safety margin? As a result, broadband networks can and do ”fall over” for (seemingly) no reason. As load is increased, applications fail in an unpredictable and uncontrolled manner. Nobody is able to measure, model and manage the hazards to the users.
The result is an industry that falls well short of the needs of its users. It either saddles them with unacceptable levels of application failure (all those lousy Skype calls you’ve ever had), or unacceptable cost (laying fibre in order to create super-empty networks to avoid the most transient overloads). This is not sustainable, especially in a “software telco” world which by its nature aims to reduce the safety padding of unused capacity. Network control systems have to make accurate judgements of available resources, and the risks of their (mis)allocation.
The effects of this capability deficit are visible across the industry, if you know where to look (and get to see the buried bodies of failed projects). I and my colleagues have seen major “structural engineering” failures in military systems, unified communications, PSTN IP voice transition, small cells, RAN sharing, and a host of other services. However, these can all be fixed.
In future articles, I will explore why we lack the necessary thinking tools, and describe how we can regain our broadband ”structural engineering” capability with a new composable resource model. In the meantime, I recommend that you stay well away from any skyscrapers built by broadband telecoms engineers.
To keep up to date with the latest fresh thinking on telecommunication, please sign up for the Geddes newsletter
Read It Now
