[TUHS] Research Datakit notes

Paul Ruizendaal pnr at planet.nl
Sun Jun 26 11:17:27 AEST 2022

> On 26 Jun 2022, at 01:57, Rob Pike <robpike at gmail.com> wrote:
> One of the things we liked about Datakit was that the computer didn't have to establish the connection before it could reject the call, unlike TCP/IP where all validation happens after the connection is made. This is also why sockets and Datakit never worked together; sockets pretty much assume Ethernet-like connection rules.
> I am not a networking expert, but to me in this regard at least Datakit seemed like a prettier picture. I suppose you can DOS-attack the network, but not the machines. Datakit had other issues, for sure, like the expensive racks of hardware, but then that's because, for better and worse, it was designed by phone engineers rather than.... however you'd characterize Ethernet and its original "I scream while listening to your whisper", 5V into 50Ω Schmidt-triggered craziness. Ethernet's come a long way, but the engineering of the original Radio Shack parts was not favored by the Bell Labs crowd.

I was not putting Datakit down, just trying to explain why the V8 approach to networking may seem a little odd from a 1980’s TCP/IP perspective, but makes perfect sense from a Datakit perspective.

In the end technology often becomes a hybrid of various solutions, and maybe in this case as well. By coincidence there was a post in the Internet History mailing list earlier today that appears to make this point.

In his video (https://www.youtube.com/watch?v=ojRtJ1U6Qzw), Sandy explains why he became dissatisfied with Spider and the main reason was that doing switching/routing on a mini computer was just plain inefficient as compared to a telephone switch (at 37:06). This was 1972. The result was a new design, Datakit, that could route/switch packets at high speed and in parallel.

On the internet history list, someone quipped: "Yeah, back then the joke was that McQuillan was the only one making money from ATM. :-) That did change in a big way (for a while) in the late 90s and early 2000s, before router silicon caught up."

To this Craig Partridge responded: "Wasn't just router silicon -- it was router design.  What made ATM appealing is that it made the inside of the router or switch parallel, which was necessary to push into multigigabit rates. Folks had to figure out how to rework an Internet router to be parallel and it took at least two major innovations: fully-standalone forwarding tables with associating forwarding engines and breaking packets apart (essentially into cells), squirting those parts through the parallel backplane, and then reassembling the packet at the outbound interface for transmission." This was around 2000.

It is not my field of expertise, but it would seem to me that Sandy had figured out a core problem some 30 years before the TCP/IP world would come up with a similar solution. I would not even be surprised if I learned that modern telco routers transparantly set up virtual circuits for tcp traffic.

More information about the TUHS mailing list