From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28503 invoked from network); 25 Jun 2022 23:58:57 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 25 Jun 2022 23:58:57 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C717A40920; Sun, 26 Jun 2022 09:58:33 +1000 (AEST) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by minnie.tuhs.org (Postfix) with ESMTPS id AEC4E4088C for ; Sun, 26 Jun 2022 09:58:29 +1000 (AEST) Received: by mail-vk1-f175.google.com with SMTP id m188so2873937vkm.3 for ; Sat, 25 Jun 2022 16:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NHiwCz3+OsynTkcpmI/gpDbTIU/qs9AoepDN4m89new=; b=qNbFlG2UUwmSszblWH4uQ0fknExsrqHHfQ3OhchmZ7UPZncvq6SJ2I+YJiX6/xz6tS 6L64pscfOd3upe1NJ4VNxFLm1YGTaMNZT+cCRpBFmnfyaUbAfmrkHGj+0fbzvnGQyuMy ygwNFrEy/rYPMjLHRZBTL7/QXfC+xFSAONkDrwmw14edPvjdMkETUSYQazhFyqxLGsRS iYe0M29mfiLiueW0zdkwgGohWZmihfrE5xvJL8yB9n0dTFYh0qIQnaoBOmhBpb4So7/I TrN5uiKRNLxelMQhYb2XomcbXUj8cq/xDrKzYgSBpOYvK0MM4Xu5BgqpeAzp0fSHS0+v Wu8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NHiwCz3+OsynTkcpmI/gpDbTIU/qs9AoepDN4m89new=; b=pA7LrBLS7kZGXvuFKA6p+2cgaWm34PX5YEKqJv+Cnng6Rc0wQKPgnMnpZPx1iq+PtZ +dOL0DTufnkfmSHSa85fKP3nP7PZGeITOQPfQMXdIccNqxh9CvycODaFn6nakdEyb82I yTfrz8EHBffOWb+7UFKeIHCZ9ayGdWIgEU+NNoMyWQpxnNrI2+0g4/NDnlggaIC0DbIb APCssIZltmoI3BVh/S2RAME6+IlBjJSBTRJkXEY10h+i+mI2zCf0D0Fxat16UZ5KGmhG OQyLIo9U42tdGvlua4vDS2KHExtGJK4uCAzh5eRtWTQkSIqE8VkF5Ku+W1t9pr36KgBi +lKQ== X-Gm-Message-State: AJIora9Do/SX4Tjj9Dzv0cbNy+ZQul17VfTvT2vFcbvVvFb6NLh8aOTz hUB0yQ3cynzec5K9PnI+ZEraRu798UpljZa6j/c= X-Google-Smtp-Source: AGRyM1u84AYhjQdSZymgh1/6p29nKel2aw/hq9WpTv6819b8iO3AbP8DDRq6wxOW3Fk4Brn5SXFfdEAh8gY6K1RPJl0= X-Received: by 2002:a1f:300c:0:b0:36f:eb7d:746f with SMTP id w12-20020a1f300c000000b0036feb7d746fmr776373vkw.27.1656201448542; Sat, 25 Jun 2022 16:57:28 -0700 (PDT) MIME-Version: 1.0 References: <2803DC51-6CBC-4257-B40C-8A559C27CAE3@planet.nl> <20220625230939.GG19404@mcvoy.com> In-Reply-To: <20220625230939.GG19404@mcvoy.com> From: Rob Pike Date: Sun, 26 Jun 2022 09:57:17 +1000 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="00000000000004551c05e24e73ae" Message-ID-Hash: I3BPBRVNDRMXS4PGTFZJPAIWAHOJUT6I X-Message-ID-Hash: I3BPBRVNDRMXS4PGTFZJPAIWAHOJUT6I X-MailFrom: robpike@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Paul Ruizendaal , The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Research Datakit notes List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000004551c05e24e73ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=84=A6 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. -rob On Sun, Jun 26, 2022 at 9:09 AM Larry McVoy wrote: > Nice. Any chance you want to do a TCP/XTP comparison? > > On Sun, Jun 26, 2022 at 01:01:07AM +0200, Paul Ruizendaal wrote: > > Wanted to post my notes as plain text, but the bullets / sub-bullets ge= t > lost. > > > > Here is a 2 page PDF with my notes on Research Datakit: > > > > https://www.jslite.net/notes/rdk.pdf > > > > The main takeaway is that connection build-up and tear-down is > considerably more expensive than with TCP. The first cost is in the > network, which builds up a dedicated path for each connection. Bandwidth = is > not allocated/reserved, but a path is and routing information is set up a= t > each hop. The other cost is in the relatively verbose switch-host > communication in this phase. This compares to the 3 packets exchanged at > the hosts??? driver level to set up a TCP connection, with no permanent > resources consumed in the network. > > > > In compensation, the cost to use a connection is considerably lower: th= e > routing is known and the host-host link protocol (???URP") can be > light-weight, as the network guarantees in-order delivery without > duplicates but packets may be corrupted or lost (i.e. as if the connectio= n > is a phone line with a modem). No need to deal with packet fragmentation, > stream reassembly and congestion storms as in the TCP of the early 80???s= . > > > > Doing UDP traffic to a fixed remote host is easily mapped to using URP > with no error correction and no flow control. Doing UDP where the remote > host is different all the time is not practical on a Datakit network (i.e= . > a virtual circuit would be set up anyway). > > > > A secondary takeaway is that Research Datakit eventually settled on a > three-level ascii namespace: ???area/trunk/switch???. On each switch, the > hosts would be known by name, and each connection request had a service > name as parameter. In an alternate reality we would maybe have used > ???ca/stclara/mtnview!google!www??? to do a search. > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > --00000000000004551c05e24e73ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the things we liked about Datakit was that the comp= uter didn't have to establish the connection before it could reject the= call, unlike TCP/IP where all validation happens after the connection is m= ade. This is also why sockets and Datakit never worked together; sockets pr= etty much assume Ethernet-like connection rules.

I am no= t a networking expert, but to me in this regard at least Datakit seemed lik= e 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 designe= d by phone engineers rather than.... however you'd characterize Etherne= t and its original "I scream while listening to your whisper", 5V= into 50=E2= =84=A6 Schmidt-triggered=C2=A0crazines= s. Ethernet's come a long way, but the engineering of the original Radi= o Shack parts was not favored by the Bell Labs crowd.

-rob


On Sun, Jun 26, 2022 at 9:09 A= M Larry McVoy <lm@mcvoy.com> wrot= e:
Nice.=C2=A0 A= ny chance you want to do a TCP/XTP comparison?

On Sun, Jun 26, 2022 at 01:01:07AM +0200, Paul Ruizendaal wrote:
> Wanted to post my notes as plain text, but the bullets / sub-bullets g= et lost.
>
> Here is a 2 page PDF with my notes on Research Datakit:
>
> https://www.jslite.net/notes/rdk.pdf
>
> The main takeaway is that connection build-up and tear-down is conside= rably more expensive than with TCP. The first cost is in the network, which= builds up a dedicated path for each connection. Bandwidth is not allocated= /reserved, but a path is and routing information is set up at each hop. The= other cost is in the relatively verbose switch-host communication in this = phase. This compares to the 3 packets exchanged at the hosts??? driver leve= l to set up a TCP connection, with no permanent resources consumed in the n= etwork.
>
> In compensation, the cost to use a connection is considerably lower: t= he routing is known and the host-host link protocol (???URP") can be l= ight-weight, as the network guarantees in-order delivery without duplicates= but packets may be corrupted or lost (i.e. as if the connection is a phone= line with a modem). No need to deal with packet fragmentation, stream reas= sembly and congestion storms as in the TCP of the early 80???s.
>
> Doing UDP traffic to a fixed remote host is easily mapped to using URP= with no error correction and no flow control. Doing UDP where the remote h= ost is different all the time is not practical on a Datakit network (i.e. a= virtual circuit would be set up anyway).
>
> A secondary takeaway is that Research Datakit eventually settled on a = three-level ascii namespace: ???area/trunk/switch???. On each switch, the h= osts would be known by name, and each connection request had a service name= as parameter. In an alternate reality we would maybe have used ???ca/stcla= ra/mtnview!google!www??? to do a search.

--
---
Larry McVoy=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Retired to fishing=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.mcvoy.com/lm/boat
--00000000000004551c05e24e73ae--