Well, if there’s a headline about the Future of Communications designed to attract attention, this one is it: computer networking is dead.
Let’s qualify what “computer networking is dead” means, because it could easily be misinterpreted. By “computer networking” I mean the distinct discipline of joining physical computers together over data networks. It’s done and gone. Finito. This is a good thing: Do not fear death so much but rather the inadequate life – Bertolt Brecht.In its place is the era of distributed supercomputing. This looks superficially similar, but is a different discipline, and one which requires a technological and skills transformation. The catalysts for radical change include the arrival of software-defined networking (SDN) and network function virtualisation (NFV).To understand why computer networking is dead, we must first return to its birth.
Packets and punch cards
Back in the 1930s, pioneers of computing like Turing, Church and von Neumann produced a theory of computation. They defined what it means to compute. It is the reason why we can compose functions and subroutines and know that we will get a meaningful and consistent result. Computer programming is only possible because we have this compositional property.
Then in the 1940s we started to build real-life digital computers. So the foundations of computation were in place before we began building computers. However, those foundations were incomplete.
Turing et al modelled the idea of distributed computing, with multiple Turing machines reading and writing symbols on a hypothetical ticker tape. The exchange of those symbols between computational processes was assumed to be always instant and perfect. As a consequence, the entirety of networking was omitted from the model.
Given we’d not even built a single digital computer at that time, it’s entirely forgivable that this issue wasn’t uppermost in their minds. The earliest computer turned a set of inputs on switches into a set of electrical outputs. Then we built another one. And more, and yet more again! Before long we were storing the prolific results of those symbolic computations on little punched cards.
Then one fine day, someone took a punched card from one computer, walked across a lab, and fed it into another computer. At that moment, computer networking blinked into the light, drew its first breath, and issued a newborn yelp.
Three fatal flaws
As we shall soon see, first steps are fateful. This early conceptual model cursed computer networking in three fatal ways:
- Computer networking started at the physical edge of one computer (where a punched card came out), and ended at the physical edge of another computer (where it was fed in).
- There was a physical thing to be moved between the computers as quickly as possible, and losing the physical thing being sent was really bad.
- The movement of that physical data object between computers took place on a radically longer timescale to the movement of data within the computer.
Unwittingly, we carried on, as we wanted to exchange larger quantities of data, and do it faster, over bigger distances. We moved from cards to tapes to networks. Computers were linked together within a single facility, and then the natural thing to do was to press into use the pre-existing infrastructure of the telephone network to speed data exchange. Early digital networks created circuits between computer facilities, like fast telephone calls. Packet networks did away with the circuits and allowed is to multiplex data together more tightly and cheaply.
The network isn’t yet a distributed supercomputer
Yet these basic ideas have persisted throughout the history of computer networking, in one form or another, despite myriad technical changes:
- We think of computer networking as starting at the physical network port on the outside of a box that contains the computer (or at the baseband chip on a wireless device). Internet Protocol addresses an interface on a computer because it conceptually follows this model. What goes on inside the computer isn’t regarded as networking.
- The network is the physical thing for moving the data, and exists outside the computers. We design networks to deliver as many packets as quickly as possible, as if we were delivering punched cards. We assume moving packets creates value, just like moving a punched card used to. Packet loss is seen as “congestion”, as if we’d dropped something valuable that we had committed to take care of. This is deemed to be an intrinsically bad thing.
- We use protocols like TCP to create control loops to manage this “congestion” on timescales that are many orders of magnitude greater than the computations being performed. We treat the signalling as if it were working in the physical world – “slow down”. You can call across the lab to ask for more punched cards, or to tell the card carrier to take a break.
What unifies these ideas is the concept of the network being about moving data, as if it were a physical thing. This seems so intuitively appealing and obvious, how can we possibly have got it so wrong?
What went very very very wrong
Computer networking is about automating punch card exchange, just sped up a billion-fold. It is fatally flawed because it mistakes the artefact for the action: it’s not about the punched cards, or the packets. Networking is really about inter-process communication, no more and no less.
Its purpose is to take the results from one computation and translocate it to another, in order to (eventually) generate some kind of experiential outcome for the user in the physical world. This is really subtle in how it differs from the “punched card carrying” metaphor of computer networking that people carry in their heads:
- Inter-process communications (IPC) begins and ends at the computation processes, not at the edge of a beige metal box. This becomes a serious problem when we virtualise the computation processes and the network, because there is no beige box anymore! There is now an additional layer of multiplexing and software control which is solely concerned with getting data to and from computation processes, not merely part-way across that path. As a result, the tools and techniques of the past create poor performance and cost outcomes when virtualised, especially in access networks.
- IPC is about flows of data, not individual packets. We aren’t moving punched cards, and the divisions of that data flow into packets are arbitrary. The information is not lost if a packet is dropped – a duplicate can be created at no cost, albeit with additional delay. “All packets are created equal” belongs in a dystopian novel about networking, not in an engineering text book. This belief leads to wasteful network resource usage and poor user experience outcomes by misallocating resources. Virtualisation amplifies this error.
- The data moves faster than the control system, not the other way round.Packets move at the speed of light in networks. We can’t call across the room faster than the packet porter can shovel packets. Yet in the computer networking model we behave as if we can, with very unfortunate consequences. It’s like trying to control automobile traffic jams by getting people to send postcards on arrival to advise future travellers of the best routes and departure times. Their experience of the past has little to do with the conditions in the future. Whilst we can get away with this (to some degree) with TCP, we can’t do this with the complex control systems of virtualised resources.
As a result, we must align with the true nature of the underlying resources and system of sharing. That means we must let go of many of the hacks and horrors of the networking past. Virtualisation of an inefficient, ineffective and unstable system doesn’t magically make it efficient, effective and stable – indeed, quite the opposite occurs, as it can become more inefficient, less effective and more unstable.
Time to transcend the sins of the past
Computer networking is dead because there is no physical “computer” and no physical “network”: the boundaries of the boxes are no longer the critical divide. The bad consequences of this wrong model keep showing up everywhere as problems with performance, cost and security.
Internet Protocol addresses the network interface, not the end application. This is a basic design flaw that cannot be undone. As a consequence, it is hard to secure individual applications, separately identify and isolate flows from different applications, and to successfully virtualise the communications requirements of applications in order to deliver greater efficiency.
Instead we have a “data sludge” which sloshes between network interfaces, and is picked over by deep packet inspection and network policy boxes like trash in a third world garbage dump. We spend a huge fortune retrofitting networks with intrusion detection and media gateways to have the kinds of properties they ought to have if they were built from the ground-up to perform IPC.
The cause of our problems is that we have disconnected the data transport from the desired application outcomes and the consequent requirements on the network. The “gap” between the computational process and network interface is what makes the idea of “computer networking” unsustainable in the long run.
That means the death of computer networking is not something to mourn. As American philosopher Elbert Hubbard wryly noted: Die, v.: To stop sinning suddenly.
Technologies in transition
We are now creating interactive distributed applications where computation is spread between a browser, content delivery systems and centralised cloud servers. This is running on top of a distributed architecture which is being virtualised using software defined networking (SDN) and network function virtualisation (NFV).
There will be a decade of trying to retrofit the needs of this new environment to the computer networking technologies of the past. This is going to be painful and slow. A whole raft of new technologies and protocols are likely to be required in order to make this work well. Technologies like TCP/IP were for a batch processes and file transfer world with a bit of telnet on the side. It is not certain that they will make it across this huge divide; my view is that a more fundamental re-think is necessary to get to the outcome we desire.
That is because this new unified architecture of virtualised distributed computing won’t look like today’s conceptual model of “networked computing”. At present we think of the device, the network and the cloud as discrete components linked together. In future this is one “liquid” distributed computing fabric, where you can dynamically distribute computation, and dynamically allocate resources to make it happen.
There is only computation and information translocation, all controlled by a centralised resource allocation system that makes trade-offs of performance and cost. That doesn’t fit the punched cards mental model and its current technological instantiation.
The Turing of translocation
The calculations of where and when to compute and communicate require you to know the effects of your actions. In today’s networks that is not possible, since they exhibit emergent and non-deterministic behaviours. This is another reason why TCP/IP is unlikely to be the protocol suite of the future, although it won’t stop us trying to force-fit it into place for a decade or two.
There will come a day where promoting an “all-IP” world will get you fired.
Just as programming can’t work without a basic compositional theory of computation, the control systems for this new distributed computing world won’t work without a compositional theory of translocation. That requires an advance in our basic understanding of translocation comparable to what Turing achieved for computation.
Thankfully, this exists.
So whilst SDN and NFV take tentative steps into this new space, they are really just transitional technologies. They lack a unifying dynamic resource allocation system which is predictable in its operation and outcomes for large distributed systems. Even these early forays into distributed computation will push the boundaries of what is currently possible. Most notably, it requires a more formal engineering approach, rather than the craftsman-tinkerer methodology currently in vogue.
As Prof Nick McKeown of Stanford University writes [registration required]:
An understanding of how to design and build distributed systems will be the key differentiating skill much sought after in the next 10 years. Any designer with demonstrated experience and skill creating distributed systems will be in very high demand.
Distributed supercomputing is the future. Computer networking is dead.
I didn’t attend the funeral, but I sent a nice letter saying I approved of it. – Mark Twain
To keep up to date with the latest fresh thinking on telecommunication, please sign up for the Geddes newsletter
Read It Now
