Not to detract from the achievements of these smart people, but I don't think that this is the whole story. Necessarily.
For example, what Metcalfe did was brilliant, but little of it survives in today's Ethernet. The format of the basic "type" frame, yes. The carrier sense and collision detect protocol, with backoff, not really. That's not how the Ethenets work anymore. Ethernets of today are actually much simpler. Just fire off those frames, and if there's a traffic jam at a merge point, put them in a queue. (And all sorts of more or less implemented schemes for prioriting frames in a queue, which are not really standardized.)
If that original CSMA/CD protocol is used at all, it's only as a legacy protocol in a single host-switch interface. Does nothing to control traffic jams anymore.
The spanning tree protocol, I studied that from a book called "Flows in Networks," L.K Ford and D.R. Fulkerson, where the initial edition was dated 1962. It was applied to Ethernet, later on when switches were used to tie together Ethernet links, true enough. And it works very well indeed. And Radia's book is a good read, humorous, and even engrossing. But how about those other two very smart people, back in 1962?
BTW, I was intrigued by the notion of "routing by name." Seems understandable enough that a name, assuming it's unique, is just as good an identifier as a 48-bit MAC address. My problem is, though, that unless names are carefully constructed, they will end up being just as un-hierarchical as MAC addresses are. Which makes actual "routing" a matter of every router having a list of all names. Hmmm.
Metcalfe and others at the event were clear only two things remain of the original Ethernet--the name and the packet format.
As for spanning tree, no one mentioned prior art. I'll see if I can get Radia to chime in.
I asked Radia how the Ford Fulkerson algorithm, and minimum weight spanning tree computation algorithms, related to her spanning tree algorithm, and this is her explanation, which I am posting with her permission:
"The concept of a graph which is a spanning tree is indeed super old...I have no idea how old. But I believe the algorithms prior to the Ethernet spanning tree algorithm are not distributed...in other words, one computer gets as input, the full view of the network, and calculates a spanning tree on the graph with various properties (e.g. minimum cost, where the sum cost of all the links in the tree is minimal across all possible trees).
I think the Ford Fulkerson algorithm the person is talking about is the "max flow" problem, which is yet even a different problem, and actually isn't even a tree...you want lots of paths to push as much "flow" as possible.
So, hopefully I'm explaining it clearly. A graph problem where one computer does computations based on seeing the whole graph is different from the Ethernet spanning tree algorithm, in which you just plug things together and the bridges do really minimal work and keep minimal state in order to do a "distributed computation."
The reason the Ethernet spanning tree algorithm is so simple is that it is not calculating a "minimal cost" tree...the goal was to be very simple and have "constant overhead" (the amount of memory necessary for bridge B to run the algorithm is the size of a spanning tree message, about 50 bytes, times the number of ports on B). For instance, if B has 7 ports, it takes 7*50 bytes, or 350 bytes, for B to run the algorithm. The tree it computes I call "greedy", which is a tree in which everyone tries to get closest to the Root bridge, which might arguably be preferable to a minimum cost spanning tree which could wind up being very long. And the Ethernet spanning tree algorithm handles not only a single computation, but it is always active, and reacting to failures."
Gallager, Humblet and Spira have a distributed algorithm to compute a minimum *weight*spanning tree (also known as "minimal cost").
Because it is calculating an optimal tree according to minimal weight, it is
much more complex and expensive than the Ethernet spanning tree algorithm. Furthermore, I don't think it handles link failures, though I suppose one could add something to have some sort of signal that everyone should start over when a link fails, but it would be tricky. But as I said, it's a different problem.
So basically...distributed algorithms are totally different than graph problems where one node has the complete graph and does computations."
It has been fascinating to watch ethernet - data comm's "wild child" - adapt, adopt and improve the policing, timing and QoS functions of pdh, sonet and atm. Ethernet did not just "win" over these technologies - it ingested them....
Here is a comment Bob Metcalfe shared with me last night over email:
"When people say that the only thing left of Ethernet is the name and frame, they are right sort of, but they are overlooking the idea of a high-bandwidth packet LAN for PCs, which was revolutionary in its time and commonplace (not noticed) today. Or they are overlooking the Ethernet Ethic, which I reviewed in my terminal keynote last week - de jure standard, owned implementations, fierce competition, interoperability, evolution, backward compatibility."
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.