The Value of History
History of Networking
The Network Collective has now recorded 18 segments featuring the origins of a technology; many future episodes are planned covering personal experiences in the network engineering world, the origins of some of the organizations and software we take for granted, and ever more stories about technology. On the other side of the world, as it were, there are college classes covering classic papers in computing, and old books on technology still sit on my shelf (such as this classic). But with so much to learn about new technology, why should we learn about all this “old stuff?”
In this figure, the network operator would like to offer what appears to be a broadcast network on top of a network topology that is a set of point-to-point links. Unicast packets are relatively easy; they can be switched host to host like any other packet on the network, along a loop free path between the source and the destination. Multicast and broadcast are a different sort of problem, however. Either of these two kinds of traffic must somehow be replicated so every host receives a single copy. But where, and by whom? In Asynchronous Transfer Mode (ATM) Local Area Network Emulation (LANE), there was a Broadcast and Unknown Server (BUS); all packets with an unknown Ethernet address, and all broadcast packets, were sent to this server. This server would replicate the packet, making certain every host attached to the network received a copy.
What good does knowing this bit of history do for you? Location-Identifier Separate Protocol (LISP), at least in the early days, solved the broadcast and unknown problem in the same way; send a copy to a set of centralized servers, and those servers will replicate the packet to every node in the network. Ethernet Virtual Private Networks (eVPNs) also solve the same problem in a similar way. The first value in knowing the history, then, is being able to see patterns like this. As RC1925, Rule 11, says:
Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
If you have a Biblical mindset, you might note that even this rule is an idea proposed again using different language (for those who are baffled, try Ecclesiastes).
From a technology perspective, knowing these patterns gives you a head start. When you encounter a new technology that needs to solve this problem—making a set of point-to-point links appear to be a broadcast segment—you are likely to find some variant of the solution used in ATM LANE (and in technologies before ATM LANE, as well). If you understand the places where ATM LANE failed, you have a good idea in knowing where to look for problems in whatever new solution you are studying.
From a technology perspective, understanding old technologies helps you understand new ones.
Knowing history can go beyond this, however. In learning history, you can see patterns in how people solved political problems, overcame challenges, and dealt with failure. In other words, there are life patterns as well as technology patterns. You can use these patterns to your advantage in your engineering career. While I can’t prove it, I am fairly certain there is actually a limited set of problems in the real world, and a limited set of solutions to those problems.
In other words, the more things change, the more they stay the same. There is value, then, in learning history through the lens of network engineering—and I would encourage every engineer to find a source of history, whether it is old books, videocasts, podcasts, and even old research papers, and learn a little history.
After all, the future might not repeat the past, but it will certainly rhyme.