I gave a short speech today at SDN & Openflow World Congress in Düsseldorf. For your benefit, I have turned my notes into an article that introduces the ideas of ‘junk’ and ‘infidelity’. These are important engineering terms that aren’t (yet) widely known.
In order to succeed in future, network architects and operations engineers need to change their resource model. This is especially true in a world of software-defined networks. Let me explain why.
Look at the building you are in right now. How did you feel as you entered it? Terrified or untroubled? The chances are, you didn’t give it any thought. What is there to worry about?
The building you are in is standing up because structural engineers understood both the properties of the materials and how they compose. They were able to take a load requirement, and from that engineer a fit-for-purpose structure by decomposing that requirement into individual load-bearing elements. In doing so, they minimised the materials needed, and thus the cost. They also had a high degree of confidence in the residual safety margin.
The maturity of structural engineering is why buildings don’t suddenly collapse under load.
Packet networks are trees of multiplexers, which compose a set of transmission resources. There are resource allocation systems at the nodes. These make resource trades (at all timescales) to match this fixed transmission supply to varying and diverse demand. SDN is about trading resources at timescales of seconds upwards. Our goal is to deliver the maximum value of fit-for-purpose application outcomes.
This requires having confidence over the resulting performance hazards, and preventing the network from collapsing into chaotic states when driven into overload. These hazards are not being correctly modelled and managed, and thus SDN-based networks will suffer failures under load.
So what is the right resource model for making good predictions?
To answer that question, we need to understand two ideas: junk and infidelity. Any model introduces inaccuracies in how it represents the world. ‘Junk’ are things that the model introduces that aren’t really there; ‘infidelities’ are aspects of reality that get missed out. The level of junk and infidelity limits the accuracy of the predictions of the effects of resource re-allocation.
The primary resource model we use today is ‘bandwidth’, albeit often implicitly. It is not a good one, because it has high junk and infidelity. It is an average, and there is no quality in averages: they fail to capture the necessary detail. This creates an appearance of performance issues where there are none; and no sense of alarm where there are.
This junk and infidelity lowers the accuracy of our predictions of how resource trades will impact the customer experience. The end result is a misallocation of resources, which causes unplanned cost and/or customer churn due to poor experiences.
Bandwidth also cannot be ‘added’ and ‘subtracted’: the first 100kbps of bandwidth in an empty network don’t have the same properties as the last 100kbps you fill on a full one. The same bandwidth in the core and edge have different properties. Furthermore, the design space is becoming more irregular, and performance variability is increasing from more sharing. If we continue on this path of using bandwidth as a resource model, our junk and infidelity will grow, and predictions are going to get a lot worse.
So to get the benefits of SDN, we need a predictive resource model that has low junk and infidelity. Since the systems we deal with are stochastic, that means we need a stochastic resource model.
The good news is that this is a solved mathematics problem. There is a stochastic resource model with extremely little junk and infidelity. We call it ΔQ. It is a general network measure with compositionality that is a strong proxy for the customer experience. Indeed, ΔQ is the only possible model which has these properties.
Only by aligning with the unyielding mathematical reality of packet networking can we erect ‘network skyscrapers’ won’t fall down unexpectedly in a storm. The structural engineering for telecoms networks needs to advance from a skilled craft to a strong science.
The next step is an industry-wide effort to put in place the missing fundamental ‘materials science’ that is taken for granted in other engineering disciplines. Software-defined networks are going to be driven into overload, either during an operational emergency, or to raise profits. By acting now, we can prevent the crisis of legitimacy that will occur if and when SDN-based networks unexpectedly fail.