The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Ruizendaal <pnr@planet.nl>
To: Rob Pike <robpike@gmail.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Research Datakit notes
Date: Sun, 26 Jun 2022 03:17:27 +0200	[thread overview]
Message-ID: <1420AC1D-8AD7-43C7-8F8B-22E1708846EF@planet.nl> (raw)
In-Reply-To: <CAKzdPgxoT5zJ-rHEe=Wqhnd4zXcUZB+Qs+0Za5bWnRuEFc7WuQ@mail.gmail.com>


> On 26 Jun 2022, at 01:57, Rob Pike <robpike@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.


  reply	other threads:[~2022-06-26  1:18 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-25 23:01 [TUHS] " Paul Ruizendaal
2022-06-25 23:09 ` [TUHS] " Larry McVoy
2022-06-25 23:57   ` Rob Pike
2022-06-26  1:17     ` Paul Ruizendaal [this message]
2022-07-02  2:51       ` Grant Taylor via TUHS
2022-07-02  2:57         ` Larry McVoy
2022-06-28 10:38     ` Derek Fawcus
2022-06-28 12:36       ` Rob Pike
2022-06-28 12:45         ` Rob Pike
2022-06-28 13:33           ` Dan Cross
2022-06-28 21:19             ` Lawrence Stewart
2022-06-28 21:34               ` Richard Salz
2022-06-29  6:07                 ` Stuart Remphrey
2022-06-28 16:11           ` Tom Teixeira
2022-06-28 18:28           ` John Floren
2022-06-28 12:47         ` Rich Morin
2022-06-28 13:13           ` Marc Donner
2022-06-28 14:41             ` Clem Cole
2022-06-28 15:54               ` Tom Teixeira
2022-06-28 17:05             ` Adam Thornton
2022-06-28 17:43               ` John Labovitz
2022-06-28 22:45               ` [TUHS] HTTP (was Re: Re: Research Datakit notes) Derek Fawcus
2022-06-26  1:41 ` [TUHS] Re: Research Datakit notes Anthony Martin
2022-06-26  9:52   ` Ralph Corderoy
2022-06-26 11:04   ` Paul Ruizendaal
2022-06-29 20:21   ` Paul Ruizendaal
2022-06-26  2:19 Noel Chiappa
2022-06-26  9:46 ` steve jenkin
2022-06-26 20:35   ` Erik Fair
2022-06-26 21:53     ` Steve Jenkin
2022-06-26 10:16 ` Paul Ruizendaal via TUHS
2022-06-26 13:07 ` John Cowan
2022-06-26 13:35   ` Larry McVoy
2022-06-26 13:58     ` John Cowan
2022-06-27  0:43 Noel Chiappa
2022-06-27  3:00 ` Erik Fair
2022-06-27 21:40 Noel Chiappa
2022-06-27 22:40 ` George Michaelson
2022-06-28 15:50 Noel Chiappa
2022-06-28 21:32 ` Lawrence Stewart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1420AC1D-8AD7-43C7-8F8B-22E1708846EF@planet.nl \
    --to=pnr@planet.nl \
    --cc=robpike@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).