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.
Many things have been reinvented independently in solving some particular problem. The spanning tree algorithm is a reinvention of the depth-first search, first investigated by 19th century French mathematician Charles Tremaux while working on the expansion of the French telegraph system. I guess that actually was actually a very similar problem.
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."
Ah the bit the Ethernet people got "wrong",
OK, war story.
remember the thick yellow ethernet and the side shoots, the self puncturing center tap to the thick cable . After a few years of changes the big cable sort of looiked a bit holly...
Or the company I worked at that had two buildings , about 500 m apart, who decided to lay a think yellow cable between the buildings, to connect the two computer centers.
would have worked great, apart from the installer who insisted on earthing both ends of the braid to the building earth. One building had VERY big machine presses sucking hundreds of amps at a time when they struck, and the other was a small office. 'worked', for a while till the earths in the machine shop were changed, The blue smoke from the Ethernet cable one day was the braid melting the plastic.
Or trying to document where a data tap had to go on the big yellow cable, and what angle. As you could not turn the cable very well, it was too stiff, if the tap had to come out at a certain angle to fit into the cabinets, then fun.
The idea of fitting the yellow cable and then tapping on site was just not in the procedures, we HAD to make up cable harnesses to a document, then feed them into the cabinet !
Dont think the procedures ever did catch up with the idea that many things could sit anywhere on the cable, it did not matter what order you wired them in/ Each and every time a cabinet was wired up, we had to do a change request to accomodate the system. Each cabinet to a standard, each one different.