Where is the governor for packet networks?

The progress of steam power was dependent on being able to regulate flow via a pressure governor. Networking has yet to learn this lesson.

Where is the governor for packet networks

Personally speaking, I don’t particularly fancy being scalded to death. It doesn’t sound like a fabulous way to exit this life. Being drowned in a vat of premium quality liquefied dark chocolate, possibly. But having my skin ripped off by high-pressure steam venting at supersonic speeds isn’t enticing.

Nor is being explosively blasted hundreds of feet across the local terrain, with my organs splatted out of my abdomen on impact. And I definitely don’t relish being impaled by splaying pipes that have been ruptured due to being loaded beyond their design limits. It’s unpleasant and undignified.

Yet these were relatively normal occurrences not so long ago (apart from the drowning in cocoa products—it was molasses you had to worry about.) During the steam power era we were forced to contain and channel a powerful force, one with much danger: superheated water in close proximity to engine operators.

The steam engine went through many stages of development and improvement, with dozens of contributors. Thomas Newcomen, an Englishman, invented the basic reciprocating beam engine. James Watt, a Scotsman, perfected its efficiency and power by a a rotary design with a separate condenser unit.

It is that power which then proved to be both a blessing and curse. It enabled miniaturisation and reduced weight, making railroad trains feasible — on which Watt filed the original steam engine patent. It also reduced the cost of oceanic voyages by 95%, and the time by 80%.

Yet it also tested the materials of the time to their limits, and their frequent failures were often hideously lethal. So another of Watt’s contributions was the centrifugal governor, with one pictured below.

The critical contribution of the governor was to prevent overload of the system. As the speed of rotation increased, a valve was progressively closed to limit the flow of energy through the system. This in turn prevented the rupture of the boiler and pipes with catastrophic consequences for both man and machine.

It was also Watt who came up with the basic unit of supply and demand: horsepower. The enabled the steam engineer to reason about whether any system could supply a given demand for energy flow. It took James Clerk Maxwell, another Scot, to formally describe the physics of steam flow.

We can now begin to draw the parallels with packet networking. Our present era is “broadband beam engine”, and is extremely inefficient and ineffective, but amazing compared to not having it at all. That people experience frequent “burst pipes” has been normalised (and indeed, fetishised by the folly of “net neutrality”.)

What Watt’s horsepower is to steam, Davies’s quality attenuation is to distributed computing: a standard unit (in the ∆Q calculus) of supply and demand for “information flow”. With such metrics, we are able to accurately reason about supply and demand, and whether there is a “safety margin” we can depend upon.

Yet there is a crucial difference between steam and telecoms: a steam engine does “work”, which can be measured in… Watts! But the value of networks is not in “work”, despite the misleading name: “net-work”. Nonetheless, we implicitly categorise networks as “information engines” that do “work” by using “work conserving” queues.

We attempt to maximise throughput, so we suck in as many packets as possible, overloading the onward “pipes”. Many people are aware that our present networks lack a much-needed “flow governor”, and have attempted to build one. These always end up in disappointment, for a subtle yet simple reason.

What they attempt to do is to restrict the bandwidth of traffic leaving the network core to the bandwidth at the edge. This looks like a good idea, but never works out as intended. For if you take, say, a 5 minute throughput average, your “miniburst” spikes of traffic cause seconds-long overloads.

Should you reduce your interval of interest to, say, ten seconds, then the “microbursts” overload the buffers. And so on, as the traffic structure is fractal. No matter how short you make your bandwidth average interval, the “nanobursts”, “picobursts”, and “femtobursts” always get you in the end.

There is no quality in averages, and any interval can have a demand “spike” above the intended average load limit, no matter how short.

The answer is simple. You need a new kind of flow governor that is “antifractal” (and “antifragile”, too). After all, the fractal nature of the traffic is merely a side-effect of our misbegotten belief that networks do “work”. This flow governor ensures that packets are only sent when they won’t encounter any previous one you’ve emitted.

Rather than limiting average quantity, we instead seek to take full control over instantaneous quality. This new kind of flow governor is what we are commercially deploying at Just Right Networks Ltd.

Who knows, it might even have a transformative effect on the value and economics of broadband. After all, Dr Davies is Welsh by origin, and my ancestors are Welsh and Scottish. We’ve got a British breakthrough science and engineering tradition to keep up!

 

For the latest fresh thinking on telecommunications, please sign up for the free Geddes newsletter.

;

Get your fresh thinking with free Geddes newsletter

    We won't send you spam. Unsubscribe at any time.

    Powered By ConvertKit