When we use casual metaphors to describe complex technical systems, we inevitably get a mismatch. This is why ISP “throttling” cannot be regulated.
Standing in Hype Park yesterday on a beautiful clear summer’s evening, there was a constant stream of aircraft overhead — each one passing in front of the moon. The prevailing winds are from the west, so the arrivals Heathrow flight path takes them right over central London. There is a particular wailing sound that they make as the flaps come down, and then a howl as landing gear is deployed.
What is notable about the approach into LHR (and many similar airports) is that it is done with constant descent rate and throttle, so as to avoid creating unnecessary noise pollution. It isn’t just that an increase in the engine power adds more noise, but also its variability attracts your attention and makes it more noticeable.
If you a regulating plane noise, then there are networks of noise sensors under flight paths. You can tell if pilots are having fun with the throttles, and ask airlines to stop them.
Today I am writing a curriculum for a regulatory workshop on “net neutrality”. One of the topics is how to detect “throttling” by ISPs and enforce a “no throttling” rule. Is such a thing sufficiently well defined and measurable so as to be enforceable against ISPs?
Longtime readers will already know the answer: no. “Throttling” cannot be defined or enforced, at least not as presently framed. That is because there are fundamental deficiencies in the metaphor when it is translated from flying people to ferrying packets.
In a jet aircraft, there is a simple unidimensional control system for the throttle: how much fuel do I put in to burn? Unlike with a car engine, you cannot restrict or increase the air intake. A turbofan engine cannot even feather its blades, unlike a typical prop aircraft. As such, “more throttle” and “less throttle” are trivially easy to identify as settings on the lever.
Networks aren’t like that. There are many reasons why, and I want to focus in here on the specific metaphor of the throttle lever. It comes from a heat engine system: more throttle implies more fuel, so you go faster, and you arrive quicker. Translated to an ISP context, if you are being “throttled”, then the network “engine” isn’t doing the “work” you have paid for.
However, networks aren’t heat engines, and don’t do “work”. They copy information, which has zero mass. You can put a photon down a 1km fibre and a 100km fibre, and they are essentially the same “effort” to send and receive. We don’t have to expend energy to overcome the friction of the air. Just look up at the photons from the moon if you don’t believe me! (Extreme pedants will note there is a thermodynamic requirement to draw energy in a computational system as the 1s become 0s. Go away.)
There is a category error involved in applying a work metaphor (such as “throttling”) to a non-work distributed computing system. They are conceptually diametrically opposed to each other! This has practical consequences, as it leads to impractical policy demands.
The performance of an application doesn’t just depend on the share of the bandwidth it gets — if we treat capacity as the “fuel”. Yes, you need quantity, but the quality matters too. Specifically, the arrival pattern of the packets (i.e. the quality) is just as important as the number you get (i.e. the quantity).
If this pattern is “unhelpful” or “unstable”, then you can get worse performance even if you deliver more bandwidth. For that matter, if I was an evil ISP, I could characterise which patterns will “upset” different applications, and engineer my traffic accordingly, with bandwidth being kept constant.
Furthermore, this is a system of two degrees of freedom (among load, loss and delay), not just one (more or less throttle). You can trade loss and delay (to a point), so the nasty “throttling” network can deliver excess loss to loss-intolerant applications, and added delay to latency-sensitive ones.
This is before we even begin to consider advanced topics like packet fragmentation, protocol constraints, and layer interactions. Trivialising the matter to “throttling” is easy for lawgeneers, but leaves policy makers and regulators with a measurement and enforcement mess to clean up.
Regrettably, overconfidence and over-assertiveness are endemic on this “net neutrality” subject. Lots of people have strong opinions, and will make all kinds of claims about what is and isn’t possible. Without a strong grounding in computer science and network performance, their pronouncements are frequently misleading and sometimes worthless.
Tragically, this erroneous “work” thinking and loose “throttling” language is now embedded into formal telecoms regulations. European national regulators have been given the unenviable task of detecting and punishing ISPs engaged in fiddling with the fuel flow. It’s a fool’s errand, and places them in an extremely difficult position, caught between their mandate to uphold the law, and an unyielding technical reality.
Fortunately, there is a way out of this uncomfortable economy travel problem for packets. If you would like to learn about it, here’s a gentle reminder that I offer first class workshops on this matter! Just hit “reply” to get in touch to schedule one. It could save you a lot of unpleasant howling and wailing noises down the regulatory flight path.
For the latest fresh thinking on telecommunications, please sign up for the free Geddes newsletter.
Read It Now
