Since broadband is an immature business and quality-assured services are rarer than rocking horse manure, many fallacies abound in the resulting information vacuum.
I am working on the delivery of commercial quality-assured broadband services. In doing so, I have come across many misconceptions, misunderstandings and mistakes about what quality “assurance” is and what it involves.
Here are some of the most important ones about the nature of broadband service quality assurance and its definition:
Fallacy #1: It’s all about perfection
Quality assurance is the act of bounding the rate at which some kind of unwanted behaviour or failure occurs. We make promises about outcomes for end users, but those promises might be very weak ones (as long as we can demonstrate we can deliver upon them). Assurance is about taking full responsibility for the truthfulness of our promises, not the strength of those promises.
Fallacy #2: It’s all about the network
The purpose of quality assurance is to deliver some kind of fit-for-purpose outcome for users. Although the mechanism for delivering that is by managing the network service quality, the promises only have value if they can be related to the experience and/or cost that results. In other words, the value of assurance is anchored in the demand-side view of the user, not the supply-side perspective of the network operator.
Fallacy #3: It’s an unconditional promise
There are things in the world we can’t control, and assurance accepts this reality. In particular, the promises we make of delivering a particular outcome are conditional on behaviours of the user (e.g. a ceiling on allowable demand) and the environment (e.g. DSL signal to noise ratio, WiFi radio signal strength). Any promise has to be conditional on the factors you don’t control being within some acceptable founds.
Fallacy #4: It’s only about delivering high quality
Applications have widely varying quality needs. When you choose to give better quality to one data flow, you must give worse to another. Hence the real value of assurance is when you are delivering a diversity of applications, with varying levels of quality, and can give the right “quantity of quality” to each. Delivering the right quality to the overnight backup so it finishes in time is just as important as to offering glitch-free 2-way videoconferencing.
Fallacy #5: It’s only about a quality floor
The natural assumption is that you are only concerned with setting a minimum quality for any application, since that is what generates a premium price. However, some applications and users are sensitive to cost rather than quality, and for them you need to avoid over-committing network resources. Hence it is also important to be able to maintain a quality “ceiling” to assure cost, not just a “floor” to assure revenue.
Fallacy #6: It merely requires fixing a quality floor or ceiling
You can only bill for the value delivered if you can prove you did it afterwards. Hence we need to distinguish between “ensurance” (making the desired service outcome happen), and full “assurance”. The latter closes the loop by having a system of traceability and auditability that demonstrates that the promise was kept (to a sufficient degree of certainty).
Fallacy #7: It only has value if done end-to-end
The heyday of the telecoms industry is possibly the 1980s when the answer to every possible customer need was “buy an expensive fixed-quality circuit”. The culture of end-to-end quality management sat in opposition to the utopian dreams of the “best effort” packet networking brigade. The reality is somewhere in the middle: even if we only assure my end of the video link, it still creates value even if your end (and everything between) is unassured.
Fallacy #8: It’s only applicable to fixed networks
By its nature, wireless is a high-variability environment in which to deliver services. It is tempting to think that all that interference and reflections mean you can’t do assurance on mobile. That is untrue. You can still make promises about how the radio resource scheduling will function given a set of radio environment preconditions. All assurance promises are relative ones of “what I will predictably do in a given situation”, not absolute outcomes.
Fallacy #9: It needs new specially-built networks
Thankfully, existing networks generally exhibit some level of predictable performance that is reasonably stable over time. (The fancy way of saying this is that the probability distribution of quality is “stationary”.) Whilst we would ideally make quality a first-class design object and architect quality assurance from the beginning, that is not a prerequisite to progress. We can “wrapper” existing networks and cleverly inject packs so as to exploit their predictable properties.
Fallacy #10: It’s not possible on IP networks
Because nearly all IP networks are designed to have emergent performance properties, rather than engineered ones, it seems that we need to use technologies like ATM, MPLS or Ethernet to deliver assurance. This isn’t true; we can make conditional promises about how we will behave even in the horribly unpredictable world of IP networks. This isn’t a theory: real and practical assurance has been proven to work at scale even with something as kludgy as Internet Protocol.
For the latest fresh thinking on telecommunications, please sign up for the free Geddes newsletter.
Read It Now
