From geoff at iconia.com  Tue Apr  1 10:47:51 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 1 Apr 2025 10:47:51 -0700
Subject: [ih] =?utf-8?q?In_loving_memory_of_=28Mr=2E_Bufferbloat=29_Dave_?=
 =?utf-8?b?VMOkaHQgPDM=?=
In-Reply-To: <CAJUtOOgQ9WxB6p68h_3kxA+nTOZ64EXpUrf7TM849dMLiOYinw@mail.gmail.com>
References: <CAJUtOOizHZCey6KihyRHkZ9N4FJwyzuM5RL6QXPejCSWnbPE3g@mail.gmail.com>
 <CAJUtOOgQ9WxB6p68h_3kxA+nTOZ64EXpUrf7TM849dMLiOYinw@mail.gmail.com>
Message-ID: <CAEf-zrgLQn3U_0UJvtE2Ju_EDm0YtOPVutvqDCEW0JLD+4pLWg@mail.gmail.com>

---------- Forwarded message ---------
From: Frantisek Borsik <frantisek.borsik at gmail.com>
Date: Tue, Apr 1, 2025 at 7:27?PM
Subject: In loving memory of Dave T?ht <3

Hello to all,

We?re devastated to announce that Dave T?ht has passed away.
<https://libreqos.io/2025/04/01/in-loving-memory-of-dave/>

Dave was an amazing man, helping the world with FQ-CoDel and CAKE, fighting
bufferbloat and trying to make the world a better place. Always willing to
help, and without him ? LibreQoS (and the other QoE solutions out there)
wouldn?t exist.

Dave was an inspiration, and we all miss him. We?re reaching out to family
and close friends to see if there?s anything we can do to help.

Dave was an inspiration to us. Dave?s contributions to Linux, FQ-CoDel, and
CAKE improved internet connectivity around the world for millions of
people. Because of him, millions of people now have access to reliable
video calls ? and in turn, access to loved ones, healthcare, and community.
One of Robert?s ISP customers is a kind paraplegic woman who lives in a
far-flung rural Colonia around El Paso, Texas. Her reliable access to her
doctors through telemedicine, and to her family through FaceTime, was only
made possible because of his algorithms. There are millions of cases like
hers, where Dave?s contributions have silently enabled human connection and
safety. Everything Dave contributed to the world of technology was free and
open source, for the betterment of humanity.

Dave is the reason that Starlink was able to tackle its latency issues ?
enabling a generation of young entrepreneurs across the developing world,
such as these young folks pictured in the Phillipines, to start their own
ISPs to expand internet access to their communities. Dave started work on
FQ-CoDel in part because of his own journey working to expand internet
access in Nicaragua, so we know he saw that his work had come full-circle
and helped so many.

We?re incredibly grateful to have Dave as our friend, mentor, and as
someone who continuously inspired us ? showing us that we could do better
for each other in the world, and leverage technology to make that happen.
He will be dearly missed.

*PS: *Dave is forever in our hearts and souls, in our routers and...in
production!

*https://github.com/LibreQoE/LibreQoS/pull/684
<https://github.com/LibreQoE/LibreQoS/pull/684>*

All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik at gmail.com


-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From jmamodio at gmail.com  Tue Apr  1 15:53:53 2025
From: jmamodio at gmail.com (Jorge Amodio)
Date: Tue, 1 Apr 2025 17:53:53 -0500
Subject: [ih] 
	=?utf-8?q?In_loving_memory_of_=28Mr=2E_Bufferbloat=29_Dave_?=
	=?utf-8?b?VMOkaHQgPDM=?=
In-Reply-To: <CAEf-zrgLQn3U_0UJvtE2Ju_EDm0YtOPVutvqDCEW0JLD+4pLWg@mail.gmail.com>
References: <CAJUtOOizHZCey6KihyRHkZ9N4FJwyzuM5RL6QXPejCSWnbPE3g@mail.gmail.com>
 <CAJUtOOgQ9WxB6p68h_3kxA+nTOZ64EXpUrf7TM849dMLiOYinw@mail.gmail.com>
 <CAEf-zrgLQn3U_0UJvtE2Ju_EDm0YtOPVutvqDCEW0JLD+4pLWg@mail.gmail.com>
Message-ID: <CAMzo+1YtKvNS+Lnyxz0_JjwHNybB2ZwJahCEQkay=nLNvk8qaw@mail.gmail.com>

Big loss for the community. Condolences to family and friends.

RIP and GoodSpeed Mr.  Bufferbloat.

Regards
-Jorge

On Tue, Apr 1, 2025 at 12:48?PM the keyboard of geoff goodfellow via
Internet-history <internet-history at elists.isoc.org> wrote:

> ---------- Forwarded message ---------
> From: Frantisek Borsik <frantisek.borsik at gmail.com>
> Date: Tue, Apr 1, 2025 at 7:27?PM
> Subject: In loving memory of Dave T?ht <3
>
> Hello to all,
>
> We?re devastated to announce that Dave T?ht has passed away.
> <https://libreqos.io/2025/04/01/in-loving-memory-of-dave/>
>
> Dave was an amazing man, helping the world with FQ-CoDel and CAKE, fighting
> bufferbloat and trying to make the world a better place. Always willing to
> help, and without him ? LibreQoS (and the other QoE solutions out there)
> wouldn?t exist.
>
> Dave was an inspiration, and we all miss him. We?re reaching out to family
> and close friends to see if there?s anything we can do to help.
>
> Dave was an inspiration to us. Dave?s contributions to Linux, FQ-CoDel, and
> CAKE improved internet connectivity around the world for millions of
> people. Because of him, millions of people now have access to reliable
> video calls ? and in turn, access to loved ones, healthcare, and community.
> One of Robert?s ISP customers is a kind paraplegic woman who lives in a
> far-flung rural Colonia around El Paso, Texas. Her reliable access to her
> doctors through telemedicine, and to her family through FaceTime, was only
> made possible because of his algorithms. There are millions of cases like
> hers, where Dave?s contributions have silently enabled human connection and
> safety. Everything Dave contributed to the world of technology was free and
> open source, for the betterment of humanity.
>
> Dave is the reason that Starlink was able to tackle its latency issues ?
> enabling a generation of young entrepreneurs across the developing world,
> such as these young folks pictured in the Phillipines, to start their own
> ISPs to expand internet access to their communities. Dave started work on
> FQ-CoDel in part because of his own journey working to expand internet
> access in Nicaragua, so we know he saw that his work had come full-circle
> and helped so many.
>
> We?re incredibly grateful to have Dave as our friend, mentor, and as
> someone who continuously inspired us ? showing us that we could do better
> for each other in the world, and leverage technology to make that happen.
> He will be dearly missed.
>
> *PS: *Dave is forever in our hearts and souls, in our routers and...in
> production!
>
> *https://github.com/LibreQoE/LibreQoS/pull/684
> <https://github.com/LibreQoE/LibreQoS/pull/684>*
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.borsik at gmail.com
>
>
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From bzg at gnu.org  Tue Apr  1 21:30:15 2025
From: bzg at gnu.org (Bastien Guerry)
Date: Wed, 02 Apr 2025 06:30:15 +0200
Subject: [ih] 
 =?utf-8?q?In_loving_memory_of_=28Mr=2E_Bufferbloat=29_Dave_?=
 =?utf-8?b?VMOkaHQgPDM=?=
In-Reply-To: <CAEf-zrgLQn3U_0UJvtE2Ju_EDm0YtOPVutvqDCEW0JLD+4pLWg@mail.gmail.com>
References: <CAJUtOOizHZCey6KihyRHkZ9N4FJwyzuM5RL6QXPejCSWnbPE3g@mail.gmail.com>
 <CAJUtOOgQ9WxB6p68h_3kxA+nTOZ64EXpUrf7TM849dMLiOYinw@mail.gmail.com>
 <CAEf-zrgLQn3U_0UJvtE2Ju_EDm0YtOPVutvqDCEW0JLD+4pLWg@mail.gmail.com>
Message-ID: <87jz83chig.fsf@bzg.fr>

the keyboard of geoff goodfellow via Internet-history
<internet-history at elists.isoc.org> writes:

> We?re devastated to announce that Dave T?ht has passed away.
> <https://libreqos.io/2025/04/01/in-loving-memory-of-dave/>

Thanks for sharing.

Dave contributed to the GNU Emacs Org-Mode community with "gnugol":

https://list.orgmode.org/4D210A00.9070901 at teklibre.org/

In 2012, he travelled to France and bought me a beer to thank me for my
work on Org-Mode: it was the first time anyone had bought me a beer to
say "thank you" for Free Software, and it was great. He was enthusiastic
about this worldwide connection, and insisted on how great it was to be
able to connect with *everyone* in this way... we certainly miss him and
that spirit.

-- 
 Bastien


From gregskinner0 at icloud.com  Thu Apr  3 00:11:33 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Thu, 3 Apr 2025 00:11:33 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
Message-ID: <E6AF1BAF-BB03-4A05-A431-EB8811FEBAC6@icloud.com>

For what it's worth, the PILC (Performance Implications of Link Characteristics) WG took up the issue of lossy networks around the end of last century. [1] A quick scan of their mailing list indicated some discussion of amateur (ham) and even some military packet radio networks. [2]

--gregbo

[1] https://datatracker.ietf.org/wg/pilc/about/
[2] https://mailarchive.ietf.org/arch/browse/pilc/

From stewart at serissa.com  Thu Apr  3 12:45:19 2025
From: stewart at serissa.com (Larry Stewart)
Date: Thu, 3 Apr 2025 15:45:19 -0400
Subject: [ih] Internet-history Digest, Vol 65, Issue 3
In-Reply-To: <mailman.5.1743706803.10955.internet-history@elists.isoc.org>
References: <mailman.5.1743706803.10955.internet-history@elists.isoc.org>
Message-ID: <520B44CE-6485-442D-99D1-066DE9D6692C@serissa.com>

I wasn't aware of the PILC work but just because it is interesting and mathy and fun I'll mention that network coding, I think invented after 2005, is relevant.  Matteo Frigo and I worked on this in 2014 and there's a bunch of work by others. The essential idea is a rateless error correcting code. The transmitter keeps sending packets and when the receiver gets "enough" of them it can reconstruct the entire message. 

One implementation transmits pseudorandom linear combinations of all previous packets and when you get enough of them a solution to the linear equations becomes possible. The details are how to estimate the error rate and assure incremental progress.

I think Microsoft has a paper in which they use this idea to implement commuter van wifi via a noisy cellular link.

With nearly free computation maybe it's time to take another look at forward error correction.

> On Apr 3, 2025, at 15:00, internet-history-request at elists.isoc.org wrote:
> 
> ?Send Internet-history mailing list submissions to
>    internet-history at elists.isoc.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://elists.isoc.org/mailman/listinfo/internet-history
> or, via email, send a message with subject or body 'help' to
>    internet-history-request at elists.isoc.org
> 
> You can reach the person managing the list at
>    internet-history-owner at elists.isoc.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Internet-history digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: TCP RTT Estimator (Greg Skinner)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 3 Apr 2025 00:11:33 -0700
> From: Greg Skinner <gregskinner0 at icloud.com>
> To: internet-history at elists.isoc.org
> Subject: Re: [ih] TCP RTT Estimator
> Message-ID: <E6AF1BAF-BB03-4A05-A431-EB8811FEBAC6 at icloud.com>
> Content-Type: text/plain;    charset=us-ascii
> 
> For what it's worth, the PILC (Performance Implications of Link Characteristics) WG took up the issue of lossy networks around the end of last century. [1] A quick scan of their mailing list indicated some discussion of amateur (ham) and even some military packet radio networks. [2]
> 
> --gregbo
> 
> [1] https://datatracker.ietf.org/wg/pilc/about/
> [2] https://mailarchive.ietf.org/arch/browse/pilc/
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> 
> 
> ------------------------------
> 
> End of Internet-history Digest, Vol 65, Issue 3
> ***********************************************



From b_a_denny at yahoo.com  Thu Apr  3 13:19:33 2025
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Thu, 3 Apr 2025 20:19:33 +0000 (UTC)
Subject: [ih] Internet-history Digest, Vol 65, Issue 3
In-Reply-To: <520B44CE-6485-442D-99D1-066DE9D6692C@serissa.com>
References: <mailman.5.1743706803.10955.internet-history@elists.isoc.org>
 <520B44CE-6485-442D-99D1-066DE9D6692C@serissa.com>
Message-ID: <33374816.1467833.1743711573095@mail.yahoo.com>

 Pretty sure network coding was a topic before 2005.? I think?? I first heard about it in the 90s. If you are interested in learning more, I believe?Muriel M?dard?was a significant early? contributor in the field.
barbara?
    On Thursday, April 3, 2025 at 12:45:44 PM PDT, Larry Stewart via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 I wasn't aware of the PILC work but just because it is interesting and mathy and fun I'll mention that network coding, I think invented after 2005, is relevant.? Matteo Frigo and I worked on this in 2014 and there's a bunch of work by others. The essential idea is a rateless error correcting code. The transmitter keeps sending packets and when the receiver gets "enough" of them it can reconstruct the entire message. 

One implementation transmits pseudorandom linear combinations of all previous packets and when you get enough of them a solution to the linear equations becomes possible. The details are how to estimate the error rate and assure incremental progress.

I think Microsoft has a paper in which they use this idea to implement commuter van wifi via a noisy cellular link.

With nearly free computation maybe it's time to take another look at forward error correction.


> Date: Thu, 3 Apr 2025 00:11:33 -0700
> From: Greg Skinner <gregskinner0 at icloud.com>
> To: internet-history at elists.isoc.org
> Subject: Re: [ih] TCP RTT Estimator
> Message-ID: <E6AF1BAF-BB03-4A05-A431-EB8811FEBAC6 at icloud.com>
> Content-Type: text/plain;? ? charset=us-ascii
> 
> For what it's worth, the PILC (Performance Implications of Link Characteristics) WG took up the issue of lossy networks around the end of last century. [1] A quick scan of their mailing list indicated some discussion of amateur (ham) and even some military packet radio networks. [2]
> 
> --gregbo
> 
> [1] https://datatracker.ietf.org/wg/pilc/about/
> [2] https://mailarchive.ietf.org/arch/browse/pilc> https://elists.isoc.org/mailman/listinfo/internet-history
> 
> 
> ------------------------------
> 
> End of Internet-history Digest, Vol 65, Issue 3
> ***********************************************

-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  

From stewart at serissa.com  Sun Apr  6 21:23:29 2025
From: stewart at serissa.com (Lawrence Stewart)
Date: Mon, 7 Apr 2025 00:23:29 -0400
Subject: [ih] Packet Radio cartoon from 1978
Message-ID: <EEB15BA9-70EC-4B09-B8C2-2E40AE576B87@serissa.com>

I was restacking papers and came across a packet radio drawing by Ted Kaehler at PARC SSL around 1978, when John Shoch and Hal Murray and I were working on the Bay Area PRNet.

Since I can?t attach images here (can I?) I put it at
https://larry.stewart.org/2025/04/07/packet-radio-1978/

-Larry

I wish I had full set of Ted?s drawings.  



From b_a_denny at yahoo.com  Sun Apr  6 22:18:34 2025
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Mon, 7 Apr 2025 05:18:34 +0000 (UTC)
Subject: [ih] Packet Radio cartoon from 1978
In-Reply-To: <EEB15BA9-70EC-4B09-B8C2-2E40AE576B87@serissa.com>
References: <EEB15BA9-70EC-4B09-B8C2-2E40AE576B87@serissa.com>
Message-ID: <458896688.2409052.1744003114960@mail.yahoo.com>

 Thanks!
I think you are generous in saying that the packet radio units (PRUs) were as small as microwaves.
barbara
    On Sunday, April 6, 2025 at 09:23:53 PM PDT, Lawrence Stewart via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 I was restacking papers and came across a packet radio drawing by Ted Kaehler at PARC SSL around 1978, when John Shoch and Hal Murray and I were working on the Bay Area PRNet.
Since I can?t attach images here (can I?) I put it at
https://larry.stewart.org/2025/04/07/packet-radio-1978/

-Larry

I wish I had full set of Ted?s drawings.? 


  

From gregskinner0 at icloud.com  Tue Apr  8 09:50:08 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Tue, 8 Apr 2025 09:50:08 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
Message-ID: <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>

I found a 1976 report by Jim Mathis describing an early TCP implementation (in pseudocode) that was compliant with RFC 675 (INWG 72). [1] It was cited in a report by Darryl Rubin, another SRI packet radio contributor. [2]

--gregbo

[1] https://nsarchive.gwu.edu/sites/default/files/documents/5793284/National-Security-Archive-James-E-Mathis.pdf
[2] https://upload.wikimedia.org/wikipedia/commons/6/6f/Army_Packet_Radio_Network_Protocol_Study_-_SRI%2C_November_1977.pdf

From vint at google.com  Tue Apr  8 10:10:24 2025
From: vint at google.com (Vint Cerf)
Date: Tue, 8 Apr 2025 13:10:24 -0400
Subject: [ih] TCP RTT Estimator
In-Reply-To: <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
Message-ID: <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>

nostalgia!!!!

v


On Tue, Apr 8, 2025 at 12:50?PM Greg Skinner via Internet-history <
internet-history at elists.isoc.org> wrote:

> I found a 1976 report by Jim Mathis describing an early TCP implementation
> (in pseudocode) that was compliant with RFC 675 (INWG 72). [1] It was cited
> in a report by Darryl Rubin, another SRI packet radio contributor. [2]
>
> --gregbo
>
> [1]
> https://nsarchive.gwu.edu/sites/default/files/documents/5793284/National-Security-Archive-James-E-Mathis.pdf
> [2]
> https://upload.wikimedia.org/wikipedia/commons/6/6f/Army_Packet_Radio_Network_Protocol_Study_-_SRI%2C_November_1977.pdf
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


From b_a_denny at yahoo.com  Tue Apr  8 16:25:59 2025
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Tue, 8 Apr 2025 23:25:59 +0000 (UTC)
Subject: [ih] TCP RTT Estimator
In-Reply-To: <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
Message-ID: <1904684696.3332161.1744154759907@mail.yahoo.com>

 The? distribution list of people and their affiliation at the end of of Jim 's document is very interesting to me.?
barbara
    On Tuesday, April 8, 2025 at 10:10:53 AM PDT, Vint Cerf via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 nostalgia!!!!

v


On Tue, Apr 8, 2025 at 12:50?PM Greg Skinner via Internet-history <
internet-history at elists.isoc.org> wrote:

> I found a 1976 report by Jim Mathis describing an early TCP implementation
> (in pseudocode) that was compliant with RFC 675 (INWG 72). [1] It was cited
> in a report by Darryl Rubin, another SRI packet radio contributor. [2]
>
> --gregbo
>
> [1]
> https://nsarchive.gwu.edu/sites/default/files/documents/5793284/National-Security-Archive-James-E-Mathis.pdf
> [2]
> https://upload.wikimedia.org/wikipedia/commons/6/6f/Army_Packet_Radio_Network_Protocol_Study_-_SRI%2C_November_1977.pdf
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  

From gregskinner0 at icloud.com  Sat Apr 12 10:00:18 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Sat, 12 Apr 2025 10:00:18 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
Message-ID: <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>

I found some additional information that may shed some light on the issue of how much packet radio influenced the round trip time (RTT) and retransmission timeout (RTO) calculations.

There is a discussion of retransmission strategy in IEN 69 that makes a distinction between loss and congestion:

There are two problems that have the same symptoms - losing segments due to poor communications media, and delayed segments due to congestion.  These two problems call for distinctly different solutions.  In a lossy network, one would retransmit more frequently; in a congested network, one would retransmit less frequently.

Appendix E of IEN 69 gives some examples of specifying retransmission parameters.  One of those is for the SRI packet radio demo - 3 seconds with no backoff, initially.  (Subsequent retransmissions are a multiple of the initial value and two additional parameters that can be expressed as a fraction.)  Jim Mathis? 1979 TCP implementation supports this feature.  It is also documented in IEN 150 as TENEX and TOPS20 JSYSs (system calls).

However, for some reason, this didn?t make it into RFC 793.  As previously noted, in IEN 177, a decision was made to use the RSRE algorithm in subsequent TCP specs.

I can understand why the RSRE algorithm was chosen, given what was understood about retransmission at the time.  Does anyone know why the alternate form was omitted?  Was there any more discussion about it prior to the publication of RFC 793?

--gregbo







From gregskinner0 at icloud.com  Sat Apr 12 11:16:00 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Sat, 12 Apr 2025 11:16:00 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
Message-ID: <8C130655-24EF-48C7-A5FC-AF527B54ED6B@icloud.com>

(Some corrections follow)

I found some additional information that may shed some light on the issue of how much packet radio influenced the round trip time (RTT) and retransmission timeout (RTO) calculations.

There is a discussion of retransmission strategy in IEN 69 that makes a distinction between loss and congestion:

There are two problems that have the same symptoms - losing segments due to poor communications media, and delayed segments due to congestion.  These two problems call for distinctly different solutions.  In a lossy network, one would retransmit more frequently; in a congested network, one would retransmit less frequently.

Appendix E of IEN 69 gives some examples of specifying retransmission parameters.  One of those is for the SRI packet radio demo - 3 seconds with no backoff, initially.  (Subsequent retransmissions are a multiple of the initial value and two additional parameters that can be expressed as a ratio.) It is also documented in IEN 150 as TENEX and TOPS20 JSYSs (system calls).  Jim Mathis? 1979 TCP implementation allows one to either set a constant, increase linearly by that constant, or increase exponentially (double the previous value), up to a maximum.

However, for some reason, these didn?t make it into RFC 793.  As previously noted, in IEN 177, a decision was made to use the RSRE algorithm in subsequent TCP specs.

I can understand why the RSRE algorithm was chosen, given what was understood about retransmission at the time.  Does anyone know why the alternate forms were omitted?  Was there any more discussion about them prior to the publication of RFC 793?

--gregbo







From jack at 3kitty.org  Sat Apr 12 11:33:33 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Sat, 12 Apr 2025 11:33:33 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
 <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
Message-ID: <c5d0db66-a8b8-4733-9b57-530d0b5ac7de@3kitty.org>

The 1980s era of The Internet was explicitly a time of research and the 
"Internet Experiment".??? We tried to reflect that in the documents of 
the day, such as RFC793.

The general principle was that the "on the wire" formats and meanings 
were standardized, so that any implementation of TCP could communicate 
with any other implementation.? Everything else was at best Recommendations.

However, there were a lot of unanswered questions, such as the best way 
to deal with network errors such as dropped, duplicated, or mangled 
datagrams - such as discussed in IEN69.

To enable research into different techniques, the specific algorithms 
for TCP functions such as retransmission timers and strategies were 
explicitly *not* standardized.??? That encouraged experimentation with 
different kinds of network environments and different ideas about how to 
cope with errors.?? It also permitted implementations of TCP with 
different goals.? An implementer might pursue algorithms which minimized 
the load on their computer system.? Or load on the network.?? Or 
rapidity of implementation. Or suitability for the specific user 
environment involved.? Or ...

No one in 1981 had any significant experience with real-world TCP 
networks and their behavior under heavy loads.?? The ARPANET was the 
basic wide-area network in use as the substrate for The Internet, and 
the ARPANET provided only a reliable byte-stream service that made 
greatly simplified TCP's task.

IEN 177 says that the RSRE algorithm is the "current best procedure" and 
"will be included in the next ... specification".? I remember talking 
with Jon and others about this.? My recollection is that such an 
algorithm might be included as a "best practice" recommendation, not as 
a mandatory part of the standard.? In 1981 we simply didn't know enough 
to nail down an algorithm and there were lots of other outstanding 
unresolved issues that might be related (such as Type Of Service, Policy 
Routing, etc.).

In 1981, The Internet was still very much an Experiment, but being 
pulled forward by its adoption as a DoD Standard, and later to be 
rocketed forward by its adoption in non-military networking.?? I think 
many of those research questions were never answered.? I recall we even 
at one point we even opined that The Internet would be fine as long as 
we kept enough capacity in the circuits and switches to avoid overloads, 
while the research continued, seeking the "right" answers.

Jack Haverty


On 4/12/25 10:00, Greg Skinner via Internet-history wrote:
> I found some additional information that may shed some light on the issue of how much packet radio influenced the round trip time (RTT) and retransmission timeout (RTO) calculations.
>
> There is a discussion of retransmission strategy in IEN 69 that makes a distinction between loss and congestion:
>
> There are two problems that have the same symptoms - losing segments due to poor communications media, and delayed segments due to congestion.  These two problems call for distinctly different solutions.  In a lossy network, one would retransmit more frequently; in a congested network, one would retransmit less frequently.
>
> Appendix E of IEN 69 gives some examples of specifying retransmission parameters.  One of those is for the SRI packet radio demo - 3 seconds with no backoff, initially.  (Subsequent retransmissions are a multiple of the initial value and two additional parameters that can be expressed as a fraction.)  Jim Mathis? 1979 TCP implementation supports this feature.  It is also documented in IEN 150 as TENEX and TOPS20 JSYSs (system calls).
>
> However, for some reason, this didn?t make it into RFC 793.  As previously noted, in IEN 177, a decision was made to use the RSRE algorithm in subsequent TCP specs.
>
> I can understand why the RSRE algorithm was chosen, given what was understood about retransmission at the time.  Does anyone know why the alternate form was omitted?  Was there any more discussion about it prior to the publication of RFC 793?
>
> --gregbo
>
>
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250412/e3105396/attachment.asc>

From touch at strayalpha.com  Sun Apr 13 03:28:27 2025
From: touch at strayalpha.com (Joe Touch)
Date: Sun, 13 Apr 2025 11:28:27 +0100
Subject: [ih] TCP RTT Estimator
In-Reply-To: <c5d0db66-a8b8-4733-9b57-530d0b5ac7de@3kitty.org>
References: <c5d0db66-a8b8-4733-9b57-530d0b5ac7de@3kitty.org>
Message-ID: <59AC171C-0FFD-4AF9-B6F8-BD04739412A6@strayalpha.com>


> On Apr 12, 2025, at 7:33?PM, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> The general principle was that the "on the wire" formats and meanings were standardized, so that any implementation of TCP could communicate with any other implementation.

?On the wire? all protocols are groups of bits. Even if some patterns are prohibited, that?s still not a protocol. 

A protocol is a tuple of wire messages sent/received, time events occurring/set up, user messages produced/consumed, and FSM relating them all. The ?on the wire? part is 2/7 of that and never enough to endure comm. Decades of advice to the contrary not withstanding (the IETF rule that even generic APIs were not part of a protocol). 

The specific parts of TCP that were left ?floating? may be interoperable but might not too. Two endpoints? timeouts or calculations could interact in ways that grind data  xfer to a halt. 

So that principle above may have worked mostly well enough for TCP so far, it fails as ?general?. 

Joe 


From dhc at dcrocker.net  Sun Apr 13 03:41:07 2025
From: dhc at dcrocker.net (Dave Crocker)
Date: Sun, 13 Apr 2025 10:41:07 +0000 (UTC)
Subject: [ih] TCP RTT Estimator
In-Reply-To: <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
 <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
Message-ID: <fcd107ac-1c5b-4e7b-b340-f9bae81f0643@dcrocker.net>

On 4/12/2025 7:00 PM, Greg Skinner via Internet-history wrote:
> There are two problems that have the same symptoms - losing segments due to poor communications media, and delayed segments due to congestion.  These two problems call for distinctly different solutions.  In a lossy network, one would retransmit more frequently; in a congested network, one would retransmit less frequently.

I never worked on the development of TCP or its constituent components.? 
Just an innocent bystander, curious to watch things developing.? I think 
Jon Postel was still at UCLA and therefore stuck with me as an 
office-mate, which also meant he was usually my source of technical 
explanations for me.

I was shocked to see how simplistic (and weak) the TCP checksum was.? 
(Since I was just learning about such components, I of course assumed 
that the strongest possible data integrity mechanisms were always 
essential.)

Similarly, given the considerable network distances data traveled, I was 
skeptical that the TCP retransmission mechanism would suffice if there 
were serious problems.

Jon suggested that a) more robust data integrity was a lot more 
expensive, and b) TCP's mechanisms were meant for occasional and major 
problems.

He said that any transit section with chronic issues needed to have its 
own, underlying and more-robust mechanisms, to bring its reliability and 
throughput up to an acceptable level.

d/

-- 
Dave Crocker

Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker at mastodon.social


From jeanjour at comcast.net  Sun Apr 13 04:48:00 2025
From: jeanjour at comcast.net (John Day)
Date: Sun, 13 Apr 2025 07:48:00 -0400
Subject: [ih] TCP RTT Estimator
In-Reply-To: <59AC171C-0FFD-4AF9-B6F8-BD04739412A6@strayalpha.com>
References: <c5d0db66-a8b8-4733-9b57-530d0b5ac7de@3kitty.org>
 <59AC171C-0FFD-4AF9-B6F8-BD04739412A6@strayalpha.com>
Message-ID: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>

Test case. According to your criteria is UDP a protocol?  What about IP?

John 

> On Apr 13, 2025, at 06:28, Joe Touch via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> 
>> On Apr 12, 2025, at 7:33?PM, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
>> 
>> The general principle was that the "on the wire" formats and meanings were standardized, so that any implementation of TCP could communicate with any other implementation.
> 
> ?On the wire? all protocols are groups of bits. Even if some patterns are prohibited, that?s still not a protocol. 
> 
> A protocol is a tuple of wire messages sent/received, time events occurring/set up, user messages produced/consumed, and FSM relating them all. The ?on the wire? part is 2/7 of that and never enough to endure comm. Decades of advice to the contrary not withstanding (the IETF rule that even generic APIs were not part of a protocol). 
> 
> The specific parts of TCP that were left ?floating? may be interoperable but might not too. Two endpoints? timeouts or calculations could interact in ways that grind data  xfer to a halt. 
> 
> So that principle above may have worked mostly well enough for TCP so far, it fails as ?general?. 
> 
> Joe 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From jeanjour at comcast.net  Sun Apr 13 04:57:04 2025
From: jeanjour at comcast.net (John Day)
Date: Sun, 13 Apr 2025 07:57:04 -0400
Subject: [ih] TCP RTT Estimator
In-Reply-To: <fcd107ac-1c5b-4e7b-b340-f9bae81f0643@dcrocker.net>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
 <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
 <fcd107ac-1c5b-4e7b-b340-f9bae81f0643@dcrocker.net>
Message-ID: <19DDADD9-C76C-4426-90E2-ADEFE19476C1@comcast.net>

Sometime ago, (I think it was Jack Haverty) said that the TCP checksum was a placeholder until they could consult someone to advise them on what to use and it got lost in the shuffle.  ;-)

That said, the Transport Layer does require a different error code than the Data Link Layer. They operate over very different scopes and the Link Layers can be different requiring different error detection choices across the network. The Data Link Layer is protecting against data corruption in the Physical Layer so needs to be relatively strong and largely determined by the characteristics of the media, i.e., for copper, burst errors are common; but for fiber single bit errors are more likely.

The primary purpose at Transport is loss due to congestion and rare memory errors during relaying. Of course, lost messages are handled by retransmissions and memory error tend to be single bit errors, so a different error code is required.

Too long to go into here but if the Link Layer is flaky (like wireless), then it needs to be enhanced to meet the minimal requirements of the error rate expected by Transport, which since there are several of them, it has to be much less.

John 

> On Apr 13, 2025, at 06:41, Dave Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> On 4/12/2025 7:00 PM, Greg Skinner via Internet-history wrote:
>> There are two problems that have the same symptoms - losing segments due to poor communications media, and delayed segments due to congestion.  These two problems call for distinctly different solutions.  In a lossy network, one would retransmit more frequently; in a congested network, one would retransmit less frequently.
> 
> I never worked on the development of TCP or its constituent components.  Just an innocent bystander, curious to watch things developing.  I think Jon Postel was still at UCLA and therefore stuck with me as an office-mate, which also meant he was usually my source of technical explanations for me.
> 
> I was shocked to see how simplistic (and weak) the TCP checksum was.  (Since I was just learning about such components, I of course assumed that the strongest possible data integrity mechanisms were always essential.)
> 
> Similarly, given the considerable network distances data traveled, I was skeptical that the TCP retransmission mechanism would suffice if there were serious problems.
> 
> Jon suggested that a) more robust data integrity was a lot more expensive, and b) TCP's mechanisms were meant for occasional and major problems.
> 
> He said that any transit section with chronic issues needed to have its own, underlying and more-robust mechanisms, to bring its reliability and throughput up to an acceptable level.
> 
> d/
> 
> -- 
> Dave Crocker
> 
> Brandenburg InternetWorking
> bbiw.net
> bluesky: @dcrocker.bsky.social
> mast: @dcrocker at mastodon.social
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From jack at 3kitty.org  Sun Apr 13 13:40:01 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Sun, 13 Apr 2025 13:40:01 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
Message-ID: <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>

Instead of "formats and meanings", I should have said "formats and 
interactions".? The required sequences of messages, and the meanings of 
those sequences, were part of the Protocol and the Standard, captured in 
details such as the State Diagram included in RFC793 as part of the 
Specification.

At one of the early TCP meetings, Vint explained to all of us what 
"protocol" meant.? It was derived from the Greek word "protokolon" 
(sorry, can't remember how to make my computer type Greek 
characters...).? Vint explained that the protokolon was the section of 
ancient scrolls at the very beginning of any such "document".? It 
described what the entire scroll contained - something like a table of 
contents or Executive Summary or today perhaps the TLDR.?? That was 
apparently useful in ancient times as a way to avoid having to unroll an 
entire scroll when searching for some particular piece of information.?? 
We recognized it of course as The Header.

Internal algorithms within host implementations, such as calculation of 
retransmission timers, were explicitly not specified as a Standard at 
that point, although we hoped they could be someday after more 
experience and experimentation.

It wasn't so much that we had to consult with somebody more 
knowledgeable.? Rather we had experienced the unpredictable behavior of 
paths that traversed multiple networks, and didn't think that anyone 
knew how to characterize or model such behavior so that suitable methods 
for error detection and correction could be chosen.

It's also important to remember that the Standardization effort that 
resulted in RFC793 et al was an unexpected surprise.? Vint gave a short 
introductory talk at the beginning of each meeting.? At one of them he 
announced that DoD had decided to establish TCP as a DoD Standard, which 
had all sorts of consequences beyond the research community of ARPA.?? 
For example, such a Standard would then influence all sorts of military 
procurements of hardware and software for anything that used computers 
and communications.

That announcement led to Jon getting the assignment to quickly create 
some required documentation, since Standards feed on paper rather than 
code.?? That led to a lot of discussion as we tried to help Jon figure 
out what all the existing code actually did.?? There was also a lot of 
whining about "It's not ready yet!" or "It's too soon!" and "but we 
don't know what the algorithm should be" (guilty!).

I recall having lots of discussions with Jon during that period. Jon was 
enamored with the notion that implementations "be conservative in what 
you do, be liberal in what you accept from others."? It's in the RFC793 
spec.

I argued against that, on the principle that incorrect behavior was 
indicative of a bug, either in the specification or implementation, and 
should be reported so that it could be fixed.?? Otherwise it just left a 
"time bomb" in some deployed system that would probably explode at some 
very inopportune time in the future.

I lost.

There weren't a lot of TCP implementations at the time.? Bill Plummer at 
BBN did Tenex.? Jim Mathis at SRI did the LSI-11 version used in Packet 
Radio experiments.?? I suspect those two were the first implementations, 
used in the early Packet Radio experiments. Before my time.

I used Jim's code (e.g., implementation of the state diagram) as the 
core for my PDP-11/40 Unix implementation, which was part of a Network 
Security project at BBN in 1977.? Dave Mills had his Fuzzballs.?? Bob 
Braden did the IBM 360 implementation at UCLA. Dave Clark and Noel 
Chiappa handled Multics at MIT.? There may have been one or two more, 
but it was a small group.? In between meetings, lots of debate and 
discussion was carried out by email, much of which is probably lost 
now.?? Jon collected it all and distilled it into words and Specifications.

He had some earlier experience with such a task.? The first "TCP 
Bakeoff" was held at ISI on a weekend (January 27, 1979 IIRC) when lots 
of offices and their terminals were unoccupied.? We all had TCP 
implementations that could talk to themselves, but none of them could 
talk to anyone else.?? Checksums were the primary culprit. But after a 
while we all got our TCPs to talk to each other.?? Jon then captured the 
exact checksumming algorithm that reflected what all our code actually 
did to compute and verify checksums.?? We had achieved Consensus at the 
Bakeoff, after starting with just Running but incompatible Code.?? Jon 
wrote it down.

(BTW, all the time I was interacting with Jon, he was at USC-ISI, in an 
office tower in Marina Del Rey.? I didn't know he had ever been at UCLA)

Out of all that, and a Herculean effort by Jon, documentation for the 
DoD Standard emerged.? It wasn't a pretty process.? RFC 793/791 specify 
Version 4, which grew out of previous versions we had named things like 
"2.5" or "2.5+", or "2.5+epsilon".? All such versions were documented 
purely in email exchanges.

There was even an early definition of Version 3, which was quickly found 
to be incorrect and replaced by Version 4.?? Unfortunately, someone in 
the DoD contractor community (Ford Aerospace IIRC) had been contracted 
to implement Version 3.? They had their TCP working, but couldn't find 
anybody to talk to.?? We had all gone on to Version 4.

Standards are messy.?? Formal standards organizations usually debate for 
years, refining documents with new ideas and epiphanies.? Code comes 
later. ? The TCP community believed in "rough consensus and running 
code" as the first step. ? Experience and experimentation drove changes. 
 ? Documentation came later.

It was fun too!

Jack Haverty

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250413/19f5030d/attachment.asc>

From gregskinner0 at icloud.com  Mon Apr 14 16:22:16 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Mon, 14 Apr 2025 16:22:16 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <c5d0db66-a8b8-4733-9b57-530d0b5ac7de@3kitty.org>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
 <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
 <c5d0db66-a8b8-4733-9b57-530d0b5ac7de@3kitty.org>
Message-ID: <35B27012-6D8A-4A1B-ACA0-28B50F544B7D@icloud.com>

On Apr 12, 2025, at 11:33?AM, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> The 1980s era of The Internet was explicitly a time of research and the "Internet Experiment".    We tried to reflect that in the documents of the day, such as RFC793.
> 
> The general principle was that the "on the wire" formats and meanings were standardized, so that any implementation of TCP could communicate with any other implementation.  Everything else was at best Recommendations.
> 
> However, there were a lot of unanswered questions, such as the best way to deal with network errors such as dropped, duplicated, or mangled datagrams - such as discussed in IEN69.
> 
> To enable research into different techniques, the specific algorithms for TCP functions such as retransmission timers and strategies were explicitly *not* standardized.    That encouraged experimentation with different kinds of network environments and different ideas about how to cope with errors.   It also permitted implementations of TCP with different goals.  An implementer might pursue algorithms which minimized the load on their computer system.  Or load on the network.   Or rapidity of implementation. Or suitability for the specific user environment involved.  Or ...
> 
> No one in 1981 had any significant experience with real-world TCP networks and their behavior under heavy loads.   The ARPANET was the basic wide-area network in use as the substrate for The Internet, and the ARPANET provided only a reliable byte-stream service that made greatly simplified TCP's task.
> 
> IEN 177 says that the RSRE algorithm is the "current best procedure" and "will be included in the next ... specification".  I remember talking with Jon and others about this.  My recollection is that such an algorithm might be included as a "best practice" recommendation, not as a mandatory part of the standard.  In 1981 we simply didn't know enough to nail down an algorithm and there were lots of other outstanding unresolved issues that might be related (such as Type Of Service, Policy Routing, etc.).
> 
> In 1981, The Internet was still very much an Experiment, but being pulled forward by its adoption as a DoD Standard, and later to be rocketed forward by its adoption in non-military networking.   I think many of those research questions were never answered.  I recall we even at one point we even opined that The Internet would be fine as long as we kept enough capacity in the circuits and switches to avoid overloads, while the research continued, seeking the "right" answers.
> 
> Jack Haverty

OK, that seems reasonable.  I did a little more digging, and found that IEN 50 provides some ?glue? by comparing some retransmission algorithms, using simulations and analytical techniques to arrive at some conclusions. [1]  It seems unfortunate to me that some of these IENs couldn?t have been included as references in RFC 793.  But as far as supporting (higher packet loss) military networking went, some of these concerns (in theory) could have been addressed in MIL-STD-1778 [2].  Does anyone know why they weren?t? The US DoD sent people to those Internet Meetings from the late 1970s and early 1980s, so (in theory) they had enough information to incorporate any additional requirements into the military standard for TCP.

--gregbo

[1] https://www.rfc-editor.org/ien/scanned/ien50.pdf
[2] http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/

From vgcerf at gmail.com  Mon Apr 14 17:03:35 2025
From: vgcerf at gmail.com (vinton cerf)
Date: Mon, 14 Apr 2025 20:03:35 -0400
Subject: [ih] TCP RTT Estimator
In-Reply-To: <35B27012-6D8A-4A1B-ACA0-28B50F544B7D@icloud.com>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
 <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
 <c5d0db66-a8b8-4733-9b57-530d0b5ac7de@3kitty.org>
 <35B27012-6D8A-4A1B-ACA0-28B50F544B7D@icloud.com>
Message-ID: <CAAFtm_Vt577-RHkcM5cGzp-r6O8nq_mnaX+cenJg80RUo73DGA@mail.gmail.com>

one possible explanation: the preparation of the MIL-STD was in parallel
with further developments and just didn't take them into account.

v


On Mon, Apr 14, 2025 at 7:22?PM Greg Skinner via Internet-history <
internet-history at elists.isoc.org> wrote:

> On Apr 12, 2025, at 11:33?AM, Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > The 1980s era of The Internet was explicitly a time of research and the
> "Internet Experiment".    We tried to reflect that in the documents of the
> day, such as RFC793.
> >
> > The general principle was that the "on the wire" formats and meanings
> were standardized, so that any implementation of TCP could communicate with
> any other implementation.  Everything else was at best Recommendations.
> >
> > However, there were a lot of unanswered questions, such as the best way
> to deal with network errors such as dropped, duplicated, or mangled
> datagrams - such as discussed in IEN69.
> >
> > To enable research into different techniques, the specific algorithms
> for TCP functions such as retransmission timers and strategies were
> explicitly *not* standardized.    That encouraged experimentation with
> different kinds of network environments and different ideas about how to
> cope with errors.   It also permitted implementations of TCP with different
> goals.  An implementer might pursue algorithms which minimized the load on
> their computer system.  Or load on the network.   Or rapidity of
> implementation. Or suitability for the specific user environment involved.
> Or ...
> >
> > No one in 1981 had any significant experience with real-world TCP
> networks and their behavior under heavy loads.   The ARPANET was the basic
> wide-area network in use as the substrate for The Internet, and the ARPANET
> provided only a reliable byte-stream service that made greatly simplified
> TCP's task.
> >
> > IEN 177 says that the RSRE algorithm is the "current best procedure" and
> "will be included in the next ... specification".  I remember talking with
> Jon and others about this.  My recollection is that such an algorithm might
> be included as a "best practice" recommendation, not as a mandatory part of
> the standard.  In 1981 we simply didn't know enough to nail down an
> algorithm and there were lots of other outstanding unresolved issues that
> might be related (such as Type Of Service, Policy Routing, etc.).
> >
> > In 1981, The Internet was still very much an Experiment, but being
> pulled forward by its adoption as a DoD Standard, and later to be rocketed
> forward by its adoption in non-military networking.   I think many of those
> research questions were never answered.  I recall we even at one point we
> even opined that The Internet would be fine as long as we kept enough
> capacity in the circuits and switches to avoid overloads, while the
> research continued, seeking the "right" answers.
> >
> > Jack Haverty
>
> OK, that seems reasonable.  I did a little more digging, and found that
> IEN 50 provides some ?glue? by comparing some retransmission algorithms,
> using simulations and analytical techniques to arrive at some conclusions.
> [1]  It seems unfortunate to me that some of these IENs couldn?t have been
> included as references in RFC 793.  But as far as supporting (higher packet
> loss) military networking went, some of these concerns (in theory) could
> have been addressed in MIL-STD-1778 [2].  Does anyone know why they
> weren?t? The US DoD sent people to those Internet Meetings from the late
> 1970s and early 1980s, so (in theory) they had enough information to
> incorporate any additional requirements into the military standard for TCP.
>
> --gregbo
>
> [1] https://www.rfc-editor.org/ien/scanned/ien50.pdf
> [2] http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From jack at 3kitty.org  Mon Apr 14 17:41:25 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Mon, 14 Apr 2025 17:41:25 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <CAAFtm_Vt577-RHkcM5cGzp-r6O8nq_mnaX+cenJg80RUo73DGA@mail.gmail.com>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
 <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
 <c5d0db66-a8b8-4733-9b57-530d0b5ac7de@3kitty.org>
 <35B27012-6D8A-4A1B-ACA0-28B50F544B7D@icloud.com>
 <CAAFtm_Vt577-RHkcM5cGzp-r6O8nq_mnaX+cenJg80RUo73DGA@mail.gmail.com>
Message-ID: <b5ad5290-81db-45cf-aff1-e9ab548a340c@3kitty.org>

The US DoD was (is still?) complicated and diverse.? The US DoD may have 
"sent someone" to meetings but it's difficult to tell what the mission 
was (influence?? observe?? learn?), or which piece of the DoD sent him 
or her.? During the 1980s, the ascendance of TCP was not guaranteed, 
even though it was a "DoD Standard".

For example, there was a sizable contingent within DoD that was 
committed to OSI (search for GOSIP), and viewed TCP at best as an 
interim step along the way there.?? In 1990, OSI was even declared as a 
Standard, not just for DoD but for the entire US government. See 
https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub146-1.pdf

Personally, I lost track of DoD networking when I migrated to Silicon 
Valley in 1990.? I've always wondered just what happened to DoD 
networking over the last 35 years.? Do today's military systems use TCP 
(V4? V6?) over a secured private military Internet?? Or over the public 
Internet?? Or use some other technology over their own secured fiber, 
circuits, and satellites?

During the 1980s, there was a lot of concern in DoD about use of 
"public" systems such as the ARPANET or neonatal Internet.? But it was 
straightforward for agencies and departments to procure their own 
systems, at first using IMPs from BBN and routers from Cisco. We helped 
quite a few such networks get to operational status.? It was quite 
common even in 1990 for corporations to build out their own private 
"intranets", using off-the-shelf circuits and routers. For example, I 
consulted in the late 1980s to one major Wall Street firm on their 
private intranet connecting London, New York, and Tokyo.?? In 1990 I was 
involved in running a private corporate intranet connecting corporate 
offices in 100+ countries.

After 1990, I have no data about the evolution of the DoD network 
world.? But I still recall some of the military scenarios which Vint 
outlined as goals for the Internet research as TCP V4 was being created 
a decade earlier.? Those scenarios motivated the introduction of UDP, 
and the splitting of TCP into TCP/IP, in order to provide a pathway for 
support of real-time interactive activities, such as coordinated 
conversational voice and graphics, across the military environment.

Is that how the DoD networking works today in military operations? Or 
perhaps TCP has been replaced by other technologies?? Signal?

Jack Haverty


On 4/14/25 17:03, vinton cerf wrote:
> one possible explanation: the preparation?of the MIL-STD was in 
> parallel with further developments and just didn't take them into 
> account.
>
> v
>
>
> On Mon, Apr 14, 2025 at 7:22?PM Greg Skinner via Internet-history 
> <internet-history at elists.isoc.org> wrote:
>
>     On Apr 12, 2025, at 11:33?AM, Jack Haverty via Internet-history
>     <internet-history at elists.isoc.org> wrote:
>     >
>     > The 1980s era of The Internet was explicitly a time of research
>     and the "Internet Experiment".? ? We tried to reflect that in the
>     documents of the day, such as RFC793.
>     >
>     > The general principle was that the "on the wire" formats and
>     meanings were standardized, so that any implementation of TCP
>     could communicate with any other implementation. Everything else
>     was at best Recommendations.
>     >
>     > However, there were a lot of unanswered questions, such as the
>     best way to deal with network errors such as dropped, duplicated,
>     or mangled datagrams - such as discussed in IEN69.
>     >
>     > To enable research into different techniques, the specific
>     algorithms for TCP functions such as retransmission timers and
>     strategies were explicitly *not* standardized. That encouraged
>     experimentation with different kinds of network environments and
>     different ideas about how to cope with errors.? ?It also permitted
>     implementations of TCP with different goals.? An implementer might
>     pursue algorithms which minimized the load on their computer
>     system.? Or load on the network.? ?Or rapidity of implementation.
>     Or suitability for the specific user environment involved.? Or ...
>     >
>     > No one in 1981 had any significant experience with real-world
>     TCP networks and their behavior under heavy loads. ?The ARPANET
>     was the basic wide-area network in use as the substrate for The
>     Internet, and the ARPANET provided only a reliable byte-stream
>     service that made greatly simplified TCP's task.
>     >
>     > IEN 177 says that the RSRE algorithm is the "current best
>     procedure" and "will be included in the next ... specification".?
>     I remember talking with Jon and others about this.? My
>     recollection is that such an algorithm might be included as a
>     "best practice" recommendation, not as a mandatory part of the
>     standard.? In 1981 we simply didn't know enough to nail down an
>     algorithm and there were lots of other outstanding unresolved
>     issues that might be related (such as Type Of Service, Policy
>     Routing, etc.).
>     >
>     > In 1981, The Internet was still very much an Experiment, but
>     being pulled forward by its adoption as a DoD Standard, and later
>     to be rocketed forward by its adoption in non-military
>     networking.? ?I think many of those research questions were never
>     answered.? I recall we even at one point we even opined that The
>     Internet would be fine as long as we kept enough capacity in the
>     circuits and switches to avoid overloads, while the research
>     continued, seeking the "right" answers.
>     >
>     > Jack Haverty
>
>     OK, that seems reasonable.? I did a little more digging, and found
>     that IEN 50 provides some ?glue? by comparing some retransmission
>     algorithms, using simulations and analytical techniques to arrive
>     at some conclusions. [1]? It seems unfortunate to me that some of
>     these IENs couldn?t have been included as references in RFC 793.?
>     But as far as supporting (higher packet loss) military networking
>     went, some of these concerns (in theory) could have been addressed
>     in MIL-STD-1778 [2].? Does anyone know why they weren?t? The US
>     DoD sent people to those Internet Meetings from the late 1970s and
>     early 1980s, so (in theory) they had enough information to
>     incorporate any additional requirements into the military standard
>     for TCP.
>
>     --gregbo
>
>     [1] https://www.rfc-editor.org/ien/scanned/ien50.pdf
>     [2] http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/
>     -- 
>     Internet-history mailing list
>     Internet-history at elists.isoc.org
>     https://elists.isoc.org/mailman/listinfo/internet-history
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250414/c6a05d19/attachment.asc>

From aam3sendonly at gmail.com  Tue Apr 15 13:50:13 2025
From: aam3sendonly at gmail.com (Alexander McKenzie)
Date: Tue, 15 Apr 2025 16:50:13 -0400
Subject: [ih] IENs
Message-ID: <CAMusaY8BbPCETXKM+RuCaDhdNyD7nMZVRyVdt7vpeUS_TKE8SA@mail.gmail.com>

 Folks,

IENs are available to everyone these days, but back at the time they were
being written they were on a strictly-enforced limited distribution.  For
example, a DARPA official told one PI at BBN that his contract would be
cancelled if the IEN's he received leaked into the possession of another PI
at BBN. Therefore it is not surprising that IEN's were rarely referenced by
other documents.

Cheers,
Alex

On Monday, April 14, 2025 at 07:22:39 PM EDT, Greg Skinner via
Internet-history <internet-history at elists.isoc.org> wrote:


On Apr 12, 2025, at 11:33?AM, Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:
>
> The 1980s era of The Internet was explicitly a time of research and the
"Internet Experiment".    We tried to reflect that in the documents of the
day, such as RFC793.
>
> The general principle was that the "on the wire" formats and meanings
were standardized, so that any implementation of TCP could communicate with
any other implementation.  Everything else was at best Recommendations.
>
> However, there were a lot of unanswered questions, such as the best way
to deal with network errors such as dropped, duplicated, or mangled
datagrams - such as discussed in IEN69.
>
> To enable research into different techniques, the specific algorithms for
TCP functions such as retransmission timers and strategies were explicitly
*not* standardized.    That encouraged experimentation with different kinds
of network environments and different ideas about how to cope with errors.
It also permitted implementations of TCP with different goals.  An
implementer might pursue algorithms which minimized the load on their
computer system.  Or load on the network.  Or rapidity of implementation.
Or suitability for the specific user environment involved.  Or ...
>
> No one in 1981 had any significant experience with real-world TCP
networks and their behavior under heavy loads.  The ARPANET was the basic
wide-area network in use as the substrate for The Internet, and the ARPANET
provided only a reliable byte-stream service that made greatly simplified
TCP's task.
>
> IEN 177 says that the RSRE algorithm is the "current best procedure" and
"will be included in the next ... specification".  I remember talking with
Jon and others about this.  My recollection is that such an algorithm might
be included as a "best practice" recommendation, not as a mandatory part of
the standard.  In 1981 we simply didn't know enough to nail down an
algorithm and there were lots of other outstanding unresolved issues that
might be related (such as Type Of Service, Policy Routing, etc.).
>
> In 1981, The Internet was still very much an Experiment, but being pulled
forward by its adoption as a DoD Standard, and later to be rocketed forward
by its adoption in non-military networking.  I think many of those research
questions were never answered.  I recall we even at one point we even
opined that The Internet would be fine as long as we kept enough capacity
in the circuits and switches to avoid overloads, while the research
continued, seeking the "right" answers.
>
> Jack Haverty

OK, that seems reasonable.  I did a little more digging, and found that IEN
50 provides some ?glue? by comparing some retransmission algorithms, using
simulations and analytical techniques to arrive at some conclusions. [1]
It seems unfortunate to me that some of these IENs couldn?t have been
included as references in RFC 793.  But as far as supporting (higher packet
loss) military networking went, some of these concerns (in theory) could
have been addressed in MIL-STD-1778 [2].  Does anyone know why they
weren?t? The US DoD sent people to those Internet Meetings from the late
1970s and early 1980s, so (in theory) they had enough information to
incorporate any additional requirements into the military standard for TCP.

--gregbo

[1] https://www.rfc-editor.org/ien/scanned/ien50.pdf
[2] http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/

-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history


From vgcerf at gmail.com  Tue Apr 15 14:51:54 2025
From: vgcerf at gmail.com (vinton cerf)
Date: Tue, 15 Apr 2025 17:51:54 -0400
Subject: [ih] IENs
In-Reply-To: <CAMusaY8BbPCETXKM+RuCaDhdNyD7nMZVRyVdt7vpeUS_TKE8SA@mail.gmail.com>
References: <CAMusaY8BbPCETXKM+RuCaDhdNyD7nMZVRyVdt7vpeUS_TKE8SA@mail.gmail.com>
Message-ID: <CAAFtm_WyVO4hE-_LK8ccVrStP3GUbFy20WyvBrbW+XM5z7scxw@mail.gmail.com>

who ever that DARPA official might have been, it was NOT me.

v


On Tue, Apr 15, 2025 at 4:50?PM Alexander McKenzie via Internet-history <
internet-history at elists.isoc.org> wrote:

>  Folks,
>
> IENs are available to everyone these days, but back at the time they were
> being written they were on a strictly-enforced limited distribution.  For
> example, a DARPA official told one PI at BBN that his contract would be
> cancelled if the IEN's he received leaked into the possession of another PI
> at BBN. Therefore it is not surprising that IEN's were rarely referenced by
> other documents.
>
> Cheers,
> Alex
>
> On Monday, April 14, 2025 at 07:22:39 PM EDT, Greg Skinner via
> Internet-history <internet-history at elists.isoc.org> wrote:
>
>
> On Apr 12, 2025, at 11:33?AM, Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > The 1980s era of The Internet was explicitly a time of research and the
> "Internet Experiment".    We tried to reflect that in the documents of the
> day, such as RFC793.
> >
> > The general principle was that the "on the wire" formats and meanings
> were standardized, so that any implementation of TCP could communicate with
> any other implementation.  Everything else was at best Recommendations.
> >
> > However, there were a lot of unanswered questions, such as the best way
> to deal with network errors such as dropped, duplicated, or mangled
> datagrams - such as discussed in IEN69.
> >
> > To enable research into different techniques, the specific algorithms for
> TCP functions such as retransmission timers and strategies were explicitly
> *not* standardized.    That encouraged experimentation with different kinds
> of network environments and different ideas about how to cope with errors.
> It also permitted implementations of TCP with different goals.  An
> implementer might pursue algorithms which minimized the load on their
> computer system.  Or load on the network.  Or rapidity of implementation.
> Or suitability for the specific user environment involved.  Or ...
> >
> > No one in 1981 had any significant experience with real-world TCP
> networks and their behavior under heavy loads.  The ARPANET was the basic
> wide-area network in use as the substrate for The Internet, and the ARPANET
> provided only a reliable byte-stream service that made greatly simplified
> TCP's task.
> >
> > IEN 177 says that the RSRE algorithm is the "current best procedure" and
> "will be included in the next ... specification".  I remember talking with
> Jon and others about this.  My recollection is that such an algorithm might
> be included as a "best practice" recommendation, not as a mandatory part of
> the standard.  In 1981 we simply didn't know enough to nail down an
> algorithm and there were lots of other outstanding unresolved issues that
> might be related (such as Type Of Service, Policy Routing, etc.).
> >
> > In 1981, The Internet was still very much an Experiment, but being pulled
> forward by its adoption as a DoD Standard, and later to be rocketed forward
> by its adoption in non-military networking.  I think many of those research
> questions were never answered.  I recall we even at one point we even
> opined that The Internet would be fine as long as we kept enough capacity
> in the circuits and switches to avoid overloads, while the research
> continued, seeking the "right" answers.
> >
> > Jack Haverty
>
> OK, that seems reasonable.  I did a little more digging, and found that IEN
> 50 provides some ?glue? by comparing some retransmission algorithms, using
> simulations and analytical techniques to arrive at some conclusions. [1]
> It seems unfortunate to me that some of these IENs couldn?t have been
> included as references in RFC 793.  But as far as supporting (higher packet
> loss) military networking went, some of these concerns (in theory) could
> have been addressed in MIL-STD-1778 [2].  Does anyone know why they
> weren?t? The US DoD sent people to those Internet Meetings from the late
> 1970s and early 1980s, so (in theory) they had enough information to
> incorporate any additional requirements into the military standard for TCP.
>
> --gregbo
>
> [1] https://www.rfc-editor.org/ien/scanned/ien50.pdf
> [2] http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From jack at 3kitty.org  Tue Apr 15 16:48:19 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 15 Apr 2025 16:48:19 -0700
Subject: [ih] IENs
In-Reply-To: <CAAFtm_WyVO4hE-_LK8ccVrStP3GUbFy20WyvBrbW+XM5z7scxw@mail.gmail.com>
References: <CAMusaY8BbPCETXKM+RuCaDhdNyD7nMZVRyVdt7vpeUS_TKE8SA@mail.gmail.com>
 <CAAFtm_WyVO4hE-_LK8ccVrStP3GUbFy20WyvBrbW+XM5z7scxw@mail.gmail.com>
Message-ID: <ed28d74e-293d-460f-9746-6ef2d0f2f992@3kitty.org>

Hmmm.? I just searched for "IEN 1" on the 'net and found IENs, starting 
with #1 in July 1977, listed today at rfc-editor.org - although the 
early ones I checked sometimes said "not available" or "contact author 
for a copy".

Some of the very early IENs (1-20 or so) I don't think I ever saw until 
today.?? Of course we didn't have the Web or Search Engines in 1977 so 
maybe I just never encountered them.? The Internet really has changed 
the world and how we access information.

Other documentation of that era had limited distribution.? I recall a 
lot of QTRs capturing the work on Internet projects were distributed 
within the group that did the work as well as a small collection of 
government recipients at ARPA, DCA, and a few others.

For example, the Packet Radio work at BBN was done in a different 
Division from the one I was in, and their documents and ours didn't get 
widely distributed across the boundary.? I knew Packet Radio was 
happening in the other building at BBN, but not much of the details.? If 
you asked a friend you could probably get a copy of a report or borrow 
one and copy it.?? But it didn't come automatically.?? I suspect the 
researchers in the other Division had a similar experience with our work.

It was probably possible, but more difficult, to get a copy of documents 
from other members of the research community (MIT, UCLA, USC, NDRE, SRI, 
RSRE, UCL, Linkabit, UDel, Collins, etc.), but only if you knew the 
document existed.?? Same for other related corporate activities, e.g., 
at PARC, Novell, etc.?? Everything, especially documents with any 
graphics, pretty much travelled on paper then.

I don't remember ever having an encounter involving "your contract will 
be cancelled".

But there was significant concern in the computing world at the time 
over trade secrets and competitive advantage.? For example, when I 
agreed to work on implementing TCP for Unix, I had to sign some NDA 
document agreeing not to disclose anything about the internal design or 
mechanisms used within the Unix kernel, which ATT was protecting as a 
work product of Bell Labs.??? I somehow found a document from University 
of Woolongong that described the basic structure of the Unix kernel, 
which really helped in implementing TCP.? I guessed Australia was out of 
reach of the corporate lawyers.

Someone in the government also told me once, long ago, that documents 
got loaded into DTIC only if someone in the government on the original 
distribution list made the explicit effort to send that document to DTIC 
for archiving.? That probably explains why only some of the documents, 
even ones that I remember writing, are in DTIC today.?? I've tried 
searching on DTIC for early documents of Packet Radio, SATNET, and 
others but was mostly unsuccessful. Perhaps I just haven't found the 
right search term yet.

I can't recall - circa 1977 were IENs available on SRI-NIC like RFCs and 
other such core documents were at that time?? If not, anybody remember 
why not?? Perhaps SRI-NIC just wasn't on the distribution list?

/Jack

On 4/15/25 14:51, vinton cerf via Internet-history wrote:
> who ever that DARPA official might have been, it was NOT me.
>
> v
>
>
> On Tue, Apr 15, 2025 at 4:50?PM Alexander McKenzie via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>>   Folks,
>>
>> IENs are available to everyone these days, but back at the time they were
>> being written they were on a strictly-enforced limited distribution.  For
>> example, a DARPA official told one PI at BBN that his contract would be
>> cancelled if the IEN's he received leaked into the possession of another PI
>> at BBN. Therefore it is not surprising that IEN's were rarely referenced by
>> other documents.
>>
>> Cheers,
>> Alex
>>
>> On Monday, April 14, 2025 at 07:22:39 PM EDT, Greg Skinner via
>> Internet-history<internet-history at elists.isoc.org>  wrote:
>>
>>
>> On Apr 12, 2025, at 11:33?AM, Jack Haverty via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>> The 1980s era of The Internet was explicitly a time of research and the
>> "Internet Experiment".    We tried to reflect that in the documents of the
>> day, such as RFC793.
>>> The general principle was that the "on the wire" formats and meanings
>> were standardized, so that any implementation of TCP could communicate with
>> any other implementation.  Everything else was at best Recommendations.
>>> However, there were a lot of unanswered questions, such as the best way
>> to deal with network errors such as dropped, duplicated, or mangled
>> datagrams - such as discussed in IEN69.
>>> To enable research into different techniques, the specific algorithms for
>> TCP functions such as retransmission timers and strategies were explicitly
>> *not* standardized.    That encouraged experimentation with different kinds
>> of network environments and different ideas about how to cope with errors.
>> It also permitted implementations of TCP with different goals.  An
>> implementer might pursue algorithms which minimized the load on their
>> computer system.  Or load on the network.  Or rapidity of implementation.
>> Or suitability for the specific user environment involved.  Or ...
>>> No one in 1981 had any significant experience with real-world TCP
>> networks and their behavior under heavy loads.  The ARPANET was the basic
>> wide-area network in use as the substrate for The Internet, and the ARPANET
>> provided only a reliable byte-stream service that made greatly simplified
>> TCP's task.
>>> IEN 177 says that the RSRE algorithm is the "current best procedure" and
>> "will be included in the next ... specification".  I remember talking with
>> Jon and others about this.  My recollection is that such an algorithm might
>> be included as a "best practice" recommendation, not as a mandatory part of
>> the standard.  In 1981 we simply didn't know enough to nail down an
>> algorithm and there were lots of other outstanding unresolved issues that
>> might be related (such as Type Of Service, Policy Routing, etc.).
>>> In 1981, The Internet was still very much an Experiment, but being pulled
>> forward by its adoption as a DoD Standard, and later to be rocketed forward
>> by its adoption in non-military networking.  I think many of those research
>> questions were never answered.  I recall we even at one point we even
>> opined that The Internet would be fine as long as we kept enough capacity
>> in the circuits and switches to avoid overloads, while the research
>> continued, seeking the "right" answers.
>>> Jack Haverty
>> OK, that seems reasonable.  I did a little more digging, and found that IEN
>> 50 provides some ?glue? by comparing some retransmission algorithms, using
>> simulations and analytical techniques to arrive at some conclusions. [1]
>> It seems unfortunate to me that some of these IENs couldn?t have been
>> included as references in RFC 793.  But as far as supporting (higher packet
>> loss) military networking went, some of these concerns (in theory) could
>> have been addressed in MIL-STD-1778 [2].  Does anyone know why they
>> weren?t? The US DoD sent people to those Internet Meetings from the late
>> 1970s and early 1980s, so (in theory) they had enough information to
>> incorporate any additional requirements into the military standard for TCP.
>>
>> --gregbo
>>
>> [1]https://www.rfc-editor.org/ien/scanned/ien50.pdf
>> [2]http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/
>>
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250415/c365ebf9/attachment.asc>

From tracyhackshaw at gmail.com  Wed Apr 16 02:23:47 2025
From: tracyhackshaw at gmail.com (Tracy F. Hackshaw @ Google)
Date: Wed, 16 Apr 2025 11:23:47 +0200
Subject: [ih] Ars Technica: A History of of the Internet Pt. 1
Message-ID: <CAC0JwGO3K6QBNafDeMd-52Eu4oCGdBzQnswSJg=yPQ76rjGRfw@mail.gmail.com>

https://arstechnica.com/gadgets/2025/04/a-history-of-the-internet-part-1-an-arpa-dream-takes-form/

Scroll down to the end for Vint's review of the article.


From vint at google.com  Wed Apr 16 04:33:43 2025
From: vint at google.com (Vint Cerf)
Date: Wed, 16 Apr 2025 07:33:43 -0400
Subject: [ih] IENs
In-Reply-To: <ed28d74e-293d-460f-9746-6ef2d0f2f992@3kitty.org>
References: <CAMusaY8BbPCETXKM+RuCaDhdNyD7nMZVRyVdt7vpeUS_TKE8SA@mail.gmail.com>
 <CAAFtm_WyVO4hE-_LK8ccVrStP3GUbFy20WyvBrbW+XM5z7scxw@mail.gmail.com>
 <ed28d74e-293d-460f-9746-6ef2d0f2f992@3kitty.org>
Message-ID: <CAHxHggfWskoKTpt+o-Tz_Lb8JYNddZDduFV3wedZ1aeRz+7eBw@mail.gmail.com>

I think they were distributed by SRI-NIC.
v


On Tue, Apr 15, 2025 at 7:48?PM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:

> Hmmm.  I just searched for "IEN 1" on the 'net and found IENs, starting
> with #1 in July 1977, listed today at rfc-editor.org - although the
> early ones I checked sometimes said "not available" or "contact author
> for a copy".
>
> Some of the very early IENs (1-20 or so) I don't think I ever saw until
> today.   Of course we didn't have the Web or Search Engines in 1977 so
> maybe I just never encountered them.  The Internet really has changed
> the world and how we access information.
>
> Other documentation of that era had limited distribution.  I recall a
> lot of QTRs capturing the work on Internet projects were distributed
> within the group that did the work as well as a small collection of
> government recipients at ARPA, DCA, and a few others.
>
> For example, the Packet Radio work at BBN was done in a different
> Division from the one I was in, and their documents and ours didn't get
> widely distributed across the boundary.  I knew Packet Radio was
> happening in the other building at BBN, but not much of the details.  If
> you asked a friend you could probably get a copy of a report or borrow
> one and copy it.   But it didn't come automatically.   I suspect the
> researchers in the other Division had a similar experience with our work.
>
> It was probably possible, but more difficult, to get a copy of documents
> from other members of the research community (MIT, UCLA, USC, NDRE, SRI,
> RSRE, UCL, Linkabit, UDel, Collins, etc.), but only if you knew the
> document existed.   Same for other related corporate activities, e.g.,
> at PARC, Novell, etc.   Everything, especially documents with any
> graphics, pretty much travelled on paper then.
>
> I don't remember ever having an encounter involving "your contract will
> be cancelled".
>
> But there was significant concern in the computing world at the time
> over trade secrets and competitive advantage.  For example, when I
> agreed to work on implementing TCP for Unix, I had to sign some NDA
> document agreeing not to disclose anything about the internal design or
> mechanisms used within the Unix kernel, which ATT was protecting as a
> work product of Bell Labs.    I somehow found a document from University
> of Woolongong that described the basic structure of the Unix kernel,
> which really helped in implementing TCP.  I guessed Australia was out of
> reach of the corporate lawyers.
>
> Someone in the government also told me once, long ago, that documents
> got loaded into DTIC only if someone in the government on the original
> distribution list made the explicit effort to send that document to DTIC
> for archiving.  That probably explains why only some of the documents,
> even ones that I remember writing, are in DTIC today.   I've tried
> searching on DTIC for early documents of Packet Radio, SATNET, and
> others but was mostly unsuccessful. Perhaps I just haven't found the
> right search term yet.
>
> I can't recall - circa 1977 were IENs available on SRI-NIC like RFCs and
> other such core documents were at that time?  If not, anybody remember
> why not?  Perhaps SRI-NIC just wasn't on the distribution list?
>
> /Jack
>
> On 4/15/25 14:51, vinton cerf via Internet-history wrote:
> > who ever that DARPA official might have been, it was NOT me.
> >
> > v
> >
> >
> > On Tue, Apr 15, 2025 at 4:50?PM Alexander McKenzie via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >>   Folks,
> >>
> >> IENs are available to everyone these days, but back at the time they
> were
> >> being written they were on a strictly-enforced limited distribution.
> For
> >> example, a DARPA official told one PI at BBN that his contract would be
> >> cancelled if the IEN's he received leaked into the possession of
> another PI
> >> at BBN. Therefore it is not surprising that IEN's were rarely
> referenced by
> >> other documents.
> >>
> >> Cheers,
> >> Alex
> >>
> >> On Monday, April 14, 2025 at 07:22:39 PM EDT, Greg Skinner via
> >> Internet-history<internet-history at elists.isoc.org>  wrote:
> >>
> >>
> >> On Apr 12, 2025, at 11:33?AM, Jack Haverty via Internet-history <
> >> internet-history at elists.isoc.org> wrote:
> >>> The 1980s era of The Internet was explicitly a time of research and the
> >> "Internet Experiment".    We tried to reflect that in the documents of
> the
> >> day, such as RFC793.
> >>> The general principle was that the "on the wire" formats and meanings
> >> were standardized, so that any implementation of TCP could communicate
> with
> >> any other implementation.  Everything else was at best Recommendations.
> >>> However, there were a lot of unanswered questions, such as the best way
> >> to deal with network errors such as dropped, duplicated, or mangled
> >> datagrams - such as discussed in IEN69.
> >>> To enable research into different techniques, the specific algorithms
> for
> >> TCP functions such as retransmission timers and strategies were
> explicitly
> >> *not* standardized.    That encouraged experimentation with different
> kinds
> >> of network environments and different ideas about how to cope with
> errors.
> >> It also permitted implementations of TCP with different goals.  An
> >> implementer might pursue algorithms which minimized the load on their
> >> computer system.  Or load on the network.  Or rapidity of
> implementation.
> >> Or suitability for the specific user environment involved.  Or ...
> >>> No one in 1981 had any significant experience with real-world TCP
> >> networks and their behavior under heavy loads.  The ARPANET was the
> basic
> >> wide-area network in use as the substrate for The Internet, and the
> ARPANET
> >> provided only a reliable byte-stream service that made greatly
> simplified
> >> TCP's task.
> >>> IEN 177 says that the RSRE algorithm is the "current best procedure"
> and
> >> "will be included in the next ... specification".  I remember talking
> with
> >> Jon and others about this.  My recollection is that such an algorithm
> might
> >> be included as a "best practice" recommendation, not as a mandatory
> part of
> >> the standard.  In 1981 we simply didn't know enough to nail down an
> >> algorithm and there were lots of other outstanding unresolved issues
> that
> >> might be related (such as Type Of Service, Policy Routing, etc.).
> >>> In 1981, The Internet was still very much an Experiment, but being
> pulled
> >> forward by its adoption as a DoD Standard, and later to be rocketed
> forward
> >> by its adoption in non-military networking.  I think many of those
> research
> >> questions were never answered.  I recall we even at one point we even
> >> opined that The Internet would be fine as long as we kept enough
> capacity
> >> in the circuits and switches to avoid overloads, while the research
> >> continued, seeking the "right" answers.
> >>> Jack Haverty
> >> OK, that seems reasonable.  I did a little more digging, and found that
> IEN
> >> 50 provides some ?glue? by comparing some retransmission algorithms,
> using
> >> simulations and analytical techniques to arrive at some conclusions. [1]
> >> It seems unfortunate to me that some of these IENs couldn?t have been
> >> included as references in RFC 793.  But as far as supporting (higher
> packet
> >> loss) military networking went, some of these concerns (in theory) could
> >> have been addressed in MIL-STD-1778 [2].  Does anyone know why they
> >> weren?t? The US DoD sent people to those Internet Meetings from the late
> >> 1970s and early 1980s, so (in theory) they had enough information to
> >> incorporate any additional requirements into the military standard for
> TCP.
> >>
> >> --gregbo
> >>
> >> [1]https://www.rfc-editor.org/ien/scanned/ien50.pdf
> >> [2]http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/
> >>
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


From aam3sendonly at gmail.com  Wed Apr 16 09:33:52 2025
From: aam3sendonly at gmail.com (Alexander McKenzie)
Date: Wed, 16 Apr 2025 12:33:52 -0400
Subject: [ih] CORRECTION: Not IEN's, but Packet Radio Notes
Message-ID: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>

Friends,

I must apologize for a serious misstatement.  I now realize it was not
IEN's which were strictly controlled, it was Packet Radio Notes.  I myself
was on the public distribution list for IENs and I should have remembered
this.

My sincere apologies,
Alex McKenzie


From jack at 3kitty.org  Wed Apr 16 09:52:14 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Wed, 16 Apr 2025 09:52:14 -0700
Subject: [ih] Ars Technica: A History of of the Internet Pt. 1
In-Reply-To: <CAC0JwGO3K6QBNafDeMd-52Eu4oCGdBzQnswSJg=yPQ76rjGRfw@mail.gmail.com>
References: <CAC0JwGO3K6QBNafDeMd-52Eu4oCGdBzQnswSJg=yPQ76rjGRfw@mail.gmail.com>
Message-ID: <c9f0798c-8698-4af0-b0f4-90862ece7290@3kitty.org>

On 4/16/25 02:23, Tracy F. Hackshaw @ Google via Internet-history wrote:
> https://arstechnica.com/gadgets/2025/04/a-history-of-the-internet-part-1-an-arpa-dream-takes-form/
>
> Scroll down to the end for Vint's review of the article.

My recollections are similar to Vint's - there are a few minor errors 
but mostly it seems to be pretty accurate.

There were some more details of Lick's role that I think were important.

Lick was my advisor and then boss at MIT in the 1970s.? His 
"Intergalactic Network" idea was whimsically named, but he really 
believed in it and that drove much of our research in his group at MIT.

His whimsical idea was basically that there would someday be a vast 
collection of computers, all communicating with each other using some 
kind of network technology, and all of them would be assisting humans in 
doing everything that humans do.? Everyone, not just the technoscenti,? 
would have their personal machine, which would act as their smart agent 
to interact with other machines to do what people do.

At the time, your "personal machine" was a large shared computer that 
you could interact with by using some kind of terminal.? We struggled to 
implement Lick's vision with the constraints of technology available at 
the time.? Today, after many decades of the effects of Moore's Law, 
Lick's vision sounds to me a lot like the Internet world we now all 
experience.

Lick spent time at BBN, MIT, and ARPA.? During the 70s, he even 
disappeared from MIT for a year, going back to ARPA to "fix some 
problems".? His vision stayed with me for many years.? BTW, Waldrop's 
book "The Dream Machine" contains much more of that early history and 
closely matches my own recollections.

A few minor errors:

I worked with Ray Tomlinson at BBN, but never met Roy Tomlinson. Perhaps 
that was Ray's brother (<

Also, the "map of the Internet in 1977" is actually a map of the ARPANET 
at the time.?? The small circles were all ARPANET IMPs, and the jagged 
lines were satellite circuits interconnecting IMPs.? No gateways or 
other networks are shown, although there were a few occasionally 
connected to IMPs at the time.? It was challenging to create a map of 
the Internet even then.? Jon's later map from 1982 seems accurate.

Jack Haverty

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250416/a57c84b5/attachment.asc>

From jnc at mercury.lcs.mit.edu  Wed Apr 16 14:02:13 2025
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 16 Apr 2025 17:02:13 -0400 (EDT)
Subject: [ih] Packet Radio cartoon from 1978
Message-ID: <20250416210213.CE31018C0BD@mercury.lcs.mit.edu>

    > From: Lawrence Stewart

    > a packet radio drawing by Ted Kaehler at PARC SSL around 1978

Thank you, thank you, thank you! There was a copy of that cartoon, or one
very similar (below), on a door within a room or two of mine, on the 5th
floor of Tech Sq, at about the time we got our Altos. We all thought it was
_great_; I too, and I have often wished I still had a copy. So I'm just
ecstatic that you've posted this. I'm not sure who brought it to us - maybe
Bob Baldwin?

The one I recall definitely included the line about 'ordering a new one', but
in my dim memory of it, I very vaguely recall it being slightly different
from this one? But my memory is definitely going, so...

	Noel


From gregskinner0 at icloud.com  Wed Apr 16 16:49:30 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Wed, 16 Apr 2025 16:49:30 -0700
Subject: [ih] CORRECTION: Not IEN's, but Packet Radio Notes
In-Reply-To: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
Message-ID: <C90872B6-7F17-4773-BDDC-736F5E36B919@icloud.com>

On Apr 16, 2025, at 9:33?AM, Alexander McKenzie via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Friends,
> 
> I must apologize for a serious misstatement.  I now realize it was not
> IEN's which were strictly controlled, it was Packet Radio Notes.  I myself
> was on the public distribution list for IENs and I should have remembered
> this.
> 
> My sincere apologies,
> Alex McKenzie
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

OK, I understand (although some of those Packet Radio Notes are also IENs).  But IMO some of the Packet Radio Notes (such as those that are in https://apps.dtic.mil/sti/tr/pdf/ADA157696.pdf) that are not IENs could have been valuable to TCP implementors who were not part of the initial group of TCP implementors from the late 1970s and early 1980s.  At the very least, they give an idea of how one might go about designing or tuning a TCP implementation, or testing for interoperability (including performance).

--gregbo



From vint at google.com  Wed Apr 16 17:07:49 2025
From: vint at google.com (Vint Cerf)
Date: Wed, 16 Apr 2025 20:07:49 -0400
Subject: [ih] CORRECTION: Not IEN's, but Packet Radio Notes
In-Reply-To: <C90872B6-7F17-4773-BDDC-736F5E36B919@icloud.com>
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
 <C90872B6-7F17-4773-BDDC-736F5E36B919@icloud.com>
Message-ID: <CAHxHggeg1U6q3iWOQCViDQoRm2=2uUEcEkL3eQRkeOMm3AKNCg@mail.gmail.com>

some key TCP players were part of the packet radio program (jim mathis,
vint cerf, ....)
v


On Wed, Apr 16, 2025 at 7:49?PM Greg Skinner via Internet-history <
internet-history at elists.isoc.org> wrote:

> On Apr 16, 2025, at 9:33?AM, Alexander McKenzie via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > Friends,
> >
> > I must apologize for a serious misstatement.  I now realize it was not
> > IEN's which were strictly controlled, it was Packet Radio Notes.  I
> myself
> > was on the public distribution list for IENs and I should have remembered
> > this.
> >
> > My sincere apologies,
> > Alex McKenzie
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
> OK, I understand (although some of those Packet Radio Notes are also
> IENs).  But IMO some of the Packet Radio Notes (such as those that are in
> https://apps.dtic.mil/sti/tr/pdf/ADA157696.pdf) that are not IENs could
> have been valuable to TCP implementors who were not part of the initial
> group of TCP implementors from the late 1970s and early 1980s.  At the very
> least, they give an idea of how one might go about designing or tuning a
> TCP implementation, or testing for interoperability (including performance).
>
> --gregbo
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


From b_a_denny at yahoo.com  Wed Apr 16 17:33:39 2025
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Thu, 17 Apr 2025 00:33:39 +0000 (UTC)
Subject: [ih] CORRECTION: Not IEN's, but Packet Radio Notes
In-Reply-To: <CAHxHggeg1U6q3iWOQCViDQoRm2=2uUEcEkL3eQRkeOMm3AKNCg@mail.gmail.com>
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
 <C90872B6-7F17-4773-BDDC-736F5E36B919@icloud.com>
 <CAHxHggeg1U6q3iWOQCViDQoRm2=2uUEcEkL3eQRkeOMm3AKNCg@mail.gmail.com>
Message-ID: <541302560.2714346.1744850019887@mail.yahoo.com>

 I also think Charlie Lynn (BBN) was working on one of the tcp implementations in the early 80s, if not before then.? He attended the BBN weekly packet radio meetings so he was aware of packet radio.
barbara
    On Wednesday, April 16, 2025 at 05:08:10 PM PDT, Vint Cerf via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 some key TCP players were part of the packet radio program (jim mathis,
vint cerf, ....)
v


On Wed, Apr 16, 2025 at 7:49?PM Greg Skinner via Internet-history <
internet-history at elists.isoc.org> wrote:

> On Apr 16, 2025, at 9:33?AM, Alexander McKenzie via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > Friends,
> >
> > I must apologize for a serious misstatement.? I now realize it was not
> > IEN's which were strictly controlled, it was Packet Radio Notes.? I
> myself
> > was on the public distribution list for IENs and I should have remembered
> > this.
> >
> > My sincere apologies,
> > Alex McKenzie
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
> OK, I understand (although some of those Packet Radio Notes are also
> IENs).? But IMO some of the Packet Radio Notes (such as those that are in
> https://apps.dtic.mil/sti/tr/pdf/ADA157696.pdf) that are not IENs could
> have been valuable to TCP implementors who were not part of the initial
> group of TCP implementors from the late 1970s and early 1980s.? At the very
> least, they give an idea of how one might go about designing or tuning a
> TCP implementation, or testing for interoperability (including performance).
>
> --gregbo

Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  

From gregskinner0 at icloud.com  Wed Apr 16 17:51:32 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Wed, 16 Apr 2025 17:51:32 -0700
Subject: [ih] CORRECTION: Not IEN's, but Packet Radio Notes
In-Reply-To: <CAHxHggeg1U6q3iWOQCViDQoRm2=2uUEcEkL3eQRkeOMm3AKNCg@mail.gmail.com>
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
 <C90872B6-7F17-4773-BDDC-736F5E36B919@icloud.com>
 <CAHxHggeg1U6q3iWOQCViDQoRm2=2uUEcEkL3eQRkeOMm3AKNCg@mail.gmail.com>
Message-ID: <D8DD8455-DD5A-45F0-82F1-8E84FAE88CC4@icloud.com>

The key players you mentioned are the ones I meant by ''initial group of TCP implementors from the late 1970s and early 1980s.??  But what about other TCP implementors who had access to RFC 793, but didn?t have access to Packet Radio Notes?  How aware were they of the application of the robustness principle for retransmission timeouts, etc?  From what I?ve seen of TCP implementations in the Unix Tree, TCP implementations varied in terms of their interpretation of the retransmission timeouts.  For example, some hardcoded the alpha/beta parameters, and some used floating point calculations to determine the smoothed round-trip time.

--gregbo

> On Apr 16, 2025, at 5:07?PM, Vint Cerf <vint at google.com> wrote:
> 
> some key TCP players were part of the packet radio program (jim mathis, vint cerf, ....)
> v
> 
> 
> On Wed, Apr 16, 2025 at 7:49?PM Greg Skinner via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> On Apr 16, 2025, at 9:33?AM, Alexander McKenzie via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> > 
>> > Friends,
>> > 
>> > I must apologize for a serious misstatement.  I now realize it was not
>> > IEN's which were strictly controlled, it was Packet Radio Notes.  I myself
>> > was on the public distribution list for IENs and I should have remembered
>> > this.
>> > 
>> > My sincere apologies,
>> > Alex McKenzie
>> > -- 
>> > Internet-history mailing list
>> > Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> > https://elists.isoc.org/mailman/listinfo/internet-history
>> 
>> OK, I understand (although some of those Packet Radio Notes are also IENs).  But IMO some of the Packet Radio Notes (such as those that are in https://apps.dtic.mil/sti/tr/pdf/ADA157696.pdf) that are not IENs could have been valuable to TCP implementors who were not part of the initial group of TCP implementors from the late 1970s and early 1980s.  At the very least, they give an idea of how one might go about designing or tuning a TCP implementation, or testing for interoperability (including performance).
>> 
>> --gregbo
>> 
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> https://elists.isoc.org/mailman/listinfo/internet-history
> 
> 
> 
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
> 
> 
> until further notice
> 
> 
> 



From jack at 3kitty.org  Wed Apr 16 18:02:45 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Wed, 16 Apr 2025 18:02:45 -0700
Subject: [ih] CORRECTION: Not IEN's, but Packet Radio Notes
In-Reply-To: <CAHxHggeg1U6q3iWOQCViDQoRm2=2uUEcEkL3eQRkeOMm3AKNCg@mail.gmail.com>
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
 <C90872B6-7F17-4773-BDDC-736F5E36B919@icloud.com>
 <CAHxHggeg1U6q3iWOQCViDQoRm2=2uUEcEkL3eQRkeOMm3AKNCg@mail.gmail.com>
Message-ID: <5f75f265-50b7-4ac3-a039-033d4af4c19a@3kitty.org>

In 1971 I encountered the ARPANET, while a student and then staff in 
Lick's group at MIT.? In 1977 I encountered The Internet, with my first 
assignment at BBN to implement TCP for Unix.

In both cases I was still in my 20s, and blissfully unaware of things 
like "office politics".?? I thought we were all working on the same team 
with the goal of building a new world using technology.?? Naive, I know.

But office politics existed.? Groups at MIT, BBN, and elsewhere competed 
with each other within their own organization for research funding.? The 
various research sites themselves similarly competed with their peers.? 
BBN, SRI, MIT, et al sought contracts from ARPA and others.? I never 
worked at ARPA, but I suspect Program Managers there also competed to 
get funds for their own projects.

In my own experience, I never encountered any pressure from ARPA to 
restrict distribution of research results (except for a few cases 
involving classified projects).? Or perhaps in my naivete I just didn't 
notice the pressure.

Managers, at some level in some organization, might have somehow 
restricted distribution of "their" research product, if only for fear of 
losing their funding to some other research activity - either because 
their benefactor warned them of the possibility, or because of fear they 
might do so.

In any event, I recall that information from other projects, in other 
groups at MIT or BBN, or from other research institutions, was not 
readily available in those years.? Perhaps we could get something, but 
it wasn't as easy as searching on the Web and downloading a copy is 
today.?? I never heard, or just missed understanding, that anything was 
being restricted.? But it wasn't made easy either to get such materials.

As The Internet was embraced by the commercial world, more competitive 
issues of course arrived.? Proprietary plans, technical details, and 
such information were likely to be kept close for competitive advantage.

It seems to me that there is a large component of Internet History that 
has never been well researched - namely the influence of things like 
such "office politics", the moving of key people from one organization 
to another (a form of "technology transfer"), and other such 
non-technical events during the formative years of The Internet.

Fifty years in the past, it may be too late now to capture that part of 
History.?? I doubt you'll find much about it in anything like RFCs or IENs.

Jack Haverty




On 4/16/25 17:07, Vint Cerf via Internet-history wrote:
> some key TCP players were part of the packet radio program (jim mathis,
> vint cerf, ....)
> v
>
>
> On Wed, Apr 16, 2025 at 7:49?PM Greg Skinner via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> On Apr 16, 2025, at 9:33?AM, Alexander McKenzie via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>> Friends,
>>>
>>> I must apologize for a serious misstatement.  I now realize it was not
>>> IEN's which were strictly controlled, it was Packet Radio Notes.  I
>> myself
>>> was on the public distribution list for IENs and I should have remembered
>>> this.
>>>
>>> My sincere apologies,
>>> Alex McKenzie
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>> OK, I understand (although some of those Packet Radio Notes are also
>> IENs).  But IMO some of the Packet Radio Notes (such as those that are in
>> https://apps.dtic.mil/sti/tr/pdf/ADA157696.pdf) that are not IENs could
>> have been valuable to TCP implementors who were not part of the initial
>> group of TCP implementors from the late 1970s and early 1980s.  At the very
>> least, they give an idea of how one might go about designing or tuning a
>> TCP implementation, or testing for interoperability (including performance).
>>
>> --gregbo
>>
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250416/b87cdb82/attachment.asc>

From gregskinner0 at icloud.com  Wed Apr 16 22:01:35 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Wed, 16 Apr 2025 22:01:35 -0700
Subject: [ih] CORRECTION: Not IEN's, but Packet Radio Notes
In-Reply-To: <541302560.2714346.1744850019887@mail.yahoo.com>
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
 <C90872B6-7F17-4773-BDDC-736F5E36B919@icloud.com>
 <CAHxHggeg1U6q3iWOQCViDQoRm2=2uUEcEkL3eQRkeOMm3AKNCg@mail.gmail.com>
 <541302560.2714346.1744850019887@mail.yahoo.com>
Message-ID: <46F26B1E-C4C8-4C1A-95D7-CE90156FF1C8@icloud.com>

There are notes written by Charlie Lynn in the RFC Editor ?museum? directory dated March and May 1982, respectively. [1] [2]  Both can be configured to use the same packet radio retransmission parameters that Jim Mathis used in his 1979 implementation.  The latter computes round-trip times similarly to the RSRE algorithm.

--gregbo 

[1] https://www.rfc-editor.org/in-notes/museum/tcp-jsys.txt
[2] https://www.rfc-editor.org/in-notes/museum/tcp-ip.txt

> On Apr 16, 2025, at 5:33?PM, Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> I also think Charlie Lynn (BBN) was working on one of the tcp implementations in the early 80s, if not before then.  He attended the BBN weekly packet radio meetings so he was aware of packet radio.
> barbara
>    On Wednesday, April 16, 2025 at 05:08:10 PM PDT, Vint Cerf via Internet-history <internet-history at elists.isoc.org> wrote:  
> 
> some key TCP players were part of the packet radio program (jim mathis,
> vint cerf, ....)
> v
> 
> 
> On Wed, Apr 16, 2025 at 7:49?PM Greg Skinner via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> On Apr 16, 2025, at 9:33?AM, Alexander McKenzie via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>> 
>>> Friends,
>>> 
>>> I must apologize for a serious misstatement.  I now realize it was not
>>> IEN's which were strictly controlled, it was Packet Radio Notes.  I
>> myself
>>> was on the public distribution list for IENs and I should have remembered
>>> this.
>>> 
>>> My sincere apologies,
>>> Alex McKenzie
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
>> OK, I understand (although some of those Packet Radio Notes are also
>> IENs).  But IMO some of the Packet Radio Notes (such as those that are in
>> https://apps.dtic.mil/sti/tr/pdf/ADA157696.pdf) that are not IENs could
>> have been valuable to TCP implementors who were not part of the initial
>> group of TCP implementors from the late 1970s and early 1980s.  At the very
>> least, they give an idea of how one might go about designing or tuning a
>> TCP implementation, or testing for interoperability (including performance).
>> 
>> --gregbo
> 
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
> 
> 
> until further notice
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From df at macgui.com  Thu Apr 17 08:19:21 2025
From: df at macgui.com (David Finnigan)
Date: Thu, 17 Apr 2025 10:19:21 -0500
Subject: [ih] TCP RTT Estimator
In-Reply-To: <19DDADD9-C76C-4426-90E2-ADEFE19476C1@comcast.net>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
 <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
 <fcd107ac-1c5b-4e7b-b340-f9bae81f0643@dcrocker.net>
 <19DDADD9-C76C-4426-90E2-ADEFE19476C1@comcast.net>
Message-ID: <c5baf34caae8aacafb78e3d22793e742@macgui.com>

On 13 Apr 2025 6:57 am, John Day via Internet-history wrote:
> Sometime ago, (I think it was Jack Haverty) said that the TCP checksum
> was a placeholder until they could consult someone to advise them on
> what to use and it got lost in the shuffle.  ;-)

Even RFC 791 [Sep 1981] states "experimental evidence indicates it [the 
checksum] is adequate, but it is provisional and may be replaced by a 
CRC procedure, depending on further experience."

-David Finnigan


From gregskinner0 at icloud.com  Thu Apr 17 09:25:35 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Thu, 17 Apr 2025 09:25:35 -0700
Subject: [ih] CORRECTION: Not IEN's, but Packet Radio Notes
In-Reply-To: <541302560.2714346.1744850019887@mail.yahoo.com>
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
 <C90872B6-7F17-4773-BDDC-736F5E36B919@icloud.com>
 <CAHxHggeg1U6q3iWOQCViDQoRm2=2uUEcEkL3eQRkeOMm3AKNCg@mail.gmail.com>
 <541302560.2714346.1744850019887@mail.yahoo.com>
Message-ID: <6D3A939F-A2A5-4D03-BB63-8FD06A4E1887@icloud.com>

Also see https://www.saildart.org/[IP,SYS]/ <https://www.saildart.org/%5BIP,SYS%5D/> in the saildart (Stanford AI Lab) archives.  It contains TCP code originally written by Bill Plummer and edited by Charlie Lynn.

--gregbo 

[1] https://www.rfc-editor.org/in-notes/museum/tcp-jsys.txt
[2] https://www.rfc-editor.org/in-notes/museum/tcp-ip.txt

> On Apr 16, 2025, at 5:33?PM, Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> I also think Charlie Lynn (BBN) was working on one of the tcp implementations in the early 80s, if not before then.  He attended the BBN weekly packet radio meetings so he was aware of packet radio.
> barbara
>    On Wednesday, April 16, 2025 at 05:08:10 PM PDT, Vint Cerf via Internet-history <internet-history at elists.isoc.org> wrote:  
> 
> some key TCP players were part of the packet radio program (jim mathis,
> vint cerf, ....)
> v
> 
> 
> On Wed, Apr 16, 2025 at 7:49?PM Greg Skinner via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> On Apr 16, 2025, at 9:33?AM, Alexander McKenzie via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>> 
>>> Friends,
>>> 
>>> I must apologize for a serious misstatement.  I now realize it was not
>>> IEN's which were strictly controlled, it was Packet Radio Notes.  I
>> myself
>>> was on the public distribution list for IENs and I should have remembered
>>> this.
>>> 
>>> My sincere apologies,
>>> Alex McKenzie
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
>> OK, I understand (although some of those Packet Radio Notes are also
>> IENs).  But IMO some of the Packet Radio Notes (such as those that are in
>> https://apps.dtic.mil/sti/tr/pdf/ADA157696.pdf) that are not IENs could
>> have been valuable to TCP implementors who were not part of the initial
>> group of TCP implementors from the late 1970s and early 1980s.  At the very
>> least, they give an idea of how one might go about designing or tuning a
>> TCP implementation, or testing for interoperability (including performance).
>> 
>> --gregbo
> 
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
> 
> 
> until further notice
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From jack at 3kitty.org  Thu Apr 17 10:53:48 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Thu, 17 Apr 2025 10:53:48 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <c5baf34caae8aacafb78e3d22793e742@macgui.com>
References: <1676873250.2847239.1741721013305.ref@mail.yahoo.com>
 <1676873250.2847239.1741721013305@mail.yahoo.com>
 <b7b35b9f-641a-4e23-91c0-a0991fc52a5b@dcrocker.net>
 <865890042.2905597.1741726920385@mail.yahoo.com>
 <4A604A2D-5CA1-4869-91EA-DC8BD9DBD254@comcast.net>
 <1333609295.2931332.1741729733743@mail.yahoo.com>
 <6D902D9F-6DDC-41A9-8E9A-21AA49C6FD35@icloud.com>
 <8441175E-BFC2-49D2-9C75-5F0C0F96F52B@comcast.net>
 <0BE57BC0-CF5E-4983-970B-6CA186397FC5@icloud.com>
 <B89C8A24-26DC-4ECE-B5C9-0EB73955B3FF@comcast.net>
 <7473A205-577B-47BC-870D-760D058DD8BA@icloud.com>
 <CAHxHggcvUOQbi8iNpiUhjHr6O3O6eRDAeqSFkB1iw46XT8m_Ng@mail.gmail.com>
 <00CCB8BF-6820-4964-BDA1-9D361522EC11@icloud.com>
 <fcd107ac-1c5b-4e7b-b340-f9bae81f0643@dcrocker.net>
 <19DDADD9-C76C-4426-90E2-ADEFE19476C1@comcast.net>
 <c5baf34caae8aacafb78e3d22793e742@macgui.com>
Message-ID: <56b54ad8-f058-4000-b401-e62fdc0822c5@3kitty.org>

A bit more recollection...

One of the reasons that the checksum was considered "adequate" was 
because, at the time, The Internet was in what I've called its "fuzzy 
peach" stage.?? The ARPANET was the peach, and the fuzz was all of the 
"local" networks attached to it.?? SATNET was the only other long-haul 
component of The Internet. ? ARPANET provided a virtual circuit service 
between gateways, which never dropped datagrams, reordered them or 
otherwise behaved in ways that a checksum would detect.? IIRC SATNET 
behavior was similar, but datagrams could be (and were) dropped in 
underpowered gateways.

Most of the focus on checksumming at the time was on dealing with errors 
in circuits.? But there had been experiences in the ARPANET where a 
problem was caused by a hardware failure in an IMP (memory problem).? 
There hadn't been much, if any, study or analysis of such failures, and 
we had no idea how the various kinds of underlying networks that might 
be part of The Internet would generate errors.

When there had been more experience with how the actual links between 
gateways behaved, some new checksum algorithm might be created to deal 
with them.? So, ... it was put on the to-do list for the Next Release.? 
Perhaps it's still there.

Jack Haverty

On 4/17/25 08:19, David Finnigan via Internet-history wrote:
> On 13 Apr 2025 6:57 am, John Day via Internet-history wrote:
>> Sometime ago, (I think it was Jack Haverty) said that the TCP checksum
>> was a placeholder until they could consult someone to advise them on
>> what to use and it got lost in the shuffle.? ;-)
>
> Even RFC 791 [Sep 1981] states "experimental evidence indicates it 
> [the checksum] is adequate, but it is provisional and may be replaced 
> by a CRC procedure, depending on further experience."
>
> -David Finnigan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250417/56d4a5ac/attachment.asc>

From lk at cs.ucla.edu  Thu Apr 17 11:34:34 2025
From: lk at cs.ucla.edu (Leonard Kleinrock)
Date: Thu, 17 Apr 2025 11:34:34 -0700 (PDT)
Subject: [ih] TCP RTT Estimator
Message-ID: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>

Hi Dave,,
?As I understood it, the CRC code was especially easy and powerful for detecting errors, but extremely complicated for correcting errors. I would?ve guessed that the error detection was indeed CRC (the BCH code). 
Len

Sent from my iPhone

> On Apr 17, 2025, at 8:19?AM, David Finnigan via Internet-history <internet-history at elists.isoc.org> wrote:
> ?On 13 Apr 2025 6:57 am, John Day via Internet-history wrote:
>> Sometime ago, (I think it was Jack Haverty) said that the TCP checksum
>> was a placeholder until they could consult someone to advise them on
>> what to use and it got lost in the shuffle.  ;-)
> 
> Even RFC 791 [Sep 1981] states "experimental evidence indicates it [the checksum] is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience."
> 
> -David Finnigan
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

From touch at strayalpha.com  Thu Apr 17 11:58:46 2025
From: touch at strayalpha.com (touch at strayalpha.com)
Date: Thu, 17 Apr 2025 11:58:46 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
Message-ID: <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>

AFAICT, the Internet checksum was basically a trade-off between an additional E2E check and the cost of implementing it in software.

Link devices already had CRCs, but implemented in hardware, where bit-wise mixing is very fast. In software, the same function can require multiple opcodes per bit; the Internet checksum is one opcode per CPU word (1 per byte in the early days, fewer now), i.e., runs around 16-30x faster in software. Because the Internet assumes link layers can vary, there?s no easy way to assume all net devices implement the same CRC in hardware.

This kind of speed difference gave rise to the misconception that *every* SW crypto/check alg was 10-50x faster in HW, which notably isn?t true for some hashes such as MD5.

Joe

?
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Apr 17, 2025, at 11:34?AM, Leonard Kleinrock via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Hi Dave,,
> ?As I understood it, the CRC code was especially easy and powerful for detecting errors, but extremely complicated for correcting errors. I would?ve guessed that the error detection was indeed CRC (the BCH code). 
> Len
> 
> Sent from my iPhone
> 
>> On Apr 17, 2025, at 8:19?AM, David Finnigan via Internet-history <internet-history at elists.isoc.org> wrote:
>> ?On 13 Apr 2025 6:57 am, John Day via Internet-history wrote:
>>> Sometime ago, (I think it was Jack Haverty) said that the TCP checksum
>>> was a placeholder until they could consult someone to advise them on
>>> what to use and it got lost in the shuffle.  ;-)
>> 
>> Even RFC 791 [Sep 1981] states "experimental evidence indicates it [the checksum] is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience."
>> 
>> -David Finnigan
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From jack at 3kitty.org  Fri Apr 18 10:09:42 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 18 Apr 2025 10:09:42 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
Message-ID: <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>

I can confirm that the computer resources for computing a checksum were 
definitely a concern with the machines of that era. Communications 
hardware, such as modems, could do robust checksums in hardware, but the 
checksums in TCP/IP were too complicated for that since only particular 
parts of datagrams were included in the calculations.

It was difficult enough to get a decent packets-per-second performance 
in gateways, and minimize overhead in host computers, without the 
additional work to do a "real" checksum.? So the rudimentary one (that 
IIRC was the same one we settled on at the first Bakeoff) was adequate 
for the moment.

In addition, we expected that, for DoD use, real-world deployment would 
utilize encryption, as was being done at the time on the ARPANET using 
PLIs.? See https://en.wikipedia.org/wiki/ARPANET_encryption_devices? 
Military grade encryption was quite good as a checksum algorithm to 
catch all sorts of problems, including errors in transmission.

Thinking back, I can't recall the reason for including checksums in TCP 
at all.? Perhaps it was just there because it was standard practice to 
include some kind of mechanism to detect the expected transmission 
errors on circuits of the day.? Of course you had to have a checksum ... 
everyone else does.

Jack Haverty

On 4/17/25 11:58, touch--- via Internet-history wrote:
> AFAICT, the Internet checksum was basically a trade-off between an additional E2E check and the cost of implementing it in software.
>
> Link devices already had CRCs, but implemented in hardware, where bit-wise mixing is very fast. In software, the same function can require multiple opcodes per bit; the Internet checksum is one opcode per CPU word (1 per byte in the early days, fewer now), i.e., runs around 16-30x faster in software. Because the Internet assumes link layers can vary, there?s no easy way to assume all net devices implement the same CRC in hardware.
>
> This kind of speed difference gave rise to the misconception that *every* SW crypto/check alg was 10-50x faster in HW, which notably isn?t true for some hashes such as MD5.
>
> Joe
>
> ?
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
>> On Apr 17, 2025, at 11:34?AM, Leonard Kleinrock via Internet-history<internet-history at elists.isoc.org>  wrote:
>>
>> Hi Dave,,
>> ?As I understood it, the CRC code was especially easy and powerful for detecting errors, but extremely complicated for correcting errors. I would?ve guessed that the error detection was indeed CRC (the BCH code).
>> Len
>>
>> Sent from my iPhone
>>
>>> On Apr 17, 2025, at 8:19?AM, David Finnigan via Internet-history<internet-history at elists.isoc.org>  wrote:
>>> ?On 13 Apr 2025 6:57 am, John Day via Internet-history wrote:
>>>> Sometime ago, (I think it was Jack Haverty) said that the TCP checksum
>>>> was a placeholder until they could consult someone to advise them on
>>>> what to use and it got lost in the shuffle.  ;-)
>>> Even RFC 791 [Sep 1981] states "experimental evidence indicates it [the checksum] is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience."
>>>
>>> -David Finnigan
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250418/cda2af2a/attachment.asc>

From agmalis at gmail.com  Fri Apr 18 10:25:10 2025
From: agmalis at gmail.com (Andrew G. Malis)
Date: Fri, 18 Apr 2025 13:25:10 -0400
Subject: [ih] TCP RTT Estimator
In-Reply-To: <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
 <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
Message-ID: <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>

Jack,

> Thinking back, I can't recall the reason for including checksums in TCP
at all.

It was primarily to catch memory errors, which were a real thing back in
the core memory days. Errors during transmission were generally caught by
the lower layers.

Cheers,
Andy


From craig at tereschau.net  Fri Apr 18 10:30:22 2025
From: craig at tereschau.net (Craig Partridge)
Date: Fri, 18 Apr 2025 11:30:22 -0600
Subject: [ih] TCP RTT Estimator
In-Reply-To: <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
 <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
 <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
Message-ID: <CAHQj4CeHUXpeYyUmHSadkR81GzU7yQaUk26MTxe00rc9FSKFqw@mail.gmail.com>

On Fri, Apr 18, 2025 at 11:25?AM Andrew G. Malis via Internet-history <
internet-history at elists.isoc.org> wrote:

> Jack,
>
> > Thinking back, I can't recall the reason for including checksums in TCP
> at all.
>
> It was primarily to catch memory errors, which were a real thing back in
> the core memory days. Errors during transmission were generally caught by
> the lower layers.
>

Memory errors are back.... I'm on a team that has caught them in disk
caches :-(
Craig


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.


From jack at 3kitty.org  Fri Apr 18 11:00:13 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 18 Apr 2025 11:00:13 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <CAHQj4CeHUXpeYyUmHSadkR81GzU7yQaUk26MTxe00rc9FSKFqw@mail.gmail.com>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
 <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
 <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
 <CAHQj4CeHUXpeYyUmHSadkR81GzU7yQaUk26MTxe00rc9FSKFqw@mail.gmail.com>
Message-ID: <811878c8-d2b8-438d-8530-858629aace8c@3kitty.org>

Memory errors caused at least some ARPANET crashes, but I suspect few 
people outside of BBN knew such details.? But memory errors could affect 
any part of the data.? The checksums in TCP only covered some parts of 
the headers.?? If they were designed to protect against memory problems, 
shouldn't they have covered the entire datagrams?

Subsequently, changes to the TCP/IP architecture made checksums even 
less potent, when devices along the path through the Internet started 
recalculating checksums.? Mechanisms such as NAT, for example.

So I still can't recall why checksums were included in TCP...

Jack

On 4/18/25 10:30, Craig Partridge wrote:
>
>
> On Fri, Apr 18, 2025 at 11:25?AM Andrew G. Malis via Internet-history 
> <internet-history at elists.isoc.org> wrote:
>
>     Jack,
>
>     > Thinking back, I can't recall the reason for including checksums
>     in TCP
>     at all.
>
>     It was primarily to catch memory errors, which were a real thing
>     back in
>     the core memory days. Errors during transmission were generally
>     caught by
>     the lower layers.
>
>
> Memory errors are back.... I'm on a team that has caught them in disk 
> caches :-(
> Craig
>
>
> -- 
> *****
> Craig Partridge's email account for professional society activities 
> and mailing lists.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250418/cd2b52c3/attachment.asc>

From jeanjour at comcast.net  Fri Apr 18 11:14:26 2025
From: jeanjour at comcast.net (John Day)
Date: Fri, 18 Apr 2025 14:14:26 -0400
Subject: [ih] TCP RTT Estimator
In-Reply-To: <811878c8-d2b8-438d-8530-858629aace8c@3kitty.org>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
 <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
 <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
 <CAHQj4CeHUXpeYyUmHSadkR81GzU7yQaUk26MTxe00rc9FSKFqw@mail.gmail.com>
 <811878c8-d2b8-438d-8530-858629aace8c@3kitty.org>
Message-ID: <B04A35EC-7886-4CEE-8BE4-A8DCC898A0C8@comcast.net>

Correct me if I am wrong, but I thought the TCP checksum covered the entire TCP packet plus the pseudo-header.

The IP checksum only covered the IP header plus the pseudo-header.

Am I wrong?

John 

> On Apr 18, 2025, at 14:00, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Memory errors caused at least some ARPANET crashes, but I suspect few people outside of BBN knew such details.  But memory errors could affect any part of the data.  The checksums in TCP only covered some parts of the headers.   If they were designed to protect against memory problems, shouldn't they have covered the entire datagrams?
> 
> Subsequently, changes to the TCP/IP architecture made checksums even less potent, when devices along the path through the Internet started recalculating checksums.  Mechanisms such as NAT, for example.
> 
> So I still can't recall why checksums were included in TCP...
> 
> Jack
> 
> On 4/18/25 10:30, Craig Partridge wrote:
>> 
>> 
>> On Fri, Apr 18, 2025 at 11:25?AM Andrew G. Malis via Internet-history <internet-history at elists.isoc.org> wrote:
>> 
>>    Jack,
>> 
>>    > Thinking back, I can't recall the reason for including checksums
>>    in TCP
>>    at all.
>> 
>>    It was primarily to catch memory errors, which were a real thing
>>    back in
>>    the core memory days. Errors during transmission were generally
>>    caught by
>>    the lower layers.
>> 
>> 
>> Memory errors are back.... I'm on a team that has caught them in disk caches :-(
>> Craig
>> 
>> 
>> -- 
>> *****
>> Craig Partridge's email account for professional society activities and mailing lists.
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From jack at 3kitty.org  Fri Apr 18 11:49:20 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 18 Apr 2025 11:49:20 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <B04A35EC-7886-4CEE-8BE4-A8DCC898A0C8@comcast.net>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
 <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
 <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
 <CAHQj4CeHUXpeYyUmHSadkR81GzU7yQaUk26MTxe00rc9FSKFqw@mail.gmail.com>
 <811878c8-d2b8-438d-8530-858629aace8c@3kitty.org>
 <B04A35EC-7886-4CEE-8BE4-A8DCC898A0C8@comcast.net>
Message-ID: <00360074-c8a7-4b49-97ec-b3405f5996ed@3kitty.org>

John - you're right, the TCP checksum covers the header and "text".?? I 
was thinking of the checksum in the IP header.?? The Cerf/Kahn 1974 
paper has checksums in various places, but I don't recall how they were 
implemented before TCP and IP had been split apart.

At the time there was a lot of debate about the "End-to-end" issues in 
The Internet.? One of the issues I brought up was the "End-Middle" 
scenarios.?? As a datagram flowed through devices, some of the 
information in headers was "consumed" by devices in the "middle", e.g., 
gateways which relied on data in IP header fields and options.? Other 
information was "produced" by devices along the way and added to the 
datagram, e.g., the addresses added into "record route" options or new 
datagrams sent such as Source Quench.

Each of those information flows, from producer to consumer(s), was 
subject to errors, but there was no mechanism to provide error 
detection, correction, or source authentication for all those flows of 
information that occurred whenever a datagram was sent.?? There were 
more "ends" than the obvious two involved in the communication.? That 
was another issue put on the long-term to-do list.

This was not just a characteristic of TCP/IP.?? The same thing happens 
even today in email headers, as you can see by looking at the raw 
headers in emails like this one.

Jack

On 4/18/25 11:14, John Day wrote:
> Correct me if I am wrong, but I thought the TCP checksum covered the entire TCP packet plus the pseudo-header.
>
> The IP checksum only covered the IP header plus the pseudo-header.
>
> Am I wrong?
>
> John
>
>> On Apr 18, 2025, at 14:00, Jack Haverty via Internet-history<internet-history at elists.isoc.org>  wrote:
>>
>> Memory errors caused at least some ARPANET crashes, but I suspect few people outside of BBN knew such details.  But memory errors could affect any part of the data.  The checksums in TCP only covered some parts of the headers.   If they were designed to protect against memory problems, shouldn't they have covered the entire datagrams?
>>
>> Subsequently, changes to the TCP/IP architecture made checksums even less potent, when devices along the path through the Internet started recalculating checksums.  Mechanisms such as NAT, for example.
>>
>> So I still can't recall why checksums were included in TCP...
>>
>> Jack
>>
>> On 4/18/25 10:30, Craig Partridge wrote:
>>>
>>> On Fri, Apr 18, 2025 at 11:25?AM Andrew G. Malis via Internet-history<internet-history at elists.isoc.org>  wrote:
>>>
>>>     Jack,
>>>
>>>     > Thinking back, I can't recall the reason for including checksums
>>>     in TCP
>>>     at all.
>>>
>>>     It was primarily to catch memory errors, which were a real thing
>>>     back in
>>>     the core memory days. Errors during transmission were generally
>>>     caught by
>>>     the lower layers.
>>>
>>>
>>> Memory errors are back.... I'm on a team that has caught them in disk caches :-(
>>> Craig
>>>
>>>
>>> -- 
>>> *****
>>> Craig Partridge's email account for professional society activities and mailing lists.
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250418/561bdfd4/attachment.asc>

From steve at shinkuro.com  Fri Apr 18 12:12:16 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Fri, 18 Apr 2025 15:12:16 -0400
Subject: [ih] TCP RTT Estimator
In-Reply-To: <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
 <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
 <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
Message-ID: <CABf5zvL2U9t9fc9peCuj7Rerhg8x4FE1RFC+x4NYx31zf7wTbA@mail.gmail.com>

We tried to include a lightweight checksum in the original host-host
protocol.  (Later it was called the Network Control Protocol or NCP.  Same
protocol.)  The checksum was designed to be reasonably easy to compute.  It
was a 16-bit ones complement sum with one bit of rotation every thousand or
so bits.  (The rotation was intended to catch packets out of order, error
which we imagined might be possible but never occurred.)  Frank Heart
argued vehemently against it, saying it would make his network look slow.
I tried to push back and asked about the Host-IMP interface.  "As reliable
as your accumulator," he roared.

We removed the checkum from our design, a mistake I've rued ever since.
And, of course, it turned out there were indeed a few cases where it would
have made a difference.  As has been pointed out, there was a major memory
error in one of the IMPs that caused that IMP to look like it was zero
distance to every IMP.  But even before that error, when Lincoln Lab first
connected its host to its IMP, their hardware interface had a problem.
There was some crosstalk between the interface and the disk (or drum)
controller.  When the disk (or drum) was operating at the same time as the
Host-IMP interface, some bits got scrambled.  It apparently took them some
time to track down.  I think they would have found it faster if the
checksum had been part of the design.

Steve


On Fri, Apr 18, 2025 at 1:25?PM Andrew G. Malis via Internet-history <
internet-history at elists.isoc.org> wrote:

> Jack,
>
> > Thinking back, I can't recall the reason for including checksums in TCP
> at all.
>
> It was primarily to catch memory errors, which were a real thing back in
> the core memory days. Errors during transmission were generally caught by
> the lower layers.
>
> Cheers,
> Andy
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Sent by a Verified

sender


From jack at 3kitty.org  Fri Apr 18 12:49:39 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 18 Apr 2025 12:49:39 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <CABf5zvL2U9t9fc9peCuj7Rerhg8x4FE1RFC+x4NYx31zf7wTbA@mail.gmail.com>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
 <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
 <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
 <CABf5zvL2U9t9fc9peCuj7Rerhg8x4FE1RFC+x4NYx31zf7wTbA@mail.gmail.com>
Message-ID: <b0614d17-2b3e-4d5f-bea0-d089c0a01eee@3kitty.org>

Hi Steve,

The IMPs actually had quite a bit of internal mechanism to address 
relability, which evolved as the network grew and more problems 
occurred.? I joined Frank Heart's group in 1977, to work on TCP-related 
contracts, but was surrounded by the ARPANET group so a lot of that DNA 
transferred over.? The IMP subnet tried real hard to hide the vagaries 
of packet switching from the end users' hosts.? In effect there was an 
end-end TCP-like function between two hosts' attached IMPs that made 
sure no packets were ever lost, duplicated, or reordered so that the 
hosts saw only the behavior of a virtual circuit.

When Vint asked me to take over the gateway work and make the "core" 
Internet a 24x7 service, we congealed a "Gateway Group" to do the work.? 
They lived literally down the hall from the ARPANET world. One of that 
crew was Mike Brescia.? We were working on making the Internet work like 
the ARPANET, but until the NOC was in the loop, Mike watched over the 
Internet behavior to catch and fix problems.

One day some gateway was reporting lots of checksum errors.? Some tools 
were already available for remote debugging.? So Mike investigated and 
noticed that all of the errors were for datagrams from one particular 
host somewhere in the US Midwest.? So not a gateway or IMP problem, but 
Mike captured a few failed datagrams, and noticed that bytes in the TCP 
header were out-of-order, which was causing the checksum errors.

That was a problem I had already struggled with in implementing my Unix 
TCP.? We knew about it.? So Mike looked up the host info in the NIC, and 
sent an email to the technical contact - something like "You need to 
swap the address bytes in your source address." Shortly after, he got a 
reply, something like "Thanks!? That was the problem."

Shortly after that he got another email -- "How the *^&%&^% did you know 
that?!"

Checksumming was a useful debugging tool, even for remote debugging.?? 
I've learned over the years that researchers don't think enough about 
how their designs will be operated and managed.

Jack


On 4/18/25 12:12, Steve Crocker wrote:
> We tried to include?a lightweight checksum in the?original host-host 
> protocol.? (Later it was called the Network Control Protocol or NCP.? 
> Same protocol.)? The checksum was designed to be reasonably easy to 
> compute.? It was a 16-bit?ones?complement sum with one bit of 
> rotation?every thousand or so bits.? (The rotation was intended to 
> catch packets out of order, error which we imagined might be possible 
> but never occurred.)? Frank Heart argued vehemently against?it, saying 
> it would?make his network look slow.? I tried to push back and asked 
> about?the Host-IMP interface. "As reliable as your accumulator," he 
> roared.
>
> We removed the checkum from our design, a mistake I've rued ever 
> since.? And, of?course, it turned out there were indeed a few cases 
> where it would have made a difference.? As has been pointed out, there 
> was a major memory error in one of the IMPs that caused that IMP to 
> look like it was zero distance to every IMP.? But even before that 
> error, when Lincoln Lab first connected its host to its IMP, their 
> hardware interface had a problem.? There was some crosstalk between 
> the interface and the disk (or drum) controller.? When the disk (or 
> drum) was operating at the same time as the Host-IMP interface, some 
> bits got scrambled.? It apparently took them some time to track?down.? 
> I think they would have found it faster if the checksum had been part 
> of the design.
>
> Steve
>
>
> On Fri, Apr 18, 2025 at 1:25?PM Andrew G. Malis via Internet-history 
> <internet-history at elists.isoc.org> wrote:
>
>     Jack,
>
>     > Thinking back, I can't recall the reason for including checksums
>     in TCP
>     at all.
>
>     It was primarily to catch memory errors, which were a real thing
>     back in
>     the core memory days. Errors during transmission were generally
>     caught by
>     the lower layers.
>
>     Cheers,
>     Andy
>     -- 
>     Internet-history mailing list
>     Internet-history at elists.isoc.org
>     https://elists.isoc.org/mailman/listinfo/internet-history
>
>
>
> -- 
> Sent by a Verified
>
> sender

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250418/da8910da/attachment.asc>

From steve at shinkuro.com  Fri Apr 18 12:55:43 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Fri, 18 Apr 2025 15:55:43 -0400
Subject: [ih] TCP RTT Estimator
In-Reply-To: <b0614d17-2b3e-4d5f-bea0-d089c0a01eee@3kitty.org>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
 <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
 <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
 <CABf5zvL2U9t9fc9peCuj7Rerhg8x4FE1RFC+x4NYx31zf7wTbA@mail.gmail.com>
 <b0614d17-2b3e-4d5f-bea0-d089c0a01eee@3kitty.org>
Message-ID: <CABf5zvKrN9yhvWzJ+6FWNx7z9kL_kGRhrKgrosQSHGyjfCH1NQ@mail.gmail.com>

Jack,

In our early design discussions, late 1968 and early 1969, Jeff Rulifson
from SRI pushed for a checksum for exactly the reason you described, viz it
would catch software errors between layers.

Steve

Sent by a Verified

sender


On Fri, Apr 18, 2025 at 3:49?PM Jack Haverty <jack at 3kitty.org> wrote:

> Hi Steve,
>
> The IMPs actually had quite a bit of internal mechanism to address
> relability, which evolved as the network grew and more problems occurred.
> I joined Frank Heart's group in 1977, to work on TCP-related contracts, but
> was surrounded by the ARPANET group so a lot of that DNA transferred over.
> The IMP subnet tried real hard to hide the vagaries of packet switching
> from the end users' hosts.  In effect there was an end-end TCP-like
> function between two hosts' attached IMPs that made sure no packets were
> ever lost, duplicated, or reordered so that the hosts saw only the behavior
> of a virtual circuit.
>
> When Vint asked me to take over the gateway work and make the "core"
> Internet a 24x7 service, we congealed a "Gateway Group" to do the work.
> They lived literally down the hall from the ARPANET world.  One of that
> crew was Mike Brescia.  We were working on making the Internet work like
> the ARPANET, but until the NOC was in the loop, Mike watched over the
> Internet behavior to catch and fix problems.
>
> One day some gateway was reporting lots of checksum errors.  Some tools
> were already available for remote debugging.  So Mike investigated and
> noticed that all of the errors were for datagrams from one particular host
> somewhere in the US Midwest.  So not a gateway or IMP problem, but Mike
> captured a few failed datagrams, and noticed that bytes in the TCP header
> were out-of-order, which was causing the checksum errors.
>
> That was a problem I had already struggled with in implementing my Unix
> TCP.  We knew about it.  So Mike looked up the host info in the NIC, and
> sent an email to the technical contact - something like "You need to swap
> the address bytes in your source address."  Shortly after, he got a reply,
> something like "Thanks!  That was the problem."
>
> Shortly after that he got another email -- "How the *^&%&^% did you know
> that?!"
>
> Checksumming was a useful debugging tool, even for remote debugging.
> I've learned over the years that researchers don't think enough about how
> their designs will be operated and managed.
>
>
> Jack
>
>
> On 4/18/25 12:12, Steve Crocker wrote:
>
> We tried to include a lightweight checksum in the original host-host
> protocol.  (Later it was called the Network Control Protocol or NCP.  Same
> protocol.)  The checksum was designed to be reasonably easy to compute.  It
> was a 16-bit ones complement sum with one bit of rotation every thousand or
> so bits.  (The rotation was intended to catch packets out of order, error
> which we imagined might be possible but never occurred.)  Frank Heart
> argued vehemently against it, saying it would make his network look slow.
> I tried to push back and asked about the Host-IMP interface.  "As reliable
> as your accumulator," he roared.
>
> We removed the checkum from our design, a mistake I've rued ever since.
> And, of course, it turned out there were indeed a few cases where it would
> have made a difference.  As has been pointed out, there was a major memory
> error in one of the IMPs that caused that IMP to look like it was zero
> distance to every IMP.  But even before that error, when Lincoln Lab first
> connected its host to its IMP, their hardware interface had a problem.
> There was some crosstalk between the interface and the disk (or drum)
> controller.  When the disk (or drum) was operating at the same time as the
> Host-IMP interface, some bits got scrambled.  It apparently took them some
> time to track down.  I think they would have found it faster if the
> checksum had been part of the design.
>
> Steve
>
>
> On Fri, Apr 18, 2025 at 1:25?PM Andrew G. Malis via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> Jack,
>>
>> > Thinking back, I can't recall the reason for including checksums in TCP
>> at all.
>>
>> It was primarily to catch memory errors, which were a real thing back in
>> the core memory days. Errors during transmission were generally caught by
>> the lower layers.
>>
>> Cheers,
>> Andy
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>
>
> --
> Sent by a Verified
>
> sender
>
>
>


From jack at 3kitty.org  Fri Apr 18 13:38:07 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 18 Apr 2025 13:38:07 -0700
Subject: [ih] TCP RTT Estimator
In-Reply-To: <CABf5zvKrN9yhvWzJ+6FWNx7z9kL_kGRhrKgrosQSHGyjfCH1NQ@mail.gmail.com>
References: <04B16C00-0533-4E91-A0EC-26F5FFAF30A4@cs.ucla.edu>
 <88A7C4FE-30C3-41A7-8C65-06745D3592DF@strayalpha.com>
 <4d3efbc5-2153-4501-be46-99c8308e62fa@3kitty.org>
 <CAA=duU1Apg6VjKrwNinwfQ2cWjZiJWg16ah7wODr+nuUNMZbZA@mail.gmail.com>
 <CABf5zvL2U9t9fc9peCuj7Rerhg8x4FE1RFC+x4NYx31zf7wTbA@mail.gmail.com>
 <b0614d17-2b3e-4d5f-bea0-d089c0a01eee@3kitty.org>
 <CABf5zvKrN9yhvWzJ+6FWNx7z9kL_kGRhrKgrosQSHGyjfCH1NQ@mail.gmail.com>
Message-ID: <98435a99-b71a-4cac-8090-fadc06895b06@3kitty.org>

That was while I was just an undergraduate so before my encountering 
networking.?? But I think there haven't been enough people thinking 
about operations when designing systems.? Of course the whole arena of 
"distributed multi-processing" (aka "networking") was just emerging as a 
possibility to replace the more common punch-card-decks and printouts 
use of computers at the time.

Taking advantage of the geographical proximity of the ARPANET work, we 
Internet Guys tried hard to adapt the operations tools proven by years 
of ARPANET operations into the Internet environment.? IMPs sent "traps" 
to the NOC; SNMP provided similar functionality in the Internet.? IMPs 
had "fake hosts" that included functions like a remote debugger (DDT) 
that could be used to examine and modify remote IMPs while they were 
running.? XNET provided a similar capability.? Fake hosts that sent test 
traffic, or reflected incoming data back to the sender, et al were 
replicated in the gateways.

When DoD first declared TCP and IP as DoD Standards, we didn't notice 
until some non-research implementations began appearing that the 
Standards didn't include "supporting protocols" -- such as ICMP, which 
was crucial for network operations, or SNMP.? Or "fake host" functions.? 
Since it wasn't part of the Specification, big government contractors 
didn't implement it.? It took some effort to get that changed.

When I was later involved in running a large corporate internet, we used 
a lot of such existing "instrumentation" as did exist, e.g., SNMP to 
monitor our own network and find and fix problems.? TCP is good at 
hiding errors from its endusers, but equally good at hiding problems 
that should be fixed by whoever, if anyone, is managing the system.?? 
Personally I've found 50+ devices on my home LAN; I don't manage any of 
them.

It's easy for someone not familiar with operating a network service to 
see some mechanism as superfluous and either not implement it or perhaps 
remove it from the next iteration of design.? I've often wondered how 
"internet operations" has evolved over the years, and how problems that 
are hidden by TCP are noticed and fixed -- if they are.

Jack

On 4/18/25 12:55, Steve Crocker wrote:
> Jack,
>
> In our early design discussions, late 1968 and early 1969, Jeff 
> Rulifson from SRI pushed for a checksum for exactly the reason you 
> described, viz it would catch software errors between layers.
>
> Steve
>
> Sent by a Verified
>
> sender
>
>
> On Fri, Apr 18, 2025 at 3:49?PM Jack Haverty <jack at 3kitty.org> wrote:
>
>     Hi Steve,
>
>     The IMPs actually had quite a bit of internal mechanism to address
>     relability, which evolved as the network grew and more problems
>     occurred.? I joined Frank Heart's group in 1977, to work on
>     TCP-related contracts, but was surrounded by the ARPANET group so
>     a lot of that DNA transferred over.? The IMP subnet tried real
>     hard to hide the vagaries of packet switching from the end users'
>     hosts.? In effect there was an end-end TCP-like function between
>     two hosts' attached IMPs that made sure no packets were ever lost,
>     duplicated, or reordered so that the hosts saw only the behavior
>     of a virtual circuit.
>
>     When Vint asked me to take over the gateway work and make the
>     "core" Internet a 24x7 service, we congealed a "Gateway Group" to
>     do the work.? They lived literally down the hall from the ARPANET
>     world.? One of that crew was Mike Brescia.? We were working on
>     making the Internet work like the ARPANET, but until the NOC was
>     in the loop, Mike watched over the Internet behavior to catch and
>     fix problems.
>
>     One day some gateway was reporting lots of checksum errors.? Some
>     tools were already available for remote debugging.? So Mike
>     investigated and noticed that all of the errors were for datagrams
>     from one particular host somewhere in the US Midwest.? So not a
>     gateway or IMP problem, but Mike captured a few failed datagrams,
>     and noticed that bytes in the TCP header were out-of-order, which
>     was causing the checksum errors.
>
>     That was a problem I had already struggled with in implementing my
>     Unix TCP.? We knew about it.? So Mike looked up the host info in
>     the NIC, and sent an email to the technical contact - something
>     like "You need to swap the address bytes in your source address."?
>     Shortly after, he got a reply, something like "Thanks!? That was
>     the problem."
>
>     Shortly after that he got another email -- "How the *^&%&^% did
>     you know that?!"
>
>     Checksumming was a useful debugging tool, even for remote
>     debugging.?? I've learned over the years that researchers don't
>     think enough about how their designs will be operated and managed.
>
>
>     Jack
>
>
>     On 4/18/25 12:12, Steve Crocker wrote:
>>     We tried to include?a lightweight checksum in the?original
>>     host-host protocol.? (Later it was called the Network Control
>>     Protocol or NCP.? Same protocol.)? The checksum was designed to
>>     be reasonably easy to compute.? It was a 16-bit?ones?complement
>>     sum with one bit of rotation?every thousand or so bits.? (The
>>     rotation was intended to catch packets out of order, error which
>>     we imagined might be possible but never occurred.)? Frank Heart
>>     argued vehemently against?it, saying it would?make his network
>>     look slow.? I tried to push back and asked about?the Host-IMP
>>     interface.? "As reliable as your accumulator," he roared.
>>
>>     We removed the checkum from our design, a mistake I've rued ever
>>     since.? And, of?course, it turned out there were indeed a few
>>     cases where it would have made a difference.? As has been pointed
>>     out, there was a major memory error in one of the IMPs that
>>     caused that IMP to look like it was zero distance to every IMP.?
>>     But even before that error, when Lincoln Lab first connected its
>>     host to its IMP, their hardware interface had a problem.? There
>>     was some crosstalk between the interface and the disk (or drum)
>>     controller.? When the disk (or drum) was operating at the same
>>     time as the Host-IMP interface, some bits got scrambled.? It
>>     apparently took them some time to track?down.? I think they would
>>     have found it faster if the checksum had been part of the design.
>>
>>     Steve
>>
>>
>>     On Fri, Apr 18, 2025 at 1:25?PM Andrew G. Malis via
>>     Internet-history <internet-history at elists.isoc.org> wrote:
>>
>>         Jack,
>>
>>         > Thinking back, I can't recall the reason for including
>>         checksums in TCP
>>         at all.
>>
>>         It was primarily to catch memory errors, which were a real
>>         thing back in
>>         the core memory days. Errors during transmission were
>>         generally caught by
>>         the lower layers.
>>
>>         Cheers,
>>         Andy
>>         -- 
>>         Internet-history mailing list
>>         Internet-history at elists.isoc.org
>>         https://elists.isoc.org/mailman/listinfo/internet-history
>>
>>
>>
>>     -- 
>>     Sent by a Verified
>>
>>     sender
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250418/fdde366b/attachment.asc>

From aam3sendonly at gmail.com  Sat Apr 19 14:00:16 2025
From: aam3sendonly at gmail.com (Alexander McKenzie)
Date: Sat, 19 Apr 2025 17:00:16 -0400
Subject: [ih] Checksums in Host-Host protocol
Message-ID: <CAMusaY-Y+Hf8aaLt8R2xgBs3DsEkZ=WBU8omq1hiTLoZVbtQBg@mail.gmail.com>

 Steve,

It sounds so simple, but the devil is in the details.  Given the plethora
of word sizes of the computers connected (or scheduled to be connected) to
ARPAnet in 1971, I would bet that for ANY checksum length proposed over 50%
of the Hosts would have to engage in mask and shift operations on every
word in a message in order to calculate even a checksum like the one you
describe. This would indeed have somewhat slowed the effective network
speed.  Enough to matter? Who knows, but at that time maximum effective
bandwidth was of real concern to prospective users (remember the motivation
for the design of the Tinker-McClellan experiment).  Recall that at that
time a majority of the communications community viewed packet switching as
foolish, and ARPAnet as an experiment about to fail. Yes, a simple
end-to-end checksum would have sometimes been of diagnostic help, but both
Frank Heart and Larry Roberts had a real reason to worry about anything
that would negatively affect perceived performance of this brand new
technology. Maybe we should have done checksumming for debugging in TELNET,
where performance was irrelevant, and left File Transfer alone.

Cheers,
Alex

On Friday, April 18, 2025 at 03:12:39 PM EDT, Steve Crocker via
Internet-history <internet-history at elists.isoc.org> wrote:


We tried to include a lightweight checksum in the original host-host
protocol.  (Later it was called the Network Control Protocol or NCP.  Same
protocol.)  The checksum was designed to be reasonably easy to compute.  It
was a 16-bit ones complement sum with one bit of rotation every thousand or
so bits.  (The rotation was intended to catch packets out of order, error
which we imagined might be possible but never occurred.)  Frank Heart
argued vehemently against it, saying it would make his network look slow.
I tried to push back and asked about the Host-IMP interface.  "As reliable
as your accumulator," he roared.

We removed the checkum from our design, a mistake I've rued ever since.
And, of course, it turned out there were indeed a few cases where it would
have made a difference.  As has been pointed out, there was a major memory
error in one of the IMPs that caused that IMP to look like it was zero
distance to every IMP.  But even before that error, when Lincoln Lab first
connected its host to its IMP, their hardware interface had a problem.
There was some crosstalk between the interface and the disk (or drum)
controller.  When the disk (or drum) was operating at the same time as the
Host-IMP interface, some bits got scrambled.  It apparently took them some
time to track down.  I think they would have found it faster if the
checksum had been part of the design.

Steve


From geoff at iconia.com  Sat Apr 19 14:18:45 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Sat, 19 Apr 2025 14:18:45 -0700
Subject: [ih] when did APRANET -TIPs become known as -TACs
Message-ID: <CAEf-zriswP6Gx5c9+4TmQWDB==uqBnyyG6RfTpxGx+JAAav75A@mail.gmail.com>

and WHY the dash -TIP to -TAC name change?

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From vgcerf at gmail.com  Sat Apr 19 14:33:30 2025
From: vgcerf at gmail.com (vinton cerf)
Date: Sat, 19 Apr 2025 17:33:30 -0400
Subject: [ih] when did APRANET -TIPs become known as -TACs
In-Reply-To: <CAEf-zriswP6Gx5c9+4TmQWDB==uqBnyyG6RfTpxGx+JAAav75A@mail.gmail.com>
References: <CAEf-zriswP6Gx5c9+4TmQWDB==uqBnyyG6RfTpxGx+JAAav75A@mail.gmail.com>
Message-ID: <CAAFtm_UCrTjPD-SiHZhSYrKob0MzuYzw=VcOyAYFCkqfYiqFtg@mail.gmail.com>

TIP-TAC-TOE....

On Sat, Apr 19, 2025, 17:19 the keyboard of geoff goodfellow via
Internet-history <internet-history at elists.isoc.org> wrote:

> and WHY the dash -TIP to -TAC name change?
>
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From aam3sendonly at gmail.com  Sat Apr 19 14:35:24 2025
From: aam3sendonly at gmail.com (Alexander McKenzie)
Date: Sat, 19 Apr 2025 17:35:24 -0400
Subject: [ih] when did APRANET -TIPs become known as -TACs
Message-ID: <CAMusaY9nHg=Z5Qipz+g5LGH99q_y+VtgJZu4xw-xOEg34LGFpg@mail.gmail.com>

 They became TACs when the management of ARPAnet switched from DARPA to DCA
and login control via user passwords was implemented.  The management shift
happened in mid-1976 and the login control somewhat later. I've never seen
the dash notation before and I don't think that is anything other than a
typo.

Cheers,
Alex McKenzie

On Saturday, April 19, 2025 at 05:19:44 PM EDT, the keyboard of geoff
goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:


and WHY the dash -TIP to -TAC name change?

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history


From jack at 3kitty.org  Sat Apr 19 14:41:09 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Sat, 19 Apr 2025 14:41:09 -0700
Subject: [ih] when did APRANET -TIPs become known as -TACs
In-Reply-To: <CAEf-zriswP6Gx5c9+4TmQWDB==uqBnyyG6RfTpxGx+JAAav75A@mail.gmail.com>
References: <CAEf-zriswP6Gx5c9+4TmQWDB==uqBnyyG6RfTpxGx+JAAav75A@mail.gmail.com>
Message-ID: <f5182529-1505-42df-b365-51add2d82934@3kitty.org>

TACs were TIPs with code added to enable the use of TCP.? That was one 
of the steps needed before the 1/1/1983 deadline for converting the 
ARPANET to only support TCP.?? So it happened well before then. IIRC, 
Bob Hinden wrote the TCP code and added it to the TIP, so he may 
remember more.

There were some other necessary changes as well.? E.g., the "TIP Login" 
mechanisms (name/password to connect to a TIP) had to be converted into 
TACACS (TAC Access Control System).?? That may have happened later, in 
preparation for the split of the ARPANET to adapt it to become part DDN.

I'm not sure about the -TIP vs -TAC naming.? It may have been just to 
keep track as individual TIPs were converted into TACs.

Jack Haverty

On 4/19/25 14:18, the keyboard of geoff goodfellow via Internet-history 
wrote:
> and WHY the dash -TIP to -TAC name change?
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250419/dc2ade5d/attachment.asc>

From olejacobsen at me.com  Sat Apr 19 14:42:44 2025
From: olejacobsen at me.com (Ole Jacobsen)
Date: Sat, 19 Apr 2025 14:42:44 -0700
Subject: [ih] when did APRANET -TIPs become known as -TACs
In-Reply-To: <CAMusaY9nHg=Z5Qipz+g5LGH99q_y+VtgJZu4xw-xOEg34LGFpg@mail.gmail.com>
References: <CAMusaY9nHg=Z5Qipz+g5LGH99q_y+VtgJZu4xw-xOEg34LGFpg@mail.gmail.com>
Message-ID: <17FFB36C-230E-4145-9521-7B70BEBCC228@me.com>


I don't recall if TACs ever had the dash, but I am pretty sure the TIPs did not.

See IEN 107 which refers to NORSAR TIP, familiar territory to the late Yngvar Lundh,
Paal Spilling and myself.

https://www.rfc-editor.org/ien/ien107.pdf

Ole

> On Apr 19, 2025, at 14:35, Alexander McKenzie via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> They became TACs when the management of ARPAnet switched from DARPA to DCA
> and login control via user passwords was implemented.  The management shift
> happened in mid-1976 and the login control somewhat later. I've never seen
> the dash notation before and I don't think that is anything other than a
> typo.
> 
> Cheers,
> Alex McKenzie
> 

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Docomo: +81 90 3337-9311
Web: protocoljournal.org
E-mail: olejacobsen at me.com
E-mail: ole at protocoljournal.org









From geoff at iconia.com  Sat Apr 19 15:09:39 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Sat, 19 Apr 2025 15:09:39 -0700
Subject: [ih] when did APRANET -TIPs become known as -TACs
In-Reply-To: <CAMusaY9nHg=Z5Qipz+g5LGH99q_y+VtgJZu4xw-xOEg34LGFpg@mail.gmail.com>
References: <CAMusaY9nHg=Z5Qipz+g5LGH99q_y+VtgJZu4xw-xOEg34LGFpg@mail.gmail.com>
Message-ID: <CAEf-zrhMoXT2Akj5g-F3jiXXZ1wwpySqgvfWKvL6KSDGuaMb_w@mail.gmail.com>

so BOTH the TIPs and TAC's had the -TIP and -TAC name notation, e.g. viz.:

243,ACCAT-TIP,TIP,USER,NEW
in
;[SRI-CSL]<GEOFF2>HSTNAM.TXT   (Kept by Geoff at SRI-CSL)
;Last update: 4-Aug-82
as EXCERPTED from:
https://pdp-10.trailing-edge.com/bb-d868e-bm_tops20_v41_2020_dist_1of2/01/new-system/hstnam.txt.html
&
https://pdp-10.trailing-edge.com/BB-H137C-BM/06/new-system/hstnam.txt.html

HOST ACCAT-TAC, 2/35,USER,TAC,C30,[NELC-TIP]
; Last updated: MRC 2/1/83
as EXCERPTED from:
https://github.com/ttkzw/hosts.txt/blob/master/pub/hosts/19830201/HOSTS.TXT

and some even had both (which must have been during the -TIP to -TAC naming
transition), viz.:
10.2.0.35       accat-tac nelc-tip
10.2.0.31       cca-tac cca-tip
as EXCERPTED from:
https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/etc/htable/hosts

geoff


On Sat, Apr 19, 2025 at 2:35?PM Alexander McKenzie via Internet-history <
internet-history at elists.isoc.org> wrote:

>  They became TACs when the management of ARPAnet switched from DARPA to DCA
> and login control via user passwords was implemented.  The management shift
> happened in mid-1976 and the login control somewhat later. I've never seen
> the dash notation before and I don't think that is anything other than a
> typo.
>
> Cheers,
> Alex McKenzie
>
> On Saturday, April 19, 2025 at 05:19:44 PM EDT, the keyboard of geoff
> goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:
>
>
> and WHY the dash -TIP to -TAC name change?
>
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From aam3sendonly at gmail.com  Sat Apr 19 15:33:39 2025
From: aam3sendonly at gmail.com (Alexander McKenzie)
Date: Sat, 19 Apr 2025 18:33:39 -0400
Subject: [ih] when did APRANET -TIPs become known as -TACs
Message-ID: <CAMusaY9zVyBKk2eZ4vqnb2M9KtSOHF4ZYcYwdULq3tj5JRbvsw@mail.gmail.com>

 Ah, you are referring to Host names.  There wasm for example, a TIP at BBN
known officially as BBN-TIP. The dash was part of the Host name, not part
of the word "TIP".

Cheers,
Alex McKenzie

On Saturday, April 19, 2025 at 06:10:31 PM EDT, the keyboard of geoff
goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:


so BOTH the TIPs and TAC's had the -TIP and -TAC name notation, e.g. viz.:

243,ACCAT-TIP,TIP,USER,NEW
in
;[SRI-CSL]<GEOFF2>HSTNAM.TXT  (Kept by Geoff at SRI-CSL)
;Last update: 4-Aug-82
as EXCERPTED from:
https://pdp-10.trailing-edge.com/bb-d868e-bm_tops20_v41_2020_dist_1of2/01/new-system/hstnam.txt.html
&
https://pdp-10.trailing-edge.com/BB-H137C-BM/06/new-system/hstnam.txt.html

HOST ACCAT-TAC, 2/35,USER,TAC,C30,[NELC-TIP]
; Last updated: MRC 2/1/83
as EXCERPTED from:
https://github.com/ttkzw/hosts.txt/blob/master/pub/hosts/19830201/HOSTS.TXT

and some even had both (which must have been during the -TIP to -TAC naming
transition), viz.:
10.2.0.35      accat-tac nelc-tip
10.2.0.31      cca-tac cca-tip
as EXCERPTED from:
https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/etc/htable/hosts

geoff


On Sat, Apr 19, 2025 at 2:35?PM Alexander McKenzie via Internet-history <
internet-history at elists.isoc.org> wrote:

>  They became TACs when the management of ARPAnet switched from DARPA to
DCA
> and login control via user passwords was implemented.  The management
shift
> happened in mid-1976 and the login control somewhat later. I've never seen
> the dash notation before and I don't think that is anything other than a
> typo.
>
> Cheers,
> Alex McKenzie
>
> On Saturday, April 19, 2025 at 05:19:44 PM EDT, the keyboard of geoff
> goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:
>
>
> and WHY the dash -TIP to -TAC name change?
>
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history


From jeanjour at comcast.net  Sat Apr 19 16:41:33 2025
From: jeanjour at comcast.net (John Day)
Date: Sat, 19 Apr 2025 19:41:33 -0400
Subject: [ih] when did APRANET -TIPs become known as -TACs
In-Reply-To: <CAMusaY9zVyBKk2eZ4vqnb2M9KtSOHF4ZYcYwdULq3tj5JRbvsw@mail.gmail.com>
References: <CAMusaY9zVyBKk2eZ4vqnb2M9KtSOHF4ZYcYwdULq3tj5JRbvsw@mail.gmail.com>
Message-ID: <B4F11E51-0413-4EAF-B258-BD446F751033@comcast.net>

A site with more than one host connected to the IMP would regularly have a hyphen between the organization name and the name of the specific lab or whatever it was, e.g. MIT-Multics, MIT-AI.

Sounds like you don?t have enough to do.

> On Apr 19, 2025, at 18:33, Alexander McKenzie via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Ah, you are referring to Host names.  There wasm for example, a TIP at BBN
> known officially as BBN-TIP. The dash was part of the Host name, not part
> of the word "TIP".
> 
> Cheers,
> Alex McKenzie
> 
> On Saturday, April 19, 2025 at 06:10:31 PM EDT, the keyboard of geoff
> goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> 
> so BOTH the TIPs and TAC's had the -TIP and -TAC name notation, e.g. viz.:
> 
> 243,ACCAT-TIP,TIP,USER,NEW
> in
> ;[SRI-CSL]<GEOFF2>HSTNAM.TXT  (Kept by Geoff at SRI-CSL)
> ;Last update: 4-Aug-82
> as EXCERPTED from:
> https://pdp-10.trailing-edge.com/bb-d868e-bm_tops20_v41_2020_dist_1of2/01/new-system/hstnam.txt.html
> &
> https://pdp-10.trailing-edge.com/BB-H137C-BM/06/new-system/hstnam.txt.html
> 
> HOST ACCAT-TAC, 2/35,USER,TAC,C30,[NELC-TIP]
> ; Last updated: MRC 2/1/83
> as EXCERPTED from:
> https://github.com/ttkzw/hosts.txt/blob/master/pub/hosts/19830201/HOSTS.TXT
> 
> and some even had both (which must have been during the -TIP to -TAC naming
> transition), viz.:
> 10.2.0.35      accat-tac nelc-tip
> 10.2.0.31      cca-tac cca-tip
> as EXCERPTED from:
> https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/etc/htable/hosts
> 
> geoff
> 
> 
> On Sat, Apr 19, 2025 at 2:35?PM Alexander McKenzie via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> They became TACs when the management of ARPAnet switched from DARPA to
> DCA
>> and login control via user passwords was implemented.  The management
> shift
>> happened in mid-1976 and the login control somewhat later. I've never seen
>> the dash notation before and I don't think that is anything other than a
>> typo.
>> 
>> Cheers,
>> Alex McKenzie
>> 
>> On Saturday, April 19, 2025 at 05:19:44 PM EDT, the keyboard of geoff
>> goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:
>> 
>> 
>> and WHY the dash -TIP to -TAC name change?
>> 
>> --
>> Geoff.Goodfellow at iconia.com
>> living as The Truth is True
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
> 
>> 
>> 
> 
> -- 
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From bob.hinden at gmail.com  Sat Apr 19 19:19:39 2025
From: bob.hinden at gmail.com (Bob Hinden)
Date: Sat, 19 Apr 2025 19:19:39 -0700
Subject: [ih] when did APRANET -TIPs become known as -TACs
In-Reply-To: <f5182529-1505-42df-b365-51add2d82934@3kitty.org>
References: <CAEf-zriswP6Gx5c9+4TmQWDB==uqBnyyG6RfTpxGx+JAAav75A@mail.gmail.com>
 <f5182529-1505-42df-b365-51add2d82934@3kitty.org>
Message-ID: <CFF8FAE6-33E3-4A0A-9462-9ACEE1AFC825@gmail.com>

Jack,

Right, I and someone else (can?t remember his name at the moment), added TCP/IP to the TIP code base to make it the TAC.   I found IEN166 that describes the design.

     https://www.rfc-editor.org/ien/ien166.txt

Was somewhat challenging doing the 32 bit TCP sequence number calculations on the H-316 with 15 bit arithmetic  :-)

From what I remember the TAC name came from AUTODIN II.

Bob


> On Apr 19, 2025, at 2:41?PM, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Signed PGP part
> TACs were TIPs with code added to enable the use of TCP.  That was one of the steps needed before the 1/1/1983 deadline for converting the ARPANET to only support TCP.   So it happened well before then. IIRC, Bob Hinden wrote the TCP code and added it to the TIP, so he may remember more.
> 
> There were some other necessary changes as well.  E.g., the "TIP Login" mechanisms (name/password to connect to a TIP) had to be converted into TACACS (TAC Access Control System).   That may have happened later, in preparation for the split of the ARPANET to adapt it to become part DDN.
> 
> I'm not sure about the -TIP vs -TAC naming.  It may have been just to keep track as individual TIPs were converted into TACs.
> 
> Jack Haverty
> 
> On 4/19/25 14:18, the keyboard of geoff goodfellow via Internet-history wrote:
>> and WHY the dash -TIP to -TAC name change?
>> 
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
> https://elists.isoc.org/mailman/listinfo/internet-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250419/a5b3b00b/attachment.asc>

From steve at shinkuro.com  Sat Apr 19 20:14:54 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Sat, 19 Apr 2025 23:14:54 -0400
Subject: [ih] Checksums in Host-Host protocol
In-Reply-To: <CAMusaY-Y+Hf8aaLt8R2xgBs3DsEkZ=WBU8omq1hiTLoZVbtQBg@mail.gmail.com>
References: <CAMusaY-Y+Hf8aaLt8R2xgBs3DsEkZ=WBU8omq1hiTLoZVbtQBg@mail.gmail.com>
Message-ID: <CABf5zv+r3LL4rK2eqWL0L4hQwcKnJSP9UOYRWhy5OwuJ+9AvJg@mail.gmail.com>

Alex,

Thanks for your note.  I understand the point you're making, but I don't
think the effect would have been very large.  I did a mental exercise to
estimate the time to compute the checksum on PDP-10s.  The PDP-10 was a 36
bit machine, so it definitely would have required the extraction and
shifting you're referring to.  However, it also had a very powerful
instruction set.  One of its instructions was a Load Byte instruction.  See
http://pdp10.nocrew.org/docs/instruction-set/Byte.html .  It uses a byte
pointer which contains the size and offset of the byte, so the instruction
takes 3 cycles.  Once the byte is loaded into one of the several registers,
it can be added to another register in one instruction, and because it does
not need to load data from memory, I believe that Add instruction would
take only one cycle.  Hence, a total of 4 cycles to extract a byte and add
it to a register.

The machine has enough registers to permit assigning one for each of the
four offsets, thus deferring the shifting to the end.

A typical word will have three bytes. so it will take 12 cycles per 36 bit
word.  But we can do slightly better.  Four words is 144 bits, which is 9
16-bit bytes.  In two of those four words, there will be 32 bits that have
two complete 16-bit bytes.  These can be treated as a single byte in the
inner loop and subdivided at the end.  Therefore, within each group of four
words, there will be only 10 Load Byte and Add instructions, i.e. 40 cycles
for every four words, or 40/9 cycles per 16 bit byte.

An 8000 bit message has 500 16-bit bytes, so the inner loop to add all the
16 bit-bytes is roughly 500 * 40 / 9 cycles, approximately 2222 cycles.
Round this up to 2500 cycles to accommodate the loop management and the
assembling the pieces at the end.

According to chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/
https://archive.computerhistory.org/resources/text/DEC/pdp-10/dec.pdp-10.the_evolution_of_the_DECsystem_10.1978.102630382.pdf
, the cycle time on the KA-10 was 5 microseconds, so the computation time
for the checksum over a full 8000 bit message would have been about 12.5
ms.  Double this to account for creating the checksum on the sending side
and checking it on the receiving side, so 25 ms overall.

For short messages, e.g. typical interactive messages, this figure would be
*much* smaller.

The Arpanet spec was to deliver a message from end to end in under a half
second, i.e. 500 ms.  Thus the checksum would have added a little bit of
time, but only about 5%.

Apologies if there are errors in the above.  Corrections welcome.

Steve

On Sat, Apr 19, 2025 at 5:00?PM Alexander McKenzie via Internet-history <
internet-history at elists.isoc.org> wrote:

>  Steve,
>
> It sounds so simple, but the devil is in the details.  Given the plethora
> of word sizes of the computers connected (or scheduled to be connected) to
> ARPAnet in 1971, I would bet that for ANY checksum length proposed over 50%
> of the Hosts would have to engage in mask and shift operations on every
> word in a message in order to calculate even a checksum like the one you
> describe. This would indeed have somewhat slowed the effective network
> speed.  Enough to matter? Who knows, but at that time maximum effective
> bandwidth was of real concern to prospective users (remember the motivation
> for the design of the Tinker-McClellan experiment).  Recall that at that
> time a majority of the communications community viewed packet switching as
> foolish, and ARPAnet as an experiment about to fail. Yes, a simple
> end-to-end checksum would have sometimes been of diagnostic help, but both
> Frank Heart and Larry Roberts had a real reason to worry about anything
> that would negatively affect perceived performance of this brand new
> technology. Maybe we should have done checksumming for debugging in TELNET,
> where performance was irrelevant, and left File Transfer alone.
>
> Cheers,
> Alex
>
> On Friday, April 18, 2025 at 03:12:39 PM EDT, Steve Crocker via
> Internet-history <internet-history at elists.isoc.org> wrote:
>
>
> We tried to include a lightweight checksum in the original host-host
> protocol.  (Later it was called the Network Control Protocol or NCP.  Same
> protocol.)  The checksum was designed to be reasonably easy to compute.  It
> was a 16-bit ones complement sum with one bit of rotation every thousand or
> so bits.  (The rotation was intended to catch packets out of order, error
> which we imagined might be possible but never occurred.)  Frank Heart
> argued vehemently against it, saying it would make his network look slow.
> I tried to push back and asked about the Host-IMP interface.  "As reliable
> as your accumulator," he roared.
>
> We removed the checkum from our design, a mistake I've rued ever since.
> And, of course, it turned out there were indeed a few cases where it would
> have made a difference.  As has been pointed out, there was a major memory
> error in one of the IMPs that caused that IMP to look like it was zero
> distance to every IMP.  But even before that error, when Lincoln Lab first
> connected its host to its IMP, their hardware interface had a problem.
> There was some crosstalk between the interface and the disk (or drum)
> controller.  When the disk (or drum) was operating at the same time as the
> Host-IMP interface, some bits got scrambled.  It apparently took them some
> time to track down.  I think they would have found it faster if the
> checksum had been part of the design.
>
> Steve
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Sent by a Verified

sender


From dhc at dcrocker.net  Sun Apr 20 01:24:05 2025
From: dhc at dcrocker.net (Dave Crocker)
Date: Sun, 20 Apr 2025 08:24:05 +0000 (UTC)
Subject: [ih] Checksums in Host-Host protocol
In-Reply-To: <CAMusaY-Y+Hf8aaLt8R2xgBs3DsEkZ=WBU8omq1hiTLoZVbtQBg@mail.gmail.com>
References: <CAMusaY-Y+Hf8aaLt8R2xgBs3DsEkZ=WBU8omq1hiTLoZVbtQBg@mail.gmail.com>
Message-ID: <a716c6bd-7d28-428a-8ef8-82658fdededa@dcrocker.net>

> On Friday, April 18, 2025 at 03:12:39 PM EDT, Steve Crocker via
> Internet-history <internet-history at elists.isoc.org> wrote:
> ...
> We removed the checkum from our design, a mistake I've rued ever since.


I was at Ungermann-Bass(*) in the latter 1980s, and managed its 
development of a TCP/IP stack for its 'smart' Ethernet cards. These has 
a Intel 186 chip on the card.

U-B?s original business was using networking tech to do terminal 
concentration back to mainframes.? That is, they reduced the amount of 
wiring needed back to the mainframe.? Eventually, however, they had to 
support PCs and that included Netbios and SMB.

The original U-B protocol stack was a modified XNS, which was true for a 
number of vendors, each making their own adaptations. (I think I was 
told that XNS had been published well enough to use but the Internet 
protocols were not yet stable, when these networking companies were 
getting started.)

While I was at U-B, there was a major fire drill for a customer that 
discovered they had very serious file data corruption. Eventually the 
culprit was found to be a bad U-B interface card. But none of the 
networking protocols enforced data integrity and this problem had, 
apparently, gone on for months.

It was quietly noted that had they been running with TCP, there would 
have been no data corruption.? Just an increase in retransmissions...


d/

(*) Ungermann-Bass was one of the original LAN companies, though it did 
not market as a networking company.? It had a very few, very large 
customers, and it never quite managed to expand from this.? One example 
was that its 'dumb' Ethernet card was superior to the wildly popular 
3Com Ethernet card.? Another was that as a private tool to aid 
development debugging, I adapted a packet tracing tool to provide 
symbolic TCP and IP traces.? After seeing some ops admin customers get 
excited about this tool, as I used it to show how the smart Ethernet 
card was performing, I tried to get Marketing interested in selling it 
and they declined.? About 2 years later, Harry Saal was making good 
money off of a similar product. sigh.

-- 
Dave Crocker

Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker at mastodon.social



From nigel at channelisles.net  Sun Apr 20 07:35:49 2025
From: nigel at channelisles.net (Nigel Roberts)
Date: Sun, 20 Apr 2025 15:35:49 +0100
Subject: [ih] when did APRANET -TIPs become known as -TACs
In-Reply-To: <B4F11E51-0413-4EAF-B258-BD446F751033@comcast.net>
References: <CAMusaY9zVyBKk2eZ4vqnb2M9KtSOHF4ZYcYwdULq3tj5JRbvsw@mail.gmail.com>
 <B4F11E51-0413-4EAF-B258-BD446F751033@comcast.net>
Message-ID: <b055154e-046c-4999-9382-93b82f61cfd6@channelisles.net>

And I still remember some of the the host numbers

MIT-AI 134
MIT-DM 70? (Home of Dungeon/Zork, our inspiration for MUD)

SU-AI was something in the twenties (23? anyone remember??)


Nigel


On 20/04/2025 00:41, John Day via Internet-history wrote:
> A site with more than one host connected to the IMP would regularly have a hyphen between the organization name and the name of the specific lab or whatever it was, e.g. MIT-Multics, MIT-AI.
>
> Sounds like you don?t have enough to do.
>
>> On Apr 19, 2025, at 18:33, Alexander McKenzie via Internet-history<internet-history at elists.isoc.org> wrote:
>>
>> Ah, you are referring to Host names.  There wasm for example, a TIP at BBN
>> known officially as BBN-TIP. The dash was part of the Host name, not part
>> of the word "TIP".
>>
>> Cheers,
>> Alex McKenzie
>>
>> On Saturday, April 19, 2025 at 06:10:31 PM EDT, the keyboard of geoff
>> goodfellow via Internet-history<internet-history at elists.isoc.org> wrote:
>>
>>
>> so BOTH the TIPs and TAC's had the -TIP and -TAC name notation, e.g. viz.:
>>
>> 243,ACCAT-TIP,TIP,USER,NEW
>> in
>> ;[SRI-CSL]<GEOFF2>HSTNAM.TXT  (Kept by Geoff at SRI-CSL)
>> ;Last update: 4-Aug-82
>> as EXCERPTED from:
>> https://pdp-10.trailing-edge.com/bb-d868e-bm_tops20_v41_2020_dist_1of2/01/new-system/hstnam.txt.html
>> &
>> https://pdp-10.trailing-edge.com/BB-H137C-BM/06/new-system/hstnam.txt.html
>>
>> HOST ACCAT-TAC, 2/35,USER,TAC,C30,[NELC-TIP]
>> ; Last updated: MRC 2/1/83
>> as EXCERPTED from:
>> https://github.com/ttkzw/hosts.txt/blob/master/pub/hosts/19830201/HOSTS.TXT
>>
>> and some even had both (which must have been during the -TIP to -TAC naming
>> transition), viz.:
>> 10.2.0.35      accat-tac nelc-tip
>> 10.2.0.31      cca-tac cca-tip
>> as EXCERPTED from:
>> https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/etc/htable/hosts
>>
>> geoff
>>
>>
>> On Sat, Apr 19, 2025 at 2:35?PM Alexander McKenzie via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>
>>> They became TACs when the management of ARPAnet switched from DARPA to
>> DCA
>>> and login control via user passwords was implemented.  The management
>> shift
>>> happened in mid-1976 and the login control somewhat later. I've never seen
>>> the dash notation before and I don't think that is anything other than a
>>> typo.
>>>
>>> Cheers,
>>> Alex McKenzie
>>>
>>> On Saturday, April 19, 2025 at 05:19:44 PM EDT, the keyboard of geoff
>>> goodfellow via Internet-history<internet-history at elists.isoc.org> wrote:
>>>
>>>
>>> and WHY the dash -TIP to -TAC name change?
>>>
>>> --
>>> Geoff.Goodfellow at iconia.com
>>> living as The Truth is True
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>
>> -- 
>> Geoff.Goodfellow at iconia.com
>> living as The Truth is True
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history

-- 
Dr Nigel Roberts FBCS FRSA, Director CHANNELISLES.NET
Maison Postel, Ollivier St, Alderney GUERNSEY GY9 3TD
Tel. +44 1481 822800 (office) or +44 20 7100 4319 (direct)
Mobile: +44 7973 263842 or +1 305 747 5714


From jack at 3kitty.org  Sun Apr 20 10:45:08 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Sun, 20 Apr 2025 10:45:08 -0700
Subject: [ih] Checksums in Host-Host protocol
In-Reply-To: <CABf5zv+r3LL4rK2eqWL0L4hQwcKnJSP9UOYRWhy5OwuJ+9AvJg@mail.gmail.com>
References: <CAMusaY-Y+Hf8aaLt8R2xgBs3DsEkZ=WBU8omq1hiTLoZVbtQBg@mail.gmail.com>
 <CABf5zv+r3LL4rK2eqWL0L4hQwcKnJSP9UOYRWhy5OwuJ+9AvJg@mail.gmail.com>
Message-ID: <87806765-0288-4380-a2ff-f1bc8bebac91@3kitty.org>

Hi Steve,

IIRC there were concerns other than the Engineering ones.

Computers in 1970 were big, expensive to purchase, and expensive to 
operate.? Projects using computers were charged by the "CPU-second" for 
the users' computing, but time consumed by the OS was overhead, and its 
costs spread across all users, along with the costs for power, HVAC, 
floor space, and such.

ARPA was into "resource sharing" but organizations with computers 
(mostly universities and research sites IIRC) were sometimes reluctant 
to "share" their hard-won computing power.?? ARPA was paying the bills 
though, so it could pressure them to connect to the ARPANET.

Still, there was concern to minimize that overhead in the OS, e.g., RFC 
425, titled "But my NCP costs $500 a day...", written by Bob Bressler, 
in Frank Heart's ARPANET group at BBN. (In 1977 I migrated from MIT to 
Frank's group at BBN, to implement TCP for Unix)

It's easy to forget the computing world of 50+ years ago, now that we 
have computers (aka "devices")? lying around everywhere, much more 
powerful than any machine on the ARPANET in the 1970s, but sitting idle 
most of the time.

Even if the Engineering analysis showed a bit of additional OS overhead 
was minimal, it was still a thorn in the sides of IT managers fifty 
years ago.

But yes, I agree that the PDP-10 had some great instructions.? I spent a 
lot of time in the 70s writing assembler code in Lick's group at MIT, as 
we all tried feverishly to make our PDP-10 do more than it was capable 
of doing.?? We did things like using JFCL as the best NO-OP instruction, 
simply because it was the fastest such instruction to execute.? The 
"official" NOP instruction took a bit longer.? That and other such 
techniques were considered common practice of us "bit twiddlers", all to 
save a few CPU-microseconds.

BTW, the ARPANET IMP code is the most amazing example of such "bit 
twiddling" that I have ever encountered.? I did a "deep dive" into the 
old IMP code as a consultant in a patent battle, to figure out exactly 
how the IMP did some of the things that I remembered it did.? I was 
astonished at the techniques used to get every bit of power out of the 
Honeywell minicomputer that was the core of the IMP, often by violating 
today's rules of good program design.? It's just what you did in those 
days of too little CPU, too little memory, and everything too expensive.

Frank Heart's focus was on Engineering - getting the system to work.? I 
can still hear his voice as he argued for that.? You knew he was serious 
when the pitch of his voice approached ultrasonic.

Jack


On 4/19/25 20:14, Steve Crocker via Internet-history wrote:
> Alex,
>
> Thanks for your note.  I understand the point you're making, but I don't
> think the effect would have been very large.  I did a mental exercise to
> estimate the time to compute the checksum on PDP-10s.  The PDP-10 was a 36
> bit machine, so it definitely would have required the extraction and
> shifting you're referring to.  However, it also had a very powerful
> instruction set.  One of its instructions was a Load Byte instruction.  See
> http://pdp10.nocrew.org/docs/instruction-set/Byte.html  .  It uses a byte
> pointer which contains the size and offset of the byte, so the instruction
> takes 3 cycles.  Once the byte is loaded into one of the several registers,
> it can be added to another register in one instruction, and because it does
> not need to load data from memory, I believe that Add instruction would
> take only one cycle.  Hence, a total of 4 cycles to extract a byte and add
> it to a register.
>
> The machine has enough registers to permit assigning one for each of the
> four offsets, thus deferring the shifting to the end.
>
> A typical word will have three bytes. so it will take 12 cycles per 36 bit
> word.  But we can do slightly better.  Four words is 144 bits, which is 9
> 16-bit bytes.  In two of those four words, there will be 32 bits that have
> two complete 16-bit bytes.  These can be treated as a single byte in the
> inner loop and subdivided at the end.  Therefore, within each group of four
> words, there will be only 10 Load Byte and Add instructions, i.e. 40 cycles
> for every four words, or 40/9 cycles per 16 bit byte.
>
> An 8000 bit message has 500 16-bit bytes, so the inner loop to add all the
> 16 bit-bytes is roughly 500 * 40 / 9 cycles, approximately 2222 cycles.
> Round this up to 2500 cycles to accommodate the loop management and the
> assembling the pieces at the end.
>
> According to chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/
> https://archive.computerhistory.org/resources/text/DEC/pdp-10/dec.pdp-10.the_evolution_of_the_DECsystem_10.1978.102630382.pdf
> , the cycle time on the KA-10 was 5 microseconds, so the computation time
> for the checksum over a full 8000 bit message would have been about 12.5
> ms.  Double this to account for creating the checksum on the sending side
> and checking it on the receiving side, so 25 ms overall.
>
> For short messages, e.g. typical interactive messages, this figure would be
> *much* smaller.
>
> The Arpanet spec was to deliver a message from end to end in under a half
> second, i.e. 500 ms.  Thus the checksum would have added a little bit of
> time, but only about 5%.
>
> Apologies if there are errors in the above.  Corrections welcome.
>
> Steve
>
> On Sat, Apr 19, 2025 at 5:00?PM Alexander McKenzie via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>>   Steve,
>>
>> It sounds so simple, but the devil is in the details.  Given the plethora
>> of word sizes of the computers connected (or scheduled to be connected) to
>> ARPAnet in 1971, I would bet that for ANY checksum length proposed over 50%
>> of the Hosts would have to engage in mask and shift operations on every
>> word in a message in order to calculate even a checksum like the one you
>> describe. This would indeed have somewhat slowed the effective network
>> speed.  Enough to matter? Who knows, but at that time maximum effective
>> bandwidth was of real concern to prospective users (remember the motivation
>> for the design of the Tinker-McClellan experiment).  Recall that at that
>> time a majority of the communications community viewed packet switching as
>> foolish, and ARPAnet as an experiment about to fail. Yes, a simple
>> end-to-end checksum would have sometimes been of diagnostic help, but both
>> Frank Heart and Larry Roberts had a real reason to worry about anything
>> that would negatively affect perceived performance of this brand new
>> technology. Maybe we should have done checksumming for debugging in TELNET,
>> where performance was irrelevant, and left File Transfer alone.
>>
>> Cheers,
>> Alex
>>
>> On Friday, April 18, 2025 at 03:12:39 PM EDT, Steve Crocker via
>> Internet-history<internet-history at elists.isoc.org>  wrote:
>>
>>
>> We tried to include a lightweight checksum in the original host-host
>> protocol.  (Later it was called the Network Control Protocol or NCP.  Same
>> protocol.)  The checksum was designed to be reasonably easy to compute.  It
>> was a 16-bit ones complement sum with one bit of rotation every thousand or
>> so bits.  (The rotation was intended to catch packets out of order, error
>> which we imagined might be possible but never occurred.)  Frank Heart
>> argued vehemently against it, saying it would make his network look slow.
>> I tried to push back and asked about the Host-IMP interface.  "As reliable
>> as your accumulator," he roared.
>>
>> We removed the checkum from our design, a mistake I've rued ever since.
>> And, of course, it turned out there were indeed a few cases where it would
>> have made a difference.  As has been pointed out, there was a major memory
>> error in one of the IMPs that caused that IMP to look like it was zero
>> distance to every IMP.  But even before that error, when Lincoln Lab first
>> connected its host to its IMP, their hardware interface had a problem.
>> There was some crosstalk between the interface and the disk (or drum)
>> controller.  When the disk (or drum) was operating at the same time as the
>> Host-IMP interface, some bits got scrambled.  It apparently took them some
>> time to track down.  I think they would have found it faster if the
>> checksum had been part of the design.
>>
>> Steve
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250420/beb65e91/attachment.asc>

From steve at shinkuro.com  Sun Apr 20 16:21:27 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Sun, 20 Apr 2025 19:21:27 -0400
Subject: [ih] Checksums in Host-Host protocol
In-Reply-To: <87806765-0288-4380-a2ff-f1bc8bebac91@3kitty.org>
References: <CAMusaY-Y+Hf8aaLt8R2xgBs3DsEkZ=WBU8omq1hiTLoZVbtQBg@mail.gmail.com>
 <CABf5zv+r3LL4rK2eqWL0L4hQwcKnJSP9UOYRWhy5OwuJ+9AvJg@mail.gmail.com>
 <87806765-0288-4380-a2ff-f1bc8bebac91@3kitty.org>
Message-ID: <CABf5zvJcABie0PWWD8Ywkz75ePV=2dzCboXhzyDtU=yFfOofkw@mail.gmail.com>

Jack,

Yes, the big computer(s) on a university campus operated on a cost recovery
basis and OMB Circular A-21 (I think) imposed some rules on charging
computer time to government funded projects.  But I'm quite sure that was
not relevant in this instance.  Most of the hosts on the Arpanet were part
of the research projects that ARPA was supporting.  In a few cases, e.g.
UCLA's main computer, a 360/91, the main computer was connected to the
Arpanet.  Anyone who used that computer needed an account and had to pay
for its use.  (I accompanied Larry Roberts on a visit to UCLA when he
negotiated for a large amount of computer time to run climate modelling
research using weekend and evening times for a reduced rate.)

Frank's response struck me as a mixture of engineering instinct and pride.
The IMPs used a very strong error detection code to detect packets that
had been damaged in transit.  There was no parity checking in the memory
but the Honeywell 516 was ruggedized -- though I'm not sure that meant with
respect to reliability.  I tried to push back by asking about the 100 kb/s
line between the host and the IMP.  "As reliable as your accumulator,"
roared Frank.  For those on this list who aren't familiar with computer
architecture before the entire CPU fit on one chip, the accumulator was the
primary register in the CPU.  If it failed, the computer was completely out
of commission.

To his credit, Frank took personal pride in the operation of the Arpanet.
In a certain sense he viewed it as "his" network.  It wasn't, of course,
but his dedication to it was admirable and undoubtedly contributed to its
success.

Meanwhile, there was another performance detail also involved in the
interaction between the host and the IMP.  The arriving packet ended with
padding that consisted of a 1 and some number of 0's appended to the
message.  The receiving host had to trim off these bits.  Finding the
location of the last 1 is time consuming if you test each bit from the end
and work backwards.  Some machines have instructions that make it easy to
find that bit, but most do not.

I wrote RFC 70, A Note on Padding, to show how to find that bit quickly
using some logical operations and division by a suitably chosen small
number.  I don't know if anyone used the idea in their code.

Regarding programming techniques changing over time, yes indeed!  The IMPs
had relatively little memory compared to today's machines.  Lick gave BBN
trouble when the TIP responded "Trying.." when someone initiated a
connection.  He wanted three dots.  BBN said it would take another half
word.

Going back much further, I spent some time learning to program the SWAC,
Standards Western Automatic Computer, the sister machine to the better
known SEAC.  256 words of memory, so addresses were eight bits.
Instructions were 36 bits wide, a four bit opcode and four addresses.  A
typical instruction was "Add alpha to beta, store in gamma and transfer to
delta if overflow."

There was no divide instruction, no index registers, no floating point and
no subroutine calls.  Division was done by successive approximation.  Loops
used self-modifying code(!)  Amazing work was done on that machine.

Fun fact: The usual computation of square root uses the iteration x' = (x +
A/x)/2.  Without a divide instruction, this iteration is very expensive.
However, the iteration for the *reciprocal* of square root, x' =
(3x-Ax^3)/2, uses three multiplications but no division.

Getting back to the cost of computing the checksum, I thought further about
the approach I described.  I think I could do better and save perhaps 20%
or so.  It would have been interesting to have a contest to see who could
write the fastest code.

On Sun, Apr 20, 2025 at 1:45?PM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:

> Hi Steve,
>
> IIRC there were concerns other than the Engineering ones.
>
> Computers in 1970 were big, expensive to purchase, and expensive to
> operate.  Projects using computers were charged by the "CPU-second" for
> the users' computing, but time consumed by the OS was overhead, and its
> costs spread across all users, along with the costs for power, HVAC,
> floor space, and such.


> ARPA was into "resource sharing" but organizations with computers
> (mostly universities and research sites IIRC) were sometimes reluctant
> to "share" their hard-won computing power.   ARPA was paying the bills
> though, so it could pressure them to connect to the ARPANET.
>
> Still, there was concern to minimize that overhead in the OS, e.g., RFC
> 425, titled "But my NCP costs $500 a day...", written by Bob Bressler,
> in Frank Heart's ARPANET group at BBN. (In 1977 I migrated from MIT to
> Frank's group at BBN, to implement TCP for Unix)
>
> It's easy to forget the computing world of 50+ years ago, now that we
> have computers (aka "devices")  lying around everywhere, much more
> powerful than any machine on the ARPANET in the 1970s, but sitting idle
> most of the time.
>
> Even if the Engineering analysis showed a bit of additional OS overhead
> was minimal, it was still a thorn in the sides of IT managers fifty
> years ago.
>
> But yes, I agree that the PDP-10 had some great instructions.  I spent a
> lot of time in the 70s writing assembler code in Lick's group at MIT, as
> we all tried feverishly to make our PDP-10 do more than it was capable
> of doing.   We did things like using JFCL as the best NO-OP instruction,
> simply because it was the fastest such instruction to execute.  The
> "official" NOP instruction took a bit longer.  That and other such
> techniques were considered common practice of us "bit twiddlers", all to
> save a few CPU-microseconds.
>
> BTW, the ARPANET IMP code is the most amazing example of such "bit
> twiddling" that I have ever encountered.  I did a "deep dive" into the
> old IMP code as a consultant in a patent battle, to figure out exactly
> how the IMP did some of the things that I remembered it did.  I was
> astonished at the techniques used to get every bit of power out of the
> Honeywell minicomputer that was the core of the IMP, often by violating
> today's rules of good program design.  It's just what you did in those
> days of too little CPU, too little memory, and everything too expensive.
>
> Frank Heart's focus was on Engineering - getting the system to work.  I
> can still hear his voice as he argued for that.  You knew he was serious
> when the pitch of his voice approached ultrasonic.
>
> Jack
>
>
> On 4/19/25 20:14, Steve Crocker via Internet-history wrote:
> > Alex,
> >
> > Thanks for your note.  I understand the point you're making, but I don't
> > think the effect would have been very large.  I did a mental exercise to
> > estimate the time to compute the checksum on PDP-10s.  The PDP-10 was a
> 36
> > bit machine, so it definitely would have required the extraction and
> > shifting you're referring to.  However, it also had a very powerful
> > instruction set.  One of its instructions was a Load Byte instruction.
> See
> > http://pdp10.nocrew.org/docs/instruction-set/Byte.html  .  It uses a
> byte
> > pointer which contains the size and offset of the byte, so the
> instruction
> > takes 3 cycles.  Once the byte is loaded into one of the several
> registers,
> > it can be added to another register in one instruction, and because it
> does
> > not need to load data from memory, I believe that Add instruction would
> > take only one cycle.  Hence, a total of 4 cycles to extract a byte and
> add
> > it to a register.
> >
> > The machine has enough registers to permit assigning one for each of the
> > four offsets, thus deferring the shifting to the end.
> >
> > A typical word will have three bytes. so it will take 12 cycles per 36
> bit
> > word.  But we can do slightly better.  Four words is 144 bits, which is 9
> > 16-bit bytes.  In two of those four words, there will be 32 bits that
> have
> > two complete 16-bit bytes.  These can be treated as a single byte in the
> > inner loop and subdivided at the end.  Therefore, within each group of
> four
> > words, there will be only 10 Load Byte and Add instructions, i.e. 40
> cycles
> > for every four words, or 40/9 cycles per 16 bit byte.
> >
> > An 8000 bit message has 500 16-bit bytes, so the inner loop to add all
> the
> > 16 bit-bytes is roughly 500 * 40 / 9 cycles, approximately 2222 cycles.
> > Round this up to 2500 cycles to accommodate the loop management and the
> > assembling the pieces at the end.
> >
> > According to chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/
> >
> https://archive.computerhistory.org/resources/text/DEC/pdp-10/dec.pdp-10.the_evolution_of_the_DECsystem_10.1978.102630382.pdf
> > , the cycle time on the KA-10 was 5 microseconds, so the computation time
> > for the checksum over a full 8000 bit message would have been about 12.5
> > ms.  Double this to account for creating the checksum on the sending side
> > and checking it on the receiving side, so 25 ms overall.
> >
> > For short messages, e.g. typical interactive messages, this figure would
> be
> > *much* smaller.
> >
> > The Arpanet spec was to deliver a message from end to end in under a half
> > second, i.e. 500 ms.  Thus the checksum would have added a little bit of
> > time, but only about 5%.
> >
> > Apologies if there are errors in the above.  Corrections welcome.
> >
> > Steve
> >
> > On Sat, Apr 19, 2025 at 5:00?PM Alexander McKenzie via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >>   Steve,
> >>
> >> It sounds so simple, but the devil is in the details.  Given the
> plethora
> >> of word sizes of the computers connected (or scheduled to be connected)
> to
> >> ARPAnet in 1971, I would bet that for ANY checksum length proposed over
> 50%
> >> of the Hosts would have to engage in mask and shift operations on every
> >> word in a message in order to calculate even a checksum like the one you
> >> describe. This would indeed have somewhat slowed the effective network
> >> speed.  Enough to matter? Who knows, but at that time maximum effective
> >> bandwidth was of real concern to prospective users (remember the
> motivation
> >> for the design of the Tinker-McClellan experiment).  Recall that at that
> >> time a majority of the communications community viewed packet switching
> as
> >> foolish, and ARPAnet as an experiment about to fail. Yes, a simple
> >> end-to-end checksum would have sometimes been of diagnostic help, but
> both
> >> Frank Heart and Larry Roberts had a real reason to worry about anything
> >> that would negatively affect perceived performance of this brand new
> >> technology. Maybe we should have done checksumming for debugging in
> TELNET,
> >> where performance was irrelevant, and left File Transfer alone.
> >>
> >> Cheers,
> >> Alex
> >>
> >> On Friday, April 18, 2025 at 03:12:39 PM EDT, Steve Crocker via
> >> Internet-history<internet-history at elists.isoc.org>  wrote:
> >>
> >>
> >> We tried to include a lightweight checksum in the original host-host
> >> protocol.  (Later it was called the Network Control Protocol or NCP.
> Same
> >> protocol.)  The checksum was designed to be reasonably easy to
> compute.  It
> >> was a 16-bit ones complement sum with one bit of rotation every
> thousand or
> >> so bits.  (The rotation was intended to catch packets out of order,
> error
> >> which we imagined might be possible but never occurred.)  Frank Heart
> >> argued vehemently against it, saying it would make his network look
> slow.
> >> I tried to push back and asked about the Host-IMP interface.  "As
> reliable
> >> as your accumulator," he roared.
> >>
> >> We removed the checkum from our design, a mistake I've rued ever since.
> >> And, of course, it turned out there were indeed a few cases where it
> would
> >> have made a difference.  As has been pointed out, there was a major
> memory
> >> error in one of the IMPs that caused that IMP to look like it was zero
> >> distance to every IMP.  But even before that error, when Lincoln Lab
> first
> >> connected its host to its IMP, their hardware interface had a problem.
> >> There was some crosstalk between the interface and the disk (or drum)
> >> controller.  When the disk (or drum) was operating at the same time as
> the
> >> Host-IMP interface, some bits got scrambled.  It apparently took them
> some
> >> time to track down.  I think they would have found it faster if the
> >> checksum had been part of the design.
> >>
> >> Steve
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> >
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Sent by a Verified

sender


From j at shoch.com  Sun Apr 20 23:23:15 2025
From: j at shoch.com (John Shoch)
Date: Sun, 20 Apr 2025 23:23:15 -0700
Subject: [ih] Internet-history Digest, Vol 65, Issue 23
In-Reply-To: <mailman.71.1745171113.24288.internet-history@elists.isoc.org>
References: <mailman.71.1745171113.24288.internet-history@elists.isoc.org>
Message-ID: <CAFrK2di6K2w_sAYVRV8jE1-d1caPi4Q4iEjP4Gzw2yqFUTJvaA@mail.gmail.com>

I do not want to lightly challenge Dave Crocker's memory nor the
programming skill of whoever implemented XNS at UB 45 years ago, but I do
feel the need to come to the defense of the XNS internet protocols.

You observe that, "Eventually the culprit was found to be a bad U-B
interface card. But none of the networking protocols enforced data
integrity and this problem had,
apparently, gone on for months."
Of course I have no real data about the problem, but I have a suspicion:  I
rather doubt that this was a protocol design issue, but it was much more
likely an implementation issue:

--The XNS protocols were widely implemented and used at the time, without
systematic error problems.
--Published by Xerox they were the basis for many early internetworking
products from U-B, Novel, and others.  Cisco's multi-protocol routers
routed both PUP and XNS packets.
--From Wilipedia:
"The protocol suite specifications for XNS were placed in the public domain
in 1977. This helped XNS become the canonical local area networking
protocol, copied to various degrees by practically all networking systems
in use into the 1990s. XNS was used unchanged by 3Com's 3+Share and
Ungermann-Bass's Net/One. It was also used, with modifications, as the
basis for Novell NetWare, and Banyan VINES"
     https://en.wikipedia.org/wiki/Xerox_Network_Systems
--There is some documentation at:

https://bitsavers.org/pdf/xerox/xns/XNSG_068504_Xerox_System_Network_Architecture_General_Information_Manual_Apr85.pdf
--There was, of course, a checksum in every XNS internet packet:
"The Internet packet fields fall into three categories: addressing fields,
which specify the address of the destination and source network addresses;
control fields, which consist of checksum, length, transport control, and
packet type fields; and data fields,. which carry the data and consist of
information that is interpreted only at the next higher Courier layer. "
--Furthermore, at a higher level of the protocol stack the Filing protocol
included a separate checksum over an entire file:
"Attributes are additional information about the file: they are partitioned
into interpreted and uninterpreted attributes. ..."
"At the files sub-layer, some of the interpreted attributes are: - a binary
file identifier - a file name as a human sensible character string. - a
flag indicating temporary or permanent - a version number - a checksum -
the file size (in octets) - access control information -the time and
identity of the client performing the operation. "

During that period we did occasionally see problems other people were
having:
--In some cases, they had just turned off the checksum capability....caveat
emptor.
--In other cases (perhaps at UB) they were implementing protocols in a
separate smart NIC;  performing a packet checksum there did not protect you
from errors in the NIC or in the path to main memory.  (A lesson learned
from IMPs doing error detection, and then introducing an error on the way
to the host.)  It's why we often preferred "dumb NICs" with error
processing being done in the main memory.
--You note that, "...the culprit was found to be a bad U-B interface." No
packet checksum can protect you from an error beyond the scope of the error
checking.
--Note that the same problem would occur if you did the TCP stack and
checksum in a smart NIC that was introducing errors...

Am I missing something?

John Shoch

------------------------------
>
> Message: 2
> Date: Sun, 20 Apr 2025 08:24:05 +0000 (UTC)
> From: Dave Crocker <dhc at dcrocker.net>
> To: internet-history at elists.isoc.org
> Subject: Re: [ih] Checksums in Host-Host protocol
> Message-ID: <a716c6bd-7d28-428a-8ef8-82658fdededa at dcrocker.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> > On Friday, April 18, 2025 at 03:12:39 PM EDT, Steve Crocker via
> > Internet-history <internet-history at elists.isoc.org> wrote:
> > ...
> > We removed the checkum from our design, a mistake I've rued ever since.
>
>
> I was at Ungermann-Bass(*) in the latter 1980s, and managed its
> development of a TCP/IP stack for its 'smart' Ethernet cards. These has
> a Intel 186 chip on the card.
>
> U-B?s original business was using networking tech to do terminal
> concentration back to mainframes.? That is, they reduced the amount of
> wiring needed back to the mainframe.? Eventually, however, they had to
> support PCs and that included Netbios and SMB.
>
> The original U-B protocol stack was a modified XNS, which was true for a
> number of vendors, each making their own adaptations. (I think I was
> told that XNS had been published well enough to use but the Internet
> protocols were not yet stable, when these networking companies were
> getting started.)
>
> While I was at U-B, there was a major fire drill for a customer that
> discovered they had very serious file data corruption. Eventually the
> culprit was found to be a bad U-B interface card. But none of the
> networking protocols enforced data integrity and this problem had,
> apparently, gone on for months.
>
> It was quietly noted that had they been running with TCP, there would
> have been no data corruption.? Just an increase in retransmissions...
>
>
> d/
>
> (*) Ungermann-Bass was one of the original LAN companies, though it did
> not market as a networking company.? It had a very few, very large
> customers, and it never quite managed to expand from this.? One example
> was that its 'dumb' Ethernet card was superior to the wildly popular
> 3Com Ethernet card.? Another was that as a private tool to aid
> development debugging, I adapted a packet tracing tool to provide
> symbolic TCP and IP traces.? After seeing some ops admin customers get
> excited about this tool, as I used it to show how the smart Ethernet
> card was performing, I tried to get Marketing interested in selling it
> and they declined.? About 2 years later, Harry Saal was making good
> money off of a similar product. sigh.
>
> --
> Dave Crocker
>
> Brandenburg InternetWorking
> bbiw.net
> bluesky: @dcrocker.bsky.social
> mast: @dcrocker at mastodon.social
>
>
>


From dhc at dcrocker.net  Mon Apr 21 00:48:52 2025
From: dhc at dcrocker.net (Dave Crocker)
Date: Mon, 21 Apr 2025 07:48:52 +0000 (UTC)
Subject: [ih] Internet-history Digest, Vol 65, Issue 23
In-Reply-To: <CAFrK2di6K2w_sAYVRV8jE1-d1caPi4Q4iEjP4Gzw2yqFUTJvaA@mail.gmail.com>
References: <mailman.71.1745171113.24288.internet-history@elists.isoc.org>
 <CAFrK2di6K2w_sAYVRV8jE1-d1caPi4Q4iEjP4Gzw2yqFUTJvaA@mail.gmail.com>
Message-ID: <4c3567af-73dd-4504-ab5e-7a6dfc49b6c9@dcrocker.net>

On 4/21/2025 8:23 AM, John Shoch via Internet-history wrote:
> But none of the networking protocols enforced data
> integrity and this problem had,
> apparently, gone on for months."


Heh. Apologies.? I thought I'd worded that more carefully.? And thanks 
for providing the background treatise this needed.

I did indeed only mean to comment on the implementation only.? I was 
tempted to review the actual protocol specs, which is something I 
probably did back then. But I'm a lot lazier now.

Anyhow, cutting corners by implementers doing proprietary 
implementations was not that unusual in those days. In the emerging 
commercial Internet space, I especially liked marketing blurbs for 
Internet protocols that said 'based on' TCP/IP, since it inevitably 
meant the product did not interoperate with other people's.

At U-B, we had a telnet client implementation that was fairly aggressive 
about setting up telnet options with the other side, as soon as the TCP 
connection was set up. One day, a friendly, knowledgeable customer 
called to say that it did not interoperate with another company?s telnet 
server.? This was a surprise, since we interoperated with plenty of 
others and had had no problem reports before this.

I sent them the packet-tracing package and had them capture a session.? 
What I saw from it was that the other side received the TCP connection 
and then immediately passed it off to their terminal driver, with no 
telnet server mediating. So their system just echoed back our telnet 
option requests!

Best of all was that after I explained this to the customer they then 
asked me what we were going to do about it.? I sputtered that the 
problem was the other company's implementation.? The customer said they 
understood this, and would certainly talk with the other folks, but we 
were more responsive....

Later, at Wollongong, we had a PC TCP/IP stack that suddenly started 
flooding the LAN.? Turned out the engineer had built it in a LAN-only 
environment (before I got there) which was a lot quicker and a lot more 
reliable than the open Internet. So they chose to avoid the hassle of 
implementing the specified retransmission code and just had a fixed, 
very-short timer....

d/

-- 
Dave Crocker

Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker at mastodon.social


From lars at nocrew.org  Mon Apr 21 07:05:23 2025
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 21 Apr 2025 14:05:23 +0000
Subject: [ih] when did APRANET -TIPs become known as -TACs
In-Reply-To: <b055154e-046c-4999-9382-93b82f61cfd6@channelisles.net> (Nigel
 Roberts via Internet-history's message of "Sun, 20 Apr 2025 15:35:49
 +0100")
References: <CAMusaY9zVyBKk2eZ4vqnb2M9KtSOHF4ZYcYwdULq3tj5JRbvsw@mail.gmail.com>
 <B4F11E51-0413-4EAF-B258-BD446F751033@comcast.net>
 <b055154e-046c-4999-9382-93b82f61cfd6@channelisles.net>
Message-ID: <7wo6wphaos.fsf@junk.nocrew.org>

Nigel Roberts wrote:
> And I still remember some of the the host numbers
> SU-AI was something in the twenties (23? anyone remember??)

11 (decimal).  I have tested SU-AI running on a PDP-10 emulator
connected to an IMP network.

If you want a more authorative source:
https://www.rfc-editor.org/rfc/rfc597.html


From stewart at serissa.com  Mon Apr 21 07:17:38 2025
From: stewart at serissa.com (Lawrence Stewart)
Date: Mon, 21 Apr 2025 10:17:38 -0400
Subject: [ih] End to end checksums
In-Reply-To: <mailman.88.1745221746.24288.internet-history@elists.isoc.org>
References: <mailman.88.1745221746.24288.internet-history@elists.isoc.org>
Message-ID: <23900A47-DE1E-4298-877D-9FF6B181DF96@serissa.com>

As an aside, the PARC Universal Packet included a 16 bit software checksum calculated by one?s complement addition of 16 bit words plus a 1-bit left cycle. The objective was to give equal protection to all bits.  No one would call the Alto ?fast? but the checksum cost was deemed acceptable.

The decision about whether to have end-to-end checks on communications and storage systems depends both on the probability of undetected errors and on the data volume.

For example, hard drives generally have undetected read error rates of 10^-14.  That probably once seemed pretty good, but it is only a dozen terabytes!  Essentially all file systems and all communications protocols should have end to end integrity checks.

Of course the situation is made worse by skewed error rates.  Some particular devices will have error rates much higher than average, so you cannot depend on that 10^-14 anyway.
 
-L



From steve at shinkuro.com  Mon Apr 21 07:26:29 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Mon, 21 Apr 2025 10:26:29 -0400
Subject: [ih] Question re rate of growth of the Arpanet
Message-ID: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>

Thanks for the pointer to RFC 597.

As I looked at it, an aspect I hadn't considered before came to mind.

Installation of an IMP required provisioning 50 kb/s lines to two or three
other points.  In the early days, we installed roughly a new IMP once a
month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
months.)

Once an IMP was installed, new hosts could be added to the IMP as quickly
as the site could build or obtain the host-IMP interface and write or
obtain the software for their operating system.

If anyone has the dates for each of the hosts, it would be interesting to
compare the growth of IMPs vs growth of hosts.

Steve


From geoff at iconia.com  Mon Apr 21 11:08:52 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Mon, 21 Apr 2025 11:08:52 -0700
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
Message-ID: <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>

steve, can you elucidate any history with respect to how/why the speed of
50 kb/s was chosen for the ARPANET lines?  were there great speeds
available then?

yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
circuits of the day" were primarily used for linking tv broadcast affiliate
stations to/with their motherships (cbs, nbc, abc, ...)?

geoff

On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> Thanks for the pointer to RFC 597.
>
> As I looked at it, an aspect I hadn't considered before came to mind.
>
> Installation of an IMP required provisioning 50 kb/s lines to two or three
> other points.  In the early days, we installed roughly a new IMP once a
> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
> months.)
>
> Once an IMP was installed, new hosts could be added to the IMP as quickly
> as the site could build or obtain the host-IMP interface and write or
> obtain the software for their operating system.
>
> If anyone has the dates for each of the hosts, it would be interesting to
> compare the growth of IMPs vs growth of hosts.
>
> Steve
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From vint at google.com  Mon Apr 21 11:10:55 2025
From: vint at google.com (Vint Cerf)
Date: Mon, 21 Apr 2025 14:10:55 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
Message-ID: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>

Best you could do with 12 3KHz bonded channels on a Bell 303 modem

V

Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice




On Mon, Apr 21, 2025, 14:09 the keyboard of geoff goodfellow via
Internet-history <internet-history at elists.isoc.org> wrote:

> steve, can you elucidate any history with respect to how/why the speed of
> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
> available then?
>
> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
> circuits of the day" were primarily used for linking tv broadcast affiliate
> stations to/with their motherships (cbs, nbc, abc, ...)?
>
> geoff
>
> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > Thanks for the pointer to RFC 597.
> >
> > As I looked at it, an aspect I hadn't considered before came to mind.
> >
> > Installation of an IMP required provisioning 50 kb/s lines to two or
> three
> > other points.  In the early days, we installed roughly a new IMP once a
> > month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
> > months.)
> >
> > Once an IMP was installed, new hosts could be added to the IMP as quickly
> > as the site could build or obtain the host-IMP interface and write or
> > obtain the software for their operating system.
> >
> > If anyone has the dates for each of the hosts, it would be interesting to
> > compare the growth of IMPs vs growth of hosts.
> >
> > Steve
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> >
>
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From steve at shinkuro.com  Mon Apr 21 11:32:46 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Mon, 21 Apr 2025 14:32:46 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
Message-ID: <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>

Geoff,

To add a bit more, I believe Larry Roberts was originally thinking in terms
of 9600 baud lines.  However, he discovered the U.S. Government had access
to a special Bell tariff for these 50 kb/s circuits.  As Vint said, the 50
kb/s was implemented using twelve voice grade circuits and a Western
Electric series 303A modem.  Bottom line, Larry found this item in the
government catalog that provided this bandwidth and was within his budget.

Steve


On Mon, Apr 21, 2025 at 2:11?PM Vint Cerf <vint at google.com> wrote:

> Best you could do with 12 3KHz bonded channels on a Bell 303 modem
>
> V
>
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
>
> On Mon, Apr 21, 2025, 14:09 the keyboard of geoff goodfellow via
> Internet-history <internet-history at elists.isoc.org> wrote:
>
>> steve, can you elucidate any history with respect to how/why the speed of
>> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
>> available then?
>>
>> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
>> circuits of the day" were primarily used for linking tv broadcast
>> affiliate
>> stations to/with their motherships (cbs, nbc, abc, ...)?
>>
>> geoff
>>
>> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>
>> > Thanks for the pointer to RFC 597.
>> >
>> > As I looked at it, an aspect I hadn't considered before came to mind.
>> >
>> > Installation of an IMP required provisioning 50 kb/s lines to two or
>> three
>> > other points.  In the early days, we installed roughly a new IMP once a
>> > month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
>> > months.)
>> >
>> > Once an IMP was installed, new hosts could be added to the IMP as
>> quickly
>> > as the site could build or obtain the host-IMP interface and write or
>> > obtain the software for their operating system.
>> >
>> > If anyone has the dates for each of the hosts, it would be interesting
>> to
>> > compare the growth of IMPs vs growth of hosts.
>> >
>> > Steve
>> > --
>> > Internet-history mailing list
>> > Internet-history at elists.isoc.org
>> > https://elists.isoc.org/mailman/listinfo/internet-history
>> >
>> >
>>
>> --
>> Geoff.Goodfellow at iconia.com
>> living as The Truth is True
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>

-- 
Sent by a Verified

sender


From jeanjour at comcast.net  Mon Apr 21 11:33:38 2025
From: jeanjour at comcast.net (John Day)
Date: Mon, 21 Apr 2025 14:33:38 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
Message-ID: <7E8D47ED-2E6B-409C-A99B-072DDB3D85DE@comcast.net>

theRoberts had originally planned to use 2.4Kbps lines. Roger Scantlebury (and others) at the Gatlinburg Operating System Conference in the Fall of 67 (it appears to have been one of *those* bar discussions) ;-) convinced him that given NPL?s experience with their packet-switched network they had found that that was way too slow and he should use 50Kbps.

Both Baran and Davies independently had come to the conclusion that 1.5Mbps would be best but it wasn?t available yet.

There are two things I find amusing about this:
1) The ARPANET would have worked at 2.4 or 9.6, etc. But would have been deemed so slow to prove that the effort wasn?t really successful. At 50K, we could really get work done. Not many systems could sustain that and there weren?t many applications needing all of that. Using 50K was a much larger part of the ARPANET?s success than we often give it credit for.

2) Roger?s experience was for the NPL campus network. I am not sure Roger had any idea what 50K (which were expensive!) would do to Roberts budget for a nation-wide network in the US.  ;-) At the time, most Europeans and many East Coast Americans had no sense of distances in the US. (I remember a tale of 3 IBMers sent from Poughkeepsie to Detroit to work on some customer's system, who thought as long as they were that far West, they could drive to Las Vegas for the weekend.) (!!) ;-) (31 hours now with Interstates which were not complete then.)  Good thing ARPA?s pockets were deep. ;-)

O, and at that conference, Roger convinced Roberts to use packet switching, which he had not heard of. (He did find Baran?s papers in a stack he hadn?t read when he got back to DC.)

Both are great serendipity, that had a profound effect and for the most part lost in history. I always find these kinds of things delightful.

Take care,
John 

> On Apr 21, 2025, at 14:08, the keyboard of geoff goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> steve, can you elucidate any history with respect to how/why the speed of
> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
> available then?
> 
> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
> circuits of the day" were primarily used for linking tv broadcast affiliate
> stations to/with their motherships (cbs, nbc, abc, ...)?
> 
> geoff
> 
> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> Thanks for the pointer to RFC 597.
>> 
>> As I looked at it, an aspect I hadn't considered before came to mind.
>> 
>> Installation of an IMP required provisioning 50 kb/s lines to two or three
>> other points.  In the early days, we installed roughly a new IMP once a
>> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
>> months.)
>> 
>> Once an IMP was installed, new hosts could be added to the IMP as quickly
>> as the site could build or obtain the host-IMP interface and write or
>> obtain the software for their operating system.
>> 
>> If anyone has the dates for each of the hosts, it would be interesting to
>> compare the growth of IMPs vs growth of hosts.
>> 
>> Steve
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
>> 
> 
> -- 
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From jeanjour at comcast.net  Mon Apr 21 11:36:04 2025
From: jeanjour at comcast.net (John Day)
Date: Mon, 21 Apr 2025 14:36:04 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
Message-ID: <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>

Yes, I thought so too.  My quoting 2.4 was based on the paper Roberts gave at the Gatlinburg conference.

Ah, so the government had a special tariff, so it wasn?t quite as expensive as I thought. Still far greater than a campus network, but better.  ;-)

> On Apr 21, 2025, at 14:32, Steve Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Geoff,
> 
> To add a bit more, I believe Larry Roberts was originally thinking in terms
> of 9600 baud lines.  However, he discovered the U.S. Government had access
> to a special Bell tariff for these 50 kb/s circuits.  As Vint said, the 50
> kb/s was implemented using twelve voice grade circuits and a Western
> Electric series 303A modem.  Bottom line, Larry found this item in the
> government catalog that provided this bandwidth and was within his budget.
> 
> Steve
> 
> 
> On Mon, Apr 21, 2025 at 2:11?PM Vint Cerf <vint at google.com> wrote:
> 
>> Best you could do with 12 3KHz bonded channels on a Bell 303 modem
>> 
>> V
>> 
>> Please send any postal/overnight deliveries to:
>> Vint Cerf
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>> 
>> 
>> until further notice
>> 
>> 
>> 
>> 
>> On Mon, Apr 21, 2025, 14:09 the keyboard of geoff goodfellow via
>> Internet-history <internet-history at elists.isoc.org> wrote:
>> 
>>> steve, can you elucidate any history with respect to how/why the speed of
>>> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
>>> available then?
>>> 
>>> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
>>> circuits of the day" were primarily used for linking tv broadcast
>>> affiliate
>>> stations to/with their motherships (cbs, nbc, abc, ...)?
>>> 
>>> geoff
>>> 
>>> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
>>> internet-history at elists.isoc.org> wrote:
>>> 
>>>> Thanks for the pointer to RFC 597.
>>>> 
>>>> As I looked at it, an aspect I hadn't considered before came to mind.
>>>> 
>>>> Installation of an IMP required provisioning 50 kb/s lines to two or
>>> three
>>>> other points.  In the early days, we installed roughly a new IMP once a
>>>> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
>>>> months.)
>>>> 
>>>> Once an IMP was installed, new hosts could be added to the IMP as
>>> quickly
>>>> as the site could build or obtain the host-IMP interface and write or
>>>> obtain the software for their operating system.
>>>> 
>>>> If anyone has the dates for each of the hosts, it would be interesting
>>> to
>>>> compare the growth of IMPs vs growth of hosts.
>>>> 
>>>> Steve
>>>> --
>>>> Internet-history mailing list
>>>> Internet-history at elists.isoc.org
>>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>> 
>>>> 
>>> 
>>> --
>>> Geoff.Goodfellow at iconia.com
>>> living as The Truth is True
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>> 
>> 
> 
> -- 
> Sent by a Verified
> 
> sender
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From steve at shinkuro.com  Mon Apr 21 11:40:42 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Mon, 21 Apr 2025 14:40:42 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <7E8D47ED-2E6B-409C-A99B-072DDB3D85DE@comcast.net>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <7E8D47ED-2E6B-409C-A99B-072DDB3D85DE@comcast.net>
Message-ID: <CABf5zvJpd0YiwzDcSm=Q4z6R6S+0_E+QX1w+qFDSbq6SQoEcnQ@mail.gmail.com>

I may be wrong about 9.6.  It's what I recall when this was relayed to me,
but I'd want to track down a more authoritative source.

Re U.S. distances: In 1968 I was in Boston until May and then in Los
Angeles.  The University of Utah was just barely beginning to come to
people's attention in the computer science community.  When I mentioned the
university to people in Boston, someone said it was near Los Angeles.  When
I mentioned it to a friend in Los Angeles, she thought it was near Chicago
:)

Steve


On Mon, Apr 21, 2025 at 2:33?PM John Day <jeanjour at comcast.net> wrote:

> theRoberts had originally planned to use 2.4Kbps lines. Roger Scantlebury
> (and others) at the Gatlinburg Operating System Conference in the Fall of
> 67 (it appears to have been one of *those* bar discussions) ;-) convinced
> him that given NPL?s experience with their packet-switched network they had
> found that that was way too slow and he should use 50Kbps.
>
> Both Baran and Davies independently had come to the conclusion that
> 1.5Mbps would be best but it wasn?t available yet.
>
> There are two things I find amusing about this:
> 1) The ARPANET would have worked at 2.4 or 9.6, etc. But would have been
> deemed so slow to prove that the effort wasn?t really successful. At 50K,
> we could really get work done. Not many systems could sustain that and
> there weren?t many applications needing all of that. Using 50K was a much
> larger part of the ARPANET?s success than we often give it credit for.
>
> 2) Roger?s experience was for the NPL campus network. I am not sure Roger
> had any idea what 50K (which were expensive!) would do to Roberts budget
> for a nation-wide network in the US.  ;-) At the time, most Europeans and
> many East Coast Americans had no sense of distances in the US. (I remember
> a tale of 3 IBMers sent from Poughkeepsie to Detroit to work on some
> customer's system, who thought as long as they were that far West, they
> could drive to Las Vegas for the weekend.) (!!) ;-) (31 hours now with
> Interstates which were not complete then.)  Good thing ARPA?s pockets were
> deep. ;-)
>
> O, and at that conference, Roger convinced Roberts to use packet
> switching, which he had not heard of. (He did find Baran?s papers in a
> stack he hadn?t read when he got back to DC.)
>
> Both are great serendipity, that had a profound effect and for the most
> part lost in history. I always find these kinds of things delightful.
>
> Take care,
> John
>
> > On Apr 21, 2025, at 14:08, the keyboard of geoff goodfellow via
> Internet-history <internet-history at elists.isoc.org> wrote:
> >
> > steve, can you elucidate any history with respect to how/why the speed of
> > 50 kb/s was chosen for the ARPANET lines?  were there great speeds
> > available then?
> >
> > yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
> > circuits of the day" were primarily used for linking tv broadcast
> affiliate
> > stations to/with their motherships (cbs, nbc, abc, ...)?
> >
> > geoff
> >
> > On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >> Thanks for the pointer to RFC 597.
> >>
> >> As I looked at it, an aspect I hadn't considered before came to mind.
> >>
> >> Installation of an IMP required provisioning 50 kb/s lines to two or
> three
> >> other points.  In the early days, we installed roughly a new IMP once a
> >> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
> >> months.)
> >>
> >> Once an IMP was installed, new hosts could be added to the IMP as
> quickly
> >> as the site could build or obtain the host-IMP interface and write or
> >> obtain the software for their operating system.
> >>
> >> If anyone has the dates for each of the hosts, it would be interesting
> to
> >> compare the growth of IMPs vs growth of hosts.
> >>
> >> Steve
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> >>
> >
> > --
> > Geoff.Goodfellow at iconia.com
> > living as The Truth is True
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Sent by a Verified

sender


From crypto at glassblower.info  Mon Apr 21 11:51:47 2025
From: crypto at glassblower.info (Tony Patti)
Date: Mon, 21 Apr 2025 14:51:47 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
Message-ID: <1f8901dbb2ee$6f8d3f90$4ea7beb0$@glassblower.info>

Bell 303 modem (suffix letter "C"): 50 kb/s synchronous, in a cabinet of size 24 inches high x 24 inches wide x 12 inches deep.

See https://bitsavers.trailing-edge.com/communications/westernElectric/modems/303_Wideband_Data_Stations_Technical_Reference_Aug66.pdf (especially PDF pages 7 and 8).

Tony Patti
(ARPAnet NIC IDENT ?TP4?)

-----Original Message-----
From: Internet-history <internet-history-bounces at elists.isoc.org> On Behalf Of Vint Cerf via Internet-history
Sent: Monday, April 21, 2025 2:11 PM
To: the keyboard of geoff goodfellow <geoff at iconia.com>
Cc: Internet-history <internet-history at elists.isoc.org>
Subject: Re: [ih] Question re rate of growth of the Arpanet

Best you could do with 12 3KHz bonded channels on a Bell 303 modem

V

Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice




On Mon, Apr 21, 2025, 14:09 the keyboard of geoff goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:

> steve, can you elucidate any history with respect to how/why the speed 
> of
> 50 kb/s was chosen for the ARPANET lines?  were there great speeds 
> available then?
>
> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband 
> circuits of the day" were primarily used for linking tv broadcast 
> affiliate stations to/with their motherships (cbs, nbc, abc, ...)?
>
> geoff
>
> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history < 
> internet-history at elists.isoc.org> wrote:
>
> > Thanks for the pointer to RFC 597.
> >
> > As I looked at it, an aspect I hadn't considered before came to mind.
> >
> > Installation of an IMP required provisioning 50 kb/s lines to two or
> three
> > other points.  In the early days, we installed roughly a new IMP 
> > once a month.  (The lead time for ordering 50 kb/s lines from AT&T 
> > was NINE
> > months.)
> >
> > Once an IMP was installed, new hosts could be added to the IMP as 
> > quickly as the site could build or obtain the host-IMP interface and 
> > write or obtain the software for their operating system.
> >
> > If anyone has the dates for each of the hosts, it would be 
> > interesting to compare the growth of IMPs vs growth of hosts.
> >
> > Steve
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> >
>
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
--
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history



From lk at cs.ucla.edu  Mon Apr 21 11:53:39 2025
From: lk at cs.ucla.edu (Leonard Kleinrock)
Date: Mon, 21 Apr 2025 14:53:39 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CABf5zvJpd0YiwzDcSm=Q4z6R6S+0_E+QX1w+qFDSbq6SQoEcnQ@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <7E8D47ED-2E6B-409C-A99B-072DDB3D85DE@comcast.net>
 <CABf5zvJpd0YiwzDcSm=Q4z6R6S+0_E+QX1w+qFDSbq6SQoEcnQ@mail.gmail.com>
Message-ID: <1377C250-9D3C-4E15-AA47-58EA9EF580CD@cs.ucla.edu>

Hi all,

In the paper ?Analytic and simulation methods in computer network design? <https://dl.acm.org/doi/pdf/10.1145/1476936.1477022>, I show the tariffs available back then.  Specifically, in Table 1, I show the "Publicly Available Leased Transmission Line Costs? and, more importantly, in Table 2, I show the "Estimated Leased Transmission Line Costs Based on Telpak Rates.? and it is the Telpak lines that Larry used to provision the Arpanet.  Note that there is a specific 50Kbps offering in the Telpak offering. Note also that at 50Kbps, the Telpak tariff is considerably more economical than the public tariff.

Len

 

> On Apr 21, 2025, at 2:40?PM, Steve Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> I may be wrong about 9.6.  It's what I recall when this was relayed to me,
> but I'd want to track down a more authoritative source.
> 
> Re U.S. distances: In 1968 I was in Boston until May and then in Los
> Angeles.  The University of Utah was just barely beginning to come to
> people's attention in the computer science community.  When I mentioned the
> university to people in Boston, someone said it was near Los Angeles.  When
> I mentioned it to a friend in Los Angeles, she thought it was near Chicago
> :)
> 
> Steve
> 
> 
> On Mon, Apr 21, 2025 at 2:33?PM John Day <jeanjour at comcast.net <mailto:jeanjour at comcast.net>> wrote:
> 
>> theRoberts had originally planned to use 2.4Kbps lines. Roger Scantlebury
>> (and others) at the Gatlinburg Operating System Conference in the Fall of
>> 67 (it appears to have been one of *those* bar discussions) ;-) convinced
>> him that given NPL?s experience with their packet-switched network they had
>> found that that was way too slow and he should use 50Kbps.
>> 
>> Both Baran and Davies independently had come to the conclusion that
>> 1.5Mbps would be best but it wasn?t available yet.
>> 
>> There are two things I find amusing about this:
>> 1) The ARPANET would have worked at 2.4 or 9.6, etc. But would have been
>> deemed so slow to prove that the effort wasn?t really successful. At 50K,
>> we could really get work done. Not many systems could sustain that and
>> there weren?t many applications needing all of that. Using 50K was a much
>> larger part of the ARPANET?s success than we often give it credit for.
>> 
>> 2) Roger?s experience was for the NPL campus network. I am not sure Roger
>> had any idea what 50K (which were expensive!) would do to Roberts budget
>> for a nation-wide network in the US.  ;-) At the time, most Europeans and
>> many East Coast Americans had no sense of distances in the US. (I remember
>> a tale of 3 IBMers sent from Poughkeepsie to Detroit to work on some
>> customer's system, who thought as long as they were that far West, they
>> could drive to Las Vegas for the weekend.) (!!) ;-) (31 hours now with
>> Interstates which were not complete then.)  Good thing ARPA?s pockets were
>> deep. ;-)
>> 
>> O, and at that conference, Roger convinced Roberts to use packet
>> switching, which he had not heard of. (He did find Baran?s papers in a
>> stack he hadn?t read when he got back to DC.)
>> 
>> Both are great serendipity, that had a profound effect and for the most
>> part lost in history. I always find these kinds of things delightful.
>> 
>> Take care,
>> John
>> 
>>> On Apr 21, 2025, at 14:08, the keyboard of geoff goodfellow via
>> Internet-history <internet-history at elists.isoc.org> wrote:
>>> 
>>> steve, can you elucidate any history with respect to how/why the speed of
>>> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
>>> available then?
>>> 
>>> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
>>> circuits of the day" were primarily used for linking tv broadcast
>> affiliate
>>> stations to/with their motherships (cbs, nbc, abc, ...)?
>>> 
>>> geoff
>>> 
>>> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
>>> internet-history at elists.isoc.org> wrote:
>>> 
>>>> Thanks for the pointer to RFC 597.
>>>> 
>>>> As I looked at it, an aspect I hadn't considered before came to mind.
>>>> 
>>>> Installation of an IMP required provisioning 50 kb/s lines to two or
>> three
>>>> other points.  In the early days, we installed roughly a new IMP once a
>>>> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
>>>> months.)
>>>> 
>>>> Once an IMP was installed, new hosts could be added to the IMP as
>> quickly
>>>> as the site could build or obtain the host-IMP interface and write or
>>>> obtain the software for their operating system.
>>>> 
>>>> If anyone has the dates for each of the hosts, it would be interesting
>> to
>>>> compare the growth of IMPs vs growth of hosts.
>>>> 
>>>> Steve
>>>> --
>>>> Internet-history mailing list
>>>> Internet-history at elists.isoc.org
>>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>> 
>>>> 
>>> 
>>> --
>>> Geoff.Goodfellow at iconia.com
>>> living as The Truth is True
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
>> 
> 
> -- 
> Sent by a Verified
> 
> sender
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
> https://elists.isoc.org/mailman/listinfo/internet-history



From vgcerf at gmail.com  Mon Apr 21 11:55:32 2025
From: vgcerf at gmail.com (vinton cerf)
Date: Mon, 21 Apr 2025 14:55:32 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
Message-ID: <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>

John is right about 2.4 KB/s original plan. The 1967 ACM event where Roger
met Larry changed things.

V

On Mon, Apr 21, 2025, 14:36 John Day via Internet-history <
internet-history at elists.isoc.org> wrote:

> Yes, I thought so too.  My quoting 2.4 was based on the paper Roberts gave
> at the Gatlinburg conference.
>
> Ah, so the government had a special tariff, so it wasn?t quite as
> expensive as I thought. Still far greater than a campus network, but
> better.  ;-)
>
> > On Apr 21, 2025, at 14:32, Steve Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > Geoff,
> >
> > To add a bit more, I believe Larry Roberts was originally thinking in
> terms
> > of 9600 baud lines.  However, he discovered the U.S. Government had
> access
> > to a special Bell tariff for these 50 kb/s circuits.  As Vint said, the
> 50
> > kb/s was implemented using twelve voice grade circuits and a Western
> > Electric series 303A modem.  Bottom line, Larry found this item in the
> > government catalog that provided this bandwidth and was within his
> budget.
> >
> > Steve
> >
> >
> > On Mon, Apr 21, 2025 at 2:11?PM Vint Cerf <vint at google.com> wrote:
> >
> >> Best you could do with 12 3KHz bonded channels on a Bell 303 modem
> >>
> >> V
> >>
> >> Please send any postal/overnight deliveries to:
> >> Vint Cerf
> >> Google, LLC
> >> 1900 Reston Metro Plaza, 16th Floor
> >> Reston, VA 20190
> >> +1 (571) 213 1346
> >>
> >>
> >> until further notice
> >>
> >>
> >>
> >>
> >> On Mon, Apr 21, 2025, 14:09 the keyboard of geoff goodfellow via
> >> Internet-history <internet-history at elists.isoc.org> wrote:
> >>
> >>> steve, can you elucidate any history with respect to how/why the speed
> of
> >>> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
> >>> available then?
> >>>
> >>> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
> >>> circuits of the day" were primarily used for linking tv broadcast
> >>> affiliate
> >>> stations to/with their motherships (cbs, nbc, abc, ...)?
> >>>
> >>> geoff
> >>>
> >>> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
> >>> internet-history at elists.isoc.org> wrote:
> >>>
> >>>> Thanks for the pointer to RFC 597.
> >>>>
> >>>> As I looked at it, an aspect I hadn't considered before came to mind.
> >>>>
> >>>> Installation of an IMP required provisioning 50 kb/s lines to two or
> >>> three
> >>>> other points.  In the early days, we installed roughly a new IMP once
> a
> >>>> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
> >>>> months.)
> >>>>
> >>>> Once an IMP was installed, new hosts could be added to the IMP as
> >>> quickly
> >>>> as the site could build or obtain the host-IMP interface and write or
> >>>> obtain the software for their operating system.
> >>>>
> >>>> If anyone has the dates for each of the hosts, it would be interesting
> >>> to
> >>>> compare the growth of IMPs vs growth of hosts.
> >>>>
> >>>> Steve
> >>>> --
> >>>> Internet-history mailing list
> >>>> Internet-history at elists.isoc.org
> >>>> https://elists.isoc.org/mailman/listinfo/internet-history
> >>>>
> >>>>
> >>>
> >>> --
> >>> Geoff.Goodfellow at iconia.com
> >>> living as The Truth is True
> >>> --
> >>> Internet-history mailing list
> >>> Internet-history at elists.isoc.org
> >>> https://elists.isoc.org/mailman/listinfo/internet-history
> >>>
> >>
> >
> > --
> > Sent by a Verified
> >
> > sender
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From jack at 3kitty.org  Mon Apr 21 12:11:48 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Mon, 21 Apr 2025 12:11:48 -0700
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CABf5zvJpd0YiwzDcSm=Q4z6R6S+0_E+QX1w+qFDSbq6SQoEcnQ@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <7E8D47ED-2E6B-409C-A99B-072DDB3D85DE@comcast.net>
 <CABf5zvJpd0YiwzDcSm=Q4z6R6S+0_E+QX1w+qFDSbq6SQoEcnQ@mail.gmail.com>
Message-ID: <73444d4d-5fe2-4f26-af7c-781e7a81d10c@3kitty.org>

The ICCC conference in 1972 at the Washington Hilton was the "coming out 
party" for ARPANET.? I was one of the crew setting up in the ballroom 
where live demos would be used by the public.? I had never seen an IMP 
actually hooked up, so I volunteered to help the Telco guy when he 
arrived to get the "wideband circuit" in place - i.e., he had orders to 
"provision" the circuit.

My expectations were to see some kind of massive cable, with robust 
military grade connectors, and the very professional "cable run" 
appropriate for a "wideband circuit".? But what I actually saw was the 
tech using a spool of wire, which looked like it had been used many 
times before, and connecting its ends to screw terminals in a box on the 
wall, just like you would then hook up a regular phone line.?? IIRC 
there was only a single circuit to the IMP (actually it was a TIP).

That makes me wonder now if the ICCC'72 demo actually used a 50-kb 
circuit.? Was it possible to get "12 bonded channels" somehow over a 
single twisted pair?

Jack

On 4/21/25 11:40, Steve Crocker via Internet-history wrote:
> I may be wrong about 9.6.  It's what I recall when this was relayed to me,
> but I'd want to track down a more authoritative source.
>
> Re U.S. distances: In 1968 I was in Boston until May and then in Los
> Angeles.  The University of Utah was just barely beginning to come to
> people's attention in the computer science community.  When I mentioned the
> university to people in Boston, someone said it was near Los Angeles.  When
> I mentioned it to a friend in Los Angeles, she thought it was near Chicago
> :)
>
> Steve
>
>
> On Mon, Apr 21, 2025 at 2:33?PM John Day<jeanjour at comcast.net>  wrote:
>
>> theRoberts had originally planned to use 2.4Kbps lines. Roger Scantlebury
>> (and others) at the Gatlinburg Operating System Conference in the Fall of
>> 67 (it appears to have been one of *those* bar discussions) ;-) convinced
>> him that given NPL?s experience with their packet-switched network they had
>> found that that was way too slow and he should use 50Kbps.
>>
>> Both Baran and Davies independently had come to the conclusion that
>> 1.5Mbps would be best but it wasn?t available yet.
>>
>> There are two things I find amusing about this:
>> 1) The ARPANET would have worked at 2.4 or 9.6, etc. But would have been
>> deemed so slow to prove that the effort wasn?t really successful. At 50K,
>> we could really get work done. Not many systems could sustain that and
>> there weren?t many applications needing all of that. Using 50K was a much
>> larger part of the ARPANET?s success than we often give it credit for.
>>
>> 2) Roger?s experience was for the NPL campus network. I am not sure Roger
>> had any idea what 50K (which were expensive!) would do to Roberts budget
>> for a nation-wide network in the US.  ;-) At the time, most Europeans and
>> many East Coast Americans had no sense of distances in the US. (I remember
>> a tale of 3 IBMers sent from Poughkeepsie to Detroit to work on some
>> customer's system, who thought as long as they were that far West, they
>> could drive to Las Vegas for the weekend.) (!!) ;-) (31 hours now with
>> Interstates which were not complete then.)  Good thing ARPA?s pockets were
>> deep. ;-)
>>
>> O, and at that conference, Roger convinced Roberts to use packet
>> switching, which he had not heard of. (He did find Baran?s papers in a
>> stack he hadn?t read when he got back to DC.)
>>
>> Both are great serendipity, that had a profound effect and for the most
>> part lost in history. I always find these kinds of things delightful.
>>
>> Take care,
>> John
>>
>>> On Apr 21, 2025, at 14:08, the keyboard of geoff goodfellow via
>> Internet-history<internet-history at elists.isoc.org>  wrote:
>>> steve, can you elucidate any history with respect to how/why the speed of
>>> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
>>> available then?
>>>
>>> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
>>> circuits of the day" were primarily used for linking tv broadcast
>> affiliate
>>> stations to/with their motherships (cbs, nbc, abc, ...)?
>>>
>>> geoff
>>>
>>> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
>>> internet-history at elists.isoc.org> wrote:
>>>
>>>> Thanks for the pointer to RFC 597.
>>>>
>>>> As I looked at it, an aspect I hadn't considered before came to mind.
>>>>
>>>> Installation of an IMP required provisioning 50 kb/s lines to two or
>> three
>>>> other points.  In the early days, we installed roughly a new IMP once a
>>>> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
>>>> months.)
>>>>
>>>> Once an IMP was installed, new hosts could be added to the IMP as
>> quickly
>>>> as the site could build or obtain the host-IMP interface and write or
>>>> obtain the software for their operating system.
>>>>
>>>> If anyone has the dates for each of the hosts, it would be interesting
>> to
>>>> compare the growth of IMPs vs growth of hosts.
>>>>
>>>> Steve
>>>> --
>>>> Internet-history mailing list
>>>> Internet-history at elists.isoc.org
>>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>>
>>>>
>>> --
>>> Geoff.Goodfellow at iconia.com
>>> living as The Truth is True
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250421/2dd807bf/attachment.asc>

From b_a_denny at yahoo.com  Mon Apr 21 12:21:30 2025
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Mon, 21 Apr 2025 19:21:30 +0000 (UTC)
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
Message-ID: <1396728882.99040.1745263290912@mail.yahoo.com>

 Don't forget about port expanders in trying to determine the host count.
barbara

    On Monday, April 21, 2025 at 07:26:50 AM PDT, Steve Crocker via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 Thanks for the pointer to RFC 597.

As I looked at it, an aspect I hadn't considered before came to mind.

Installation of an IMP required provisioning 50 kb/s lines to two or three
other points.? In the early days, we installed roughly a new IMP once a
month.? (The lead time for ordering 50 kb/s lines from AT&T was NINE
months.)

Once an IMP was installed, new hosts could be added to the IMP as quickly
as the site could build or obtain the host-IMP interface and write or
obtain the software for their operating system.

If anyone has the dates for each of the hosts, it would be interesting to
compare the growth of IMPs vs growth of hosts.

Steve
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  

From aam3sendonly at gmail.com  Mon Apr 21 12:23:14 2025
From: aam3sendonly at gmail.com (Alexander McKenzie)
Date: Mon, 21 Apr 2025 15:23:14 -0400
Subject: [ih] Question re rate of growth of the Arpanet
Message-ID: <CAMusaY8aE=VLWFV-r2_gTiH8jN_Mfmr9VmTApavzoA8ZB2BLsg@mail.gmail.com>

 Steve,

Perhaps the growth rates you are interested in can be determined from the
series of RFCs summarizing Host Traffic Statistics (RFC 612 et al).

Cheers,
Alex

On Monday, April 21, 2025 at 10:26:50 AM EDT, Steve Crocker via
Internet-history <internet-history at elists.isoc.org> wrote:


Thanks for the pointer to RFC 597.

As I looked at it, an aspect I hadn't considered before came to mind.

Installation of an IMP required provisioning 50 kb/s lines to two or three
other points.  In the early days, we installed roughly a new IMP once a
month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
months.)

Once an IMP was installed, new hosts could be added to the IMP as quickly
as the site could build or obtain the host-IMP interface and write or
obtain the software for their operating system.

If anyone has the dates for each of the hosts, it would be interesting to
compare the growth of IMPs vs growth of hosts.

Steve
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history


From aam3sendonly at gmail.com  Mon Apr 21 12:28:34 2025
From: aam3sendonly at gmail.com (Alexander McKenzie)
Date: Mon, 21 Apr 2025 15:28:34 -0400
Subject: [ih] Question re rate of growth of the ArpanetYes,
 the ICCC demo site was connected to the ARPAnet via a 50kbps cable.
 Cheers, Alex On Monday, April 21, 2025 at 03:12:01 PM EDT,
 Jack Haverty via Internet-history <internet-history@elists.isoc.org> wrote:
 The ICCC conference in 1972 at the Washington Hilton was the "coming out
 party" for ARPANET. I was one of the crew setting up in the ballroom where
 live demos would be used by the public. I had never seen an IMP actually
 hooked up,
 so I volunteered to help the Telco guy when he arrived to get the "wideband
 circuit" in place - i.e.,
 he had orders to "provision" the circuit. My expectations were to see some
 kind of massive cable, with robust military grade connectors,
 and the very professional "cable run" appropriate for a "wideband circuit".
 But what I actually saw was the tech using a spool of wire,
 which looked like it had been used many times before,
 and connecting its ends to screw terminals in a box on the wall, jus...
Message-ID: <CAMusaY9r7C9XhPYmHNhXoDVFwJ7zzG=vj8uYwg_=VzEb7ChBdw@mail.gmail.com>

 Yes, the ICCC demo site was connected to the ARPAnet via a 50kbps cable.

Cheers,
Alex

On Monday, April 21, 2025 at 03:12:01 PM EDT, Jack Haverty via
Internet-history <internet-history at elists.isoc.org> wrote:


The ICCC conference in 1972 at the Washington Hilton was the "coming out
party" for ARPANET.  I was one of the crew setting up in the ballroom
where live demos would be used by the public.  I had never seen an IMP
actually hooked up, so I volunteered to help the Telco guy when he
arrived to get the "wideband circuit" in place - i.e., he had orders to
"provision" the circuit.

My expectations were to see some kind of massive cable, with robust
military grade connectors, and the very professional "cable run"
appropriate for a "wideband circuit".  But what I actually saw was the
tech using a spool of wire, which looked like it had been used many
times before, and connecting its ends to screw terminals in a box on the
wall, just like you would then hook up a regular phone line.   IIRC
there was only a single circuit to the IMP (actually it was a TIP).

That makes me wonder now if the ICCC'72 demo actually used a 50-kb
circuit.  Was it possible to get "12 bonded channels" somehow over a
single twisted pair?

Jack


From jeanjour at comcast.net  Mon Apr 21 12:31:57 2025
From: jeanjour at comcast.net (John Day)
Date: Mon, 21 Apr 2025 15:31:57 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CABf5zvJpd0YiwzDcSm=Q4z6R6S+0_E+QX1w+qFDSbq6SQoEcnQ@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <7E8D47ED-2E6B-409C-A99B-072DDB3D85DE@comcast.net>
 <CABf5zvJpd0YiwzDcSm=Q4z6R6S+0_E+QX1w+qFDSbq6SQoEcnQ@mail.gmail.com>
Message-ID: <5058A827-37AC-404A-9254-B5111BD08758@comcast.net>

;-) lol

Yea, I thought it was 9.6 too

> On Apr 21, 2025, at 14:40, Steve Crocker <steve at shinkuro.com> wrote:
> 
> I may be wrong about 9.6.  It's what I recall when this was relayed to me, but I'd want to track down a more authoritative source.
> 
> Re U.S. distances: In 1968 I was in Boston until May and then in Los Angeles.  The University of Utah was just barely beginning to come to people's attention in the computer science community.  When I mentioned the university to people in Boston, someone said it was near Los Angeles.  When I mentioned it to a friend in Los Angeles, she thought it was near Chicago :)
> 
> Steve
> 
> 
> On Mon, Apr 21, 2025 at 2:33?PM John Day <jeanjour at comcast.net <mailto:jeanjour at comcast.net>> wrote:
>> theRoberts had originally planned to use 2.4Kbps lines. Roger Scantlebury (and others) at the Gatlinburg Operating System Conference in the Fall of 67 (it appears to have been one of *those* bar discussions) ;-) convinced him that given NPL?s experience with their packet-switched network they had found that that was way too slow and he should use 50Kbps.
>> 
>> Both Baran and Davies independently had come to the conclusion that 1.5Mbps would be best but it wasn?t available yet.
>> 
>> There are two things I find amusing about this:
>> 1) The ARPANET would have worked at 2.4 or 9.6, etc. But would have been deemed so slow to prove that the effort wasn?t really successful. At 50K, we could really get work done. Not many systems could sustain that and there weren?t many applications needing all of that. Using 50K was a much larger part of the ARPANET?s success than we often give it credit for.
>> 
>> 2) Roger?s experience was for the NPL campus network. I am not sure Roger had any idea what 50K (which were expensive!) would do to Roberts budget for a nation-wide network in the US.  ;-) At the time, most Europeans and many East Coast Americans had no sense of distances in the US. (I remember a tale of 3 IBMers sent from Poughkeepsie to Detroit to work on some customer's system, who thought as long as they were that far West, they could drive to Las Vegas for the weekend.) (!!) ;-) (31 hours now with Interstates which were not complete then.)  Good thing ARPA?s pockets were deep. ;-)
>> 
>> O, and at that conference, Roger convinced Roberts to use packet switching, which he had not heard of. (He did find Baran?s papers in a stack he hadn?t read when he got back to DC.)
>> 
>> Both are great serendipity, that had a profound effect and for the most part lost in history. I always find these kinds of things delightful.
>> 
>> Take care,
>> John 
>> 
>> > On Apr 21, 2025, at 14:08, the keyboard of geoff goodfellow via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> > 
>> > steve, can you elucidate any history with respect to how/why the speed of
>> > 50 kb/s was chosen for the ARPANET lines?  were there great speeds
>> > available then?
>> > 
>> > yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
>> > circuits of the day" were primarily used for linking tv broadcast affiliate
>> > stations to/with their motherships (cbs, nbc, abc, ...)?
>> > 
>> > geoff
>> > 
>> > On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
>> > internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> > 
>> >> Thanks for the pointer to RFC 597.
>> >> 
>> >> As I looked at it, an aspect I hadn't considered before came to mind.
>> >> 
>> >> Installation of an IMP required provisioning 50 kb/s lines to two or three
>> >> other points.  In the early days, we installed roughly a new IMP once a
>> >> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
>> >> months.)
>> >> 
>> >> Once an IMP was installed, new hosts could be added to the IMP as quickly
>> >> as the site could build or obtain the host-IMP interface and write or
>> >> obtain the software for their operating system.
>> >> 
>> >> If anyone has the dates for each of the hosts, it would be interesting to
>> >> compare the growth of IMPs vs growth of hosts.
>> >> 
>> >> Steve
>> >> --
>> >> Internet-history mailing list
>> >> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> >> https://elists.isoc.org/mailman/listinfo/internet-history
>> >> 
>> >> 
>> > 
>> > -- 
>> > Geoff.Goodfellow at iconia.com <mailto:Geoff.Goodfellow at iconia.com>
>> > living as The Truth is True
>> > -- 
>> > Internet-history mailing list
>> > Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> > https://elists.isoc.org/mailman/listinfo/internet-history
>> 
> 
> 
> 
> --
> 



From jeanjour at comcast.net  Mon Apr 21 12:33:40 2025
From: jeanjour at comcast.net (John Day)
Date: Mon, 21 Apr 2025 15:33:40 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
Message-ID: <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>

The benefits of checking the sources.  As I said, I thought it was 9.6 too until I dug into it.  ;-)

2.4 would have been *really* slow!!

> On Apr 21, 2025, at 14:55, vinton cerf <vgcerf at gmail.com> wrote:
> 
> John is right about 2.4 KB/s original plan. The 1967 ACM event where Roger met Larry changed things.
> 
> V
> 
> On Mon, Apr 21, 2025, 14:36 John Day via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> Yes, I thought so too.  My quoting 2.4 was based on the paper Roberts gave at the Gatlinburg conference.
>> 
>> Ah, so the government had a special tariff, so it wasn?t quite as expensive as I thought. Still far greater than a campus network, but better.  ;-)
>> 
>> > On Apr 21, 2025, at 14:32, Steve Crocker via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> > 
>> > Geoff,
>> > 
>> > To add a bit more, I believe Larry Roberts was originally thinking in terms
>> > of 9600 baud lines.  However, he discovered the U.S. Government had access
>> > to a special Bell tariff for these 50 kb/s circuits.  As Vint said, the 50
>> > kb/s was implemented using twelve voice grade circuits and a Western
>> > Electric series 303A modem.  Bottom line, Larry found this item in the
>> > government catalog that provided this bandwidth and was within his budget.
>> > 
>> > Steve
>> > 
>> > 
>> > On Mon, Apr 21, 2025 at 2:11?PM Vint Cerf <vint at google.com <mailto:vint at google.com>> wrote:
>> > 
>> >> Best you could do with 12 3KHz bonded channels on a Bell 303 modem
>> >> 
>> >> V
>> >> 
>> >> Please send any postal/overnight deliveries to:
>> >> Vint Cerf
>> >> Google, LLC
>> >> 1900 Reston Metro Plaza, 16th Floor
>> >> Reston, VA 20190
>> >> +1 (571) 213 1346
>> >> 
>> >> 
>> >> until further notice
>> >> 
>> >> 
>> >> 
>> >> 
>> >> On Mon, Apr 21, 2025, 14:09 the keyboard of geoff goodfellow via
>> >> Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> >> 
>> >>> steve, can you elucidate any history with respect to how/why the speed of
>> >>> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
>> >>> available then?
>> >>> 
>> >>> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
>> >>> circuits of the day" were primarily used for linking tv broadcast
>> >>> affiliate
>> >>> stations to/with their motherships (cbs, nbc, abc, ...)?
>> >>> 
>> >>> geoff
>> >>> 
>> >>> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
>> >>> internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> >>> 
>> >>>> Thanks for the pointer to RFC 597.
>> >>>> 
>> >>>> As I looked at it, an aspect I hadn't considered before came to mind.
>> >>>> 
>> >>>> Installation of an IMP required provisioning 50 kb/s lines to two or
>> >>> three
>> >>>> other points.  In the early days, we installed roughly a new IMP once a
>> >>>> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
>> >>>> months.)
>> >>>> 
>> >>>> Once an IMP was installed, new hosts could be added to the IMP as
>> >>> quickly
>> >>>> as the site could build or obtain the host-IMP interface and write or
>> >>>> obtain the software for their operating system.
>> >>>> 
>> >>>> If anyone has the dates for each of the hosts, it would be interesting
>> >>> to
>> >>>> compare the growth of IMPs vs growth of hosts.
>> >>>> 
>> >>>> Steve
>> >>>> --
>> >>>> Internet-history mailing list
>> >>>> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> >>>> https://elists.isoc.org/mailman/listinfo/internet-history
>> >>>> 
>> >>>> 
>> >>> 
>> >>> --
>> >>> Geoff.Goodfellow at iconia.com <mailto:Geoff.Goodfellow at iconia.com>
>> >>> living as The Truth is True
>> >>> --
>> >>> Internet-history mailing list
>> >>> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> >>> https://elists.isoc.org/mailman/listinfo/internet-history
>> >>> 
>> >> 
>> > 
>> > -- 
>> > Sent by a Verified
>> > 
>> > sender
>> > -- 
>> > Internet-history mailing list
>> > Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> > https://elists.isoc.org/mailman/listinfo/internet-history
>> 
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> https://elists.isoc.org/mailman/listinfo/internet-history



From aam3sendonly at gmail.com  Mon Apr 21 12:40:14 2025
From: aam3sendonly at gmail.com (Alexander McKenzie)
Date: Mon, 21 Apr 2025 15:40:14 -0400
Subject: [ih] Sorry for the sloppy cut & paste
Message-ID: <CAMusaY-hG5zTems25sJXGCzC=uPx+NMiOwdvGn5CVpcxT7LPDg@mail.gmail.com>

Alex


From geoff at iconia.com  Mon Apr 21 13:15:55 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Mon, 21 Apr 2025 13:15:55 -0700
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
Message-ID: <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>

yours truly could not imagine the "shared resources" ARPANET at 2.4 being
"successful" at anything more than a "glorified" ASCII Terminal
Concentrator for a bunch of 110 baud/10 cps Teletypes with maybe an
occasional something or other like a 300 baud/30 cps "printer" terminal !

can't imagine that bandwidth being "shared" for  FTP or practically
anything else...

maybe John Shoch or other PARC/Alto alumni can chime in here, as yours
truly recalls that the link between the Palo Alto and El Segundo networks
of Alto's was a "mere" 9.6 circuit that was pretty much jammed up with
traffic, but at least was useable for more than that Chat (the PUP
equivalent to NCP's TELNET) sessions?

then there was UUCP... can anyone chime in what the "minimum" acceptable
bit rate for that was?  anything less than Bell 202 at 1.2 or Racal Vadic
at 2.4?

geoff

On Mon, Apr 21, 2025 at 12:33?PM John Day via Internet-history <
internet-history at elists.isoc.org> wrote:

> The benefits of checking the sources.  As I said, I thought it was 9.6 too
> until I dug into it.  ;-)
>
> 2.4 would have been *really* slow!!
>
> > On Apr 21, 2025, at 14:55, vinton cerf <vgcerf at gmail.com> wrote:
> >
> > John is right about 2.4 KB/s original plan. The 1967 ACM event where
> Roger met Larry changed things.
> >
> > V
> >
> > On Mon, Apr 21, 2025, 14:36 John Day via Internet-history <
> internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>>
> wrote:
> >> Yes, I thought so too.  My quoting 2.4 was based on the paper Roberts
> gave at the Gatlinburg conference.
> >>
> >> Ah, so the government had a special tariff, so it wasn?t quite as
> expensive as I thought. Still far greater than a campus network, but
> better.  ;-)
> >>
> >> > On Apr 21, 2025, at 14:32, Steve Crocker via Internet-history <
> internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>>
> wrote:
> >> >
> >> > Geoff,
> >> >
> >> > To add a bit more, I believe Larry Roberts was originally thinking in
> terms
> >> > of 9600 baud lines.  However, he discovered the U.S. Government had
> access
> >> > to a special Bell tariff for these 50 kb/s circuits.  As Vint said,
> the 50
> >> > kb/s was implemented using twelve voice grade circuits and a Western
> >> > Electric series 303A modem.  Bottom line, Larry found this item in the
> >> > government catalog that provided this bandwidth and was within his
> budget.
> >> >
> >> > Steve
> >> >
> >> >
> >> > On Mon, Apr 21, 2025 at 2:11?PM Vint Cerf <vint at google.com <mailto:
> vint at google.com>> wrote:
> >> >
> >> >> Best you could do with 12 3KHz bonded channels on a Bell 303 modem
> >> >>
> >> >> V
> >> >>
> >> >> Please send any postal/overnight deliveries to:
> >> >> Vint Cerf
> >> >> Google, LLC
> >> >> 1900 Reston Metro Plaza, 16th Floor
> >> >> Reston, VA 20190
> >> >> +1 (571) 213 1346
> >> >>
> >> >>
> >> >> until further notice
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Apr 21, 2025, 14:09 the keyboard of geoff goodfellow via
> >> >> Internet-history <internet-history at elists.isoc.org <mailto:
> internet-history at elists.isoc.org>> wrote:
> >> >>
> >> >>> steve, can you elucidate any history with respect to how/why the
> speed of
> >> >>> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
> >> >>> available then?
> >> >>>
> >> >>> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s
> "wideband
> >> >>> circuits of the day" were primarily used for linking tv broadcast
> >> >>> affiliate
> >> >>> stations to/with their motherships (cbs, nbc, abc, ...)?
> >> >>>
> >> >>> geoff
> >> >>>
> >> >>> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
> >> >>> internet-history at elists.isoc.org <mailto:
> internet-history at elists.isoc.org>> wrote:
> >> >>>
> >> >>>> Thanks for the pointer to RFC 597.
> >> >>>>
> >> >>>> As I looked at it, an aspect I hadn't considered before came to
> mind.
> >> >>>>
> >> >>>> Installation of an IMP required provisioning 50 kb/s lines to two
> or
> >> >>> three
> >> >>>> other points.  In the early days, we installed roughly a new IMP
> once a
> >> >>>> month.  (The lead time for ordering 50 kb/s lines from AT&T was
> NINE
> >> >>>> months.)
> >> >>>>
> >> >>>> Once an IMP was installed, new hosts could be added to the IMP as
> >> >>> quickly
> >> >>>> as the site could build or obtain the host-IMP interface and write
> or
> >> >>>> obtain the software for their operating system.
> >> >>>>
> >> >>>> If anyone has the dates for each of the hosts, it would be
> interesting
> >> >>> to
> >> >>>> compare the growth of IMPs vs growth of hosts.
> >> >>>>
> >> >>>> Steve
> >> >>>> --
> >> >>>> Internet-history mailing list
> >> >>>> Internet-history at elists.isoc.org <mailto:
> Internet-history at elists.isoc.org>
> >> >>>> https://elists.isoc.org/mailman/listinfo/internet-history
> >> >>>>
> >> >>>>
> >> >>>
> >> >>> --
> >> >>> Geoff.Goodfellow at iconia.com <mailto:Geoff.Goodfellow at iconia.com>
> >> >>> living as The Truth is True
> >> >>> --
> >> >>> Internet-history mailing list
> >> >>> Internet-history at elists.isoc.org <mailto:
> Internet-history at elists.isoc.org>
> >> >>> https://elists.isoc.org/mailman/listinfo/internet-history
> >> >>>
> >> >>
> >> >
> >> > --
> >> > Sent by a Verified
> >> >
> >> > sender
> >> > --
> >> > Internet-history mailing list
> >> > Internet-history at elists.isoc.org <mailto:
> Internet-history at elists.isoc.org>
> >> > https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org <mailto:
> Internet-history at elists.isoc.org>
> >> https://elists.isoc.org/mailman/listinfo/internet-history
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From lk at cs.ucla.edu  Mon Apr 21 18:19:56 2025
From: lk at cs.ucla.edu (Leonard Kleinrock)
Date: Mon, 21 Apr 2025 21:19:56 -0400
Subject: [ih] Checksums in Host-Host protocol
In-Reply-To: <CABf5zvJcABie0PWWD8Ywkz75ePV=2dzCboXhzyDtU=yFfOofkw@mail.gmail.com>
References: <CAMusaY-Y+Hf8aaLt8R2xgBs3DsEkZ=WBU8omq1hiTLoZVbtQBg@mail.gmail.com>
 <CABf5zv+r3LL4rK2eqWL0L4hQwcKnJSP9UOYRWhy5OwuJ+9AvJg@mail.gmail.com>
 <87806765-0288-4380-a2ff-f1bc8bebac91@3kitty.org>
 <CABf5zvJcABie0PWWD8Ywkz75ePV=2dzCboXhzyDtU=yFfOofkw@mail.gmail.com>
Message-ID: <0BBFE7C3-A575-4A1E-B91B-48237C91C13C@cs.ucla.edu>

Steve, et al,

Let me refer this group to a 1974 paper that addresses a considerable number of detailed issues regarding efficiency and line overhead in that early Arpanet (which some of you have probably read).  The paper is ?A study of line overhead in the Arpanet?? <https://dl.acm.org/doi/pdf/10.1145/359970.359976>(by Kleinrock, Naylor and Opderbeck).  It addresses detailed issues of line overhead and control overhead in the Arpanet as it existed in 1974 and projects the impact on such overhead on the then proposed Internet Protocol.  Lots of specifics and details and comments that have some relevance to the ongoing discussion currently taking place.

Best,
Len

> On Apr 20, 2025, at 7:21?PM, Steve Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Jack,
> 
> Yes, the big computer(s) on a university campus operated on a cost recovery
> basis and OMB Circular A-21 (I think) imposed some rules on charging
> computer time to government funded projects.  But I'm quite sure that was
> not relevant in this instance.  Most of the hosts on the Arpanet were part
> of the research projects that ARPA was supporting.  In a few cases, e.g.
> UCLA's main computer, a 360/91, the main computer was connected to the
> Arpanet.  Anyone who used that computer needed an account and had to pay
> for its use.  (I accompanied Larry Roberts on a visit to UCLA when he
> negotiated for a large amount of computer time to run climate modelling
> research using weekend and evening times for a reduced rate.)
> 
> Frank's response struck me as a mixture of engineering instinct and pride.
> The IMPs used a very strong error detection code to detect packets that
> had been damaged in transit.  There was no parity checking in the memory
> but the Honeywell 516 was ruggedized -- though I'm not sure that meant with
> respect to reliability.  I tried to push back by asking about the 100 kb/s
> line between the host and the IMP.  "As reliable as your accumulator,"
> roared Frank.  For those on this list who aren't familiar with computer
> architecture before the entire CPU fit on one chip, the accumulator was the
> primary register in the CPU.  If it failed, the computer was completely out
> of commission.
> 
> To his credit, Frank took personal pride in the operation of the Arpanet.
> In a certain sense he viewed it as "his" network.  It wasn't, of course,
> but his dedication to it was admirable and undoubtedly contributed to its
> success.
> 
> Meanwhile, there was another performance detail also involved in the
> interaction between the host and the IMP.  The arriving packet ended with
> padding that consisted of a 1 and some number of 0's appended to the
> message.  The receiving host had to trim off these bits.  Finding the
> location of the last 1 is time consuming if you test each bit from the end
> and work backwards.  Some machines have instructions that make it easy to
> find that bit, but most do not.
> 
> I wrote RFC 70, A Note on Padding, to show how to find that bit quickly
> using some logical operations and division by a suitably chosen small
> number.  I don't know if anyone used the idea in their code.
> 
> Regarding programming techniques changing over time, yes indeed!  The IMPs
> had relatively little memory compared to today's machines.  Lick gave BBN
> trouble when the TIP responded "Trying.." when someone initiated a
> connection.  He wanted three dots.  BBN said it would take another half
> word.
> 
> Going back much further, I spent some time learning to program the SWAC,
> Standards Western Automatic Computer, the sister machine to the better
> known SEAC.  256 words of memory, so addresses were eight bits.
> Instructions were 36 bits wide, a four bit opcode and four addresses.  A
> typical instruction was "Add alpha to beta, store in gamma and transfer to
> delta if overflow."
> 
> There was no divide instruction, no index registers, no floating point and
> no subroutine calls.  Division was done by successive approximation.  Loops
> used self-modifying code(!)  Amazing work was done on that machine.
> 
> Fun fact: The usual computation of square root uses the iteration x' = (x +
> A/x)/2.  Without a divide instruction, this iteration is very expensive.
> However, the iteration for the *reciprocal* of square root, x' =
> (3x-Ax^3)/2, uses three multiplications but no division.
> 
> Getting back to the cost of computing the checksum, I thought further about
> the approach I described.  I think I could do better and save perhaps 20%
> or so.  It would have been interesting to have a contest to see who could
> write the fastest code.
> 
> On Sun, Apr 20, 2025 at 1:45?PM Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> Hi Steve,
>> 
>> IIRC there were concerns other than the Engineering ones.
>> 
>> Computers in 1970 were big, expensive to purchase, and expensive to
>> operate.  Projects using computers were charged by the "CPU-second" for
>> the users' computing, but time consumed by the OS was overhead, and its
>> costs spread across all users, along with the costs for power, HVAC,
>> floor space, and such.
> 
> 
>> ARPA was into "resource sharing" but organizations with computers
>> (mostly universities and research sites IIRC) were sometimes reluctant
>> to "share" their hard-won computing power.   ARPA was paying the bills
>> though, so it could pressure them to connect to the ARPANET.
>> 
>> Still, there was concern to minimize that overhead in the OS, e.g., RFC
>> 425, titled "But my NCP costs $500 a day...", written by Bob Bressler,
>> in Frank Heart's ARPANET group at BBN. (In 1977 I migrated from MIT to
>> Frank's group at BBN, to implement TCP for Unix)
>> 
>> It's easy to forget the computing world of 50+ years ago, now that we
>> have computers (aka "devices")  lying around everywhere, much more
>> powerful than any machine on the ARPANET in the 1970s, but sitting idle
>> most of the time.
>> 
>> Even if the Engineering analysis showed a bit of additional OS overhead
>> was minimal, it was still a thorn in the sides of IT managers fifty
>> years ago.
>> 
>> But yes, I agree that the PDP-10 had some great instructions.  I spent a
>> lot of time in the 70s writing assembler code in Lick's group at MIT, as
>> we all tried feverishly to make our PDP-10 do more than it was capable
>> of doing.   We did things like using JFCL as the best NO-OP instruction,
>> simply because it was the fastest such instruction to execute.  The
>> "official" NOP instruction took a bit longer.  That and other such
>> techniques were considered common practice of us "bit twiddlers", all to
>> save a few CPU-microseconds.
>> 
>> BTW, the ARPANET IMP code is the most amazing example of such "bit
>> twiddling" that I have ever encountered.  I did a "deep dive" into the
>> old IMP code as a consultant in a patent battle, to figure out exactly
>> how the IMP did some of the things that I remembered it did.  I was
>> astonished at the techniques used to get every bit of power out of the
>> Honeywell minicomputer that was the core of the IMP, often by violating
>> today's rules of good program design.  It's just what you did in those
>> days of too little CPU, too little memory, and everything too expensive.
>> 
>> Frank Heart's focus was on Engineering - getting the system to work.  I
>> can still hear his voice as he argued for that.  You knew he was serious
>> when the pitch of his voice approached ultrasonic.
>> 
>> Jack
>> 
>> 
>> On 4/19/25 20:14, Steve Crocker via Internet-history wrote:
>>> Alex,
>>> 
>>> Thanks for your note.  I understand the point you're making, but I don't
>>> think the effect would have been very large.  I did a mental exercise to
>>> estimate the time to compute the checksum on PDP-10s.  The PDP-10 was a
>> 36
>>> bit machine, so it definitely would have required the extraction and
>>> shifting you're referring to.  However, it also had a very powerful
>>> instruction set.  One of its instructions was a Load Byte instruction.
>> See
>>> http://pdp10.nocrew.org/docs/instruction-set/Byte.html  .  It uses a
>> byte
>>> pointer which contains the size and offset of the byte, so the
>> instruction
>>> takes 3 cycles.  Once the byte is loaded into one of the several
>> registers,
>>> it can be added to another register in one instruction, and because it
>> does
>>> not need to load data from memory, I believe that Add instruction would
>>> take only one cycle.  Hence, a total of 4 cycles to extract a byte and
>> add
>>> it to a register.
>>> 
>>> The machine has enough registers to permit assigning one for each of the
>>> four offsets, thus deferring the shifting to the end.
>>> 
>>> A typical word will have three bytes. so it will take 12 cycles per 36
>> bit
>>> word.  But we can do slightly better.  Four words is 144 bits, which is 9
>>> 16-bit bytes.  In two of those four words, there will be 32 bits that
>> have
>>> two complete 16-bit bytes.  These can be treated as a single byte in the
>>> inner loop and subdivided at the end.  Therefore, within each group of
>> four
>>> words, there will be only 10 Load Byte and Add instructions, i.e. 40
>> cycles
>>> for every four words, or 40/9 cycles per 16 bit byte.
>>> 
>>> An 8000 bit message has 500 16-bit bytes, so the inner loop to add all
>> the
>>> 16 bit-bytes is roughly 500 * 40 / 9 cycles, approximately 2222 cycles.
>>> Round this up to 2500 cycles to accommodate the loop management and the
>>> assembling the pieces at the end.
>>> 
>>> According to chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/
>>> 
>> https://archive.computerhistory.org/resources/text/DEC/pdp-10/dec.pdp-10.the_evolution_of_the_DECsystem_10.1978.102630382.pdf
>>> , the cycle time on the KA-10 was 5 microseconds, so the computation time
>>> for the checksum over a full 8000 bit message would have been about 12.5
>>> ms.  Double this to account for creating the checksum on the sending side
>>> and checking it on the receiving side, so 25 ms overall.
>>> 
>>> For short messages, e.g. typical interactive messages, this figure would
>> be
>>> *much* smaller.
>>> 
>>> The Arpanet spec was to deliver a message from end to end in under a half
>>> second, i.e. 500 ms.  Thus the checksum would have added a little bit of
>>> time, but only about 5%.
>>> 
>>> Apologies if there are errors in the above.  Corrections welcome.
>>> 
>>> Steve
>>> 
>>> On Sat, Apr 19, 2025 at 5:00?PM Alexander McKenzie via Internet-history <
>>> internet-history at elists.isoc.org> wrote:
>>> 
>>>>  Steve,
>>>> 
>>>> It sounds so simple, but the devil is in the details.  Given the
>> plethora
>>>> of word sizes of the computers connected (or scheduled to be connected)
>> to
>>>> ARPAnet in 1971, I would bet that for ANY checksum length proposed over
>> 50%
>>>> of the Hosts would have to engage in mask and shift operations on every
>>>> word in a message in order to calculate even a checksum like the one you
>>>> describe. This would indeed have somewhat slowed the effective network
>>>> speed.  Enough to matter? Who knows, but at that time maximum effective
>>>> bandwidth was of real concern to prospective users (remember the
>> motivation
>>>> for the design of the Tinker-McClellan experiment).  Recall that at that
>>>> time a majority of the communications community viewed packet switching
>> as
>>>> foolish, and ARPAnet as an experiment about to fail. Yes, a simple
>>>> end-to-end checksum would have sometimes been of diagnostic help, but
>> both
>>>> Frank Heart and Larry Roberts had a real reason to worry about anything
>>>> that would negatively affect perceived performance of this brand new
>>>> technology. Maybe we should have done checksumming for debugging in
>> TELNET,
>>>> where performance was irrelevant, and left File Transfer alone.
>>>> 
>>>> Cheers,
>>>> Alex
>>>> 
>>>> On Friday, April 18, 2025 at 03:12:39 PM EDT, Steve Crocker via
>>>> Internet-history<internet-history at elists.isoc.org>  wrote:
>>>> 
>>>> 
>>>> We tried to include a lightweight checksum in the original host-host
>>>> protocol.  (Later it was called the Network Control Protocol or NCP.
>> Same
>>>> protocol.)  The checksum was designed to be reasonably easy to
>> compute.  It
>>>> was a 16-bit ones complement sum with one bit of rotation every
>> thousand or
>>>> so bits.  (The rotation was intended to catch packets out of order,
>> error
>>>> which we imagined might be possible but never occurred.)  Frank Heart
>>>> argued vehemently against it, saying it would make his network look
>> slow.
>>>> I tried to push back and asked about the Host-IMP interface.  "As
>> reliable
>>>> as your accumulator," he roared.
>>>> 
>>>> We removed the checkum from our design, a mistake I've rued ever since.
>>>> And, of course, it turned out there were indeed a few cases where it
>> would
>>>> have made a difference.  As has been pointed out, there was a major
>> memory
>>>> error in one of the IMPs that caused that IMP to look like it was zero
>>>> distance to every IMP.  But even before that error, when Lincoln Lab
>> first
>>>> connected its host to its IMP, their hardware interface had a problem.
>>>> There was some crosstalk between the interface and the disk (or drum)
>>>> controller.  When the disk (or drum) was operating at the same time as
>> the
>>>> Host-IMP interface, some bits got scrambled.  It apparently took them
>> some
>>>> time to track down.  I think they would have found it faster if the
>>>> checksum had been part of the design.
>>>> 
>>>> Steve
>>>> --
>>>> Internet-history mailing list
>>>> Internet-history at elists.isoc.org
>>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>> 
>>> 
>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
> 
> 
> -- 
> Sent by a Verified
> 
> sender
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From julf at Julf.com  Mon Apr 21 23:23:59 2025
From: julf at Julf.com (Johan Helsingius)
Date: Tue, 22 Apr 2025 08:23:59 +0200
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
Message-ID: <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>

On 21/04/2025 22:15, the keyboard of geoff goodfellow via 
Internet-history wrote:

> then there was UUCP... can anyone chime in what the "minimum" acceptable
> bit rate for that was?  anything less than Bell 202 at 1.2 or Racal Vadic
> at 2.4?

Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
but I don't think I ever saw anything slower.

	Julf



From jaap at NLnetLabs.nl  Tue Apr 22 00:36:39 2025
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Tue, 22 Apr 2025 09:36:39 +0200
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
Message-ID: <202504220736.53M7ad04072659@bela.nlnetlabs.nl>

 Johan Helsingius via Internet-history writes:

 > On 21/04/2025 22:15, the keyboard of geoff goodfellow via 
 > Internet-history wrote:
 >
 > > then there was UUCP... can anyone chime in what the "minimum" acceptable
 > > bit rate for that was?  anything less than Bell 202 at 1.2 or Racal Vadic
 > > at 2.4?
 >
 > Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
 > but I don't think I ever saw anything slower.

I did. The first connections from mcvax to (multiple) US sites where on 300 bps modems.

	jaap


From vgcerf at gmail.com  Tue Apr 22 00:42:49 2025
From: vgcerf at gmail.com (vinton cerf)
Date: Tue, 22 Apr 2025 03:42:49 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <202504220736.53M7ad04072659@bela.nlnetlabs.nl>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <202504220736.53M7ad04072659@bela.nlnetlabs.nl>
Message-ID: <CAAFtm_UKDwK-EY2Tu0skGvVXi06Y-JH5s1nVCDi5MtuFi4yQAw@mail.gmail.com>

Sometime in the early 1970s, Tohoku University was connected at 50 baud, I
believe....

vint


On Tue, Apr 22, 2025 at 3:36?AM Jaap Akkerhuis via Internet-history <
internet-history at elists.isoc.org> wrote:

>  Johan Helsingius via Internet-history writes:
>
>  > On 21/04/2025 22:15, the keyboard of geoff goodfellow via
>  > Internet-history wrote:
>  >
>  > > then there was UUCP... can anyone chime in what the "minimum"
> acceptable
>  > > bit rate for that was?  anything less than Bell 202 at 1.2 or Racal
> Vadic
>  > > at 2.4?
>  >
>  > Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
>  > but I don't think I ever saw anything slower.
>
> I did. The first connections from mcvax to (multiple) US sites where on
> 300 bps modems.
>
>         jaap
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From johnl at iecc.com  Tue Apr 22 07:23:59 2025
From: johnl at iecc.com (John Levine)
Date: 22 Apr 2025 10:23:59 -0400
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
Message-ID: <20250422142400.2DA12C5A86D5@ary.qy>

It appears that Johan Helsingius via Internet-history <julf at Julf.com> said:
>On 21/04/2025 22:15, the keyboard of geoff goodfellow via 
>Internet-history wrote:
>
>> then there was UUCP... can anyone chime in what the "minimum" acceptable
>> bit rate for that was?  anything less than Bell 202 at 1.2 or Racal Vadic
>> at 2.4?
>
>Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
>but I don't think I ever saw anything slower.

I think I set up a 300 bps leaf node but didn't run much traffic over it.

All the serious uucp nodes used Telebit modems that had special support for uucp
and could run about 14K bps over a regular phone line. I believe that was the
best you could do until the era of 56K modems that cheated by connecting
directly to digital trunks.

R's,
John


From craig at tereschau.net  Tue Apr 22 07:56:04 2025
From: craig at tereschau.net (Craig Partridge)
Date: Tue, 22 Apr 2025 08:56:04 -0600
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <20250422142400.2DA12C5A86D5@ary.qy>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
Message-ID: <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>

According to the wikipedia page (which could be wrong), the pioneering
Telebit Trailblazer didn't show up until 1985, by which time USENIX/UUCP
was already quite big.  So something else must have been in place before
then -- or was the fact that ihnp4 was willing to run up a huge phone tab
hide many issues?

Side note: the web page also noted that Telebit was founded by Paul Baran
(small world department).

Craig

On Tue, Apr 22, 2025 at 8:24?AM John Levine via Internet-history <
internet-history at elists.isoc.org> wrote:

> It appears that Johan Helsingius via Internet-history <julf at Julf.com>
> said:
> >On 21/04/2025 22:15, the keyboard of geoff goodfellow via
> >Internet-history wrote:
> >
> >> then there was UUCP... can anyone chime in what the "minimum" acceptable
> >> bit rate for that was?  anything less than Bell 202 at 1.2 or Racal
> Vadic
> >> at 2.4?
> >
> >Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
> >but I don't think I ever saw anything slower.
>
> I think I set up a 300 bps leaf node but didn't run much traffic over it.
>
> All the serious uucp nodes used Telebit modems that had special support
> for uucp
> and could run about 14K bps over a regular phone line. I believe that was
> the
> best you could do until the era of 56K modems that cheated by connecting
> directly to digital trunks.
>
> R's,
> John
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.


From dhc at dcrocker.net  Tue Apr 22 08:24:10 2025
From: dhc at dcrocker.net (Dave Crocker)
Date: Tue, 22 Apr 2025 15:24:10 +0000 (UTC)
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
Message-ID: <190c75bf-851b-402a-b209-f11b3f8e3d3e@dcrocker.net>

On 4/22/2025 8:23 AM, Johan Helsingius via Internet-history wrote:
> Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
> but I don't think I ever saw anything slower. 


MMDF was initially developed for use by the Army Materi?l Command, in 
1979, but a year or two later it was applied to the initial operation of 
CSNet, the forerunner to NSFNet.

It's role was as an email gateway to Arpanet mail (and then, of course, 
Internet Mail.)? Its contact with these 'distant' participants was over 
dial-up.? Although X.29/X.25 could be used to emulate a phone call, most 
connections really were via telephone.

Speeds were 300 or 1200 baud, where I think 300 was the most common 
initially.

It was quite noteworthy that having email transfer take place entirely 
in the background made even 300 baud useful for email traffic of those 
days.? Users simply did not have to know or care what the connection 
speed was, since the transfer happened 'away' from them.

There was, however one problem this model had: Users were not aware what 
the connection speed was, or when there were problems.

One day, I got a call from a site's admin claiming that no mail was 
getting through.? There would be a connection for about an hour and then 
it would break off, repeating at the next wake-up cycle.

Looking at the logs showed that the queue was stuck on trying to send a 
1MB file... sigh.

The user environment that I shipped with MMDF contained some 
alternatives, but the popular choice was code that emulated BBN Tenex`s 
SNDMSG(*) and ISI's MSG(**).? This was in the days long before there was 
official support for attachments, but people would include files 
anyhow..? In SNDMSG, do a Ctl-B and you stuffed the file into the 
message.? You did not have to know or care how big it was.? sigh.

The dial-up link simply could not sustain a data call long enough.


d/


(*) SNDMSG was the program Ray Tomlinson hacked, to create the first 
'networked' email, in 1971.

(**) MSG was written by John Vittal and was functionally derived from 
the first email program, RD, that let you selectively read mail; it was 
developed by the Arpa CS lead, Larry Roberts, albeit I hear some other 
folk had more than little involvement.? More significant was that MSG 
was the first program to have a reply command, those its constrained 
command model forced choose 'A'nswer, instead. The presence of that 
function altered email use dramatically, since it meant someone 
responding did not have to laboriously fill out address and subject info 
each time.

-- 
Dave Crocker

Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker at mastodon.social


From geoff at iconia.com  Tue Apr 22 08:24:44 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 22 Apr 2025 08:24:44 -0700
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
Message-ID: <CAEf-zrhmLwwLPhW-KpUqViiL-XkXbi1wzW1831RFu+4FY8+hSg@mail.gmail.com>

the Telebit modems ran at 19.2 and had some "magic" in them called "UUCP
Spoofing" that IIRC "faked spoofed" the UUCP ACK packet locally at the
forward sending host to make it run lickity split rather than having to
"endure" the latency of remote receiving host sending it back.

a bit more of Internet History is that Telebit was also going to put more
of this kind of "magic" in the modems to similarly speed up TCP/IP PPP
connections BUT Telebit was unwilling to do so until (understandably) PPP
was "standardized"... THE PROBLEM was that the lead of the IETF Standard
Working Group (who will remain nameless!) wasn't doing their "job" (let's
say) and the endless delays and frustration built to a point that yours
truly's business (as well as others) was being "stymied"/"harmed" was The
Entire Impetus for yours truly facilitating and launching the (most dearly
revered and reviled) Internet Crucible publication:

"THE CRUCIBLE                                                  INTERNET
EDITION
August, 1989                                                Volume 1 :
Issue 1
                                                                 (reprint)
   In this issue:
A Critical Analysis of the Internet Management Situation..."

[for which the archive of Internet Crucible issues are available at
https://iconia.com/ic/
should anyone wish to summarily "revisit" that Era of Internet History
(from roughly the late 1980's to 1990).]

geoff

On Tue, Apr 22, 2025 at 7:56?AM Craig Partridge via Internet-history <
internet-history at elists.isoc.org> wrote:

> According to the wikipedia page (which could be wrong), the pioneering
> Telebit Trailblazer didn't show up until 1985, by which time USENIX/UUCP
> was already quite big.  So something else must have been in place before
> then -- or was the fact that ihnp4 was willing to run up a huge phone tab
> hide many issues?
>
> Side note: the web page also noted that Telebit was founded by Paul Baran
> (small world department).
>
> Craig
>
> On Tue, Apr 22, 2025 at 8:24?AM John Levine via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > It appears that Johan Helsingius via Internet-history <julf at Julf.com>
> > said:
> > >On 21/04/2025 22:15, the keyboard of geoff goodfellow via
> > >Internet-history wrote:
> > >
> > >> then there was UUCP... can anyone chime in what the "minimum"
> acceptable
> > >> bit rate for that was?  anything less than Bell 202 at 1.2 or Racal
> > Vadic
> > >> at 2.4?
> > >
> > >Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
> > >but I don't think I ever saw anything slower.
> >
> > I think I set up a 300 bps leaf node but didn't run much traffic over it.
> >
> > All the serious uucp nodes used Telebit modems that had special support
> > for uucp
> > and could run about 14K bps over a regular phone line. I believe that was
> > the
> > best you could do until the era of 56K modems that cheated by connecting
> > directly to digital trunks.
> >
> > R's,
> > John
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
>
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From geoff at iconia.com  Tue Apr 22 08:33:22 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 22 Apr 2025 08:33:22 -0700
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <190c75bf-851b-402a-b209-f11b3f8e3d3e@dcrocker.net>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <190c75bf-851b-402a-b209-f11b3f8e3d3e@dcrocker.net>
Message-ID: <CAEf-zrgStjP1AtHbPKdoyWq51OOyK7Tki_Z9f0OCPKpQ6sm_LA@mail.gmail.com>

let's not forget that "between" Larry Roberts RD and John Vittal's MSG was
Marty Yonkee's BANANARD, viz.:

"... Lawrence Roberts, the project manager for the ARPANET development,
took the idea of READMAIL, which dumped all "recent" messages onto the
user's terminal, and wrote a program for TENEX in TECO macros called RD,
which permitted access to individual messages.[88] Barry Wessler then
updated RD and called it NRD.[89]

Marty Yonke rewrote NRD to include reading, access to SNDMSG for sending,
and a help system, and called the utility WRD, which was later known as
BANANARD. John Vittal then updated this version to include three important
commands: Move (combined save/delete command), Answer (determined to whom a
reply should be sent) and Forward (sent a message to a person who was not
already a recipient). The system was called MSG. With inclusion of these
features, MSG is considered to be the first integrated modern electronic
mail program, from which many other applications have descended.[88]..."
https://en.wikipedia.org/wiki/History_of_email

geoff

On Tue, Apr 22, 2025 at 8:24?AM Dave Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> On 4/22/2025 8:23 AM, Johan Helsingius via Internet-history wrote:
> > Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
> > but I don't think I ever saw anything slower.
>
>
> MMDF was initially developed for use by the Army Materi?l Command, in
> 1979, but a year or two later it was applied to the initial operation of
> CSNet, the forerunner to NSFNet.
>
> It's role was as an email gateway to Arpanet mail (and then, of course,
> Internet Mail.)  Its contact with these 'distant' participants was over
> dial-up.  Although X.29/X.25 could be used to emulate a phone call, most
> connections really were via telephone.
>
> Speeds were 300 or 1200 baud, where I think 300 was the most common
> initially.
>
> It was quite noteworthy that having email transfer take place entirely
> in the background made even 300 baud useful for email traffic of those
> days.  Users simply did not have to know or care what the connection
> speed was, since the transfer happened 'away' from them.
>
> There was, however one problem this model had: Users were not aware what
> the connection speed was, or when there were problems.
>
> One day, I got a call from a site's admin claiming that no mail was
> getting through.  There would be a connection for about an hour and then
> it would break off, repeating at the next wake-up cycle.
>
> Looking at the logs showed that the queue was stuck on trying to send a
> 1MB file... sigh.
>
> The user environment that I shipped with MMDF contained some
> alternatives, but the popular choice was code that emulated BBN Tenex`s
> SNDMSG(*) and ISI's MSG(**).  This was in the days long before there was
> official support for attachments, but people would include files
> anyhow..  In SNDMSG, do a Ctl-B and you stuffed the file into the
> message.  You did not have to know or care how big it was.  sigh.
>
> The dial-up link simply could not sustain a data call long enough.
>
>
> d/
>
>
> (*) SNDMSG was the program Ray Tomlinson hacked, to create the first
> 'networked' email, in 1971.
>
> (**) MSG was written by John Vittal and was functionally derived from
> the first email program, RD, that let you selectively read mail; it was
> developed by the Arpa CS lead, Larry Roberts, albeit I hear some other
> folk had more than little involvement.  More significant was that MSG
> was the first program to have a reply command, those its constrained
> command model forced choose 'A'nswer, instead. The presence of that
> function altered email use dramatically, since it meant someone
> responding did not have to laboriously fill out address and subject info
> each time.
>
> --
> Dave Crocker
>
> Brandenburg InternetWorking
> bbiw.net
> bluesky: @dcrocker.bsky.social
> mast: @dcrocker at mastodon.social
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From christinehaughneydb at gmail.com  Tue Apr 22 08:34:15 2025
From: christinehaughneydb at gmail.com (Christine Dare-Bryan)
Date: Tue, 22 Apr 2025 11:34:15 -0400
Subject: [ih] Sharing the second season of Computer Freaks:
Message-ID: <CACr+R5+35JjH1Praw2qY50G-Qnz6V+W8Xm+dk=RS0SZNFSbMmQ@mail.gmail.com>

Hello Friends:
We just wrapped the second season of Computer Freaks which dug into the
1990s and the birth of browsers, ecommerce and search. There were lots of
similarities between the early days of the Arpanet and this time period in
Internet history - AND we included some Season One interview subjects like
John Day!
You can find Season Two anywhere you subscribe to podcasts or find the link
on apple here
<https://podcasts.apple.com/us/podcast/computer-freaks/id1686448197>.  You
can find the landing page to all of the episodes and related articles here
<https://www.inc.com/podcasts/computer-freaks>.
Thank you!
Christine Haughney Dare-Bryan


From dhc at dcrocker.net  Tue Apr 22 08:43:31 2025
From: dhc at dcrocker.net (Dave Crocker)
Date: Tue, 22 Apr 2025 15:43:31 +0000 (UTC)
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CAEf-zrgStjP1AtHbPKdoyWq51OOyK7Tki_Z9f0OCPKpQ6sm_LA@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <190c75bf-851b-402a-b209-f11b3f8e3d3e@dcrocker.net>
 <CAEf-zrgStjP1AtHbPKdoyWq51OOyK7Tki_Z9f0OCPKpQ6sm_LA@mail.gmail.com>
Message-ID: <69bf9efd-7a49-46a7-9b74-666839f6d1e6@dcrocker.net>

On 4/22/2025 5:33 PM, the keyboard of geoff goodfellow wrote:
> Marty Yonke rewrote NRD to include reading, access to SNDMSG for 
> sending, and a help system, and called the utility WRD, which was 
> later known as BANANARD. John Vittal then updated this version to 
> include three important commands:


The 'then' for John's effort appears to be a bit controversial.? As I 
understand it, they started working collaboratively and but things... 
diverged.

Anyhow, BananaRD had a very short lifespan, since MSG quickly and 
massively outpaced it.

d/

-- 
Dave Crocker

Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker at mastodon.social


From johnl at iecc.com  Tue Apr 22 09:20:46 2025
From: johnl at iecc.com (John R. Levine)
Date: 22 Apr 2025 12:20:46 -0400
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
Message-ID: <34fa31a6-22a1-2f14-07e3-59d24b22a045@iecc.com>

On Tue, 22 Apr 2025, Craig Partridge wrote:
> According to the wikipedia page (which could be wrong), the pioneering
> Telebit Trailblazer didn't show up until 1985, by which time USENIX/UUCP
> was already quite big.  So something else must have been in place before
> then -- or was the fact that ihnp4 was willing to run up a huge phone tab
> hide many issues?

I think that's it.  We used what we could use, from 300 to 1200 and then 
V.32 9600 until Telebit came along.  We also learned a lot about what 
phone exchanges were in the free local calling area.  One summer I was at 
my beach house on Long Beach Island in NJ and I saw that even though the 
FAA's Tech Center west of Atlantic City was 40 miles away, it was a 
local call and I talked their uucp admin into giving me a usenet feed for 
a month.

Telebit had an ISA card version which had an unbuffered UART that lost 
characters if the interrupts weren't handled fast enough.  Fortunately 
there was a pin-compatible buffered UART and in those days the boards were 
simple enough that I could unsolder the old UART and put in a socket 
without damaging the board.  I think everyone who got the ISA card did 
that.

R's,
John


>
> Side note: the web page also noted that Telebit was founded by Paul Baran
> (small world department).
>
> Craig
>
> On Tue, Apr 22, 2025 at 8:24?AM John Levine via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> It appears that Johan Helsingius via Internet-history <julf at Julf.com>
>> said:
>>> On 21/04/2025 22:15, the keyboard of geoff goodfellow via
>>> Internet-history wrote:
>>>
>>>> then there was UUCP... can anyone chime in what the "minimum" acceptable
>>>> bit rate for that was?  anything less than Bell 202 at 1.2 or Racal
>> Vadic
>>>> at 2.4?
>>>
>>> Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
>>> but I don't think I ever saw anything slower.
>>
>> I think I set up a 300 bps leaf node but didn't run much traffic over it.
>>
>> All the serious uucp nodes used Telebit modems that had special support
>> for uucp
>> and could run about 14K bps over a regular phone line. I believe that was
>> the
>> best you could do until the era of 56K modems that cheated by connecting
>> directly to digital trunks.


From jack at 3kitty.org  Tue Apr 22 09:38:13 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 22 Apr 2025 09:38:13 -0700
Subject: [ih] Internet nostalgia
Message-ID: <95849ab5-6fac-4d82-b7ff-6c0253aa27a5@3kitty.org>

With all the nostalgia floating around, I thought someone might be 
interested in some historical re-enactment...here's some tools which 
might help.

It is now possible to have your own PDP-11, PDP-10, or PDP-8, if only to 
play with the console switches.?? All powered by a Raspberry Pi running 
a simulator of your favorite old computer, with a real but replica 
computer console.

See https://www.ceds.dev/pidp-11 or https://www.ceds.dev/pidp-8 or 
https://www.ceds.dev/pidp-10

You can also resurrect old software on it, as the ITS-Hackers have done 
with the PDP-10.?? See https://github.com/PDP-10/its

Perhaps someday we'll have an Internet Museum, with the technology of 
the 1970s/80s running again, on modern hardware but using the old 
historic code, protocols, and formats.

You might even debug that final problem you still remember but never 
fixed....

Jack Haverty

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250422/909ef917/attachment.asc>

From lyndon at orthanc.ca  Tue Apr 22 09:55:02 2025
From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM))
Date: Tue, 22 Apr 2025 09:55:02 -0700
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
Message-ID: <401cbd61a1063d7c@orthanc.ca>

> So something else must have been in place before then -- or was the
> fact that ihnp4 was willing to run up a huge phone tab hide many
> issues?

Well, ihnp4 *was* the phone company :-),  So the long distance bill
was "funny money" at the corporate level.  I don't know how they
justified the soft expense internally, though.

Most of the mid-80s long haul was 1200bps dialup.  If you look at
the UUCP maps there were two obvious tiers of sites: the backbone,
and everyone else.  The backbone carried most of the long haul
traffic, and was homed at universities and large corporations that
could justify the budget for the phone bills.  One of those sites
was 'alberta', a VAX at the U of Alberta comp. sci. department.
The long distances charges were funded out of one of the professor's
(Tony Marsland?) research budgets.

The backbone sites then re-distributed the traffic on a more local
basis.  In Edmonton, 'alberta' handled most of the long distance
traffic, then fed it to 'ncc' (a node I ran). 'ncc' handled
much of the fanout to the other local UUCP nodes, with 'alberta'
picking up the rest.  'ncc' also handled a small amount of long
distance traffic.  'alberta' also had a Datapac (X.25) connection,
and used that to exchange traffic with UBC and another site out
east (Waterloo?).

This sort of setup was very typical of the regional hub and spoke
deployments across the continent.

--ncc!lyndon


From lyndon at orthanc.ca  Tue Apr 22 10:03:03 2025
From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM))
Date: Tue, 22 Apr 2025 10:03:03 -0700
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <CAEf-zrhmLwwLPhW-KpUqViiL-XkXbi1wzW1831RFu+4FY8+hSg@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <CAEf-zrhmLwwLPhW-KpUqViiL-XkXbi1wzW1831RFu+4FY8+hSg@mail.gmail.com>
Message-ID: <401cbd78b908a48c@orthanc.ca>

> the Telebit modems ran at 19.2 and had some "magic" in them called
> "UUCP Spoofing" that IIRC "faked spoofed" the UUCP ACK packet locally
> at the forward sending host to make it run lickity split rather
> than having to "endure" the latency of remote receiving host sending
> it back.

The telebits took advantage of the half duplex nature of the UUCP
'g' prototol.  When sending a->b, the modems would configure the
line for bulk data transfer in the a->b dirction.  The a modem
would then directly speak the 'g' protocol with the local host
(pretending to be the remote node), block the data into an internal
buffer, then send the buffered data across the link (possible
conpressed?).  At the other end the reverse set of steps would take
place.  When the a node exhausted its file send queue, the modems
would reverse the line and file transfers from b->a would happen.

--lyndon


From ocl at gih.com  Tue Apr 22 10:35:43 2025
From: ocl at gih.com (=?UTF-8?Q?Olivier_MJ_Cr=C3=A9pin-Leblond?=)
Date: Tue, 22 Apr 2025 19:35:43 +0200
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <190c75bf-851b-402a-b209-f11b3f8e3d3e@dcrocker.net>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <190c75bf-851b-402a-b209-f11b3f8e3d3e@dcrocker.net>
Message-ID: <30c9474d-df87-4319-88cb-cec3cad953b9@gih.com>



On 22/04/2025 17:24, Dave Crocker via Internet-history wrote:
> Speeds were 300 or 1200 baud, where I think 300 was the most common 
> initially.

300 baud mostly in US. In Europe we had the joy 1200/75 as well which 
meant if you originated the call you'd scarcely be able to send anything 
out.
I remember dreaming of a Telebit which was the Rolls Royce of modems at 
the time, when all we could afford locally were Hayes 300 or a lovely 
Racal-Milgo MPS1222 modem. A bit more money would purchase you a USR 
Courier. No money: some cheap no-name add-on hacked cards with dodgy 
Eproms...

>
> It was quite noteworthy that having email transfer take place entirely 
> in the background made even 300 baud useful for email traffic of those 
> days.? Users simply did not have to know or care what the connection 
> speed was, since the transfer happened 'away' from them.
>
> There was, however one problem this model had: Users were not aware 
> what the connection speed was, or when there were problems.
>
> One day, I got a call from a site's admin claiming that no mail was 
> getting through.? There would be a connection for about an hour and 
> then it would break off, repeating at the next wake-up cycle.
>
> Looking at the logs showed that the queue was stuck on trying to send 
> a 1MB file... sigh.
>
> The user environment that I shipped with MMDF contained some 
> alternatives, but the popular choice was code that emulated BBN 
> Tenex`s SNDMSG(*) and ISI's MSG(**).? This was in the days long before 
> there was official support for attachments, but people would include 
> files anyhow..? In SNDMSG, do a Ctl-B and you stuffed the file into 
> the message.? You did not have to know or care how big it was.? sigh.
>
> The dial-up link simply could not sustain a data call long enough. 

Not when you used UUCP!!! UUCP worked really well because when the line 
got dropped, it would restart the file transfer reasonably close to 
where it had been dropped. So it might take time, but the information 
eventually got to the other end. It was only an amount of time. Some of 
the UUCP hosts I was working with regularly had 600 or 700Mb in the 
queue, just dripping them along to the other end...
Kindest regards,

Olivier

From geoff at iconia.com  Tue Apr 22 10:38:23 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 22 Apr 2025 10:38:23 -0700
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <401cbd61a1063d7c@orthanc.ca>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
Message-ID: <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>

let's not forget the UUCP 't' protocol which effectuated a "via Internet
long-distance TPC UUCP bypass/transit" :D, viz.:

"The `t' protocol is intended for TCP links. It does no error checking or
flow control, and requires an eight bit clear channel.

I believe the `t' protocol originated in BSD versions of UUCP.

The Taylor UUCP code for the `t' protocol is in `prott.c'.

When a UUCP package transmits a command, it first gets the length of the
command string, c. It then sends ((c / 512) + 1) * 512 bytes (the smallest
multiple of 512 which can hold c bytes plus a null byte) consisting of the
command string itself followed by trailing null bytes.

When a UUCP package sends a file, it sends it in blocks. Each block
contains at most 1024 bytes of data. Each block consists of four bytes
containing the amount of data in binary (most significant byte first, the
same format as used by the Unix function htonl) followed by that amount of
data. The end of the file is signalled by a block containing zero bytes of
data."
https://www.math.utah.edu/docs/info/uucp_5.html

g

On Tue, Apr 22, 2025 at 9:55?AM Lyndon Nerenberg (VE7TFX/VE6BBM) via
Internet-history <internet-history at elists.isoc.org> wrote:

> > So something else must have been in place before then -- or was the
> > fact that ihnp4 was willing to run up a huge phone tab hide many
> > issues?
>
> Well, ihnp4 *was* the phone company :-),  So the long distance bill
> was "funny money" at the corporate level.  I don't know how they
> justified the soft expense internally, though.
>
> Most of the mid-80s long haul was 1200bps dialup.  If you look at
> the UUCP maps there were two obvious tiers of sites: the backbone,
> and everyone else.  The backbone carried most of the long haul
> traffic, and was homed at universities and large corporations that
> could justify the budget for the phone bills.  One of those sites
> was 'alberta', a VAX at the U of Alberta comp. sci. department.
> The long distances charges were funded out of one of the professor's
> (Tony Marsland?) research budgets.
>
> The backbone sites then re-distributed the traffic on a more local
> basis.  In Edmonton, 'alberta' handled most of the long distance
> traffic, then fed it to 'ncc' (a node I ran). 'ncc' handled
> much of the fanout to the other local UUCP nodes, with 'alberta'
> picking up the rest.  'ncc' also handled a small amount of long
> distance traffic.  'alberta' also had a Datapac (X.25) connection,
> and used that to exchange traffic with UBC and another site out
> east (Waterloo?).
>
> This sort of setup was very typical of the regional hub and spoke
> deployments across the continent.
>
> --ncc!lyndon
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From el at lisse.na  Tue Apr 22 10:52:45 2025
From: el at lisse.na (Eberhard W Lisse)
Date: Tue, 22 Apr 2025 19:52:45 +0200
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <401cbd78b908a48c@orthanc.ca>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <CAEf-zrhmLwwLPhW-KpUqViiL-XkXbi1wzW1831RFu+4FY8+hSg@mail.gmail.com>
 <401cbd78b908a48c@orthanc.ca>
Message-ID: <8d3654dc-a3e7-4c2f-8490-a302b9684884@Spark>

In the early 90's we ran the whole country on 1200 (or was it 2400?), but it was only me anyway at first :-)-O.

Eventually we got one with 9600. Taylor UUCP came along with the longer and sliding packets, I figured out how to batch and gzip and found smail so we could pretend to have domain names.

Connection was to the Rhodes University in South Africa which was almost a local phone call away shortly after I dependence, and prices only slowly increased, so our growth could keep in step.

Once the growth fuelled phone costs higher than a leased line we switched to TCP/IP to the University of the Witwatersrand and it took a few days before anyone noticed ;-)-O

I am still fond of Taylor UUCP...

el


--
Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (retired)
el at lisse.NA / * | Telephone: +264 81 124 6733 (cell)
PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP
10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply


From geoff at iconia.com  Tue Apr 22 10:59:25 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 22 Apr 2025 10:59:25 -0700
Subject: [ih] Internet nostalgia
In-Reply-To: <95849ab5-6fac-4d82-b7ff-6c0253aa27a5@3kitty.org>
References: <95849ab5-6fac-4d82-b7ff-6c0253aa27a5@3kitty.org>
Message-ID: <CAEf-zrjSfzsuhzKe2XH_rBZ1YWrTLmrAQ9hmMb6VDmpdKwrBYg@mail.gmail.com>

recommend checking out https://obsolescence.dev/index.html where a team is
working on PDP-1 and Whirlwind replicas (and as well as an
ARPANET reconstruction project that has come to a point where they can run
connections between multiple PDP-10s running the MIT ITS operating system
and where work is also underway to restore some PDP-11 NCPs)

g

On Tue, Apr 22, 2025 at 9:38?AM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:

> With all the nostalgia floating around, I thought someone might be
> interested in some historical re-enactment...here's some tools which
> might help.
>
> It is now possible to have your own PDP-11, PDP-10, or PDP-8, if only to
> play with the console switches.   All powered by a Raspberry Pi running
> a simulator of your favorite old computer, with a real but replica
> computer console.
>
> See https://www.ceds.dev/pidp-11 or https://www.ceds.dev/pidp-8 or
> https://www.ceds.dev/pidp-10
>
> You can also resurrect old software on it, as the ITS-Hackers have done
> with the PDP-10.   See https://github.com/PDP-10/its
>
> Perhaps someday we'll have an Internet Museum, with the technology of
> the 1970s/80s running again, on modern hardware but using the old
> historic code, protocols, and formats.
>
> You might even debug that final problem you still remember but never
> fixed....
>
> Jack Haverty
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From dhc at dcrocker.net  Tue Apr 22 11:19:53 2025
From: dhc at dcrocker.net (Dave Crocker)
Date: Tue, 22 Apr 2025 18:19:53 +0000 (UTC)
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <30c9474d-df87-4319-88cb-cec3cad953b9@gih.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <190c75bf-851b-402a-b209-f11b3f8e3d3e@dcrocker.net>
 <30c9474d-df87-4319-88cb-cec3cad953b9@gih.com>
Message-ID: <fc8dfb53-40c9-4964-abb8-472f461764b5@dcrocker.net>

On 4/22/2025 7:35 PM, Olivier MJ Cr?pin-Leblond wrote:
>> The dial-up link simply could not sustain a data call long enough. 
>
> Not when you used UUCP!!! UUCP worked really well because when the 
> line got dropped, it would restart the file transfer reasonably close 
> to where it had been dropped

yeah.? this certainly prompted my considering that but I didn't get 
around to it.

d/

-- 
Dave Crocker

Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker at mastodon.social


From chet.ramey at case.edu  Tue Apr 22 11:31:28 2025
From: chet.ramey at case.edu (Chet Ramey)
Date: Tue, 22 Apr 2025 14:31:28 -0400
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
Message-ID: <13d85311-8cc7-4d59-9556-d3ef6aa622eb@case.edu>

On 4/22/25 10:56 AM, Craig Partridge via Internet-history wrote:
> or was the fact that ihnp4 was willing to run up a huge phone tab
> hide many issues?

Them and decvax. DEC covered a *lot* of phone bills and made a *lot*
of outgoing long distance calls (including to us).

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From julf at Julf.com  Tue Apr 22 11:41:58 2025
From: julf at Julf.com (Johan Helsingius)
Date: Tue, 22 Apr 2025 20:41:58 +0200
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
Message-ID: <45bf17b0-0faf-498d-92cb-a728cda5edc9@Julf.com>

Then there was "UUCP over floppy disks". When I did my military service
back in the 1980s in Finland, I was the only person on the base that
had their own PC - but no unauthorized phone connections were allowed
(this was before mobile phones). Every time I got home leave, I would
copy the outgoing queue directory to floppy disks, giving me a batch
update of email and USENET.

The reason I got away with my own PC was because I had a special
position, reporting directly to the base commander. At one point
there was a reunion of all of us who had held that special job
(basically a base ombuds), and I discovered who had held the job
for the first time at the base I was at. It was Nils Torvalds,
journalist, politician and past member of the European Parliament,
and father of Linus...

	Julf


On 22/04/2025 19:38, the keyboard of geoff goodfellow via 
Internet-history wrote:
> let's not forget the UUCP 't' protocol which effectuated a "via Internet
> long-distance TPC UUCP bypass/transit" :D, viz.:
> 
> "The `t' protocol is intended for TCP links. It does no error checking or
> flow control, and requires an eight bit clear channel.
> 
> I believe the `t' protocol originated in BSD versions of UUCP.
> 
> The Taylor UUCP code for the `t' protocol is in `prott.c'.
> 
> When a UUCP package transmits a command, it first gets the length of the
> command string, c. It then sends ((c / 512) + 1) * 512 bytes (the smallest
> multiple of 512 which can hold c bytes plus a null byte) consisting of the
> command string itself followed by trailing null bytes.
> 
> When a UUCP package sends a file, it sends it in blocks. Each block
> contains at most 1024 bytes of data. Each block consists of four bytes
> containing the amount of data in binary (most significant byte first, the
> same format as used by the Unix function htonl) followed by that amount of
> data. The end of the file is signalled by a block containing zero bytes of
> data."
> https://www.math.utah.edu/docs/info/uucp_5.html
> 
> g
> 
> On Tue, Apr 22, 2025 at 9:55?AM Lyndon Nerenberg (VE7TFX/VE6BBM) via
> Internet-history <internet-history at elists.isoc.org> wrote:
> 
>>> So something else must have been in place before then -- or was the
>>> fact that ihnp4 was willing to run up a huge phone tab hide many
>>> issues?
>>
>> Well, ihnp4 *was* the phone company :-),  So the long distance bill
>> was "funny money" at the corporate level.  I don't know how they
>> justified the soft expense internally, though.
>>
>> Most of the mid-80s long haul was 1200bps dialup.  If you look at
>> the UUCP maps there were two obvious tiers of sites: the backbone,
>> and everyone else.  The backbone carried most of the long haul
>> traffic, and was homed at universities and large corporations that
>> could justify the budget for the phone bills.  One of those sites
>> was 'alberta', a VAX at the U of Alberta comp. sci. department.
>> The long distances charges were funded out of one of the professor's
>> (Tony Marsland?) research budgets.
>>
>> The backbone sites then re-distributed the traffic on a more local
>> basis.  In Edmonton, 'alberta' handled most of the long distance
>> traffic, then fed it to 'ncc' (a node I ran). 'ncc' handled
>> much of the fanout to the other local UUCP nodes, with 'alberta'
>> picking up the rest.  'ncc' also handled a small amount of long
>> distance traffic.  'alberta' also had a Datapac (X.25) connection,
>> and used that to exchange traffic with UBC and another site out
>> east (Waterloo?).
>>
>> This sort of setup was very typical of the regional hub and spoke
>> deployments across the continent.
>>
>> --ncc!lyndon
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>>
> 



From awalding at gmail.com  Tue Apr 22 11:51:18 2025
From: awalding at gmail.com (Andrew Walding)
Date: Tue, 22 Apr 2025 13:51:18 -0500
Subject: [ih] The invention of what we now call NAT
Message-ID: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>

Wizards and Historians,
Someone please correct me if what I had heard was wrong.  Back in the BBS
days when those of us were considering/wanting to connect our BBS systems
to the TCP/IP world (which as I recall really was not successful -
certainly not for my BBS) one of the members of the Homebrew Computer Club
of Menlo Park came up with the idea to bypass the high cost of static and
public IP addresses by translating private address space to a single public
IP, therefore avoiding the cost of having multiple public IPs.  The
motivation for this was to avoid paying the service provider more money, of
course.  Every time we added a phone line and a modem, it cost more money
for our BBS's so we were all very sensitive about this.  Now, we used
tricks like "teen lines" and so forth to minimize costs, but the thought of
then having to pay for multiple public IP's for each line was cost
prohibitive for most of us along with the perhaps bigger question: why
would the TCP/IP network want BBS systems on it?

Anyway, I heard about this trick and the code to accomplish this way before
RFC 1631 (1994) was even a draft.  I would say this was in 1985 or so.
 Never saw it myself so it has always been a "tall tale" in my head.

Anyone know anything to confirm or deny this tall tale?
Andy

-- 
*Andrew M. Walding*

Direct: 214-659-1274
Twitter: @awalding
www.cellstream.com <http://bit.ly/2PzyatN>
www.netscionline.com <http://bit.ly/2PzbxWE>

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure. If you are not the intended recipient of this message or
their agent, or if this message has been addressed to you in error, please
immediately alert the sender by reply email and then delete this message
and any attachments. If you are not the intended recipient, you are hereby
notified that any use, dissemination, copying, or storage of this message
or its attachments is strictly prohibited.


From lyndon at orthanc.ca  Tue Apr 22 12:19:20 2025
From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM))
Date: Tue, 22 Apr 2025 12:19:20 -0700
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
Message-ID: <401cbe00edefdb0f@orthanc.ca>

> The `t' protocol is intended for TCP links. It does no error
> checking or flow control, and requires an eight bit clear channel.

> I believe the `t' protocol originated in BSD versions of UUCP.

And down the protocol rabbit hole we go :-)  't' required an 8-bit
error corrected in-order channel.  I.e. TCP.  AT&T independently
created an almost identical protocol named 'e' for TCP (they were
unaware of the 't' protocol from Berkeley).  Later, Taylor UUCP
introduced the 'i' protocol, a full-duplex version of 't'.  Full
duplex in the sense that it transfered files on both directions
concurrently -- a huge time saving for sites that had bi-directional
Usenet feeds (pre-NNTP).

The 'f' protocol was designed for use over X.25 via X.28 PADs.  It
encoded 8-bit data to fit in the 7-bit data channel, and escaped
various control characters that were used by the PADs to control
the terminal session.

The original protocol was 'g'.  Somewhat similar to X.25's LAPB,
in AT&T's uucp it defaulted to 64 byte packets with a window size
of three.  But the protocol parameters allowed a window size up to
7 and a maximum packet size of 256 bytes IIRC.  Increasing both
values really sped things up, but the Xenix UUCP impleentation
had a bug that caused uucico to drop core if the remote tried to
negotiate a window size > 3, and the AT&T uucico binary didn't
let you change the window or packet size.  I'm pretty sure
Honey DanBer did let you monkey with those settings.

Honey DanBer also introduced the 'G' protocol.  It was mostly an
enhanced 'g' with larger packet sizes, from what I remember.

And there were several niche protocols written.  E.g. Doug Evans
wrote the 'z' protocol.  It was intended for use over "mostly 8-bit"
paths; it escaped the ^s/^q control characters, and a few others.

--lyndon


From craig at tereschau.net  Tue Apr 22 12:23:50 2025
From: craig at tereschau.net (Craig Partridge)
Date: Tue, 22 Apr 2025 13:23:50 -0600
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
References: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
Message-ID: <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>

Well, and I'm working from memory for the most part, so flaws may exist.

Van Jacobson is credited as the initial thinker about NAT in RFC 1631 prior
to January 1993, which matches my memory, which is that Van came up with
NAT as a concept while serving on the ROAD WG (which made its report at the
1992 IETF in San Diego -- see minutes p. 508ff, which mention the address
exhaustion problem but not NAT).

I have a fuzzy memory of Van talking about the idea, which required an
enabling idea, which was how to match which TCP connection to which host
among the hosts sharing the IP address.  And, as I recall, Van made use of
the fact that firewalls were doing per TCP connection mappings to firewall
rules and said "aha, that's how you do it."   Since firewalls were a new
concept, c. 1990 by Bellovin and Cheswick, the idea of a prior invention of
NAT prior that 1990 would be unlikely.  Also, ISPs typically didn't charge
for IP addresses until a bit after 1990.  So the window for someone to
separately invent NAT exists (c. 1991-1993) but is narrow.

Craig

On Tue, Apr 22, 2025 at 12:52?PM Andrew Walding via Internet-history <
internet-history at elists.isoc.org> wrote:

> Wizards and Historians,
> Someone please correct me if what I had heard was wrong.  Back in the BBS
> days when those of us were considering/wanting to connect our BBS systems
> to the TCP/IP world (which as I recall really was not successful -
> certainly not for my BBS) one of the members of the Homebrew Computer Club
> of Menlo Park came up with the idea to bypass the high cost of static and
> public IP addresses by translating private address space to a single public
> IP, therefore avoiding the cost of having multiple public IPs.  The
> motivation for this was to avoid paying the service provider more money, of
> course.  Every time we added a phone line and a modem, it cost more money
> for our BBS's so we were all very sensitive about this.  Now, we used
> tricks like "teen lines" and so forth to minimize costs, but the thought of
> then having to pay for multiple public IP's for each line was cost
> prohibitive for most of us along with the perhaps bigger question: why
> would the TCP/IP network want BBS systems on it?
>
> Anyway, I heard about this trick and the code to accomplish this way before
> RFC 1631 (1994) was even a draft.  I would say this was in 1985 or so.
>  Never saw it myself so it has always been a "tall tale" in my head.
>
> Anyone know anything to confirm or deny this tall tale?
> Andy
>
> --
> *Andrew M. Walding*
>
> Direct: 214-659-1274
> Twitter: @awalding
> www.cellstream.com <http://bit.ly/2PzyatN>
> www.netscionline.com <http://bit.ly/2PzbxWE>
>
> CONFIDENTIALITY NOTICE: The contents of this email message and any
> attachments are intended solely for the addressee(s) and may contain
> confidential and/or privileged information and may be legally protected
> from disclosure. If you are not the intended recipient of this message or
> their agent, or if this message has been addressed to you in error, please
> immediately alert the sender by reply email and then delete this message
> and any attachments. If you are not the intended recipient, you are hereby
> notified that any use, dissemination, copying, or storage of this message
> or its attachments is strictly prohibited.
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.


From ocl at gih.com  Tue Apr 22 12:25:24 2025
From: ocl at gih.com (=?UTF-8?Q?Olivier_MJ_Cr=C3=A9pin-Leblond?=)
Date: Tue, 22 Apr 2025 21:25:24 +0200
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <45bf17b0-0faf-498d-92cb-a728cda5edc9@Julf.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <45bf17b0-0faf-498d-92cb-a728cda5edc9@Julf.com>
Message-ID: <9967cfff-4ea4-417d-92a0-b6b3830bf73b@gih.com>



On 22/04/2025 20:41, Johan Helsingius via Internet-history wrote:
> Then there was "UUCP over floppy disks". When I did my military service
> back in the 1980s in Finland, I was the only person on the base that
> had their own PC - but no unauthorized phone connections were allowed
> (this was before mobile phones). Every time I got home leave, I would
> copy the outgoing queue directory to floppy disks, giving me a batch
> update of email and USENET. 

Ah - an illustrious example of a Sneakernet.
https://en.wikipedia.org/wiki/Sneakernet

From clemc at ccc.com  Tue Apr 22 12:32:11 2025
From: clemc at ccc.com (Clem Cole)
Date: Tue, 22 Apr 2025 15:32:11 -0400
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
Message-ID: <CAC20D2P+HOkG9wphOHYOVAxVoxCG8HqWPkUi5AzhNvd82p7iYw@mail.gmail.com>

As is often the case with these sorts of remembrances, a few things are
being mixed up, and I'll try to separate them a bit: UUCP itself and the
Telebit Trailblazer, Rich Adam's work, *etc.*  As an Arpanet IP Developer
at CMU and Tektronix for the original TCP/IP VMS in 1979 and the original
mumble{}!ccc!clemc (that got grandfathered in as clemc at ccc.com when the
names space were brought together in 1982),  I'm also a past president of
USENIX as well as BOD member during some of the issues being discussed ?
basically, I lived all this.

I only hope my dyslexia keeps my prose readable... so be with me and ask
questions and my apologies for my poor typing.

First, UUCP itself.  As other have said, to use UUCP it did not take much
and in the beginning, a serial port such as a DC, DL, DZ, DH, and Western
Electrical compatible automatic call unit such as a DEC DN11 (or Steve
Bellovin?s non-standard relay hack across TIP and RING noted although don?t
let the local Telco know you did that ?I can explain if need be), and a
WE212 or Vadic Triple modem) whose model number I have long forgotten.  We
typically ran on Able DMAX (DH/DM) controllers because DZ's killed Vaxen
with interrupt loads and could not do hardware flow control.    A couple of
big sites UUCP ?forwarding? sites were bank rolling the core of the
transcontinental UUCP circuits, inhp4 (AT&T) and decvax (Digital) that
would actually dial out to other sites with a couple of more sites in AT&T
sites in NJ, plus some slightly smaller sites like teklabs (Tektronix),
ncar (US Gov)  as well as many well know Arpanet sites the allowed dial-in
the most famous being ucbvax
[note, I'm not trying to slight anyone here, just trying to give a taste of
the many sites].

There is an essential piece of economics that feeds this monster.  First,
some wizards at AT&T realized that for every long-distance call that
ihnp4 placed,
it generated at least 12 downstream (paid) long-distance calls on the AT&T
network.  And the team in that own decvax, the Telephone Industry Group
(TIG), discovered that phone charges were not broken out.  Each group was
?taxed? for its share of the building's overhead, including heat, phones,
*etc*.  Bill Munson, TIG?s manager, once realized the cost was around $0.6
M a year, but AT&T was DEC's largest customer by far, and he rationalized
it as a cost of doing business to keep his customer happy.

That said, we all knew it would not work in the long run, hence Rich Adams ?
 more in a minute.

In the early to mid-1980s, the first Telebit Trailblazer appeared,
featuring, I believe, a higher-end Z80 as its processor.  The key was that
it was sending multiple bits over the POTS audio link, thus it could
increase the data bandwidth from what the original Western Electric 212
could do, *i.e.*, obtain 56kb BW over a standard POTS line, but needed to
send additional error correction, thus it needed to buffer the data stream.
[This is why the Able boards quickly became the primary UUCP serial
interface hardware because RTS/CTS flow control was done at the UART level,
plus as a, DH11 emulation, everything as DMAs into/out of memory].

The late Greg Chesson developed the 'g' protocol for Datakit, which was the
primary protocol used by "the "Unix to Unix Copy In Copy Out ? uucico"
program. Since UUCP had error correction in it, there was a bit waste,
so the Telebit
folks would put the 'g' protocol into its ROMs and could ?fake-out? uucico
on each.  It was all very slick.

Before I get to Rick, I need to point out what was really putting the
pressure on the USENET community ? what many of us at the time called it:
net.noise but was formally called NetNews. [This author always felt that
the signal to ratio went away before 1988, but I digress].  NetNews drove
the need for the Telebit product.  We do not have the web yet, and I?m even
sure Archie or many of ?search? and 'indexing' function have started up.
What we have is a broadcast media, plus email.  But is the media of the
expanding news groups that is growing at a prodigious rate.
We all knew the gravy train of  ihnp4 and decvax would eventually end, just
as folks on the Arpanet were starting to see that their world would
soon change.
 The USENIX BOD considered and funded two solutions:
    ? broadcasting netnews over cable (really)
    ? UUNET

The first one was tried, actually ran, and was actively used for a couple
of years.  It was based on the "empty space" in the vertical sync signal of
one of the national PBS channels, with the injection point in LA.  The
advantage was that it was free for the consumers.   The original decode was
an electronics Frankenstein, which I think is what doomed this scheme.  I
made a decoder board, one as did a few others.   The plan was to get
Heathkit to offer it, but It was prototyped right around the time Heath
died. Today, we would open-source the board and the design, and I think
that might have worked.  I suspect that it failed due to the timing.

On the other hand, Rich Adam came to the USENIX board with a different
proposal.  We backed the purchase of some hardware and cosigned some
agreements so he could set up a connection to Telenet Service for incoming
connections to his new system across the USA.  His clients (like me) could
call a local number to us with a trailblazer and attach using Telenet to
Rick?s system at a very fixed cost.  This drastically reduced costs and
removed the need for ihnp4 or decvax sort the x!y!z!mysite style
addresses.  Anyone could become ?!uunet!mysite inexpensively.


Clem


From el at lisse.NA  Tue Apr 22 12:33:57 2025
From: el at lisse.NA (Eberhard W Lisse)
Date: Tue, 22 Apr 2025 21:33:57 +0200
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <401cbe00edefdb0f@orthanc.ca>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
Message-ID: <eeb97f9d-1396-4d66-b3cb-364ec6c76474@lisse.NA>

I seem to vaguely remember that we used 'i', but it was bi-directional
and could do larger packet sizes. Worked extremely well.

el

On 2025-04-22 21:19, Lyndon Nerenberg (VE7TFX/VE6BBM) via Internet-
history wrote:
[...]
> Later, Taylor UUCP introduced the 'i' protocol, a full-duplex
> version of 't'.  Full duplex in the sense that it transfered files
> on both directions concurrently -- a huge time saving for sites that
> had bi-directional Usenet feeds (pre-NNTP).
[...]


-- 
Eberhard W. Lisse     \         /Obstetrician & Gynaecologist (retired)
el at lisse.NA           / *      |     Telephone: +264 81 124 6733 (cell)
PO Box 8421 Bachbrecht\      /     If this email is signed with GPG/PGP
10007, Namibia         ;____/    Sect 20 of Act No. 4 of 2019 may apply



From clemc at ccc.com  Tue Apr 22 12:35:47 2025
From: clemc at ccc.com (Clem Cole)
Date: Tue, 22 Apr 2025 15:35:47 -0400
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <401cbe00edefdb0f@orthanc.ca>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
Message-ID: <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>

Lyndon,

May the record show, I release the 'e' protocol for ethernet and gave it to
Sam.
It used a Berkeley Socket, but it meant that you did not need to run
sendmail.

I wrote it for Masscomp weeks after I left Masscomp and was originally
implemented on 4.1C
Clem
?

On Tue, Apr 22, 2025 at 3:19?PM Lyndon Nerenberg (VE7TFX/VE6BBM) via
Internet-history <internet-history at elists.isoc.org> wrote:

> > The `t' protocol is intended for TCP links. It does no error
> > checking or flow control, and requires an eight bit clear channel.
>
> > I believe the `t' protocol originated in BSD versions of UUCP.
>
> And down the protocol rabbit hole we go :-)  't' required an 8-bit
> error corrected in-order channel.  I.e. TCP.  AT&T independently
> created an almost identical protocol named 'e' for TCP (they were
> unaware of the 't' protocol from Berkeley).  Later, Taylor UUCP
> introduced the 'i' protocol, a full-duplex version of 't'.  Full
> duplex in the sense that it transfered files on both directions
> concurrently -- a huge time saving for sites that had bi-directional
> Usenet feeds (pre-NNTP).
>
> The 'f' protocol was designed for use over X.25 via X.28 PADs.  It
> encoded 8-bit data to fit in the 7-bit data channel, and escaped
> various control characters that were used by the PADs to control
> the terminal session.
>
> The original protocol was 'g'.  Somewhat similar to X.25's LAPB,
> in AT&T's uucp it defaulted to 64 byte packets with a window size
> of three.  But the protocol parameters allowed a window size up to
> 7 and a maximum packet size of 256 bytes IIRC.  Increasing both
> values really sped things up, but the Xenix UUCP impleentation
> had a bug that caused uucico to drop core if the remote tried to
> negotiate a window size > 3, and the AT&T uucico binary didn't
> let you change the window or packet size.  I'm pretty sure
> Honey DanBer did let you monkey with those settings.
>
> Honey DanBer also introduced the 'G' protocol.  It was mostly an
> enhanced 'g' with larger packet sizes, from what I remember.
>
> And there were several niche protocols written.  E.g. Doug Evans
> wrote the 'z' protocol.  It was intended for use over "mostly 8-bit"
> paths; it escaped the ^s/^q control characters, and a few others.
>
> --lyndon
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From lyndon at orthanc.ca  Tue Apr 22 12:46:33 2025
From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM))
Date: Tue, 22 Apr 2025 12:46:33 -0700
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
Message-ID: <401cbe24fba598f0@orthanc.ca>

> May the record show, I release the 'e' protocol for ethernet and
> gave it to Sam.

Clem, my admittedly broken memory remembers you writing on one of
these lists a while back that you invented 'e' not knowing that
Berkeley had already done 't', thus the two co-existed for a
time without knowing each other.  Is that the correct timeline?

--lyndon


From touch at strayalpha.com  Tue Apr 22 12:47:16 2025
From: touch at strayalpha.com (touch at strayalpha.com)
Date: Tue, 22 Apr 2025 12:47:16 -0700
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
References: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
 <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
Message-ID: <FA359D10-4A45-4404-8EA2-97F542F50946@strayalpha.com>

There was also a project at ISI called the ?tunnel? that involved a network device with stateful ports used for network access control, developed by Danny Cohen and Annette Deschon, right around that time:
https://apps.dtic.mil/sti/tr/pdf/ADA271585.pdf

There's also Jeff Mogul?s tech report from 1989 that dances around the same concept:
https://bitsavers.org/pdf/dec/tech_reports/WRL-89-4.pdf

I would hesitate to attribute it to any one person, but I do think the timeline is roughly correct.

Joe

?
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Apr 22, 2025, at 12:23?PM, Craig Partridge via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Well, and I'm working from memory for the most part, so flaws may exist.
> 
> Van Jacobson is credited as the initial thinker about NAT in RFC 1631 prior
> to January 1993, which matches my memory, which is that Van came up with
> NAT as a concept while serving on the ROAD WG (which made its report at the
> 1992 IETF in San Diego -- see minutes p. 508ff, which mention the address
> exhaustion problem but not NAT).
> 
> I have a fuzzy memory of Van talking about the idea, which required an
> enabling idea, which was how to match which TCP connection to which host
> among the hosts sharing the IP address.  And, as I recall, Van made use of
> the fact that firewalls were doing per TCP connection mappings to firewall
> rules and said "aha, that's how you do it."   Since firewalls were a new
> concept, c. 1990 by Bellovin and Cheswick, the idea of a prior invention of
> NAT prior that 1990 would be unlikely.  Also, ISPs typically didn't charge
> for IP addresses until a bit after 1990.  So the window for someone to
> separately invent NAT exists (c. 1991-1993) but is narrow.
> 
> Craig
> 
> On Tue, Apr 22, 2025 at 12:52?PM Andrew Walding via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> Wizards and Historians,
>> Someone please correct me if what I had heard was wrong.  Back in the BBS
>> days when those of us were considering/wanting to connect our BBS systems
>> to the TCP/IP world (which as I recall really was not successful -
>> certainly not for my BBS) one of the members of the Homebrew Computer Club
>> of Menlo Park came up with the idea to bypass the high cost of static and
>> public IP addresses by translating private address space to a single public
>> IP, therefore avoiding the cost of having multiple public IPs.  The
>> motivation for this was to avoid paying the service provider more money, of
>> course.  Every time we added a phone line and a modem, it cost more money
>> for our BBS's so we were all very sensitive about this.  Now, we used
>> tricks like "teen lines" and so forth to minimize costs, but the thought of
>> then having to pay for multiple public IP's for each line was cost
>> prohibitive for most of us along with the perhaps bigger question: why
>> would the TCP/IP network want BBS systems on it?
>> 
>> Anyway, I heard about this trick and the code to accomplish this way before
>> RFC 1631 (1994) was even a draft.  I would say this was in 1985 or so.
>> Never saw it myself so it has always been a "tall tale" in my head.
>> 
>> Anyone know anything to confirm or deny this tall tale?
>> Andy
>> 
>> --
>> *Andrew M. Walding*
>> 
>> Direct: 214-659-1274
>> Twitter: @awalding
>> www.cellstream.com <http://bit.ly/2PzyatN>
>> www.netscionline.com <http://bit.ly/2PzbxWE>
>> 
>> CONFIDENTIALITY NOTICE: The contents of this email message and any
>> attachments are intended solely for the addressee(s) and may contain
>> confidential and/or privileged information and may be legally protected
>> from disclosure. If you are not the intended recipient of this message or
>> their agent, or if this message has been addressed to you in error, please
>> immediately alert the sender by reply email and then delete this message
>> and any attachments. If you are not the intended recipient, you are hereby
>> notified that any use, dissemination, copying, or storage of this message
>> or its attachments is strictly prohibited.
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
> 
> 
> -- 
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From karl at iwl.com  Tue Apr 22 13:17:09 2025
From: karl at iwl.com (Karl Auerbach)
Date: Tue, 22 Apr 2025 13:17:09 -0700
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <FA359D10-4A45-4404-8EA2-97F542F50946@strayalpha.com>
References: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
 <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
 <FA359D10-4A45-4404-8EA2-97F542F50946@strayalpha.com>
Message-ID: <c896238b-e2b2-42d4-9e5a-9221e097ec7b@iwl.com>

In the mid 1970's our group (Dave Kaufman, Frank Heinrich, etc, and 
myself, under the management of Gerry Cole and Clark Weissman) at SDC 
(System Development Corporation) worked on a then classified project. 
(We worked with various US based agencies and a bit with RSRE in the UK 
- where I had the privilege of getting to do some work with Donald Davies.)

We didn't do NAT in the sense of doing address translation.  Rather we 
created an entire overlay network with its own IP address space.  (This 
was done in the very early days of TCP - before the formal development 
of IP, although we arrived at the same conclusion as others, that there 
ought to be some sort of formalized datagram layer underneath TCP - we 
used that notion of an underlying layer as a way to insert our security 
system.  What was strange to today's eyes was that we used an underlying 
TCP based network as our datagram layer, so we effectively ended up with 
TCP over TCP.)

Our architecture included what we would today call a "tunnel". 
(Actually, many encrypted tunnels, each with its own security level, 
plus a key management system.)

We actually built it, it worked, and I heard that it was put into actual 
worldwide production.  (My group did most of the security kernel 
design/implementation, David, and if I remember correctly, along with 
Carl Sunshine, did more of the protocol design, and Frank, David, and I 
collaborated on the key management and access control system.  Security 
policy and software verification was done by Marv Schaeffer, Hillary O., 
Val Schorre, Tom Hinke, John Schied - I am sure I misspelled several of 
those names.)

I've chatted with Dave Kaufman about this and we both are quite unclear 
whether, even today, fifty years later, we can say much about what we 
designed and implemented.

(On a personal basis, my mind wonders how I managed to do all of this 
while at the same time attending law school.)

	--karl--




From brian.e.carpenter at gmail.com  Tue Apr 22 13:28:18 2025
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Wed, 23 Apr 2025 08:28:18 +1200
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <FA359D10-4A45-4404-8EA2-97F542F50946@strayalpha.com>
References: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
 <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
 <FA359D10-4A45-4404-8EA2-97F542F50946@strayalpha.com>
Message-ID: <9e8f5e72-7698-4ec9-9c4d-1098643d0d64@gmail.com>

Before 1990, running out of address space wasn't a theoretical matter; that's why DEC invented "hidden areas" for DECnet Phase IV, which sort of did NAT at the subnet ("area") level. That was in widespread use in the late 1980s. Anyone who had to work with hidden areas hated it, and it was the main motivation for migrating large DECnets to Phase V.

There was also IBM's US patent #5371852 in 1994 (filed October 14, 1992): Method and Apparatus for Making a Cluster of Computers Appear as a Single Host on a Network.

Regards
    Brian Carpenter

On 23-Apr-25 07:47, touch--- via Internet-history wrote:
> There was also a project at ISI called the ?tunnel? that involved a network device with stateful ports used for network access control, developed by Danny Cohen and Annette Deschon, right around that time:
> https://apps.dtic.mil/sti/tr/pdf/ADA271585.pdf
> 
> There's also Jeff Mogul?s tech report from 1989 that dances around the same concept:
> https://bitsavers.org/pdf/dec/tech_reports/WRL-89-4.pdf
> 
> I would hesitate to attribute it to any one person, but I do think the timeline is roughly correct.
> 
> Joe
> 
> ?
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
> 
>> On Apr 22, 2025, at 12:23?PM, Craig Partridge via Internet-history <internet-history at elists.isoc.org> wrote:
>>
>> Well, and I'm working from memory for the most part, so flaws may exist.
>>
>> Van Jacobson is credited as the initial thinker about NAT in RFC 1631 prior
>> to January 1993, which matches my memory, which is that Van came up with
>> NAT as a concept while serving on the ROAD WG (which made its report at the
>> 1992 IETF in San Diego -- see minutes p. 508ff, which mention the address
>> exhaustion problem but not NAT).
>>
>> I have a fuzzy memory of Van talking about the idea, which required an
>> enabling idea, which was how to match which TCP connection to which host
>> among the hosts sharing the IP address.  And, as I recall, Van made use of
>> the fact that firewalls were doing per TCP connection mappings to firewall
>> rules and said "aha, that's how you do it."   Since firewalls were a new
>> concept, c. 1990 by Bellovin and Cheswick, the idea of a prior invention of
>> NAT prior that 1990 would be unlikely.  Also, ISPs typically didn't charge
>> for IP addresses until a bit after 1990.  So the window for someone to
>> separately invent NAT exists (c. 1991-1993) but is narrow.
>>
>> Craig
>>
>> On Tue, Apr 22, 2025 at 12:52?PM Andrew Walding via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>
>>> Wizards and Historians,
>>> Someone please correct me if what I had heard was wrong.  Back in the BBS
>>> days when those of us were considering/wanting to connect our BBS systems
>>> to the TCP/IP world (which as I recall really was not successful -
>>> certainly not for my BBS) one of the members of the Homebrew Computer Club
>>> of Menlo Park came up with the idea to bypass the high cost of static and
>>> public IP addresses by translating private address space to a single public
>>> IP, therefore avoiding the cost of having multiple public IPs.  The
>>> motivation for this was to avoid paying the service provider more money, of
>>> course.  Every time we added a phone line and a modem, it cost more money
>>> for our BBS's so we were all very sensitive about this.  Now, we used
>>> tricks like "teen lines" and so forth to minimize costs, but the thought of
>>> then having to pay for multiple public IP's for each line was cost
>>> prohibitive for most of us along with the perhaps bigger question: why
>>> would the TCP/IP network want BBS systems on it?
>>>
>>> Anyway, I heard about this trick and the code to accomplish this way before
>>> RFC 1631 (1994) was even a draft.  I would say this was in 1985 or so.
>>> Never saw it myself so it has always been a "tall tale" in my head.
>>>
>>> Anyone know anything to confirm or deny this tall tale?
>>> Andy
>>>
>>> --
>>> *Andrew M. Walding*
>>>
>>> Direct: 214-659-1274
>>> Twitter: @awalding
>>> www.cellstream.com <http://bit.ly/2PzyatN>
>>> www.netscionline.com <http://bit.ly/2PzbxWE>
>>>
>>> CONFIDENTIALITY NOTICE: The contents of this email message and any
>>> attachments are intended solely for the addressee(s) and may contain
>>> confidential and/or privileged information and may be legally protected
>>> from disclosure. If you are not the intended recipient of this message or
>>> their agent, or if this message has been addressed to you in error, please
>>> immediately alert the sender by reply email and then delete this message
>>> and any attachments. If you are not the intended recipient, you are hereby
>>> notified that any use, dissemination, copying, or storage of this message
>>> or its attachments is strictly prohibited.
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>
>>
>>
>> -- 
>> *****
>> Craig Partridge's email account for professional society activities and
>> mailing lists.
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
> 

From galmes at tamu.edu  Tue Apr 22 13:44:57 2025
From: galmes at tamu.edu (Guy Almes)
Date: Tue, 22 Apr 2025 16:44:57 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
Message-ID: <1b3e2e7b-231d-42ec-a279-a1ff07155151@tamu.edu>

Steve, Geoff, et al.,
   I actually find this a very interesting thread and a significant gap 
in (at least) my understanding of how the ARPAnet came to be.

   Although I was an ARPAnet user (as a CMU CS grad student), I only 
became aware of how long-distance digital circuits were provided when 
active in the NSFnet regional networks beginning about 1986.  At that 
time, the key technical, regulatory, and business enablers of the needed 
digital services were:
<> technical: the Bell System's DS0, T1, and eventually T3 services. 
The fact that these T1-based services were (more or less) mature by the 
early 1980s was key for us.
<> regulatory: the breakup of the Bell System about 1984 resulted in 
several competing long-distance carriers, each supporting the T1-based 
services and interoperating with the sort-of-regulated monopoly LECs.
<> business: though there's more to it, the essence is the demand for 
more long-distance telephony capacity.  Many of us remember how 
expensive long-distance was and the famous busy signals on Mother's Day.
   This story is pretty well known in our community.
   But we often forget how fortuitous it was that these two 
"prerequisites" were in place by the mid-80s.

   But this thread makes me aware that the corresponding "prerequisites" 
for the ARPAnet are less well understood.
   What I've found so far is this:
<> technical: Western Electric had, by 1966, developed its 303 Type 
Wideband Data Station.  This technology used a "group" of 12 voice 
channels to provide a 50 kb/s service.  (It could also use a 
"supergroup" of 60 voice channels to provide 250 kb/s or a "half-group" 
of 6 voice channels to provide 19.2 kb/s service.)
<> regulatory: Bell System monopoly, but with the government, 
particularly during the Cold War era, as an important special customer.
<> business: here's where I'm weakest.  More in the next paragraph.  Why 
did the Bell System find it "good business" to develop these wideband 
services?
   It occurred to me that I've "always known" that the ARPAnet used 
50-kb/s leased lines based on some kind of "modem".
   If, somehow, those Bell System 50-kb/s digital services had not been 
available, then would the ARPAnet been successful?

   So here are my hunches on the "business" part of the story:
<> I don't think it was used in the SAGE system.  What I've seen so far 
about the technology of SAGE (which was deployed beginning 1959), it 
used 1200-b/s modems.
<> I don't think it was used much by the TV industry.  This had been my 
hunch, and I allow that I might be wrong about this, but my impression 
is that the TV industry had their own technologies for using 
long-distance cables and microwaves.
<> I think it might well have been used for NASA telemetry etc., but I 
don't have any specific evidence.
<> I think it was used by the SABRE airline reservation system.

   But this is pretty sketchy.
   I'd welcome input from others.
   My key objective is to better understand why the long-distance 
telecommunications industry (in this case, the Bell System) had created 
this premium wideband digital service in the pre-T1 era such that, when 
the ARPAnet designers were doing their work, 50-kb/s long-distance 
service was available.

   Thanks in advance to any additions or corrections,
	-- Guy

On 4/21/25 2:08 PM, the keyboard of geoff goodfellow via 
Internet-history wrote:
> steve, can you elucidate any history with respect to how/why the speed of
> 50 kb/s was chosen for the ARPANET lines?  were there great speeds
> available then?
> 
> yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
> circuits of the day" were primarily used for linking tv broadcast affiliate
> stations to/with their motherships (cbs, nbc, abc, ...)?
> 
> geoff
> 
> On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> Thanks for the pointer to RFC 597.
>>
>> As I looked at it, an aspect I hadn't considered before came to mind.
>>
>> Installation of an IMP required provisioning 50 kb/s lines to two or three
>> other points.  In the early days, we installed roughly a new IMP once a
>> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
>> months.)
>>
>> Once an IMP was installed, new hosts could be added to the IMP as quickly
>> as the site could build or obtain the host-IMP interface and write or
>> obtain the software for their operating system.
>>
>> If anyone has the dates for each of the hosts, it would be interesting to
>> compare the growth of IMPs vs growth of hosts.
>>
>> Steve
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/ 
> internet-history__;!!KwNVnqRv! 
> CvnEaxskHMjf5GDDAK0yK26KGlSUJU3NOkWGxNhpUZy2w019Knw4jAy7yaqEPt6QipJlK7Z2kh6L19IKzgKMXGaLQDRZkw$ <https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!CvnEaxskHMjf5GDDAK0yK26KGlSUJU3NOkWGxNhpUZy2w019Knw4jAy7yaqEPt6QipJlK7Z2kh6L19IKzgKMXGaLQDRZkw$>
>>
>>
> 
> -- 
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/ 
> internet-history__;!!KwNVnqRv! 
> CvnEaxskHMjf5GDDAK0yK26KGlSUJU3NOkWGxNhpUZy2w019Knw4jAy7yaqEPt6QipJlK7Z2kh6L19IKzgKMXGaLQDRZkw$ <https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!CvnEaxskHMjf5GDDAK0yK26KGlSUJU3NOkWGxNhpUZy2w019Knw4jAy7yaqEPt6QipJlK7Z2kh6L19IKzgKMXGaLQDRZkw$>
> 



From jack at 3kitty.org  Tue Apr 22 13:45:25 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 22 Apr 2025 13:45:25 -0700
Subject: [ih] The First Atlantic CyberWar - was uucp
In-Reply-To: <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
Message-ID: <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>

Since there's a lot of UUCP memories still intact, I was just curious 
about a possible relationship between UUCP and some battles in the First 
Atlantic CyberWar (FACW).

Basically, my question is whether or not the UUCP implementers used 
similar tactics to manage their site's budget and expenses for dialup 
calls.?? Or were we the first?

What, you never heard of the FACW!?? Few people did; even the combatants 
might not have known.

Circa 1982 or so, we added the "VAN Gateway" to the Internet.? At the 
time, the transatlantic interconnection was provided by SATNET, which 
was restricted to use by projects of interest to ARPA.? They were paying 
the bills and satellite channels were expensive.

More people and projects in EU wanted to "get on the 'net" and 
collaborate with US counterparts.? But ARPA was reluctant to add more 
usage to the SATNET.? The VAN gateway was added to provide an alternate 
"second path" connecting the US to EU (specifically at UCL in London and 
from there probably to other countries).

The public X.25/X.75 network already existed and could provide 
connections "across the pond".? Rather expensive too, IIRC.? The "VAN 
Gateway" was created by simply adding to a gateway a driver for another 
kind of circuit - namely the virtual circuit provided by X.25.

This of course caused all sorts of confusion to all the people who were 
enamored of the 7-layer model of ISO.?? The entire public ISO X.25/X.75 
international network was treated as a link layer circuit in the ARPA 
Internet.? I gave up long ago on trying to stuff this into a 7-layer 
diagram and explain it.

I wasn't involved in the deal, but I think it involved adding a gateway 
at BBN that knew how to use the X.25 public network, as well as 
modifying another gateway at UCL, built by UCL, to have similar 
capabilities.? ARPA would pay for the US side, and UCL (or perhaps 
UKMOD?) would pay for the EU side.? The bulk of the ongoing costs were 
expected to be the charges from the public net connections. More use 
would mean more expense.

That configuration led to a discussion of "policy-based routing", in 
which traffic would flow over different paths depending on what policy 
dictated - e.g.,? traffic for some projects would go one way, while 
traffic for other projects went another.?? Even from the same host computer.

We didn't know how to do that, so "policy routing" went on the 
longer-term to-do list.? Meanwhile, a routing hack was implemented by 
assigning computers two IP addresses, even if they were connected to the 
same LAN.? A single Ethernet might have two different network numbers, 
and its computers have two very different IP addresses, with traffic 
taking different paths depending on the address the computer software 
decided to use as its Source Address.

That addressed the problem of unauthorized use of SATNET.? Still, there 
was concern about the X.25 costs.? Just like dialup phone calls, X.25 
calls were billed based on connection time.?? So there was a need for 
the gateways to shut down a connection if it had been idle for a while.? 
But there was no way in the IP protocol for a host to signal "I'm done" 
to the gateways to initiate a "hangup" of the X.25 connection.

X.25 connections were billed by something like a charge "per minute or 
fraction thereof".? So if there had been no traffic for a minute or so, 
it would make sense to shut down the X.25 connection.? Both sides of the 
Atlantic implemented that.? The next IP datagram crossing the Atlantic 
would reopen the connection so the disconnect would be invisible to the 
hosts and users.? TCP wouldn't care.

Still, we were concerned about the unpredictable and unbounded nature of 
the X.25 charges.? So we fired the first round in the FACW.

The US gateway was configured so that, instead of waiting for a minute 
of no traffic flow, it would shut down the connection immediately but 
only after it had to open a connection to send an IP datagram toward 
EU.?? The recipient TCP would likely respond to continue the TCP 
connection.? When that response datagram got to the EU gateway, it would 
open the connection to the US.? Subsequent traffic would that connection 
until eventually the connection became idle for a minute and was closed.

Result - the bulk of the charges for the international X.25 calls were 
billed to the EU side.? That followed the old management doctrine "The 
best way to control your expenses is to move them into someone else's 
budget."? We never saw the bills themselves so it's difficult to say how 
effective that was.? No one complained though. Probably no one noticed.

AFAIK, there never was a second round fired in the FACW.

Did UUCP sites play similar games with dialup?

Jack Haverty


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250422/577f19cc/attachment.asc>

From steve at shinkuro.com  Tue Apr 22 13:58:36 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 22 Apr 2025 16:58:36 -0400
Subject: [ih] A comment on the seven layer model
In-Reply-To: <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
Message-ID: <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>

Jack,

I liked your comment, "I gave up long ago on trying to stuff this into a
7-layer diagram and explain it."

I was part of the original group that designed the first set of host level
protocols for the Arpanet.  From the beginning we thought in terms of thin
layers that provided useful services, with the proviso that others would
build on, ignore and build around, or insert other layers in between as
needed

I turned my attention away from protocol design when I moved to (D)ARPA in
1971 and focused on AI and other topics.  When I re-engaged with the
network architecture and discovered OSI had determined there were
exactly seven layers, I nearly fell over laughing.

The seven layer model has been useful, but it is not complete or definitive.

Steve


From steve at shinkuro.com  Tue Apr 22 14:06:00 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 22 Apr 2025 17:06:00 -0400
Subject: [ih] Question re rate of growth of the Arpanet
In-Reply-To: <1b3e2e7b-231d-42ec-a279-a1ff07155151@tamu.edu>
References: <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <1b3e2e7b-231d-42ec-a279-a1ff07155151@tamu.edu>
Message-ID: <CABf5zvL4=4ph_A9urSVXdieZixoM=V5uLnNiscA5zQ2W65A4Fw@mail.gmail.com>

Guy,

See brief comments inline below.

Steve


On Tue, Apr 22, 2025 at 4:44?PM Guy Almes <galmes at tamu.edu> wrote:

> Steve, Geoff, et al.,
>    I actually find this a very interesting thread and a significant gap
> in (at least) my understanding of how the ARPAnet came to be.
>
>    Although I was an ARPAnet user (as a CMU CS grad student), I only
> became aware of how long-distance digital circuits were provided when
> active in the NSFnet regional networks beginning about 1986.  At that
> time, the key technical, regulatory, and business enablers of the needed
> digital services were:
> <> technical: the Bell System's DS0, T1, and eventually T3 services.
> The fact that these T1-based services were (more or less) mature by the
> early 1980s was key for us.
> <> regulatory: the breakup of the Bell System about 1984 resulted in
> several competing long-distance carriers, each supporting the T1-based
> services and interoperating with the sort-of-regulated monopoly LECs.
> <> business: though there's more to it, the essence is the demand for
> more long-distance telephony capacity.  Many of us remember how
> expensive long-distance was and the famous busy signals on Mother's Day.
>    This story is pretty well known in our community.
>    But we often forget how fortuitous it was that these two
> "prerequisites" were in place by the mid-80s.
>
>    But this thread makes me aware that the corresponding "prerequisites"
> for the ARPAnet are less well understood.
>    What I've found so far is this:
> <> technical: Western Electric had, by 1966, developed its 303 Type
> Wideband Data Station.  This technology used a "group" of 12 voice
> channels to provide a 50 kb/s service.  (It could also use a
> "supergroup" of 60 voice channels to provide 250 kb/s or a "half-group"
> of 6 voice channels to provide 19.2 kb/s service.)
> <> regulatory: Bell System monopoly, but with the government,
> particularly during the Cold War era, as an important special customer.
> <> business: here's where I'm weakest.  More in the next paragraph.  Why
> did the Bell System find it "good business" to develop these wideband
> services?
>    It occurred to me that I've "always known" that the ARPAnet used
> 50-kb/s leased lines based on some kind of "modem".
>    If, somehow, those Bell System 50-kb/s digital services had not been
> available, then would the ARPAnet been successful?
>

Interesting question, but I don't know enough to even speculate.  Larry
Roberts explored various options and was committed to building the Arpanet
before he became aware of the government rate for 50 kb/s lines, so I
imagine the Arpanet would have been build even if the 50 kb/s service was
not available.  But would it have been successful?  Too hard to tell.

>
>    So here are my hunches on the "business" part of the story:
> <> I don't think it was used in the SAGE system.  What I've seen so far
> about the technology of SAGE (which was deployed beginning 1959), it
> used 1200-b/s modems.
> <> I don't think it was used much by the TV industry.  This had been my
> hunch, and I allow that I might be wrong about this, but my impression
> is that the TV industry had their own technologies for using
> long-distance cables and microwaves.
> <> I think it might well have been used for NASA telemetry etc., but I
> don't have any specific evidence.
> <> I think it was used by the SABRE airline reservation system.
>

On reading the description of the 303 series modems, it seems clear to me
there was substantial use of wideband communication.  By whom and for what
I don't know.

>
>    But this is pretty sketchy.
>    I'd welcome input from others.
>    My key objective is to better understand why the long-distance
> telecommunications industry (in this case, the Bell System) had created
> this premium wideband digital service in the pre-T1 era such that, when
> the ARPAnet designers were doing their work, 50-kb/s long-distance
> service was available.
>
>    Thanks in advance to any additions or corrections,
>         -- Guy
>
> On 4/21/25 2:08 PM, the keyboard of geoff goodfellow via
> Internet-history wrote:
> > steve, can you elucidate any history with respect to how/why the speed of
> > 50 kb/s was chosen for the ARPANET lines?  were there great speeds
> > available then?
> >
> > yours truly kinda (perhaps mistakenly) recalls these 50 kb/s "wideband
> > circuits of the day" were primarily used for linking tv broadcast
> affiliate
> > stations to/with their motherships (cbs, nbc, abc, ...)?
> >
> > geoff
> >
> > On Mon, Apr 21, 2025 at 7:26?AM Steve Crocker via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >> Thanks for the pointer to RFC 597.
> >>
> >> As I looked at it, an aspect I hadn't considered before came to mind.
> >>
> >> Installation of an IMP required provisioning 50 kb/s lines to two or
> three
> >> other points.  In the early days, we installed roughly a new IMP once a
> >> month.  (The lead time for ordering 50 kb/s lines from AT&T was NINE
> >> months.)
> >>
> >> Once an IMP was installed, new hosts could be added to the IMP as
> quickly
> >> as the site could build or obtain the host-IMP interface and write or
> >> obtain the software for their operating system.
> >>
> >> If anyone has the dates for each of the hosts, it would be interesting
> to
> >> compare the growth of IMPs vs growth of hosts.
> >>
> >> Steve
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/
> > internet-history__;!!KwNVnqRv!
> >
> CvnEaxskHMjf5GDDAK0yK26KGlSUJU3NOkWGxNhpUZy2w019Knw4jAy7yaqEPt6QipJlK7Z2kh6L19IKzgKMXGaLQDRZkw$
> <
> https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!CvnEaxskHMjf5GDDAK0yK26KGlSUJU3NOkWGxNhpUZy2w019Knw4jAy7yaqEPt6QipJlK7Z2kh6L19IKzgKMXGaLQDRZkw$
> >
> >>
> >>
> >
> > --
> > Geoff.Goodfellow at iconia.com
> > living as The Truth is True
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/
> > internet-history__;!!KwNVnqRv!
> >
> CvnEaxskHMjf5GDDAK0yK26KGlSUJU3NOkWGxNhpUZy2w019Knw4jAy7yaqEPt6QipJlK7Z2kh6L19IKzgKMXGaLQDRZkw$
> <
> https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!CvnEaxskHMjf5GDDAK0yK26KGlSUJU3NOkWGxNhpUZy2w019Knw4jAy7yaqEPt6QipJlK7Z2kh6L19IKzgKMXGaLQDRZkw$
> >
> >
>
>

-- 
Sent by a Verified

sender


From clemc at ccc.com  Tue Apr 22 14:20:19 2025
From: clemc at ccc.com (Clem Cole)
Date: Tue, 22 Apr 2025 17:20:19 -0400
Subject: [ih] The First Atlantic CyberWar - was uucp
In-Reply-To: <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
Message-ID: <CAC20D2M64XVe7WKZb_0at8psU4Q9Ok5hs8HDqsBN5Aj=Xi0brw@mail.gmail.com>

Jack.
There were two basic issues with a UUCP site.

1.) who can I get a news feed from?
2.) How do I keep my phone bills low?

In the beginning, when netnews was small, it was easy to get someone to
give you a connection.  But before Rick came along, it used to be a hundred
megabytes a night, and it could be quite a burden, so whoever was your feed
was really a good friend.  It began to get challenging to find someone who
would give you everything. Since it's just me, I did not care that I had a
filtered list, so I stripped my feed back a bit, but it was still
substantial.

As for the phones. The sending of a message defined the route x!y!z
 you needed
to know the topology. There were paths published fairly regularly that we
sourced from the big forwarding sites.  This is why Rick's UUNET project
was so important.  Once we got used to making local phone calls to Telenet
services to connect with Rick, it was a real game-changer.  I was trying to
find my old UUNET file before I wrote the earlier message because it
contains some of the fees.  I could not find it quickly. If I can find it,
I'll follow up.  But it was a small consulting firm, and Rick started up
right about the time I went independent.  I had UUCP connections to MIT and
a few places in Cambridge, but at the time, calls to 508 and 617 were toll
calls, so I was careful about even those.

 My netnews feed was from Masscomp, which was in Westford. While I could
call decvax and ucbvax, and a few of the 'big sites' directly, I was
conscientious about that.  Because I was 'ccc' I had to put some early spam
filtering in so people that were trying experiments did not accidental
route through me [I had a problem with getting multi-meg core dumps from
Amdahl's corporate computer center for a while that would force a call my
system tie up one modem from something like decvax tying up there line and
mine -- fortunately Tony Lyons' was an old friend and helped me get them to
fix the issue they had].

IIRC, once I subscribed to UUNET, I severed any link to a long-distance
site and was forced to use Telenet, which I don't remember. The way it
worked is that Rick never called you.   He had a ton of space, and you
polled him.  If you didn't get a netnews feed, polling him once or twice a
day via email was quick and reasonable.

Clem
?


From jack at 3kitty.org  Tue Apr 22 14:25:11 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 22 Apr 2025 14:25:11 -0700
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <c896238b-e2b2-42d4-9e5a-9221e097ec7b@iwl.com>
References: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
 <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
 <FA359D10-4A45-4404-8EA2-97F542F50946@strayalpha.com>
 <c896238b-e2b2-42d4-9e5a-9221e097ec7b@iwl.com>
Message-ID: <302e6a91-f1f0-49c8-b325-ebfb2ff610a9@3kitty.org>

Hi Karl,

That TCP-over-TCP architecture from such projects was probably the 
inspiration for the Internet-over-X.25World that I just described in 
another post.?? I remember occasionally running into DaveK at various 
meetings.

TCP was probably unique in its design to take anything, even a different 
"internet", or avian network or anything that could deliver bits from 
point A to B despite the presence of marauding hawks, and use it as a 
component piece of "The Internet".

There's some discussion of those projects in these 1983 documents:

https://apps.dtic.mil/sti/tr/pdf/ADA152524.pdf
https://apps.dtic.mil/sti/tr/pdf/ADA162888.pdf

These are publicly available now, so it seems it must be OK.?? They 
describe how the US DoD was dealing with security and privacy concerns 
in 1983 that were important in military situations. Contrary to some 
posts I've seen, there was a lot of work and thinking about security.

I've often wondered about that part of the Internet History - especially 
how things progressed from those 1983 plans for the Defense Data Network 
to today's use of smartphones and Signal.? But you probably can't say 
much about it....

Jack

On 4/22/25 13:17, Karl Auerbach via Internet-history wrote:
> In the mid 1970's our group (Dave Kaufman, Frank Heinrich, etc, and 
> myself, under the management of Gerry Cole and Clark Weissman) at SDC 
> (System Development Corporation) worked on a then classified project. 
> (We worked with various US based agencies and a bit with RSRE in the 
> UK - where I had the privilege of getting to do some work with Donald 
> Davies.)
>
> We didn't do NAT in the sense of doing address translation. Rather we 
> created an entire overlay network with its own IP address space.? 
> (This was done in the very early days of TCP - before the formal 
> development of IP, although we arrived at the same conclusion as 
> others, that there ought to be some sort of formalized datagram layer 
> underneath TCP - we used that notion of an underlying layer as a way 
> to insert our security system.? What was strange to today's eyes was 
> that we used an underlying TCP based network as our datagram layer, so 
> we effectively ended up with TCP over TCP.)
>
> Our architecture included what we would today call a "tunnel". 
> (Actually, many encrypted tunnels, each with its own security level, 
> plus a key management system.)
>
> We actually built it, it worked, and I heard that it was put into 
> actual worldwide production.? (My group did most of the security 
> kernel design/implementation, David, and if I remember correctly, 
> along with Carl Sunshine, did more of the protocol design, and Frank, 
> David, and I collaborated on the key management and access control 
> system.? Security policy and software verification was done by Marv 
> Schaeffer, Hillary O., Val Schorre, Tom Hinke, John Schied - I am sure 
> I misspelled several of those names.)
>
> I've chatted with Dave Kaufman about this and we both are quite 
> unclear whether, even today, fifty years later, we can say much about 
> what we designed and implemented.
>
> (On a personal basis, my mind wonders how I managed to do all of this 
> while at the same time attending law school.)
>
> ????--karl--
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250422/08d9ebb1/attachment.asc>

From craig at tereschau.net  Tue Apr 22 15:05:08 2025
From: craig at tereschau.net (Craig Partridge)
Date: Tue, 22 Apr 2025 16:05:08 -0600
Subject: [ih] The First Atlantic CyberWar - was uucp
In-Reply-To: <CAC20D2M64XVe7WKZb_0at8psU4Q9Ok5hs8HDqsBN5Aj=Xi0brw@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CAC20D2M64XVe7WKZb_0at8psU4Q9Ok5hs8HDqsBN5Aj=Xi0brw@mail.gmail.com>
Message-ID: <CAHQj4CdC1QhdA1Vfn5aopFqD=05J3LyEToWrm5geeCavW3Wwjg@mail.gmail.com>

On Tue, Apr 22, 2025 at 3:21?PM Clem Cole via Internet-history <
internet-history at elists.isoc.org> wrote:

>
> IIRC, once I subscribed to UUNET, I severed any link to a long-distance
> site and was forced to use Telenet, which I don't remember. The way it
> worked is that Rick never called you.   He had a ton of space, and you
> polled him.  If you didn't get a netnews feed, polling him once or twice a
> day via email was quick and reasonable.
>
>
Just a footnote here, this situation was not true for CSNET/UUNET.

Larger story: both CSNET and SEISMO/UUNET (Rick's unit) did most of their
email transfers after 5pm their local time (due to
the aforementioned calling tariffs, which dropped sharply after 5pm).  A
couple of hours after that, CSNET
and SEISMO would start to hammer the ARPANET (go back and look at the
ARPANET stats and my recollection is
you'll see their ports were typically in the top 3, with SRI-NIC being the
third) relaying emails between each other.

If either end had a hiccough, it usually meant a phone call at 1am (at
least at the CSNET end, from the BBN computer
center admins) indicating that disks were about to fill/overflow.
Sometimes things would not clear by morning and I
remember occasional chats with Rick about making sure our respective queues
were tidied up before the next
evening's rush.  (Part of the dynamic here was that CSNET made two calls to
each site every night -- the first delivery the
day's ARPANET email and pick up the site's email.  The second to deliver
all emails we'd received from other sites on
CSNET plus UUNET email.  And on busy days, we narrowly finished up those
calls before tariffs went up.  So there was
a certain amount of managing queues to try to ensure the next night would
go well).

Craig (former CSNET techie)


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.


From jack at 3kitty.org  Tue Apr 22 15:08:50 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 22 Apr 2025 15:08:50 -0700
Subject: [ih] A comment on the seven layer model
In-Reply-To: <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
Message-ID: <967634e2-b4c1-44db-9d2f-b094ef5e48cf@3kitty.org>

On 4/22/25 13:58, Steve Crocker wrote:
> Jack,
>
> I liked your comment, "I gave up long ago on trying to stuff this into 
> a 7-layer diagram and explain it."
>
> I was part of the original group that designed the first set of host 
> level protocols for the Arpanet.? From the beginning we thought in 
> terms of thin layers that provided useful services, with the proviso 
> that others would build on, ignore and build around, or insert other 
> layers in between as needed
>
> I turned my attention away from protocol design when I moved to 
> (D)ARPA in 1971 and focused on AI and other topics. When I re-engaged 
> with the network architecture and discovered OSI had determined?there 
> were exactly?seven layers, I nearly fell over laughing.
>
> The seven layer model has been useful, but it is not complete or 
> definitive.
>
> Steve
>

My first encounter with Networking was when I became one of Lick's 
thesis students, and got thoroughly indoctrinated into his 
"Intergalactic Network" vision. ? Later he was my boss as we worked to 
implement some of his vision with not enough computer or networking 
power.?? Computers would be somehow connected through networks, every 
user would have their own "personal computer", and those computers would 
interact to help humans do whatever humans do, only occasionally 
actually interacting with the human through some kind of UI.

That picture doesn't fit into the 7-layer model, which was derived from 
the world of telephony and "calls".? It only addressed what was 
happening during the times when the human was interacting with some 
single computer to use some program.? The notions of Presentation or 
Session is a clue to its intermittent and human-centric nature.? I think 
the 7-layer model actually slowed down progress towards the new way of 
Lick's vision.? Maybe still does.?? Not just incomplete, but also 
obstructionist.

Lick's vision was much more that the computers would all be mostly 
talking to each other.?? I found it interesting to read recently that 
someone connected two AIs to each other, and they developed their own 
language to better communicate amongst themselves.

I think Lick would like today's Internet, which seems to me pretty close 
to his vision, but he'd also see the problems that still need to be 
addressed.

Jack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250422/a2b134b9/attachment.asc>

From johnl at iecc.com  Tue Apr 22 15:15:08 2025
From: johnl at iecc.com (John Levine)
Date: 22 Apr 2025 18:15:08 -0400
Subject: [ih] The First Atlantic CyberWar - was uucp
In-Reply-To: <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
References: <401cbe00edefdb0f@orthanc.ca>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRd
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
Message-ID: <20250422221508.EF3E7C5B3F38@ary.qy>

It appears that Jack Haverty via Internet-history <jack at 3kitty.org> said:
>Did UUCP sites play similar games with dialup?

Not that I recall.  The uucp world was very informal and collaborative
and if someone was playing silly buggers like that, few people would want
to talk to them.

Also remember that uucp was store and forward. There'd be a queue of files to
transfer at each end and the calls were typically made either on demand if they
were local free calls or scheduled for late in the day when rates were low.

The local calling areas were usually symmetrical so it didn't matter which end
called, but even so it was common for links to be set up so one end always made
the calls.

R's,
John




From johnl at iecc.com  Tue Apr 22 15:17:19 2025
From: johnl at iecc.com (John Levine)
Date: 22 Apr 2025 18:17:19 -0400
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <9967cfff-4ea4-417d-92a0-b6b3830bf73b@gih.com>
References: <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4 <9967cfff-4ea4-417d-92a0-b6b3830bf73b@gih.com>
Message-ID: <20250422221720.6CBD3C5B3FB1@ary.qy>

It appears that Olivier MJ Cr?pin-Leblond via Internet-history <ocl at gih.com> said:
>
>
>On 22/04/2025 20:41, Johan Helsingius via Internet-history wrote:
>> Then there was "UUCP over floppy disks". ...

>Ah - an illustrious example of a Sneakernet.
>https://en.wikipedia.org/wiki/Sneakernet

I heard from a credible source that the NSA got a usenet feed on mag tapes.

R's,
John


From vint at google.com  Tue Apr 22 15:18:01 2025
From: vint at google.com (Vint Cerf)
Date: Tue, 22 Apr 2025 18:18:01 -0400
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <c896238b-e2b2-42d4-9e5a-9221e097ec7b@iwl.com>
References: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
 <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
 <FA359D10-4A45-4404-8EA2-97F542F50946@strayalpha.com>
 <c896238b-e2b2-42d4-9e5a-9221e097ec7b@iwl.com>
Message-ID: <CAHxHggc3=EG4-jBMr5g8ELZG8E0FjqDoGTuMEnxpzKrAkFRoeQ@mail.gmail.com>

The BCR project (DARPA/NSA) used TCP embedded in an encrypted TCP layer not
unlike what Karl is describing. Later, IPSEC could be used to carry
encrypted TCP as payload.

On the Arpanet, SRI built a "port expander" which allowed up to 4 hosts to
be connected through what would otherwise have been a single port for a
host - using some extra bits in the TCP header. Documented at DTIC
<https://apps.dtic.mil/sti/tr/pdf/ADA156186.pdf#:~:text=ARPANET%2C%20substitution%20of%20a%20connection%20by%20means%20of%20the%20port%20expander%20in&text=This%20allows%20one.%20NCP%2Dbased%20host%20and%20several%20TCP%2Dbased%20hosts%20to%20be>

Not a NAT, but a way of expanding Arpanet IMP address space using bits in
the TCP/IP header.

v


On Tue, Apr 22, 2025 at 4:17?PM Karl Auerbach via Internet-history <
internet-history at elists.isoc.org> wrote:

> In the mid 1970's our group (Dave Kaufman, Frank Heinrich, etc, and
> myself, under the management of Gerry Cole and Clark Weissman) at SDC
> (System Development Corporation) worked on a then classified project.
> (We worked with various US based agencies and a bit with RSRE in the UK
> - where I had the privilege of getting to do some work with Donald Davies.)
>
> We didn't do NAT in the sense of doing address translation.  Rather we
> created an entire overlay network with its own IP address space.  (This
> was done in the very early days of TCP - before the formal development
> of IP, although we arrived at the same conclusion as others, that there
> ought to be some sort of formalized datagram layer underneath TCP - we
> used that notion of an underlying layer as a way to insert our security
> system.  What was strange to today's eyes was that we used an underlying
> TCP based network as our datagram layer, so we effectively ended up with
> TCP over TCP.)
>
> Our architecture included what we would today call a "tunnel".
> (Actually, many encrypted tunnels, each with its own security level,
> plus a key management system.)
>
> We actually built it, it worked, and I heard that it was put into actual
> worldwide production.  (My group did most of the security kernel
> design/implementation, David, and if I remember correctly, along with
> Carl Sunshine, did more of the protocol design, and Frank, David, and I
> collaborated on the key management and access control system.  Security
> policy and software verification was done by Marv Schaeffer, Hillary O.,
> Val Schorre, Tom Hinke, John Schied - I am sure I misspelled several of
> those names.)
>
> I've chatted with Dave Kaufman about this and we both are quite unclear
> whether, even today, fifty years later, we can say much about what we
> designed and implemented.
>
> (On a personal basis, my mind wonders how I managed to do all of this
> while at the same time attending law school.)
>
>         --karl--
>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


From geoff at iconia.com  Tue Apr 22 15:26:30 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 22 Apr 2025 15:26:30 -0700
Subject: [ih] A comment on the seven layer model
In-Reply-To: <967634e2-b4c1-44db-9d2f-b094ef5e48cf@3kitty.org>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
 <967634e2-b4c1-44db-9d2f-b094ef5e48cf@3kitty.org>
Message-ID: <CAEf-zrhrwhGqFCSck-RE-fPu6UeKKmGeRu6z6HbWAEBwczxqnA@mail.gmail.com>

OH MY, vis-a-vis:

"Lick's vision was much more that the computers would all be mostly
talking to each other.   I found it interesting to read recently that
someone connected two AIs to each other, and they developed their own
language to better communicate amongst themselves."

that's a scene right out of "Colossus: The Forbin Project (1970)"
https://www.imdb.com/title/tt0064177/
(or maybe "Colossus: The Forbin Project (1970)" is right out of Lick's
vision?)

g

On Tue, Apr 22, 2025 at 3:09?PM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:

> On 4/22/25 13:58, Steve Crocker wrote:
> > Jack,
> >
> > I liked your comment, "I gave up long ago on trying to stuff this into
> > a 7-layer diagram and explain it."
> >
> > I was part of the original group that designed the first set of host
> > level protocols for the Arpanet.  From the beginning we thought in
> > terms of thin layers that provided useful services, with the proviso
> > that others would build on, ignore and build around, or insert other
> > layers in between as needed
> >
> > I turned my attention away from protocol design when I moved to
> > (D)ARPA in 1971 and focused on AI and other topics. When I re-engaged
> > with the network architecture and discovered OSI had determined there
> > were exactly seven layers, I nearly fell over laughing.
> >
> > The seven layer model has been useful, but it is not complete or
> > definitive.
> >
> > Steve
> >
>
> My first encounter with Networking was when I became one of Lick's
> thesis students, and got thoroughly indoctrinated into his
> "Intergalactic Network" vision.   Later he was my boss as we worked to
> implement some of his vision with not enough computer or networking
> power.   Computers would be somehow connected through networks, every
> user would have their own "personal computer", and those computers would
> interact to help humans do whatever humans do, only occasionally
> actually interacting with the human through some kind of UI.
>
> That picture doesn't fit into the 7-layer model, which was derived from
> the world of telephony and "calls".  It only addressed what was
> happening during the times when the human was interacting with some
> single computer to use some program.  The notions of Presentation or
> Session is a clue to its intermittent and human-centric nature.  I think
> the 7-layer model actually slowed down progress towards the new way of
> Lick's vision.  Maybe still does.   Not just incomplete, but also
> obstructionist.
>
> Lick's vision was much more that the computers would all be mostly
> talking to each other.   I found it interesting to read recently that
> someone connected two AIs to each other, and they developed their own
> language to better communicate amongst themselves.
>
> I think Lick would like today's Internet, which seems to me pretty close
> to his vision, but he'd also see the problems that still need to be
> addressed.
>
> Jack
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From jack at 3kitty.org  Tue Apr 22 15:35:10 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 22 Apr 2025 15:35:10 -0700
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <20250422221720.6CBD3C5B3FB1@ary.qy>
References: <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4 <9967cfff-4ea4-417d-92a0-b6b3830bf73b@gih.com>
 <20250422221720.6CBD3C5B3FB1@ary.qy>
Message-ID: <e8cb1a4f-1b78-40b9-bb9b-75919341a547@3kitty.org>

I recall once in the 1980s being in a meeting planning a new site to be 
added to the Defense Data Network.? We were debating what speed of 
circuit would be appropriate for the expected traffic.? Someone 
commented something like "Well, the data we're transferring will have 
just come over the mountains on the back of a mule, so a few extra 
minutes over the network won't matter."

Made "avian networking" more realistic.? Better than "mule networking"?? 
Probably more dropped datagrams though with avian. Sneakernet (even with 
mules) was part of The Internet to get bits from point A to B.

Jack

On 4/22/25 15:17, John Levine via Internet-history wrote:
> It appears that Olivier MJ Cr?pin-Leblond via Internet-history<ocl at gih.com>  said:
>>
>> On 22/04/2025 20:41, Johan Helsingius via Internet-history wrote:
>>> Then there was "UUCP over floppy disks". ...
>> Ah - an illustrious example of a Sneakernet.
>> https://en.wikipedia.org/wiki/Sneakernet
> I heard from a credible source that the NSA got a usenet feed on mag tapes.
>
> R's,
> John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250422/57bbafc7/attachment.asc>

From vint at google.com  Tue Apr 22 15:35:04 2025
From: vint at google.com (Vint Cerf)
Date: Tue, 22 Apr 2025 18:35:04 -0400
Subject: [ih] A comment on the seven layer model
In-Reply-To: <CAEf-zrhrwhGqFCSck-RE-fPu6UeKKmGeRu6z6HbWAEBwczxqnA@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
 <967634e2-b4c1-44db-9d2f-b094ef5e48cf@3kitty.org>
 <CAEf-zrhrwhGqFCSck-RE-fPu6UeKKmGeRu6z6HbWAEBwczxqnA@mail.gmail.com>
Message-ID: <CAHxHggeBfmOyeJs+gMVW8O-Z1kbyuaFm4xcMBQ_wNLU0+itn9w@mail.gmail.com>

John McCarthy was heard to say that someday someone would say that "100
years ago they had books that did not talk to each other...."

v


On Tue, Apr 22, 2025 at 6:27?PM the keyboard of geoff goodfellow via
Internet-history <internet-history at elists.isoc.org> wrote:

> OH MY, vis-a-vis:
>
> "Lick's vision was much more that the computers would all be mostly
> talking to each other.   I found it interesting to read recently that
> someone connected two AIs to each other, and they developed their own
> language to better communicate amongst themselves."
>
> that's a scene right out of "Colossus: The Forbin Project (1970)"
> https://www.imdb.com/title/tt0064177/
> (or maybe "Colossus: The Forbin Project (1970)" is right out of Lick's
> vision?)
>
> g
>
> On Tue, Apr 22, 2025 at 3:09?PM Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > On 4/22/25 13:58, Steve Crocker wrote:
> > > Jack,
> > >
> > > I liked your comment, "I gave up long ago on trying to stuff this into
> > > a 7-layer diagram and explain it."
> > >
> > > I was part of the original group that designed the first set of host
> > > level protocols for the Arpanet.  From the beginning we thought in
> > > terms of thin layers that provided useful services, with the proviso
> > > that others would build on, ignore and build around, or insert other
> > > layers in between as needed
> > >
> > > I turned my attention away from protocol design when I moved to
> > > (D)ARPA in 1971 and focused on AI and other topics. When I re-engaged
> > > with the network architecture and discovered OSI had determined there
> > > were exactly seven layers, I nearly fell over laughing.
> > >
> > > The seven layer model has been useful, but it is not complete or
> > > definitive.
> > >
> > > Steve
> > >
> >
> > My first encounter with Networking was when I became one of Lick's
> > thesis students, and got thoroughly indoctrinated into his
> > "Intergalactic Network" vision.   Later he was my boss as we worked to
> > implement some of his vision with not enough computer or networking
> > power.   Computers would be somehow connected through networks, every
> > user would have their own "personal computer", and those computers would
> > interact to help humans do whatever humans do, only occasionally
> > actually interacting with the human through some kind of UI.
> >
> > That picture doesn't fit into the 7-layer model, which was derived from
> > the world of telephony and "calls".  It only addressed what was
> > happening during the times when the human was interacting with some
> > single computer to use some program.  The notions of Presentation or
> > Session is a clue to its intermittent and human-centric nature.  I think
> > the 7-layer model actually slowed down progress towards the new way of
> > Lick's vision.  Maybe still does.   Not just incomplete, but also
> > obstructionist.
> >
> > Lick's vision was much more that the computers would all be mostly
> > talking to each other.   I found it interesting to read recently that
> > someone connected two AIs to each other, and they developed their own
> > language to better communicate amongst themselves.
> >
> > I think Lick would like today's Internet, which seems to me pretty close
> > to his vision, but he'd also see the problems that still need to be
> > addressed.
> >
> > Jack
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
>
>
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


From clemc at ccc.com  Tue Apr 22 16:19:02 2025
From: clemc at ccc.com (Clem Cole)
Date: Tue, 22 Apr 2025 19:19:02 -0400
Subject: [ih] The First Atlantic CyberWar - was uucp
In-Reply-To: <CAHQj4CdC1QhdA1Vfn5aopFqD=05J3LyEToWrm5geeCavW3Wwjg@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CAC20D2M64XVe7WKZb_0at8psU4Q9Ok5hs8HDqsBN5Aj=Xi0brw@mail.gmail.com>
 <CAHQj4CdC1QhdA1Vfn5aopFqD=05J3LyEToWrm5geeCavW3Wwjg@mail.gmail.com>
Message-ID: <CAC20D2OOYtR12KGm1Z=BqO_FnwsUmjoYgNZENrYGsmrTPv22+w@mail.gmail.com>

That makes sense.

Sent from a handheld expect more typos than usual


On Tue, Apr 22, 2025 at 6:05?PM Craig Partridge <craig at tereschau.net> wrote:

>
>
> On Tue, Apr 22, 2025 at 3:21?PM Clem Cole via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>>
>> IIRC, once I subscribed to UUNET, I severed any link to a long-distance
>> site and was forced to use Telenet, which I don't remember. The way it
>> worked is that Rick never called you.   He had a ton of space, and you
>> polled him.  If you didn't get a netnews feed, polling him once or twice a
>> day via email was quick and reasonable.
>>
>>
> Just a footnote here, this situation was not true for CSNET/UUNET.
>
> Larger story: both CSNET and SEISMO/UUNET (Rick's unit) did most of their
> email transfers after 5pm their local time (due to
> the aforementioned calling tariffs, which dropped sharply after 5pm).  A
> couple of hours after that, CSNET
> and SEISMO would start to hammer the ARPANET (go back and look at the
> ARPANET stats and my recollection is
> you'll see their ports were typically in the top 3, with SRI-NIC being the
> third) relaying emails between each other.
>
> If either end had a hiccough, it usually meant a phone call at 1am (at
> least at the CSNET end, from the BBN computer
> center admins) indicating that disks were about to fill/overflow.
> Sometimes things would not clear by morning and I
> remember occasional chats with Rick about making sure our respective
> queues were tidied up before the next
> evening's rush.  (Part of the dynamic here was that CSNET made two calls
> to each site every night -- the first delivery the
> day's ARPANET email and pick up the site's email.  The second to deliver
> all emails we'd received from other sites on
> CSNET plus UUNET email.  And on busy days, we narrowly finished up those
> calls before tariffs went up.  So there was
> a certain amount of managing queues to try to ensure the next night would
> go well).
>
> Craig (former CSNET techie)
>
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
>


From jack at 3kitty.org  Tue Apr 22 16:52:05 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 22 Apr 2025 16:52:05 -0700
Subject: [ih] A comment on the seven layer model
In-Reply-To: <CAEf-zrhrwhGqFCSck-RE-fPu6UeKKmGeRu6z6HbWAEBwczxqnA@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
 <967634e2-b4c1-44db-9d2f-b094ef5e48cf@3kitty.org>
 <CAEf-zrhrwhGqFCSck-RE-fPu6UeKKmGeRu6z6HbWAEBwczxqnA@mail.gmail.com>
Message-ID: <ed91204f-7f32-454a-825a-3f9ad0928dd3@3kitty.org>

Yes, could be.? Lick's intergalactic paper was distributed in 1963 or 
so, so it might have influenced a 1970 movie.? Such sci-fi, in movies 
but especially books, provided inspirations for the hackers building 
computer stuff.? We all read scifi.? The "matrix" network in Neuromancer 
(1984ish) was especially relevant for the ARPANET and Internet.

Star Trek - the original TV series in the 60s - was another source of 
ideas.? Sometimes we could see some tech in Star Trek and think "maybe 
we could actually build that".? Laser weapons are one example just 
recently becoming reality.?? AI is another, where the computer 
understands spoken English (as well as Klingon et al of course).

Curiously, even in the far future of Star Trek, computers weren't all 
powerful.? Some tasks took a while.? But the computer would work at it 
while the humans did something else -- just like Lick's vision.

Jack

On 4/22/25 15:26, the keyboard of geoff goodfellow wrote:
> OH MY, vis-a-vis:
>
>     "Lick's vision was much more that the computers would all be mostly
>     talking to each other.? ?I found it interesting to read recently that
>     someone connected two AIs to each other, and they developed their own
>     language to better communicate amongst themselves."
>
> that's a scene right out of "Colossus: The Forbin Project (1970)"
> https://www.imdb.com/title/tt0064177/
> (or maybe "Colossus: The Forbin Project (1970)" is right out of Lick's 
> vision?)
>
> g
>
> On Tue, Apr 22, 2025 at 3:09?PM Jack Haverty via Internet-history 
> <internet-history at elists.isoc.org> wrote:
>
>     On 4/22/25 13:58, Steve Crocker wrote:
>     > Jack,
>     >
>     > I liked your comment, "I gave up long ago on trying to stuff
>     this into
>     > a 7-layer diagram and explain it."
>     >
>     > I was part of the original group that designed the first set of
>     host
>     > level protocols for the Arpanet.? From the beginning we thought in
>     > terms of thin layers that provided useful services, with the
>     proviso
>     > that others would build on, ignore and build around, or insert
>     other
>     > layers in between as needed
>     >
>     > I turned my attention away from protocol design when I moved to
>     > (D)ARPA in 1971 and focused on AI and other topics. When I
>     re-engaged
>     > with the network architecture and discovered OSI had
>     determined?there
>     > were exactly?seven layers, I nearly fell over laughing.
>     >
>     > The seven layer model has been useful, but it is not complete or
>     > definitive.
>     >
>     > Steve
>     >
>
>     My first encounter with Networking was when I became one of Lick's
>     thesis students, and got thoroughly indoctrinated into his
>     "Intergalactic Network" vision. ? Later he was my boss as we
>     worked to
>     implement some of his vision with not enough computer or networking
>     power.?? Computers would be somehow connected through networks, every
>     user would have their own "personal computer", and those computers
>     would
>     interact to help humans do whatever humans do, only occasionally
>     actually interacting with the human through some kind of UI.
>
>     That picture doesn't fit into the 7-layer model, which was derived
>     from
>     the world of telephony and "calls".? It only addressed what was
>     happening during the times when the human was interacting with some
>     single computer to use some program.? The notions of Presentation or
>     Session is a clue to its intermittent and human-centric nature.? I
>     think
>     the 7-layer model actually slowed down progress towards the new
>     way of
>     Lick's vision.? Maybe still does.?? Not just incomplete, but also
>     obstructionist.
>
>     Lick's vision was much more that the computers would all be mostly
>     talking to each other.?? I found it interesting to read recently that
>     someone connected two AIs to each other, and they developed their own
>     language to better communicate amongst themselves.
>
>     I think Lick would like today's Internet, which seems to me pretty
>     close
>     to his vision, but he'd also see the problems that still need to be
>     addressed.
>
>     Jack
>     -- 
>     Internet-history mailing list
>     Internet-history at elists.isoc.org
>     https://elists.isoc.org/mailman/listinfo/internet-history
>
>
>
> -- 
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250422/2fd8a088/attachment.asc>

From lyndon at orthanc.ca  Tue Apr 22 17:09:47 2025
From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM))
Date: Tue, 22 Apr 2025 17:09:47 -0700
Subject: [ih] The First Atlantic CyberWar - was uucp
In-Reply-To: <CAC20D2M64XVe7WKZb_0at8psU4Q9Ok5hs8HDqsBN5Aj=Xi0brw@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CAC20D2M64XVe7WKZb_0at8psU4Q9Ok5hs8HDqsBN5Aj=Xi0brw@mail.gmail.com>
Message-ID: <401cbf08e0f8fde3@orthanc.ca>

> In the beginning, when netnews was small, it was easy to get someone
> to give you a connection.  But before Rick came along, it used to
> be a hundred megabytes a night, and it could be quite a burden, so
> whoever was your feed was really a good friend.  It began to get
> challenging to find someone who would give you everything. Since
> it's just me, I did not care that I had a filtered list, so I
> stripped my feed back a bit, but it was still substantial.

Traffic volumes didn't get that high until the 90s, and by then
NNTP was taking over.  I remember when Usenet hit 5 MB/day, some
time around 1987.  In 1988, when I left Nexus (ncc) for Athabasca
Univrsity, ncc was providing full feeds to at least a dozen sites
with no modem bandwidth issues.  In fact, my biggest traffic
concern wasn't Usenet, it was the ftpmail service at decwrl!  Our
local UUCP neighbours used to regularly gum up the UUCP queues
as they tried to download the entire internet via UUCP mail :-)

--lyndon


From geoff at iconia.com  Tue Apr 22 17:10:20 2025
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 22 Apr 2025 17:10:20 -0700
Subject: [ih] A comment on the seven layer model
In-Reply-To: <ed91204f-7f32-454a-825a-3f9ad0928dd3@3kitty.org>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
 <967634e2-b4c1-44db-9d2f-b094ef5e48cf@3kitty.org>
 <CAEf-zrhrwhGqFCSck-RE-fPu6UeKKmGeRu6z6HbWAEBwczxqnA@mail.gmail.com>
 <ed91204f-7f32-454a-825a-3f9ad0928dd3@3kitty.org>
Message-ID: <CAEf-zrgefd0nhrDrJhc--DQODWtXaPVHwa09zC6MoY1aVgOSaw@mail.gmail.com>

indeed, but let's also not forget The HAL 9000 in Kubrick's
"2001: A Space Odyssey (1968)"
https://www.imdb.com/title/tt0062622/
for whom yours truly has been hoping that Apple's AI SIRI
or Elon's evolving Grok will "implement" the personality of
along with the voice of the late Douglas Rain... :)
https://en.wikipedia.org/wiki/Douglas_Rain

wouldn't that be "something"?

but then again what with the 2 different AI's having recently
developed their own language to better communicate amongst
themselves like Colossus & Guardian did in The Forbin Project a
future AI will just do that all on its own or directly up user request...

g


On Tue, Apr 22, 2025 at 4:52?PM Jack Haverty <jack at 3kitty.org> wrote:

> Yes, could be.  Lick's intergalactic paper was distributed in 1963 or so,
> so it might have influenced a 1970 movie.  Such sci-fi, in movies but
> especially books, provided inspirations for the hackers building computer
> stuff.  We all read scifi.  The "matrix" network in Neuromancer (1984ish)
> was especially relevant for the ARPANET and Internet.
>
> Star Trek - the original TV series in the 60s - was another source of
> ideas.  Sometimes we could see some tech in Star Trek and think "maybe we
> could actually build that".  Laser weapons are one example just recently
> becoming reality.   AI is another, where the computer understands spoken
> English (as well as Klingon et al of course).
>
> Curiously, even in the far future of Star Trek, computers weren't all
> powerful.  Some tasks took a while.  But the computer would work at it
> while the humans did something else -- just like Lick's vision.
>
> Jack
>
> On 4/22/25 15:26, the keyboard of geoff goodfellow wrote:
>
> OH MY, vis-a-vis:
>
> "Lick's vision was much more that the computers would all be mostly
> talking to each other.   I found it interesting to read recently that
> someone connected two AIs to each other, and they developed their own
> language to better communicate amongst themselves."
>
> that's a scene right out of "Colossus: The Forbin Project (1970)"
> https://www.imdb.com/title/tt0064177/
> (or maybe "Colossus: The Forbin Project (1970)" is right out of Lick's
> vision?)
>
> g
>
> On Tue, Apr 22, 2025 at 3:09?PM Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> On 4/22/25 13:58, Steve Crocker wrote:
>> > Jack,
>> >
>> > I liked your comment, "I gave up long ago on trying to stuff this into
>> > a 7-layer diagram and explain it."
>> >
>> > I was part of the original group that designed the first set of host
>> > level protocols for the Arpanet.  From the beginning we thought in
>> > terms of thin layers that provided useful services, with the proviso
>> > that others would build on, ignore and build around, or insert other
>> > layers in between as needed
>> >
>> > I turned my attention away from protocol design when I moved to
>> > (D)ARPA in 1971 and focused on AI and other topics. When I re-engaged
>> > with the network architecture and discovered OSI had determined there
>> > were exactly seven layers, I nearly fell over laughing.
>> >
>> > The seven layer model has been useful, but it is not complete or
>> > definitive.
>> >
>> > Steve
>> >
>>
>> My first encounter with Networking was when I became one of Lick's
>> thesis students, and got thoroughly indoctrinated into his
>> "Intergalactic Network" vision.   Later he was my boss as we worked to
>> implement some of his vision with not enough computer or networking
>> power.   Computers would be somehow connected through networks, every
>> user would have their own "personal computer", and those computers would
>> interact to help humans do whatever humans do, only occasionally
>> actually interacting with the human through some kind of UI.
>>
>> That picture doesn't fit into the 7-layer model, which was derived from
>> the world of telephony and "calls".  It only addressed what was
>> happening during the times when the human was interacting with some
>> single computer to use some program.  The notions of Presentation or
>> Session is a clue to its intermittent and human-centric nature.  I think
>> the 7-layer model actually slowed down progress towards the new way of
>> Lick's vision.  Maybe still does.   Not just incomplete, but also
>> obstructionist.
>>
>> Lick's vision was much more that the computers would all be mostly
>> talking to each other.   I found it interesting to read recently that
>> someone connected two AIs to each other, and they developed their own
>> language to better communicate amongst themselves.
>>
>> I think Lick would like today's Internet, which seems to me pretty close
>> to his vision, but he'd also see the problems that still need to be
>> addressed.
>>
>> Jack
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>
>
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
>
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True


From gnu at toad.com  Tue Apr 22 17:26:18 2025
From: gnu at toad.com (John Gilmore)
Date: Tue, 22 Apr 2025 17:26:18 -0700
Subject: [ih] Packet Radio Notes
In-Reply-To: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com> 
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
Message-ID: <29545.1745367978@hop.toad.com>

Alexander McKenzie via Internet-history wrote:
> I must apologize for a serious misstatement.  I now realize it was not
> IEN's which were strictly controlled, it was Packet Radio Notes.

Surely the need for strict control of the 1970s Packet Radio Notes has
passed by now.  Is there a full archive of them publicly accessible
somewhere?

Is there a list somewhere of all the issued Packet Radio Notes?
Which could perhaps be used to anchor searches for all of them?

ARDC.net and the Internet Archive are collecting a Digital Library of
Amateur Radio and Communications, which would probably be happy to host
this collection.  See:

  https://blog.archive.org/tag/dlarc/

A web search for "Packet Radio Note" turned up exactly one reference,
which is hidden inside ACM's "digital crypt" where papers check in and
never check out:

  https://dl.acm.org/doi/pdf/10.1145/1499949.1499988

  Technological considerations for packet radio networks
  Authors: Stanley C. Fralick, James C. Garrett
  AFIPS '75: Proceedings of the May 19-22, 1975, national computer conference and exposition
  Pages 233 - 243
  https://doi.org/10.1145/1499949.1499988
  Published: 19 May 1975 

  Abstract: The application of packet-switching techniques to radio
  channels has provided a solution to many computer-communications
  problems previously unsolved. For example, a packet radio network can
  readily be designed to provide area coverage at data rates fast enough
  to support interactive operations for thousands of users having a
  variety of terminals such as hand-held devices, TTY-like devices,
  display devices, computers, and unattended sensors. Since the
  interconnections are by radio, the users can be fixed or mobile, and
  the network can be easily moved. Furthermore, it can be readily
  established in remote or primitive areas where a wired network would
  be impossible, and total connectivity of users will be provided.

It lists as a reference:

  Nielson, D. L., Microwave Propagation and Noise Measurements for
  Mobile Digital Radio Application, SRI PACKET RADIO NOTE No. 4
  (emphasis mine), January 1975, Stanford Research Institute, Menlo
  Park, California.

That Nielson paper is available here:

  https://sci-hub.se/10.1109/t-vt.1978.23733

(the sci-hub version doesn't say it's Secret Packet Radio Note No. 4.)

	John



From bill.n1vux at gmail.com  Tue Apr 22 17:43:25 2025
From: bill.n1vux at gmail.com (Bill Ricker)
Date: Tue, 22 Apr 2025 20:43:25 -0400
Subject: [ih] A comment on the seven layer model
In-Reply-To: <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
Message-ID: <CAAbKA3Vn+DwZEZfVgAO-RKGwXzLt04D+DrqrPBthc1ccdRTC8A@mail.gmail.com>

On Tue, Apr 22, 2025 at 4:58?PM Steve Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> I liked your comment, "I gave up long ago on trying to stuff this into a
> 7-layer diagram and explain it."
> ...
>
>From the beginning we thought in terms of thin
> layers that provided useful services, with the proviso that others would
> build on, ignore and build around, or insert other layers in between as
> needed


I don't have MAP's original canonical phrasing immediately to hand, but as
he happily republished my copy-pasta of John S Quarterman's paraphrase, he
had accepted it as close enough:

> I like Mike's statement, which I'll paraphrase
> "If you know what you're doing, 3 layers is enough; if you don't, 17
layers won't help you."

MAP also pointed out that the OSI ISORM's holy seven layers were _not_ all
end-to-end, though usually drawn that way: the bottom 3 layers were to be
traversed in both DTEs' attached DCEs, so in reality the 7-story apartment
buildings should always be drawn with shorter parking garages between them,
with full tour of each parking garage required.

(If one searches, one can find OSI diagrams with 7 layer DTEs left and
right with a pair of 3 layer DCEs betwixt, but it's rare, outside of
materials regarding e.g. DataLink layer or Frames. This is not to imply
that non-OSI systems didn't often have DCE with similar constraints, but it
wasn't hard-layered or required.)

(And MAP also observed that hard layering of Session "below" Presentation
prevented sensible engineering in ways permitted by what he termed the
ARPAnet Reference Model (ARM), e.g. optimizing the EBCDIC/ASCII
Presentation of multiplexed Sessions by doing it at the system boundary,
possibly outsourced to the adapter or DCE, where ISORM would forbid
Transport and Presentation functions.)


// William Ricker for The Literary Estate of Michael A Padlipsky


From jack at 3kitty.org  Tue Apr 22 18:06:31 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 22 Apr 2025 18:06:31 -0700
Subject: [ih] Packet Radio Notes
In-Reply-To: <29545.1745367978@hop.toad.com>
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
 <29545.1745367978@hop.toad.com>
Message-ID: <cf7aed77-ce53-44b4-bbee-59a528643ba8@3kitty.org>

There are archive sites which the normal search tools apparently don't 
reach.? But the documents they store are still accessible, but only if 
you use the search tool on the archive site.

I've found many old tech reports at discover.dtic.mil -- the Defense 
Technical Information Center.? Ignore the verbiage about logging in or 
setting up an account.? Just type your search term into the box at the 
top right of the page, labelled "Enhanced by Google".

If you can find them, the "contract number" associated with the project, 
or the "ADA number" identifying a specific document, are both good ways 
to do a search.?? If Packet Radio Notes are anywhere, it's likely they 
are in DTIC.

Jack

On 4/22/25 17:26, John Gilmore via Internet-history wrote:
> Alexander McKenzie via Internet-history wrote:
>> I must apologize for a serious misstatement.  I now realize it was not
>> IEN's which were strictly controlled, it was Packet Radio Notes.
> Surely the need for strict control of the 1970s Packet Radio Notes has
> passed by now.  Is there a full archive of them publicly accessible
> somewhere?
>
> Is there a list somewhere of all the issued Packet Radio Notes?
> Which could perhaps be used to anchor searches for all of them?
>
> ARDC.net and the Internet Archive are collecting a Digital Library of
> Amateur Radio and Communications, which would probably be happy to host
> this collection.  See:
>
>    https://blog.archive.org/tag/dlarc/
>
> A web search for "Packet Radio Note" turned up exactly one reference,
> which is hidden inside ACM's "digital crypt" where papers check in and
> never check out:
>
>    https://dl.acm.org/doi/pdf/10.1145/1499949.1499988
>
>    Technological considerations for packet radio networks
>    Authors: Stanley C. Fralick, James C. Garrett
>    AFIPS '75: Proceedings of the May 19-22, 1975, national computer conference and exposition
>    Pages 233 - 243
>    https://doi.org/10.1145/1499949.1499988
>    Published: 19 May 1975
>
>    Abstract: The application of packet-switching techniques to radio
>    channels has provided a solution to many computer-communications
>    problems previously unsolved. For example, a packet radio network can
>    readily be designed to provide area coverage at data rates fast enough
>    to support interactive operations for thousands of users having a
>    variety of terminals such as hand-held devices, TTY-like devices,
>    display devices, computers, and unattended sensors. Since the
>    interconnections are by radio, the users can be fixed or mobile, and
>    the network can be easily moved. Furthermore, it can be readily
>    established in remote or primitive areas where a wired network would
>    be impossible, and total connectivity of users will be provided.
>
> It lists as a reference:
>
>    Nielson, D. L., Microwave Propagation and Noise Measurements for
>    Mobile Digital Radio Application, SRI PACKET RADIO NOTE No. 4
>    (emphasis mine), January 1975, Stanford Research Institute, Menlo
>    Park, California.
>
> That Nielson paper is available here:
>
>    https://sci-hub.se/10.1109/t-vt.1978.23733
>
> (the sci-hub version doesn't say it's Secret Packet Radio Note No. 4.)
>
> 	John
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250422/596418c1/attachment.asc>

From touch at strayalpha.com  Tue Apr 22 19:01:56 2025
From: touch at strayalpha.com (touch at strayalpha.com)
Date: Tue, 22 Apr 2025 19:01:56 -0700
Subject: [ih] A comment on the seven layer model
In-Reply-To: <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
Message-ID: <C926127D-67F4-4ABD-87C4-A532AD1E9E8A@strayalpha.com>


> On Apr 22, 2025, at 1:58?PM, Steve Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Jack,
> 
> I liked your comment, "I gave up long ago on trying to stuff this into a
> 7-layer diagram and explain it.?

I like it as well. My class approach is that layers are all relative, e.g., IP-a over IP-b means that IP-a is a transport over IP-b, and IP-b is a link to IP-a.

There?s real utility in layering and in the relation of layers, but not in any absolute count.

Joe

?
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

From brian.e.carpenter at gmail.com  Tue Apr 22 20:15:03 2025
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Wed, 23 Apr 2025 15:15:03 +1200
Subject: [ih] A comment on the seven layer model
In-Reply-To: <C926127D-67F4-4ABD-87C4-A532AD1E9E8A@strayalpha.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
 <C926127D-67F4-4ABD-87C4-A532AD1E9E8A@strayalpha.com>
Message-ID: <ceba6a4f-d88c-47d3-a945-5bd29c131aeb@gmail.com>

I've always argued that the main defect in the 7-layer model is that
it isn't recursive, especially in layers 2-5. Given that it was invented
by computer scientists, I'm also still a bit surprised by this defect.

     Brian
On 23-Apr-25 14:01, touch--- via Internet-history wrote:
> 
>> On Apr 22, 2025, at 1:58?PM, Steve Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
>>
>> Jack,
>>
>> I liked your comment, "I gave up long ago on trying to stuff this into a
>> 7-layer diagram and explain it.?
> 
> I like it as well. My class approach is that layers are all relative, e.g., IP-a over IP-b means that IP-a is a transport over IP-b, and IP-b is a link to IP-a.
> 
> There?s real utility in layering and in the relation of layers, but not in any absolute count.
> 
> Joe
> 
> ?
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com

From touch at strayalpha.com  Tue Apr 22 20:28:03 2025
From: touch at strayalpha.com (touch at strayalpha.com)
Date: Tue, 22 Apr 2025 20:28:03 -0700
Subject: [ih] A comment on the seven layer model
In-Reply-To: <ceba6a4f-d88c-47d3-a945-5bd29c131aeb@gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
 <C926127D-67F4-4ABD-87C4-A532AD1E9E8A@strayalpha.com>
 <ceba6a4f-d88c-47d3-a945-5bd29c131aeb@gmail.com>
Message-ID: <F3149F8C-4841-4BF7-97DD-BDAC69CF1719@strayalpha.com>

Yup - recursive - it's the basis of what I call the Recursive Network Architecture, which is the theory on which the way I taught networking works:
https://www.strayalpha.com/rna/#:~:text=The%20Recursive%20Network%20Architecture%20(RNA,protocol%20layers%20to%20avoid%20reimplementation.

The approach I use is called a ?first principles approach to networking?, which ties together info theory, physics, and recursion?

Joe
?
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Apr 22, 2025, at 8:15?PM, Brian E Carpenter via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> I've always argued that the main defect in the 7-layer model is that
> it isn't recursive, especially in layers 2-5. Given that it was invented
> by computer scientists, I'm also still a bit surprised by this defect.
> 
>    Brian
> On 23-Apr-25 14:01, touch--- via Internet-history wrote:
>>> On Apr 22, 2025, at 1:58?PM, Steve Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
>>> 
>>> Jack,
>>> 
>>> I liked your comment, "I gave up long ago on trying to stuff this into a
>>> 7-layer diagram and explain it.?
>> I like it as well. My class approach is that layers are all relative, e.g., IP-a over IP-b means that IP-a is a transport over IP-b, and IP-b is a link to IP-a.
>> There?s real utility in layering and in the relation of layers, but not in any absolute count.
>> Joe
>> ?
>> Dr. Joe Touch, temporal epistemologist
>> www.strayalpha.com
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From dhc at dcrocker.net  Tue Apr 22 20:34:48 2025
From: dhc at dcrocker.net (Dave Crocker)
Date: Wed, 23 Apr 2025 03:34:48 +0000 (UTC)
Subject: [ih] A comment on the seven layer model
In-Reply-To: <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
Message-ID: <42e092fb-e9fd-49a8-a6eb-3cc084c4951c@dcrocker.net>

On 4/22/2025 10:58 PM, Steve Crocker via Internet-history wrote:
> When I re-engaged with the
> network architecture and discovered OSI had determined there were
> exactly seven layers, I nearly fell over laughing.
>
> The seven layer model has been useful, but it is not complete or definitive.


Indeed, on both counts.? The Arpa networking community did not have a 
formal model of layering.? Layering was there, but there was no 
documentation for a 'model'.? When the OSI model got visibility, the 
Arpa community reacted by declaring a retroactive model.? I think it was 
5 layers.? But it was never part of serious dialogue, as I recall.

When I started teaching TCP/IP classes, I decided the 7-layer model 
offered useful pedagogy, including the construct of a 'convergence' 
sub-layer, such as where IP was packaged for the link layer.? Equally, 
something like TLS nicely fit sinto the Session layer between 
applications and transport.? (Interestingly, TLS is actually designed 
with extensibility that is, I believe, unused, and could permit other 
functions.? I once explored trying to support application robustness by 
having that layer support multiple transport paths, independent of the 
host's having a single IP Address.)

But 7 was an apt choice for the pedagogy, since it is a magical number 
with respect to humans...

    https://labs.la.utexas.edu/gilden/files/2016/04/MagicNumberSeven-Miller1956.pdf

Seriously, having a model like this factor in human utility is not a 
small benefit.? As for being limited, well, sure.? So the companion 
requirements are clarity about what it covers and and doesn't cover, and 
what it can and cannot be used for.

d/

-- 
Dave Crocker

Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker at mastodon.social


From jack at 3kitty.org  Tue Apr 22 20:57:33 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 22 Apr 2025 20:57:33 -0700
Subject: [ih] A comment on the seven layer model
In-Reply-To: <F3149F8C-4841-4BF7-97DD-BDAC69CF1719@strayalpha.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
 <C926127D-67F4-4ABD-87C4-A532AD1E9E8A@strayalpha.com>
 <ceba6a4f-d88c-47d3-a945-5bd29c131aeb@gmail.com>
 <F3149F8C-4841-4BF7-97DD-BDAC69CF1719@strayalpha.com>
Message-ID: <245e5424-5b0b-437c-9b0f-c105e81b3b0c@3kitty.org>

Recursive is a nice improvement, but I think there's still more complexity.

At Oracle in the 1990s we had customers with a mess of a multiprotocol 
IT environment.? Most of them.? There might be LU6.2 in the mainframe 
managing inventory, SPX/IPX in Accounting, Appletalk in the Graphics 
department, TCP in Engineering on their Vaxen and Sparcs, etc.? All of 
them had a need to get to corporate databases.

Everyone was pretty much committed to standardize on TCP.?? But it would 
take a while, and the unruliness of the transition period might kill the 
company.

We followed the lead of TCP and created an internet "above" all of those 
other protocol worlds, mimicking what TCP did to interconnect different 
kinds of physical networks.

All was in software, including an "Interchange" which performed 
functions similar to a gateway or router.? But instead of passing 
datagrams from one type of network to another as data travelled, the 
Interchange passed data from one virtual circuit to another (TCP 
connection, SPX connection, whatever the underlying protocol environment 
provided as a reliable byte-stream.)

You needed a few machines able to use multiple protocols, but such 
connections could be patched together as needed, and changed as they 
progressed.? Accounting, perhaps on Novell's SPX, might use an 
Interchange to a DECNET world, and another Interchange somewhere else 
might connect DECNET to TCP where the database lived.

Of course each of those underlying network world might also be its own 
"internet", e.g., with a "global LAN" connecting together the Accounting 
departments at all the companies sites.? They might even all be using 
the same LANs and circuits, with multiprotocol routers to keep all the 
data moving.? But the PCs in Accounting couldn't talk to the mainframes 
running LU6.2

It worked well enough, and provided a means for a company to 
methodically transition from its melange of multiprotocol network 
technologies into its chosen long-term IT architecture, which was 
increasingly based on TCP.? I think it probably helped TCP supplant all 
those other internet technologies, by providing a way for companies to 
"get from here to there".

Corporations had drunk the TCP KoolAid.? We helped them avoid drowning 
in it while they changed everything.? Configurations might change as 
progress was made towards a full TCP-based environment.

All of this might be running on the same physical network, perhaps of 
Ethernets and cisco multiprotocol routers.? We called this underlying 
service of virtual circuits patched together TNS - Transparent Network 
System IIRC.

Does that fit into the 7-layer, or recursive, models?? Seems like it 
might be a challenge.? I never tried.

Jack Haverty


On 4/22/25 20:28, touch--- via Internet-history wrote:
> Yup - recursive - it's the basis of what I call the Recursive Network Architecture, which is the theory on which the way I taught networking works:
> https://www.strayalpha.com/rna/#:~:text=The%20Recursive%20Network%20Architecture%20(RNA,protocol%20layers%20to%20avoid%20reimplementation.
>
> The approach I use is called a ?first principles approach to networking?, which ties together info theory, physics, and recursion?
>
> Joe
> ?
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
>> On Apr 22, 2025, at 8:15?PM, Brian E Carpenter via Internet-history<internet-history at elists.isoc.org>  wrote:
>>
>> I've always argued that the main defect in the 7-layer model is that
>> it isn't recursive, especially in layers 2-5. Given that it was invented
>> by computer scientists, I'm also still a bit surprised by this defect.
>>
>>     Brian
>> On 23-Apr-25 14:01, touch--- via Internet-history wrote:
>>>> On Apr 22, 2025, at 1:58?PM, Steve Crocker via Internet-history<internet-history at elists.isoc.org>  wrote:
>>>>
>>>> Jack,
>>>>
>>>> I liked your comment, "I gave up long ago on trying to stuff this into a
>>>> 7-layer diagram and explain it.?
>>> I like it as well. My class approach is that layers are all relative, e.g., IP-a over IP-b means that IP-a is a transport over IP-b, and IP-b is a link to IP-a.
>>> There?s real utility in layering and in the relation of layers, but not in any absolute count.
>>> Joe
>>> ?
>>> Dr. Joe Touch, temporal epistemologist
>>> www.strayalpha.com
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250422/f1211c90/attachment.asc>

From touch at strayalpha.com  Tue Apr 22 21:06:02 2025
From: touch at strayalpha.com (touch at strayalpha.com)
Date: Tue, 22 Apr 2025 21:06:02 -0700
Subject: [ih] A comment on the seven layer model
In-Reply-To: <245e5424-5b0b-437c-9b0f-c105e81b3b0c@3kitty.org>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
 <C926127D-67F4-4ABD-87C4-A532AD1E9E8A@strayalpha.com>
 <ceba6a4f-d88c-47d3-a945-5bd29c131aeb@gmail.com>
 <F3149F8C-4841-4BF7-97DD-BDAC69CF1719@strayalpha.com>
 <245e5424-5b0b-437c-9b0f-c105e81b3b0c@3kitty.org>
Message-ID: <262AE191-2640-4C3C-A986-B6E2758C675F@strayalpha.com>


> On Apr 22, 2025, at 8:57?PM, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Does that fit into the 7-layer, or recursive, models?  Seems like it might be a challenge.  I never tried.

Actually, yes - the key is that the ?protocol stack? isn?t really a stack except at the packet level. It?s a DAG (directed acyclic graph) of protocol layers alternated with name translation layers.

With that recursive, dynamic model, both forwarding and layering are the same mechanism. And the mechanism allows the path through the DAG to change on a per-message basis - i.e., so that a TCP connection can be replaced with an optical circuit on-the-fly.

Joe

?
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com



From nextnetproject at gmail.com  Tue Apr 22 22:30:36 2025
From: nextnetproject at gmail.com (Jennifer Adamson)
Date: Tue, 22 Apr 2025 22:30:36 -0700
Subject: [ih] Internet nostalgia
In-Reply-To: <CAEf-zrjSfzsuhzKe2XH_rBZ1YWrTLmrAQ9hmMb6VDmpdKwrBYg@mail.gmail.com>
References: <CAEf-zrjSfzsuhzKe2XH_rBZ1YWrTLmrAQ9hmMb6VDmpdKwrBYg@mail.gmail.com>
Message-ID: <CB0DDE9A-9DD7-4E10-8CE8-9E969B5E96C9@gmail.com>


I love the idea of an Internet museum!

I was thinking exhibits could be in part crowd sourced. People develop exhibits and share details with other museums. This would allow local museums to customize their exhibits knowing they can build on quality material. It would be awesome if museums around the world could interact with each other like the Internet of 1990s. 

In Vancouver Canada we have a small museum with classic computers and a pay phone. I like the idea of classic hardware and classic software to convey the experience. 

Jen


> On Apr 22, 2025, at 11:00, the keyboard of geoff goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> ?recommend checking out https://obsolescence.dev/index.html where a team is
> working on PDP-1 and Whirlwind replicas (and as well as an
> ARPANET reconstruction project that has come to a point where they can run
> connections between multiple PDP-10s running the MIT ITS operating system
> and where work is also underway to restore some PDP-11 NCPs)
> 
> g
> 
>> On Tue, Apr 22, 2025 at 9:38?AM Jack Haverty via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>> 
>> With all the nostalgia floating around, I thought someone might be
>> interested in some historical re-enactment...here's some tools which
>> might help.
>> 
>> It is now possible to have your own PDP-11, PDP-10, or PDP-8, if only to
>> play with the console switches.   All powered by a Raspberry Pi running
>> a simulator of your favorite old computer, with a real but replica
>> computer console.
>> 
>> See https://www.ceds.dev/pidp-11 or https://www.ceds.dev/pidp-8 or
>> https://www.ceds.dev/pidp-10
>> 
>> You can also resurrect old software on it, as the ITS-Hackers have done
>> with the PDP-10.   See https://github.com/PDP-10/its
>> 
>> Perhaps someday we'll have an Internet Museum, with the technology of
>> the 1970s/80s running again, on modern hardware but using the old
>> historic code, protocols, and formats.
>> 
>> You might even debug that final problem you still remember but never
>> fixed....
>> 
>> Jack Haverty
>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
> 
> 
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history


From gregskinner0 at icloud.com  Tue Apr 22 23:16:04 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Tue, 22 Apr 2025 23:16:04 -0700
Subject: [ih] Packet Radio Notes
In-Reply-To: <29545.1745367978@hop.toad.com>
References: <CAMusaY_2uD8kH5DnBhwZnrL0DO=hbSDv33tjVem6p2yaX-kiTw@mail.gmail.com>
 <29545.1745367978@hop.toad.com>
Message-ID: <DD32275E-B827-4DB2-B20C-D8F79080FCA6@icloud.com>

(Responses inline)

On Apr 22, 2025, at 5:26?PM, John Gilmore via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Alexander McKenzie via Internet-history wrote:
>> I must apologize for a serious misstatement.  I now realize it was not
>> IEN's which were strictly controlled, it was Packet Radio Notes.
> 
> Surely the need for strict control of the 1970s Packet Radio Notes has
> passed by now.  Is there a full archive of them publicly accessible
> somewhere?
> 
> Is there a list somewhere of all the issued Packet Radio Notes?
> Which could perhaps be used to anchor searches for all of them?

John,

I don?t know of a full archive, but there is a list of Packet Radio Temporary Notes that?s available from the DTIC site.

https://apps.dtic.mil/sti/tr/pdf/ADA141528.pdf

Some of those PRTNs are IENs as well.

> ARDC.net and the Internet Archive are collecting a Digital Library of
> Amateur Radio and Communications, which would probably be happy to host
> this collection.  See:
> 
>  https://blog.archive.org/tag/dlarc/
> 
> A web search for "Packet Radio Note" turned up exactly one reference,
> which is hidden inside ACM's "digital crypt" where papers check in and
> never check out:
> 
>  https://dl.acm.org/doi/pdf/10.1145/1499949.1499988
> 
>  Technological considerations for packet radio networks
>  Authors: Stanley C. Fralick, James C. Garrett
>  AFIPS '75: Proceedings of the May 19-22, 1975, national computer conference and exposition
>  Pages 233 - 243
>  https://doi.org/10.1145/1499949.1499988
>  Published: 19 May 1975 
> 
>  Abstract: The application of packet-switching techniques to radio
>  channels has provided a solution to many computer-communications
>  problems previously unsolved. For example, a packet radio network can
>  readily be designed to provide area coverage at data rates fast enough
>  to support interactive operations for thousands of users having a
>  variety of terminals such as hand-held devices, TTY-like devices,
>  display devices, computers, and unattended sensors. Since the
>  interconnections are by radio, the users can be fixed or mobile, and
>  the network can be easily moved. Furthermore, it can be readily
>  established in remote or primitive areas where a wired network would
>  be impossible, and total connectivity of users will be provided.
> 
> It lists as a reference:
> 
>  Nielson, D. L., Microwave Propagation and Noise Measurements for
>  Mobile Digital Radio Application, SRI PACKET RADIO NOTE No. 4
>  (emphasis mine), January 1975, Stanford Research Institute, Menlo
>  Park, California.
> 
> That Nielson paper is available here:
> 
>  https://sci-hub.se/10.1109/t-vt.1978.23733
> 
> (the sci-hub version doesn't say it's Secret Packet Radio Note No. 4.)
> 
> 	John

That paper is from a collection I?m not familiar with.  There is a report by Don Nielson I found on the CHM site that?s part of another series of SRI quarterly management packet radio reports.

https://archive.computerhistory.org/resources/text/2009/102686324.05.01.acc.pdf

--gregbo



From frantisek.borsik at gmail.com  Tue Apr 22 23:37:18 2025
From: frantisek.borsik at gmail.com (Frantisek Borsik)
Date: Wed, 23 Apr 2025 08:37:18 +0200
Subject: [ih] Internet nostalgia
In-Reply-To: <CB0DDE9A-9DD7-4E10-8CE8-9E969B5E96C9@gmail.com>
References: <CAEf-zrjSfzsuhzKe2XH_rBZ1YWrTLmrAQ9hmMb6VDmpdKwrBYg@mail.gmail.com>
 <CB0DDE9A-9DD7-4E10-8CE8-9E969B5E96C9@gmail.com>
Message-ID: <CAJUtOOjmK-LGEn1oOCdXRwNvHH5+=w5+7cgc4DDTDkM-owAMdQ@mail.gmail.com>

It really is a great idea! There is only one I have visited so far - it was
in Szeged, a city in Hungary: https://it-muzeum.njszt.hu/en/home-en/

It's called a computer museum, but you know, it has a lot of artefacts
connected to the early Internet in the Central and Eastern Europe.

Been there while attending https://freesoftwareconference.eu in 2022.

All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave T?ht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik at gmail.com


On Wed, Apr 23, 2025 at 7:30?AM Jennifer Adamson via Internet-history <
internet-history at elists.isoc.org> wrote:

>
> I love the idea of an Internet museum!
>
> I was thinking exhibits could be in part crowd sourced. People develop
> exhibits and share details with other museums. This would allow local
> museums to customize their exhibits knowing they can build on quality
> material. It would be awesome if museums around the world could interact
> with each other like the Internet of 1990s.
>
> In Vancouver Canada we have a small museum with classic computers and a
> pay phone. I like the idea of classic hardware and classic software to
> convey the experience.
>
> Jen
>
>
> > On Apr 22, 2025, at 11:00, the keyboard of geoff goodfellow via
> Internet-history <internet-history at elists.isoc.org> wrote:
> >
> > ?recommend checking out https://obsolescence.dev/index.html where a
> team is
> > working on PDP-1 and Whirlwind replicas (and as well as an
> > ARPANET reconstruction project that has come to a point where they can
> run
> > connections between multiple PDP-10s running the MIT ITS operating system
> > and where work is also underway to restore some PDP-11 NCPs)
> >
> > g
> >
> >> On Tue, Apr 22, 2025 at 9:38?AM Jack Haverty via Internet-history <
> >> internet-history at elists.isoc.org> wrote:
> >>
> >> With all the nostalgia floating around, I thought someone might be
> >> interested in some historical re-enactment...here's some tools which
> >> might help.
> >>
> >> It is now possible to have your own PDP-11, PDP-10, or PDP-8, if only to
> >> play with the console switches.   All powered by a Raspberry Pi running
> >> a simulator of your favorite old computer, with a real but replica
> >> computer console.
> >>
> >> See https://www.ceds.dev/pidp-11 or https://www.ceds.dev/pidp-8 or
> >> https://www.ceds.dev/pidp-10
> >>
> >> You can also resurrect old software on it, as the ITS-Hackers have done
> >> with the PDP-10.   See https://github.com/PDP-10/its
> >>
> >> Perhaps someday we'll have an Internet Museum, with the technology of
> >> the 1970s/80s running again, on modern hardware but using the old
> >> historic code, protocols, and formats.
> >>
> >> You might even debug that final problem you still remember but never
> >> fixed....
> >>
> >> Jack Haverty
> >>
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> >
> >
> > --
> > Geoff.Goodfellow at iconia.com
> > living as The Truth is True
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From jaap at NLnetLabs.nl  Wed Apr 23 05:30:02 2025
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Wed, 23 Apr 2025 14:30:02 +0200
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <20250422142400.2DA12C5A86D5@ary.qy>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
Message-ID: <202504231230.53NCU2hl013641@bela.nlnetlabs.nl>

[Continuing UUCP nostagia, here are some highlights from EUrope]

 John Levine via Internet-history writes:

 > It appears that Johan Helsingius via Internet-history <julf at Julf.com> said:
 > >On 21/04/2025 22:15, the keyboard of geoff goodfellow via 
 > >Internet-history wrote:
 > >
 > >> then there was UUCP... can anyone chime in what the "minimum" acceptable
 > >> bit rate for that was?  anything less than Bell 202 at 1.2 or Racal Vadic
 > >> at 2.4?
 > >
 > >Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
 > >but I don't think I ever saw anything slower.
 >
 > I think I set up a 300 bps leaf node but didn't run much traffic over it.
 >

Well, it was all we had at that time, Also, one had to toggle
switches by hand which was a bit clumsy so we had this little box
built to do it remotely. Later on we could get our hand on 1200 bps
and even 2400 bps (but don't tell the regulators). The dialler boxes
became a great succes and somehow spread over Europe.

When the X.25 DN-1 came available foe international traffic, we
startad to use that as well.  It also gave birth to the f-protocol.
(Our uucp version was based on the olde V7 verson and some bits of
honeydanber) But the available bandwith wasn't enough so we ended
up havong a leased line over the ocean. Meanwhile a lot of traffice
went via Armano's uucp hub as well.  In exchance for n course on
Ultrix, we actually managed to get an VAX 750 from DEC.  When the
Telebit  modems came around, it was impossible to get the g-protocol
spoofing version. It forced us to blow our own e-proms to get it.

	jaap

PS. I really have t mention some of the prople involved: Teus Hagen, Jim McKie, Piet
    Beertema, Daniel Karrenberg, Peter Collinson, Rob Blokzijl. Note
    this list is in random order and rather incomplete.


From ocl at gih.com  Wed Apr 23 06:20:13 2025
From: ocl at gih.com (=?UTF-8?Q?Olivier_MJ_Cr=C3=A9pin-Leblond?=)
Date: Wed, 23 Apr 2025 15:20:13 +0200
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <202504231230.53NCU2hl013641@bela.nlnetlabs.nl>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <202504231230.53NCU2hl013641@bela.nlnetlabs.nl>
Message-ID: <ad0ca1a6-f02b-4938-9490-15aa4c86f92c@gih.com>

Was that mcvax, connected to seismo?

O.

On 23/04/2025 14:30, Jaap Akkerhuis via Internet-history wrote:
> [Continuing UUCP nostagia, here are some highlights from EUrope]
>
>   John Levine via Internet-history writes:
>
>   > It appears that Johan Helsingius via Internet-history<julf at Julf.com> said:
>   > >On 21/04/2025 22:15, the keyboard of geoff goodfellow via
>   > >Internet-history wrote:
>   > >
>   > >> then there was UUCP... can anyone chime in what the "minimum" acceptable
>   > >> bit rate for that was?  anything less than Bell 202 at 1.2 or Racal Vadic
>   > >> at 2.4?
>   > >
>   > >Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
>   > >but I don't think I ever saw anything slower.
>   >
>   > I think I set up a 300 bps leaf node but didn't run much traffic over it.
>   >
>
> Well, it was all we had at that time, Also, one had to toggle
> switches by hand which was a bit clumsy so we had this little box
> built to do it remotely. Later on we could get our hand on 1200 bps
> and even 2400 bps (but don't tell the regulators). The dialler boxes
> became a great succes and somehow spread over Europe.
>
> When the X.25 DN-1 came available foe international traffic, we
> startad to use that as well.  It also gave birth to the f-protocol.
> (Our uucp version was based on the olde V7 verson and some bits of
> honeydanber) But the available bandwith wasn't enough so we ended
> up havong a leased line over the ocean. Meanwhile a lot of traffice
> went via Armano's uucp hub as well.  In exchance for n course on
> Ultrix, we actually managed to get an VAX 750 from DEC.  When the
> Telebit  modems came around, it was impossible to get the g-protocol
> spoofing version. It forced us to blow our own e-proms to get it.
>
> 	jaap
>
> PS. I really have t mention some of the prople involved: Teus Hagen, Jim McKie, Piet
>      Beertema, Daniel Karrenberg, Peter Collinson, Rob Blokzijl. Note
>      this list is in random order and rather incomplete.


From yasuhiro at jprs.co.jp  Wed Apr 23 06:28:00 2025
From: yasuhiro at jprs.co.jp (Yasuhiro Orange Morishita / =?iso-2022-jp?B?GyRCPzkyPEJZOSgbKEI=?=)
Date: Wed, 23 Apr 2025 22:28:00 +0900 (JST)
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <ad0ca1a6-f02b-4938-9490-15aa4c86f92c@gih.com>
References: <20250422142400.2DA12C5A86D5@ary.qy>
 <202504231230.53NCU2hl013641@bela.nlnetlabs.nl>
 <ad0ca1a6-f02b-4938-9490-15aa4c86f92c@gih.com>
Message-ID: <20250423.222800.207790284654567867.yasuhiro@jprs.co.jp>

Hi,

> Was that mcvax, connected to seismo?

Legendary Piet Beertema has written great articles:

Piet Beertema's website
https://godfatherof.nl/ 

-- 
Yasuhiro 'Orange' Morishita <yasuhiro at jprs.co.jp>

From: Olivier MJ Cr?pin-Leblond via Internet-history <internet-history at elists.isoc.org>
Subject: Re: [ih] uucp, was Question re rate of growth of the Arpanet
Date: Wed, 23 Apr 2025 15:20:13 +0200

> Was that mcvax, connected to seismo?
> 
> O.
> 
> On 23/04/2025 14:30, Jaap Akkerhuis via Internet-history wrote:
>> [Continuing UUCP nostagia, here are some highlights from EUrope]
>>
>>   John Levine via Internet-history writes:
>>
>>   > It appears that Johan Helsingius via Internet-history<julf at Julf.com>
>>   > said:
>>   > >On 21/04/2025 22:15, the keyboard of geoff goodfellow via
>>   > >Internet-history wrote:
>>   > >
>>   > >> then there was UUCP... can anyone chime in what the "minimum"
>>   > >> acceptable
>>   > >> bit rate for that was?  anything less than Bell 202 at 1.2 or Racal
>>   > >> Vadic
>>   > >> at 2.4?
>>   > >
>>   > >Pretty much, yes. Leaf nodes could survive on a 1200 bps connection,
>>   > >but I don't think I ever saw anything slower.
>>   >
>>   > I think I set up a 300 bps leaf node but didn't run much traffic over
>>   > it.
>>   >
>>
>> Well, it was all we had at that time, Also, one had to toggle
>> switches by hand which was a bit clumsy so we had this little box
>> built to do it remotely. Later on we could get our hand on 1200 bps
>> and even 2400 bps (but don't tell the regulators). The dialler boxes
>> became a great succes and somehow spread over Europe.
>>
>> When the X.25 DN-1 came available foe international traffic, we
>> startad to use that as well.  It also gave birth to the f-protocol.
>> (Our uucp version was based on the olde V7 verson and some bits of
>> honeydanber) But the available bandwith wasn't enough so we ended
>> up havong a leased line over the ocean. Meanwhile a lot of traffice
>> went via Armano's uucp hub as well.  In exchance for n course on
>> Ultrix, we actually managed to get an VAX 750 from DEC.  When the
>> Telebit  modems came around, it was impossible to get the g-protocol
>> spoofing version. It forced us to blow our own e-proms to get it.
>>
>> 	jaap
>>
>> PS. I really have t mention some of the prople involved: Teus Hagen,
>> Jim McKie, Piet
>>      Beertema, Daniel Karrenberg, Peter Collinson, Rob Blokzijl. Note
>>      this list is in random order and rather incomplete.
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> 


From clemc at ccc.com  Wed Apr 23 07:05:28 2025
From: clemc at ccc.com (Clem Cole)
Date: Wed, 23 Apr 2025 10:05:28 -0400
Subject: [ih] Internet nostalgia
In-Reply-To: <95849ab5-6fac-4d82-b7ff-6c0253aa27a5@3kitty.org>
References: <95849ab5-6fac-4d82-b7ff-6c0253aa27a5@3kitty.org>
Message-ID: <CAC20D2MeRU7DLieUWy24hGL_4VJ+rOxS6MyGSg+oqo-3U=5Ybw@mail.gmail.com>

On Tue, Apr 22, 2025 at 12:38?PM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:

>
> See https://www.ceds.dev/pidp-11 or https://www.ceds.dev/pidp-8 or
> https://www.ceds.dev/pidp-10
>
>
There is a whole set of pidp-{X} where X is 1,8,10, or 11 mailing list to
discuss Oscar's creations. And, of course, a lot of activities on the simh
mailing list, which powers them all (you can run OpenSimH.org on pretty
much anything, from VMS, Mac, Winders, or any Unix flavor that supports X11
or beyond).   On any of these mailing lists at least once a year, someone
(usually a person who did not live it) talks about wanting to bring up
either UUCP or the old ARPANET [they're is an IMP simulator in OpenSIMH
BTW].   The old guys smile, answer questions, and, typically, when the
question of what they are going to do with it finally gets considered, it
will stop.

FYI: Oscar's criteria for building a front panel, like the ones Jack
mentioned, are having fun things to do with the system.  This is why PDP-8.
then PDP-11, then PDP-10, now PDP-1.  We have been trying to build a case
for S/360 or S/370 from panel, but we have never found anything unique
besides some APL content to make a strong case for it.  There has been talk
about the IMP, but it does not have a compelling argument.  It just sits
there.  So, except for a museum where you might set up five of them running
OpenSIMH and the lights flash, we couldn't see a compelling reason to add
the front panel hardware.  If someone here can help me out, I can go back
to Oscar and make the case.

The short form is that Oscar, who still lives in Europe, has quit his 'day
job' .  He set up a factory to kit things in Panama but "ships in Florida.
He is now trying to turn these electronic kits into a small business, so I
think he's looking for ideas for new kits. IIIUIC The latest pipd-10 is now
over the break-even mark.  So he started up the pidp-1 development, which
is next, and that mailing list for it went live a week or two ago.  So I 'm
starting a rumor ?   I>> think << he's hoping to have alpha kits in the
hands of a few of us in a bit, with a beta run in the winter and first
production in 2026 ? but that >>me talking<< not him.

Clem

?


From bob.hinden at gmail.com  Wed Apr 23 09:15:45 2025
From: bob.hinden at gmail.com (Bob Hinden)
Date: Wed, 23 Apr 2025 09:15:45 -0700
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
References: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
 <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
Message-ID: <90F05F89-C110-4F54-A182-A48006DDEF68@gmail.com>

Craig,

I was at the same meetings and have the same fuzzy memory about Van talking about address translation.

Bob

> On Apr 22, 2025, at 12:23?PM, Craig Partridge via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Well, and I'm working from memory for the most part, so flaws may exist.
> 
> Van Jacobson is credited as the initial thinker about NAT in RFC 1631 prior
> to January 1993, which matches my memory, which is that Van came up with
> NAT as a concept while serving on the ROAD WG (which made its report at the
> 1992 IETF in San Diego -- see minutes p. 508ff, which mention the address
> exhaustion problem but not NAT).
> 
> I have a fuzzy memory of Van talking about the idea, which required an
> enabling idea, which was how to match which TCP connection to which host
> among the hosts sharing the IP address.  And, as I recall, Van made use of
> the fact that firewalls were doing per TCP connection mappings to firewall
> rules and said "aha, that's how you do it."   Since firewalls were a new
> concept, c. 1990 by Bellovin and Cheswick, the idea of a prior invention of
> NAT prior that 1990 would be unlikely.  Also, ISPs typically didn't charge
> for IP addresses until a bit after 1990.  So the window for someone to
> separately invent NAT exists (c. 1991-1993) but is narrow.
> 
> Craig
> 
> On Tue, Apr 22, 2025 at 12:52?PM Andrew Walding via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> Wizards and Historians,
>> Someone please correct me if what I had heard was wrong.  Back in the BBS
>> days when those of us were considering/wanting to connect our BBS systems
>> to the TCP/IP world (which as I recall really was not successful -
>> certainly not for my BBS) one of the members of the Homebrew Computer Club
>> of Menlo Park came up with the idea to bypass the high cost of static and
>> public IP addresses by translating private address space to a single public
>> IP, therefore avoiding the cost of having multiple public IPs.  The
>> motivation for this was to avoid paying the service provider more money, of
>> course.  Every time we added a phone line and a modem, it cost more money
>> for our BBS's so we were all very sensitive about this.  Now, we used
>> tricks like "teen lines" and so forth to minimize costs, but the thought of
>> then having to pay for multiple public IP's for each line was cost
>> prohibitive for most of us along with the perhaps bigger question: why
>> would the TCP/IP network want BBS systems on it?
>> 
>> Anyway, I heard about this trick and the code to accomplish this way before
>> RFC 1631 (1994) was even a draft.  I would say this was in 1985 or so.
>> Never saw it myself so it has always been a "tall tale" in my head.
>> 
>> Anyone know anything to confirm or deny this tall tale?
>> Andy
>> 
>> --
>> *Andrew M. Walding*
>> 
>> Direct: 214-659-1274
>> Twitter: @awalding
>> www.cellstream.com <http://bit.ly/2PzyatN>
>> www.netscionline.com <http://bit.ly/2PzbxWE>
>> 
>> CONFIDENTIALITY NOTICE: The contents of this email message and any
>> attachments are intended solely for the addressee(s) and may contain
>> confidential and/or privileged information and may be legally protected
>> from disclosure. If you are not the intended recipient of this message or
>> their agent, or if this message has been addressed to you in error, please
>> immediately alert the sender by reply email and then delete this message
>> and any attachments. If you are not the intended recipient, you are hereby
>> notified that any use, dissemination, copying, or storage of this message
>> or its attachments is strictly prohibited.
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
> 
> 
> -- 
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250423/a40cf979/attachment.asc>

From b_a_denny at yahoo.com  Wed Apr 23 10:25:32 2025
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Wed, 23 Apr 2025 17:25:32 +0000 (UTC)
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
References: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
 <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
Message-ID: <1551850795.971719.1745429132300@mail.yahoo.com>

 BTW, I think there may be question about the when and who in the history of firewalls.? I have seen 1988 as the date for the first firewall from DEC SRC.
barbara


    On Tuesday, April 22, 2025 at 12:24:12 PM PDT, Craig Partridge via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 Well, and I'm working from memory for the most part, so flaws may exist.

Van Jacobson is credited as the initial thinker about NAT in RFC 1631 prior
to January 1993, which matches my memory, which is that Van came up with
NAT as a concept while serving on the ROAD WG (which made its report at the
1992 IETF in San Diego -- see minutes p. 508ff, which mention the address
exhaustion problem but not NAT).

I have a fuzzy memory of Van talking about the idea, which required an
enabling idea, which was how to match which TCP connection to which host
among the hosts sharing the IP address.? And, as I recall, Van made use of
the fact that firewalls were doing per TCP connection mappings to firewall
rules and said "aha, that's how you do it."? Since firewalls were a new
concept, c. 1990 by Bellovin and Cheswick, the idea of a prior invention of
NAT prior that 1990 would be unlikely.? Also, ISPs typically didn't charge
for IP addresses until a bit after 1990.? So the window for someone to
separately invent NAT exists (c. 1991-1993) but is narrow.

Craig

On Tue, Apr 22, 2025 at 12:52?PM Andrew Walding via Internet-history <
internet-history at elists.isoc.org> wrote:

> Wizards and Historians,
> Someone please correct me if what I had heard was wrong.? Back in the BBS
> days when those of us were considering/wanting to connect our BBS systems
> to the TCP/IP world (which as I recall really was not successful -
> certainly not for my BBS) one of the members of the Homebrew Computer Club
> of Menlo Park came up with the idea to bypass the high cost of static and
> public IP addresses by translating private address space to a single public
> IP, therefore avoiding the cost of having multiple public IPs.? The
> motivation for this was to avoid paying the service provider more money, of
> course.? Every time we added a phone line and a modem, it cost more money
> for our BBS's so we were all very sensitive about this.? Now, we used
> tricks like "teen lines" and so forth to minimize costs, but the thought of
> then having to pay for multiple public IP's for each line was cost
> prohibitive for most of us along with the perhaps bigger question: why
> would the TCP/IP network want BBS systems on it?
>
> Anyway, I heard about this trick and the code to accomplish this way before
> RFC 1631 (1994) was even a draft.? I would say this was in 1985 or so.
>? Never saw it myself so it has always been a "tall tale" in my head.
>
> Anyone know anything to confirm or deny this tall tale?
> Andy
>
> --
> *Andrew M. Walding*



-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  

From julf at Julf.com  Wed Apr 23 11:29:42 2025
From: julf at Julf.com (Johan Helsingius)
Date: Wed, 23 Apr 2025 20:29:42 +0200
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <202504231230.53NCU2hl013641@bela.nlnetlabs.nl>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <202504231230.53NCU2hl013641@bela.nlnetlabs.nl>
Message-ID: <cec7f305-de4a-40f1-b814-af36c3107f65@Julf.com>

On 23/04/2025 14:30, Jaap Akkerhuis via Internet-history wrote:
> Well, it was all we had at that time, Also, one had to toggle
> switches by hand which was a bit clumsy so we had this little box
> built to do it remotely. Later on we could get our hand on 1200 bps
> and even 2400 bps (but don't tell the regulators). The dialler boxes
> became a great succes and somehow spread over Europe.

We fortunately managed to get a semi-prototype Nokia dialler.

> When the X.25 DN-1 came available foe international traffic, we
> startad to use that as well.  It also gave birth to the f-protocol.

We were running a Zilog Z8000 box, with their port of System III UNIX.
The Zilog guys had noticed the discrepancy between the termip manual
page description and what the code actually did - but unfortunately
they fixed the code to do what the man page said, and not the other
way around. The result was that if both c_cc[TIME] (read timeout time)
and c_cc[MIN] (number of characters to buffer) were non-zero, the
Zilog code counted the timeout from the beginning of the read()
system call, not from the first character. Thus if the sending host
was slow, the read() might time out before any characters are read,
resulting in 0 characters being returned - the signal for line being
dropped. Not fun when most of a large packet has been received (and you
are paying per byte/X.25 packet transferred.

Cost us a fair bit of X.25 charges until I figured it out. Couldn't
fix the tty driver (no kernel sources), but could do a workaround
in the UUCP code (from Piet).

	Julf



From jnc at mercury.lcs.mit.edu  Wed Apr 23 12:50:30 2025
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 23 Apr 2025 15:50:30 -0400 (EDT)
Subject: [ih] The invention of what we now call NAT
Message-ID: <20250423195031.00C5018C075@mercury.lcs.mit.edu>

   > From: Craig Partridge

   > I'm working from memory for the most part, so flaws may exist.

Ditto.

    > Van Jacobson is credited as the initial thinker about NAT

I have him in memory as the co-inventor, along with Paul Tsuchiya. Not
partners, mind - independent inventors.

I don't recall why Paul was working in that area (NAT is something I never
had much time for - among other things, it makes the network more brittle, by
moving state into the end routers - clearly a hack - even more so than BGP -
so the details have been GC'd from my memory) - if he's still with us, and
someone is in touch with him, they should ask him.

    > Van came up with NAT as a concept while serving on the ROAD WG

IIRC, there was a ROAD meeting on the West Coast (not as part of an IETF),
and that was were Van introduced his to us. But I had heard of Paul's before
that.

I think I still have my email from that era, squirreled away somewhere. I'm
not up to looking, though.

	Noel


From sob at sobco.com  Wed Apr 23 12:57:08 2025
From: sob at sobco.com (Scott Bradner)
Date: Wed, 23 Apr 2025 15:57:08 -0400
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <20250423195031.00C5018C075@mercury.lcs.mit.edu>
References: <20250423195031.00C5018C075@mercury.lcs.mit.edu>
Message-ID: <91A18D3A-F7CA-4B24-B070-0DF5A5BBA1FD@sobco.com>

in RFC 1631 Paul credits Van for "address reuse"

Acknowledgments

   This memo is based on a paper by Paul Francis (formerly Tsuchiya) and
   Tony Eng, published in Computer Communication Review, January 1993.
   Paul had the concept of address reuse from Van Jacobson.

> On Apr 23, 2025, at 3:50?PM, Noel Chiappa via Internet-history <internet-history at elists.isoc.org> wrote:
> 
>> From: Craig Partridge
> 
>> I'm working from memory for the most part, so flaws may exist.
> 
> Ditto.
> 
>> Van Jacobson is credited as the initial thinker about NAT
> 
> I have him in memory as the co-inventor, along with Paul Tsuchiya. Not
> partners, mind - independent inventors.
> 
> I don't recall why Paul was working in that area (NAT is something I never
> had much time for - among other things, it makes the network more brittle, by
> moving state into the end routers - clearly a hack - even more so than BGP -
> so the details have been GC'd from my memory) - if he's still with us, and
> someone is in touch with him, they should ask him.
> 
>> Van came up with NAT as a concept while serving on the ROAD WG
> 
> IIRC, there was a ROAD meeting on the West Coast (not as part of an IETF),
> and that was were Van introduced his to us. But I had heard of Paul's before
> that.
> 
> I think I still have my email from that era, squirreled away somewhere. I'm
> not up to looking, though.
> 
> Noel
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From brian.e.carpenter at gmail.com  Wed Apr 23 13:35:09 2025
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Thu, 24 Apr 2025 08:35:09 +1200
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <91A18D3A-F7CA-4B24-B070-0DF5A5BBA1FD@sobco.com>
References: <20250423195031.00C5018C075@mercury.lcs.mit.edu>
 <91A18D3A-F7CA-4B24-B070-0DF5A5BBA1FD@sobco.com>
Message-ID: <a2e78caf-6c9a-4264-8d69-3271db109f5e@gmail.com>

On 24-Apr-25 07:57, Scott Bradner via Internet-history wrote:
> in RFC 1631 Paul credits Van for "address reuse"
> 
> Acknowledgments
> 
>     This memo is based on a paper by Paul Francis (formerly Tsuchiya) and
>     Tony Eng, published in Computer Communication Review, January 1993.
>     Paul had the concept of address reuse from Van Jacobson.

That was (given publication delays) ~simultaneous with US patent #5371852 filed October 14, 1992. The inventors on that patent were Clement R. Attanasio and Stephen E. Smith, who I'm guessing were both at IBM Poughkeepsie. There's a lot to unpack in the patent, and some interesting prior art, but there's definitely NAT in there. I guess it was just another case of great minds thinking alike.

IBM never disclosed this patent to the IETF. But NAT wasn't on the standards track. If it had been, there would have been a disclosure (because I would have made it happen).

    Brian


> 
>> On Apr 23, 2025, at 3:50?PM, Noel Chiappa via Internet-history <internet-history at elists.isoc.org> wrote:
>>
>>> From: Craig Partridge
>>
>>> I'm working from memory for the most part, so flaws may exist.
>>
>> Ditto.
>>
>>> Van Jacobson is credited as the initial thinker about NAT
>>
>> I have him in memory as the co-inventor, along with Paul Tsuchiya. Not
>> partners, mind - independent inventors.
>>
>> I don't recall why Paul was working in that area (NAT is something I never
>> had much time for - among other things, it makes the network more brittle, by
>> moving state into the end routers - clearly a hack - even more so than BGP -
>> so the details have been GC'd from my memory) - if he's still with us, and
>> someone is in touch with him, they should ask him.
>>
>>> Van came up with NAT as a concept while serving on the ROAD WG
>>
>> IIRC, there was a ROAD meeting on the West Coast (not as part of an IETF),
>> and that was were Van introduced his to us. But I had heard of Paul's before
>> that.
>>
>> I think I still have my email from that era, squirreled away somewhere. I'm
>> not up to looking, though.
>>
>> Noel
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
> 

From gregskinner0 at icloud.com  Wed Apr 23 14:04:00 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Wed, 23 Apr 2025 14:04:00 -0700
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <20250423195031.00C5018C075@mercury.lcs.mit.edu>
References: <20250423195031.00C5018C075@mercury.lcs.mit.edu>
Message-ID: <18395016-5C44-4180-B7C3-24FDA2FCD883@icloud.com>

On Apr 23, 2025, at 12:50?PM, Noel Chiappa via Internet-history <internet-history at elists.isoc.org> wrote:
> 
>> From: Craig Partridge
> 
>> I'm working from memory for the most part, so flaws may exist.
> 
> Ditto.
> 
>> Van Jacobson is credited as the initial thinker about NAT
> 
> I have him in memory as the co-inventor, along with Paul Tsuchiya. Not
> partners, mind - independent inventors.
> 
> I don't recall why Paul was working in that area (NAT is something I never
> had much time for - among other things, it makes the network more brittle, by
> moving state into the end routers - clearly a hack - even more so than BGP -
> so the details have been GC'd from my memory) - if he's still with us, and
> someone is in touch with him, they should ask him.
> 
>> Van came up with NAT as a concept while serving on the ROAD WG
> 
> IIRC, there was a ROAD meeting on the West Coast (not as part of an IETF),
> and that was were Van introduced his to us. But I had heard of Paul's before
> that.
> 
> I think I still have my email from that era, squirreled away somewhere. I'm
> not up to looking, though.
> 
> 	Noel

In one of your emails from that era (June 1992), you sent a Taxonomy of NAT variants (https://mailarchive.ietf.org/arch/msg/big-internet/2gr4OOWRk7VrweWByd1cJ7Kjc8M/) to the big-internet list. 

--gregbo



From gregskinner0 at icloud.com  Wed Apr 23 14:46:55 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Wed, 23 Apr 2025 14:46:55 -0700
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <1551850795.971719.1745429132300@mail.yahoo.com>
References: <CAKvFookLphtwWtPWfE1c2iCg8LKzBAJ2dtxKCijEwZZLbw+1Vg@mail.gmail.com>
 <CAHQj4CfeuRF8C-JipWUNgtP6i30D9q-Ucz7yuKVPmkL81Enyvw@mail.gmail.com>
 <1551850795.971719.1745429132300@mail.yahoo.com>
Message-ID: <1CEFD981-5C59-45BA-BDD7-12F6B105164A@icloud.com>

On Apr 23, 2025, at 10:25?AM, Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> BTW, I think there may be question about the when and who in the history of firewalls.  I have seen 1988 as the date for the first firewall from DEC SRC.
> barbara

Regarding firewalls, Marcus Ranum put together a presentation of their early days. [1] There is also historical firewall literature (and other security-related topics) in the bibliography of the second edition of Cheswick and Bellovin?s book on firewalls. [2] (Some links may no longer work.)

--gregbo

[1] https://www.ranum.com/security/computer_security/archives/firewall-early-days.pdf
[2] https://www.wilyhacker.com/refs/




From johnl at iecc.com  Wed Apr 23 15:28:26 2025
From: johnl at iecc.com (John Levine)
Date: 23 Apr 2025 18:28:26 -0400
Subject: [ih] The invention of what we now call NAT
In-Reply-To: <a2e78caf-6c9a-4264-8d69-3271db109f5e@gmail.com>
References: <20250423195031.00C5018C075@mercury.lcs.mit.edu>
 <91A18D3A-F7CA-4B24-B070-0DF5A5BBA1FD@sobco.com>
 <a2e78caf-6c9a-4264-8d69-3271db109f5e@gmail.com>
Message-ID: <20250423222826.9E22AC608412@ary.qy>

It appears that Brian E Carpenter via Internet-history <brian.e.carpenter at gmail.com> said:
>On 24-Apr-25 07:57, Scott Bradner via Internet-history wrote:
>> in RFC 1631 Paul credits Van for "address reuse"
>> 
>> Acknowledgments
>> 
>>     This memo is based on a paper by Paul Francis (formerly Tsuchiya) and
>>     Tony Eng, published in Computer Communication Review, January 1993.
>>     Paul had the concept of address reuse from Van Jacobson.
>
>That was (given publication delays) ~simultaneous with US patent #5371852 filed October 14, 1992. The inventors on that patent were Clement R. Attanasio and Stephen E. Smith,
>who I'm guessing were both at IBM Poughkeepsie.

They were at IBM Research in Yorktown Heights.  I found a bio for Attanasio in an IBMJRD article.

 There's a lot to unpack in the patent, and some interesting prior art, but there's definitely NAT in there. I guess it was
>just another case of great minds thinking alike.

Agreed, the first five claims describe NAT. The addresses in SNA were too small
and I recall some kludgery in connecting SNA networks that might have been the
inspiration for their work.

R's,
John


From jaap at NLnetLabs.nl  Fri Apr 25 02:24:11 2025
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Fri, 25 Apr 2025 11:24:11 +0200
Subject: [ih] uucp, was Question re rate of growth of the Arpanet
In-Reply-To: <ad0ca1a6-f02b-4938-9490-15aa4c86f92c@gih.com>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <CABf5zv+UBDUpke=1R5UwxsB2_esmZV7_z+OG0hvkY44xZ+f0xQ@
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <202504231230.53NCU2hl013641@bela.nlnetlabs.nl>
 <ad0ca1a6-f02b-4938-9490-15aa4c86f92c@gih.com>
Message-ID: <202504250924.53P9OBXi042007@bela.nlnetlabs.nl>

 Olivier MJ Cr?pin-Leblond writes:

 > Was that mcvax,

Yup. The MC stood for Mathematisch Centrum, now known as the Centrum
voor Wiskunde an Informatica (https://www.cwi.nl/en/). The vax was
a vax780, serial number 37.

 >connected to seismo?

At first we just used dial-up and X.25 to various places (North
America, Japan, Europe, Korea etc.) and yes, later we also got a
leased line to seismo).

	jaap


From gregskinner0 at icloud.com  Fri Apr 25 09:47:31 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Fri, 25 Apr 2025 09:47:31 -0700
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
Message-ID: <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>

On Apr 13, 2025, at 1:40?PM, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Instead of "formats and meanings", I should have said "formats and interactions".  The required sequences of messages, and the meanings of those sequences, were part of the Protocol and the Standard, captured in details such as the State Diagram included in RFC793 as part of the Specification.
> 
> At one of the early TCP meetings, Vint explained to all of us what "protocol" meant.  It was derived from the Greek word "protokolon" (sorry, can't remember how to make my computer type Greek characters...).  Vint explained that the protokolon was the section of ancient scrolls at the very beginning of any such "document".  It described what the entire scroll contained - something like a table of contents or Executive Summary or today perhaps the TLDR.   That was apparently useful in ancient times as a way to avoid having to unroll an entire scroll when searching for some particular piece of information.   We recognized it of course as The Header.
> 
> Internal algorithms within host implementations, such as calculation of retransmission timers, were explicitly not specified as a Standard at that point, although we hoped they could be someday after more experience and experimentation.
> 
> It wasn't so much that we had to consult with somebody more knowledgeable.  Rather we had experienced the unpredictable behavior of paths that traversed multiple networks, and didn't think that anyone knew how to characterize or model such behavior so that suitable methods for error detection and correction could be chosen.
> 
> It's also important to remember that the Standardization effort that resulted in RFC793 et al was an unexpected surprise.  Vint gave a short introductory talk at the beginning of each meeting.  At one of them he announced that DoD had decided to establish TCP as a DoD Standard, which had all sorts of consequences beyond the research community of ARPA.   For example, such a Standard would then influence all sorts of military procurements of hardware and software for anything that used computers and communications.
> 
> That announcement led to Jon getting the assignment to quickly create some required documentation, since Standards feed on paper rather than code.   That led to a lot of discussion as we tried to help Jon figure out what all the existing code actually did.   There was also a lot of whining about "It's not ready yet!" or "It's too soon!" and "but we don't know what the algorithm should be" (guilty!).
> 
> I recall having lots of discussions with Jon during that period. Jon was enamored with the notion that implementations "be conservative in what you do, be liberal in what you accept from others."  It's in the RFC793 spec.
> 
> I argued against that, on the principle that incorrect behavior was indicative of a bug, either in the specification or implementation, and should be reported so that it could be fixed.   Otherwise it just left a "time bomb" in some deployed system that would probably explode at some very inopportune time in the future.
> 
> I lost.
> 
> There weren't a lot of TCP implementations at the time.  Bill Plummer at BBN did Tenex.  Jim Mathis at SRI did the LSI-11 version used in Packet Radio experiments.   I suspect those two were the first implementations, used in the early Packet Radio experiments. Before my time.
> 
> I used Jim's code (e.g., implementation of the state diagram) as the core for my PDP-11/40 Unix implementation, which was part of a Network Security project at BBN in 1977.  Dave Mills had his Fuzzballs.   Bob Braden did the IBM 360 implementation at UCLA. Dave Clark and Noel Chiappa handled Multics at MIT.  There may have been one or two more, but it was a small group.  In between meetings, lots of debate and discussion was carried out by email, much of which is probably lost now.   Jon collected it all and distilled it into words and Specifications.
> 
> He had some earlier experience with such a task.  The first "TCP Bakeoff" was held at ISI on a weekend (January 27, 1979 IIRC) when lots of offices and their terminals were unoccupied.  We all had TCP implementations that could talk to themselves, but none of them could talk to anyone else.   Checksums were the primary culprit. But after a while we all got our TCPs to talk to each other.   Jon then captured the exact checksumming algorithm that reflected what all our code actually did to compute and verify checksums.   We had achieved Consensus at the Bakeoff, after starting with just Running but incompatible Code.   Jon wrote it down.
> 
> (BTW, all the time I was interacting with Jon, he was at USC-ISI, in an office tower in Marina Del Rey.  I didn't know he had ever been at UCLA)
> 
> Out of all that, and a Herculean effort by Jon, documentation for the DoD Standard emerged.  It wasn't a pretty process.  RFC 793/791 specify Version 4, which grew out of previous versions we had named things like "2.5" or "2.5+", or "2.5+epsilon".  All such versions were documented purely in email exchanges.
> 
> There was even an early definition of Version 3, which was quickly found to be incorrect and replaced by Version 4.   Unfortunately, someone in the DoD contractor community (Ford Aerospace IIRC) had been contracted to implement Version 3.  They had their TCP working, but couldn't find anybody to talk to.   We had all gone on to Version 4.
> 
> Standards are messy.   Formal standards organizations usually debate for years, refining documents with new ideas and epiphanies.  Code comes later.   The TCP community believed in "rough consensus and running code" as the first step.   Experience and experimentation drove changes.   Documentation came later.
> 
> It was fun too!
> 
> Jack Haverty

Do any of you remember a seminar in November 1980 at NBS where there were several presentations about the TCP/IP protocols that were being developed at that time?  [1] It seems like this seminar would have been an ideal time for concerns (such as what we have been discussing about retransmissions) to be discussed.

--gregbo

[1] https://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n3.1



From jack at 3kitty.org  Fri Apr 25 11:11:39 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 25 Apr 2025 11:11:39 -0700
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
 <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
Message-ID: <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>

Since I'm listed as one of the speakers, I was probably there.? But I 
don't remember that particular seminar at all.? OTOH, during the early 
1980s I went from Boston to DC probably at least once a week, often to 
brief someone or some group on The Internet.? I do recall going to NBS, 
but can't remember exactly why.?? It certainly could have been to give a 
talk on TCP for an hour to some audience.

That seminar was almost certainly part of DCA's efforts to support the 
standardization of TCP as a DoD Standard.? See, for example, RFC 761, 
published in January 1980 - with a seminar scheduled for November.

The adoption of TCP as a requirement for DoD procurements (not just 
research contracts) triggered a lot of big and small government 
contractors to get interested in exactly what this thing was that they 
were going to have to implement.? I recall even getting a phone call 
from a cousin, who worked at a big government shop, to get a little free 
education and advice.

So the NBS seminar was probably more of an educational venue for people 
new to TCP; it was likely not a place where nuances of retransmission 
algorithms would be of interest.

At the time, the ARPANET had been transferred from ARPA to DCA. Research 
results were progressing towards operation, part of the "technology 
transfer" impetus.? Joe Haughney was in charge of the ARPANET in DCA 
Code 535.? IIRC, there's a lot more detail in the podcasts which Joe's 
daughter Christine put together recently - see 
https://www.inc.com/podcasts/computer-freaks

Jack Haverty

On 4/25/25 09:47, Greg Skinner wrote:
> On Apr 13, 2025, at 1:40?PM, Jack Haverty via Internet-history<internet-history at elists.isoc.org>  wrote:
>> Instead of "formats and meanings", I should have said "formats and interactions".  The required sequences of messages, and the meanings of those sequences, were part of the Protocol and the Standard, captured in details such as the State Diagram included in RFC793 as part of the Specification.
>>
>> At one of the early TCP meetings, Vint explained to all of us what "protocol" meant.  It was derived from the Greek word "protokolon" (sorry, can't remember how to make my computer type Greek characters...).  Vint explained that the protokolon was the section of ancient scrolls at the very beginning of any such "document".  It described what the entire scroll contained - something like a table of contents or Executive Summary or today perhaps the TLDR.   That was apparently useful in ancient times as a way to avoid having to unroll an entire scroll when searching for some particular piece of information.   We recognized it of course as The Header.
>>
>> Internal algorithms within host implementations, such as calculation of retransmission timers, were explicitly not specified as a Standard at that point, although we hoped they could be someday after more experience and experimentation.
>>
>> It wasn't so much that we had to consult with somebody more knowledgeable.  Rather we had experienced the unpredictable behavior of paths that traversed multiple networks, and didn't think that anyone knew how to characterize or model such behavior so that suitable methods for error detection and correction could be chosen.
>>
>> It's also important to remember that the Standardization effort that resulted in RFC793 et al was an unexpected surprise.  Vint gave a short introductory talk at the beginning of each meeting.  At one of them he announced that DoD had decided to establish TCP as a DoD Standard, which had all sorts of consequences beyond the research community of ARPA.   For example, such a Standard would then influence all sorts of military procurements of hardware and software for anything that used computers and communications.
>>
>> That announcement led to Jon getting the assignment to quickly create some required documentation, since Standards feed on paper rather than code.   That led to a lot of discussion as we tried to help Jon figure out what all the existing code actually did.   There was also a lot of whining about "It's not ready yet!" or "It's too soon!" and "but we don't know what the algorithm should be" (guilty!).
>>
>> I recall having lots of discussions with Jon during that period. Jon was enamored with the notion that implementations "be conservative in what you do, be liberal in what you accept from others."  It's in the RFC793 spec.
>>
>> I argued against that, on the principle that incorrect behavior was indicative of a bug, either in the specification or implementation, and should be reported so that it could be fixed.   Otherwise it just left a "time bomb" in some deployed system that would probably explode at some very inopportune time in the future.
>>
>> I lost.
>>
>> There weren't a lot of TCP implementations at the time.  Bill Plummer at BBN did Tenex.  Jim Mathis at SRI did the LSI-11 version used in Packet Radio experiments.   I suspect those two were the first implementations, used in the early Packet Radio experiments. Before my time.
>>
>> I used Jim's code (e.g., implementation of the state diagram) as the core for my PDP-11/40 Unix implementation, which was part of a Network Security project at BBN in 1977.  Dave Mills had his Fuzzballs.   Bob Braden did the IBM 360 implementation at UCLA. Dave Clark and Noel Chiappa handled Multics at MIT.  There may have been one or two more, but it was a small group.  In between meetings, lots of debate and discussion was carried out by email, much of which is probably lost now.   Jon collected it all and distilled it into words and Specifications.
>>
>> He had some earlier experience with such a task.  The first "TCP Bakeoff" was held at ISI on a weekend (January 27, 1979 IIRC) when lots of offices and their terminals were unoccupied.  We all had TCP implementations that could talk to themselves, but none of them could talk to anyone else.   Checksums were the primary culprit. But after a while we all got our TCPs to talk to each other.   Jon then captured the exact checksumming algorithm that reflected what all our code actually did to compute and verify checksums.   We had achieved Consensus at the Bakeoff, after starting with just Running but incompatible Code.   Jon wrote it down.
>>
>> (BTW, all the time I was interacting with Jon, he was at USC-ISI, in an office tower in Marina Del Rey.  I didn't know he had ever been at UCLA)
>>
>> Out of all that, and a Herculean effort by Jon, documentation for the DoD Standard emerged.  It wasn't a pretty process.  RFC 793/791 specify Version 4, which grew out of previous versions we had named things like "2.5" or "2.5+", or "2.5+epsilon".  All such versions were documented purely in email exchanges.
>>
>> There was even an early definition of Version 3, which was quickly found to be incorrect and replaced by Version 4.   Unfortunately, someone in the DoD contractor community (Ford Aerospace IIRC) had been contracted to implement Version 3.  They had their TCP working, but couldn't find anybody to talk to.   We had all gone on to Version 4.
>>
>> Standards are messy.   Formal standards organizations usually debate for years, refining documents with new ideas and epiphanies.  Code comes later.   The TCP community believed in "rough consensus and running code" as the first step.   Experience and experimentation drove changes.   Documentation came later.
>>
>> It was fun too!
>>
>> Jack Haverty
> Do any of you remember a seminar in November 1980 at NBS where there were several presentations about the TCP/IP protocols that were being developed at that time?  [1] It seems like this seminar would have been an ideal time for concerns (such as what we have been discussing about retransmissions) to be discussed.
>
> --gregbo
>
> [1]https://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n3.1
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250425/ba24e3da/attachment.asc>

From gregskinner0 at icloud.com  Fri Apr 25 15:17:56 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Fri, 25 Apr 2025 15:17:56 -0700
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
 <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
 <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>
Message-ID: <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>

Just to clarify, I have listened to the computer-freaks podcasts about Joe Haughney.  He (and his successors) had access to information about the TCP/IP implementations that were discussed at the meetings summarized in the IEN notes.  So in theory, there was a means for them to raise concerns about retransmission algorithms, or collect information that could be passed on to people who had those concerns.  Furthermore, they were getting feedback on the tcp-ip list about implementation concerns, in general. [1]

So far, based on what I?ve read, I don?t see any evidence that the concerns of the military, or users of lossy networks, were given insufficient consideration.  I see that there were features left out of RFC 793 that could have mitigated some retransmission issues that impacted performance.  But there were DCA people involved who, in theory, could have questioned the wisdom of omitting those features, at least.

--gregbo

[1] https://www.columbia.edu/~rh120/other/tcpdigest_paper.txt


> On Apr 25, 2025, at 11:11?AM, Jack Haverty <jack at 3kitty.org> wrote:
> 
> Since I'm listed as one of the speakers, I was probably there.  But I don't remember that particular seminar at all.  OTOH, during the early 1980s I went from Boston to DC probably at least once a week, often to brief someone or some group on The Internet.  I do recall going to NBS, but can't remember exactly why.   It certainly could have been to give a talk on TCP for an hour to some audience.
> 
> That seminar was almost certainly part of DCA's efforts to support the standardization of TCP as a DoD Standard.  See, for example, RFC 761, published in January 1980 - with a seminar scheduled for November.
> 
> The adoption of TCP as a requirement for DoD procurements (not just research contracts) triggered a lot of big and small government contractors to get interested in exactly what this thing was that they were going to have to implement.  I recall even getting a phone call from a cousin, who worked at a big government shop, to get a little free education and advice.
> 
> So the NBS seminar was probably more of an educational venue for people new to TCP; it was likely not a place where nuances of retransmission algorithms would be of interest.
> 
> At the time, the ARPANET had been transferred from ARPA to DCA.  Research results were progressing towards operation, part of the "technology transfer" impetus.  Joe Haughney was in charge of the ARPANET in DCA Code 535.  IIRC, there's a lot more detail in the podcasts which Joe's daughter Christine put together recently - see https://www.inc.com/podcasts/computer-freaks
> 
> Jack Haverty



From karl at iwl.com  Fri Apr 25 16:03:00 2025
From: karl at iwl.com (Karl Auerbach)
Date: Fri, 25 Apr 2025 16:03:00 -0700
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
 <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
 <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>
 <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>
Message-ID: <e5460639-a79f-4bb7-8acd-98fc12e30435@iwl.com>



On 4/25/25 3:17 PM, Greg Skinner via Internet-history wrote:

> So far, based on what I?ve read, I don?t see any evidence that the concerns of the military, or users of lossy networks, were given insufficient consideration.

For a while (circa 1972/73), while at SDC, I worked on projects for the 
US Joint Chiefs of Staff.

We were working on packet switched networking issues, mostly for 
tactical communications.  And we were highly concerned with lossy 
networks - not only in terms of packet loss (or corruption) but also 
with the loss of physical assets, such as routers/gateways disappearing 
(usually accompanied by a loud "boom" from conventional explosives or 
intense X-rays from a nuclear blast - the "cold war" was running rather 
hot at the time.)

(We were also concerned with the physical capture of operating packet 
switching devices or the links between them.  I remember one project 
where we were concerned about loss of devices due to them being dropped 
into the mud by tired Marines slogging across a battlefield.)

This was well before the advent of TCP but the idea of highly dynamic 
routing of store-and-forward packets was well accepted as the right road 
forward.

Much of what I saw during those years was hidden behind cone-of-silence 
upon cone-of-silence - Our world was "we don't talk about it" or 
"everything is classified".  (I even got dinged for publishing a piece 
based only on open source/unclassified materials.)

So it would not be surprising that the academic and tech communities 
that were not inside our security walls did not hear us loudly 
expressing our concerns.

	--karl--


From jack at 3kitty.org  Fri Apr 25 16:13:38 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 25 Apr 2025 16:13:38 -0700
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
 <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
 <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>
 <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>
Message-ID: <6f6c08fe-1402-4fa4-bb14-f87cd4e1a99c@3kitty.org>

The managers in the military hierarchy mostly had to trust their 
technical staff, who were either within the military or one of their 
contractors, for technical issues.??? DCA was responsible for operating 
communications infrastructure and changing it as new technologies became 
viable.?? ARPA was responsible for supplying a stream of new 
technologies.?? Together they ran the "pipeline" to move ideas from 
research to operational systems.

DCA had a "lab" arm, called the Defense Communications Engineering 
Center (DCEC) where technologies, such as TCP/IP, were tested and judged 
to be, or not yet be, appropriate, for general deployment throughout 
DoD.? Ed Cain was in charge of a lab for evaluating TCP/IP. ? He was 
also a member of Vint's ICCB.? So DCA was aware of the outstanding issues.

But other issues are usually surfaced as any new technology goes into an 
operational environment. Getting "in the field" experience as early as 
possible provides a way to shake out those operational issues, and feed 
them back into the technical evolution.

SATNET had been operated by ARPA for a while, but MATNET, a clone of 
SATNET, was also being evaluated by a Navy lab, run by Frank Deckelman, 
with its nodes on ships such as the USS Carl Vinson. Similarly, Packet 
Radio networks were in use at places like Fort Bragg and elsewhere to 
get similar operational experience in the Army.? All such testbeds could 
generate feedback of issues important to military needs.

TCP/IP was ready enough to go "into the field", but was known to be not 
yet "done".? There was a list of outstanding issues that the ICCB kept, 
of things that needed to be addressed but were not yet resolved by us 
"techies".? Many of the issues involved routing, as well as how to best 
support a mix of traffic types with different needs for "type of 
service".? These were all things that us techies simply didn't know how 
to do yet.

While the then-current version of TCP/IP (V4) was deployed and 
operational experience gathered, the outstanding issues could be 
addressed by the ongoing Research Community, to discuss, debate, test, 
and choose appropriate mechanisms for each of the pending issues, and 
incorporate them in the next release of TCP/IP Specifications.

Meanwhile, the limitations of the current release were understood and 
avoided.?? IP Fragmentation is one example; we knew it didn't work very 
well, but the "Don't Fragment" bit was added to provide a way to avoid it.

So, important "features" weren't "omitted".? They were targetted to be 
solved and incorporated in a future release, once the technical experts 
reached "rough consensus and running code".

The Defense Research Internet (DRI) was supposed to be a new high-speed 
network to provide a foundation for continuing such research, such as 
the "policy routing" and "type of service" requirements that were on the 
to-do list.

I don't myself know much about the DRI though, or what role it might 
have played in creating the "next release" of TCP/IP? (V6?).? Or if DRI 
ever got built at all.? Perhaps someone else does.

I think the whole Internet world changed quite a bit when NSF got 
involved, and when the commercial world chose TCP/IP as their target 
architecture.? The military became just one of a global list of 
customers.?? NSF instigated the creation of a bunch of regional 
networks, with a mandate and deadline to become self-sufficient, and 
public ISPs started to spread as a result - leading to The Internet we 
know today.

Jack Haverty

On 4/25/25 15:17, Greg Skinner wrote:
> Just to clarify, I have listened to the computer-freaks podcasts about 
> Joe Haughney. ?He (and his successors) had access to information about 
> the TCP/IP implementations that were discussed at the meetings 
> summarized in the IEN notes. ?So in theory, there was a means for them 
> to raise concerns about retransmission algorithms, or collect 
> information that could be passed on to people who had those concerns. 
> ?Furthermore, they were getting feedback on the tcp-ip list about 
> implementation concerns, in general. [1]
>
> So far, based on what I?ve read, I don?t see any evidence that the 
> concerns of the military, or users of lossy networks, were given 
> insufficient consideration. ?I see that there were features left out 
> of RFC 793 that could have mitigated some retransmission issues that 
> impacted performance. ?But there were DCA people involved who, in 
> theory, could have questioned the wisdom of omitting those features, 
> at least.
>
> --gregbo
>
> [1] https://www.columbia.edu/~rh120/other/tcpdigest_paper.txt
>
>
>> On Apr 25, 2025, at 11:11?AM, Jack Haverty <jack at 3kitty.org> wrote:
>>
>> Since I'm listed as one of the speakers, I was probably there.? But I 
>> don't remember that particular seminar at all.? OTOH, during the 
>> early 1980s I went from Boston to DC probably at least once a week, 
>> often to brief someone or some group on The Internet.? I do recall 
>> going to NBS, but can't remember exactly why. It certainly could have 
>> been to give a talk on TCP for an hour to some audience.
>>
>> That seminar was almost certainly part of DCA's efforts to support 
>> the standardization of TCP as a DoD Standard.? See, for example, RFC 
>> 761, published in January 1980 - with a seminar scheduled for November.
>>
>> The adoption of TCP as a requirement for DoD procurements (not just 
>> research contracts) triggered a lot of big and small government 
>> contractors to get interested in exactly what this thing was that 
>> they were going to have to implement.? I recall even getting a phone 
>> call from a cousin, who worked at a big government shop, to get a 
>> little free education and advice.
>>
>> So the NBS seminar was probably more of an educational venue for 
>> people new to TCP; it was likely not a place where nuances of 
>> retransmission algorithms would be of interest.
>>
>> At the time, the ARPANET had been transferred from ARPA to DCA.? 
>> Research results were progressing towards operation, part of the 
>> "technology transfer" impetus.? Joe Haughney was in charge of the 
>> ARPANET in DCA Code 535.? IIRC, there's a lot more detail in the 
>> podcasts which Joe's daughter Christine put together recently - see 
>> https://www.inc.com/podcasts/computer-freaks
>>
>> Jack Haverty
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250425/b777b588/attachment.asc>

From jack at 3kitty.org  Fri Apr 25 16:28:11 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 25 Apr 2025 16:28:11 -0700
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <e5460639-a79f-4bb7-8acd-98fc12e30435@iwl.com>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
 <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
 <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>
 <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>
 <e5460639-a79f-4bb7-8acd-98fc12e30435@iwl.com>
Message-ID: <dc2840f7-dfe9-443e-b5c0-6fb638e8ec10@3kitty.org>

You reminded me of another item on the to-do list for routing mechanisms 
-- how do we "excise" a particular router (e.g., that had been captured) 
from the network?"

Curiously, I've much later realized this is not so different from how 
you excise a network node that has been successfully attacked by 
malware.?? Seems possibly harder, especially to detect, because there's 
probably no "boom" involved to indicate something bad has happened.

We knew about the possibility of such events.?? I remember Metcalfe once 
telling the story of a 1980s bug in a maintenance tool at Xerox PARC 
which was wreaking havoc throughout their network, and had "holed up" in 
the CEOs workstation which was inaccessible to the techie minions.

Jack

On 4/25/25 16:03, Karl Auerbach via Internet-history wrote:
>
>
> On 4/25/25 3:17 PM, Greg Skinner via Internet-history wrote:
>
>> So far, based on what I?ve read, I don?t see any evidence that the 
>> concerns of the military, or users of lossy networks, were given 
>> insufficient consideration.
>
> For a while (circa 1972/73), while at SDC, I worked on projects for 
> the US Joint Chiefs of Staff.
>
> We were working on packet switched networking issues, mostly for 
> tactical communications.? And we were highly concerned with lossy 
> networks - not only in terms of packet loss (or corruption) but also 
> with the loss of physical assets, such as routers/gateways 
> disappearing (usually accompanied by a loud "boom" from conventional 
> explosives or intense X-rays from a nuclear blast - the "cold war" was 
> running rather hot at the time.)
>
> (We were also concerned with the physical capture of operating packet 
> switching devices or the links between them.? I remember one project 
> where we were concerned about loss of devices due to them being 
> dropped into the mud by tired Marines slogging across a battlefield.)
>
> This was well before the advent of TCP but the idea of highly dynamic 
> routing of store-and-forward packets was well accepted as the right 
> road forward.
>
> Much of what I saw during those years was hidden behind 
> cone-of-silence upon cone-of-silence - Our world was "we don't talk 
> about it" or "everything is classified".? (I even got dinged for 
> publishing a piece based only on open source/unclassified materials.)
>
> So it would not be surprising that the academic and tech communities 
> that were not inside our security walls did not hear us loudly 
> expressing our concerns.
>
> ????--karl--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250425/a711c868/attachment.asc>

From b_a_denny at yahoo.com  Fri Apr 25 17:43:38 2025
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Sat, 26 Apr 2025 00:43:38 +0000 (UTC)
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <e5460639-a79f-4bb7-8acd-98fc12e30435@iwl.com>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
 <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
 <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>
 <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>
 <e5460639-a79f-4bb7-8acd-98fc12e30435@iwl.com>
Message-ID: <1973258168.2022519.1745628218462@mail.yahoo.com>

 Anyone out there know what happened to a project I think was called SAPE ( Strategic Adaptive Planning Experiments(?)).? The RFP was in the early to mid 80s and could have had some interesting networking stuff to look at. I worked on the proposal more than once: SRI kept having to rewrite the proposal because things? kept getting contested by bidders?? if I remember right. I think the RFP changed enough over time that SRI dropped out in the bidding process so I never heard what happened.
barbara
    On Friday, April 25, 2025 at 04:03:12 PM PDT, Karl Auerbach via Internet-history <internet-history at elists.isoc.org> wrote:
On 4/25/25 3:17 PM, Greg Skinner via Internet-history wrote:

> So far, based on what I?ve read, I don?t see any evidence that the concerns of the military, or users of lossy networks, were given insufficient consideration.

For a while (circa 1972/73), while at SDC, I worked on projects for the 
US Joint Chiefs of Staff.

We were working on packet switched networking issues, mostly for 
tactical communications.? And we were highly concerned with lossy 
networks - not only in terms of packet loss (or corruption) but also 
with the loss of physical assets, such as routers/gateways disappearing 
(usually accompanied by a loud "boom" from conventional explosives or 
intense X-rays from a nuclear blast - the "cold war" was running rather 
hot at the time.)

(We were also concerned with the physical capture of operating packet 
switching devices or the links between them.? I remember one project 
where we were concerned about loss of devices due to them being dropped 
into the mud by tired Marines slogging across a battlefield.)

This was well before the advent of TCP but the idea of highly dynamic 
routing of store-and-forward packets was well accepted as the right road 
forward.

Much of what I saw during those years was hidden behind cone-of-silence 
upon cone-of-silence - Our world was "we don't talk about it" or 
"everything is classified".? (I even got dinged for publishing a piece 
based only on open source/unclassified materials.)

So it would not be surprising that the academic and tech communities 
that were not inside our security walls did not hear us loudly 
expressing our concerns.

??? --karl--
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  

From vint at google.com  Sat Apr 26 03:58:09 2025
From: vint at google.com (Vint Cerf)
Date: Sat, 26 Apr 2025 06:58:09 -0400
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <6f6c08fe-1402-4fa4-bb14-f87cd4e1a99c@3kitty.org>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
 <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
 <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>
 <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>
 <6f6c08fe-1402-4fa4-bb14-f87cd4e1a99c@3kitty.org>
Message-ID: <CAHxHggfF8watWE3Z6h5JRkTay-X2X-70vsuJ75S8_XeBw-XW_A@mail.gmail.com>

I worked closely with Ed Cain at DCEC. In fact, while I was still at
Stanford, I used to fly in on the red-eye to Dulles, go to DCEC  building
which is now walking distance from my Reston Office at Google, and worked
on the BCR project.I would take a late afternoon flight to get back to SFO
and go to my morning lectures the next day. If memory serves, some of the
BCRs were installed at DCEC, on Wiehle Ave/Sunset Blvd. I even seem to
recall that BCR TCP retransmissions hid a flaky connection until we
realized the data rates we were getting were much worse than reasonably
expected. Ed or someone reporting to him pulled up a floor plate to
discover the flaky connector.

v


On Fri, Apr 25, 2025 at 7:13?PM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:

> The managers in the military hierarchy mostly had to trust their
> technical staff, who were either within the military or one of their
> contractors, for technical issues.    DCA was responsible for operating
> communications infrastructure and changing it as new technologies became
> viable.   ARPA was responsible for supplying a stream of new
> technologies.   Together they ran the "pipeline" to move ideas from
> research to operational systems.
>
> DCA had a "lab" arm, called the Defense Communications Engineering
> Center (DCEC) where technologies, such as TCP/IP, were tested and judged
> to be, or not yet be, appropriate, for general deployment throughout
> DoD.  Ed Cain was in charge of a lab for evaluating TCP/IP.   He was
> also a member of Vint's ICCB.  So DCA was aware of the outstanding issues.
>
> But other issues are usually surfaced as any new technology goes into an
> operational environment. Getting "in the field" experience as early as
> possible provides a way to shake out those operational issues, and feed
> them back into the technical evolution.
>
> SATNET had been operated by ARPA for a while, but MATNET, a clone of
> SATNET, was also being evaluated by a Navy lab, run by Frank Deckelman,
> with its nodes on ships such as the USS Carl Vinson. Similarly, Packet
> Radio networks were in use at places like Fort Bragg and elsewhere to
> get similar operational experience in the Army.  All such testbeds could
> generate feedback of issues important to military needs.
>
> TCP/IP was ready enough to go "into the field", but was known to be not
> yet "done".  There was a list of outstanding issues that the ICCB kept,
> of things that needed to be addressed but were not yet resolved by us
> "techies".  Many of the issues involved routing, as well as how to best
> support a mix of traffic types with different needs for "type of
> service".  These were all things that us techies simply didn't know how
> to do yet.
>
> While the then-current version of TCP/IP (V4) was deployed and
> operational experience gathered, the outstanding issues could be
> addressed by the ongoing Research Community, to discuss, debate, test,
> and choose appropriate mechanisms for each of the pending issues, and
> incorporate them in the next release of TCP/IP Specifications.
>
> Meanwhile, the limitations of the current release were understood and
> avoided.   IP Fragmentation is one example; we knew it didn't work very
> well, but the "Don't Fragment" bit was added to provide a way to avoid it.
>
> So, important "features" weren't "omitted".  They were targetted to be
> solved and incorporated in a future release, once the technical experts
> reached "rough consensus and running code".
>
> The Defense Research Internet (DRI) was supposed to be a new high-speed
> network to provide a foundation for continuing such research, such as
> the "policy routing" and "type of service" requirements that were on the
> to-do list.
>
> I don't myself know much about the DRI though, or what role it might
> have played in creating the "next release" of TCP/IP  (V6?).  Or if DRI
> ever got built at all.  Perhaps someone else does.
>
> I think the whole Internet world changed quite a bit when NSF got
> involved, and when the commercial world chose TCP/IP as their target
> architecture.  The military became just one of a global list of
> customers.   NSF instigated the creation of a bunch of regional
> networks, with a mandate and deadline to become self-sufficient, and
> public ISPs started to spread as a result - leading to The Internet we
> know today.
>
> Jack Haverty
>
> On 4/25/25 15:17, Greg Skinner wrote:
> > Just to clarify, I have listened to the computer-freaks podcasts about
> > Joe Haughney.  He (and his successors) had access to information about
> > the TCP/IP implementations that were discussed at the meetings
> > summarized in the IEN notes.  So in theory, there was a means for them
> > to raise concerns about retransmission algorithms, or collect
> > information that could be passed on to people who had those concerns.
> >  Furthermore, they were getting feedback on the tcp-ip list about
> > implementation concerns, in general. [1]
> >
> > So far, based on what I?ve read, I don?t see any evidence that the
> > concerns of the military, or users of lossy networks, were given
> > insufficient consideration.  I see that there were features left out
> > of RFC 793 that could have mitigated some retransmission issues that
> > impacted performance.  But there were DCA people involved who, in
> > theory, could have questioned the wisdom of omitting those features,
> > at least.
> >
> > --gregbo
> >
> > [1] https://www.columbia.edu/~rh120/other/tcpdigest_paper.txt
> >
> >
> >> On Apr 25, 2025, at 11:11?AM, Jack Haverty <jack at 3kitty.org> wrote:
> >>
> >> Since I'm listed as one of the speakers, I was probably there.  But I
> >> don't remember that particular seminar at all.  OTOH, during the
> >> early 1980s I went from Boston to DC probably at least once a week,
> >> often to brief someone or some group on The Internet.  I do recall
> >> going to NBS, but can't remember exactly why. It certainly could have
> >> been to give a talk on TCP for an hour to some audience.
> >>
> >> That seminar was almost certainly part of DCA's efforts to support
> >> the standardization of TCP as a DoD Standard.  See, for example, RFC
> >> 761, published in January 1980 - with a seminar scheduled for November.
> >>
> >> The adoption of TCP as a requirement for DoD procurements (not just
> >> research contracts) triggered a lot of big and small government
> >> contractors to get interested in exactly what this thing was that
> >> they were going to have to implement.  I recall even getting a phone
> >> call from a cousin, who worked at a big government shop, to get a
> >> little free education and advice.
> >>
> >> So the NBS seminar was probably more of an educational venue for
> >> people new to TCP; it was likely not a place where nuances of
> >> retransmission algorithms would be of interest.
> >>
> >> At the time, the ARPANET had been transferred from ARPA to DCA.
> >> Research results were progressing towards operation, part of the
> >> "technology transfer" impetus.  Joe Haughney was in charge of the
> >> ARPANET in DCA Code 535.  IIRC, there's a lot more detail in the
> >> podcasts which Joe's daughter Christine put together recently - see
> >> https://www.inc.com/podcasts/computer-freaks
> >>
> >> Jack Haverty
> >
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


From jack at 3kitty.org  Sat Apr 26 12:55:25 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Sat, 26 Apr 2025 12:55:25 -0700
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <CAHxHggfF8watWE3Z6h5JRkTay-X2X-70vsuJ75S8_XeBw-XW_A@mail.gmail.com>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
 <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
 <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>
 <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>
 <6f6c08fe-1402-4fa4-bb14-f87cd4e1a99c@3kitty.org>
 <CAHxHggfF8watWE3Z6h5JRkTay-X2X-70vsuJ75S8_XeBw-XW_A@mail.gmail.com>
Message-ID: <52c0c468-8a90-4cb0-ac1d-a05e6a11cbb9@3kitty.org>

The TCP implementation I did for Unix on a PDP-11/40 was for use in the 
BCR project.? I also had lots of performance issues, some of which were 
finally traced to hardware issues such as connectors!

In the late 1960s as an undergraduate I had a student job programming a 
PDP-8 doing data collection at the MIT Instrumentation Lab (also known 
as "The ILab").? The group I worked for was designing and deploying 
inertial navigation systems.? At the time their focus was on the Apollo 
moon missions and "PIGA" devices (Pendulous Integrating Gyroscopic 
Accelerometers), but their technology had been in use for years in older 
systems such as the Minuteman ICBMs.?? (Google "minuteman piga" if 
you're curious).

In EE classes, we had been learning about all sorts of Engineering 
techniques for optimizing circuit designs - things like Karnaugh maps.? 
One day while sitting at my desk in the ILab, I realized that the 
engineer sitting at the next desk was an actual "rocket scientist" 
working on rocket stuff.? So I asked him what Engineering principles and 
techniques he found most useful in his design work.

His answer surprised me -- "Connectors are all that matters!".? All 
designs were focussed on minimizing the number of connectors. Nothing 
else was considered important, as long as it fit in the size, weight, 
and power budget.

Over years of accumulated field data, they had determined that failures 
were mainly associated with connectors.? A few extra logic gates didn't 
matter.? An extra connector made the system noticeably less reliable.

That's why computer problems even today sometimes disappear if you 
simply unplug and replug the cables.?? Any sliding metal-metal contact 
(i.e., a "connector") eventually corrodes and disrupts whatever signal 
was travelling through it. The sliding action of replugging usually 
cleans the contacts and things work again.

Plugging and replugging connectors isn't easy when the connector is 
somewhere between the Earth and Moon, or deep inside a missile buried in 
some farmer's field.? So that engineer told me that they avoided such 
problems by assuring that every circuit passing through a connector 
always had some tiny current flowing through it.?? Even a few microamps 
was enough to avoid corrosion.? That was another crucial design principle.

They didn't teach such things in school back then.?? I wonder if that's 
changed.

My desk neighbor was Oriental, and told me of an old "Confucian Curse", 
from a time far before electricity was discovered.? It applies to all 
sorts of "interfaces" and undoubtedly loses in the translation, but he 
said today's curse would be "May You Be In Charge Of Connectors!"

TCP does a wonderful job of hiding such problems.? Such experiences were 
what motivated me later to push hard for SNMP as instrumentation -- 
including instrumentation of TCP behavior in end-users computers.

My Unix TCP had counters for things like duplicates, retransmissions, 
and the like.? Such data was invaluable to even detect that something 
wasn't working as it should, whether it was a bug in the software, a 
defect in the protocol, or a flaky connector under the floor.?? When I 
was later involved in operating a large intranet, such mechanisms were 
very useful in figuring out why the users were rightly complaining about 
network performance.

Connectors in networking, whether they are plugs/sockets, protocols, or 
APIs, matter.

Jack Haverty


On 4/26/25 03:58, Vint Cerf wrote:
> I worked closely with Ed Cain at DCEC. In fact, while I was still at 
> Stanford, I used to fly in on the red-eye to Dulles, go to DCEC? 
> building which is now walking distance from my Reston Office at 
> Google, and worked on the BCR project.I would take a late afternoon 
> flight to get back to SFO and go to my morning lectures the next day. 
> If memory serves, some of the BCRs were installed at DCEC, on Wiehle 
> Ave/Sunset Blvd. I even seem to recall that BCR TCP retransmissions 
> hid a flaky connection until we realized the data rates we were 
> getting were much worse than reasonably expected. Ed or someone 
> reporting to him pulled up a floor plate to discover the flaky connector.
>
> v
>
>
> On Fri, Apr 25, 2025 at 7:13?PM Jack Haverty via Internet-history 
> <internet-history at elists.isoc.org> wrote:
>
>     The managers in the military hierarchy mostly had to trust their
>     technical staff, who were either within the military or one of their
>     contractors, for technical issues.??? DCA was responsible for
>     operating
>     communications infrastructure and changing it as new technologies
>     became
>     viable.?? ARPA was responsible for supplying a stream of new
>     technologies.?? Together they ran the "pipeline" to move ideas from
>     research to operational systems.
>
>     DCA had a "lab" arm, called the Defense Communications Engineering
>     Center (DCEC) where technologies, such as TCP/IP, were tested and
>     judged
>     to be, or not yet be, appropriate, for general deployment throughout
>     DoD.? Ed Cain was in charge of a lab for evaluating TCP/IP. He was
>     also a member of Vint's ICCB.? So DCA was aware of the outstanding
>     issues.
>
>     But other issues are usually surfaced as any new technology goes
>     into an
>     operational environment. Getting "in the field" experience as
>     early as
>     possible provides a way to shake out those operational issues, and
>     feed
>     them back into the technical evolution.
>
>     SATNET had been operated by ARPA for a while, but MATNET, a clone of
>     SATNET, was also being evaluated by a Navy lab, run by Frank
>     Deckelman,
>     with its nodes on ships such as the USS Carl Vinson. Similarly,
>     Packet
>     Radio networks were in use at places like Fort Bragg and elsewhere to
>     get similar operational experience in the Army.? All such testbeds
>     could
>     generate feedback of issues important to military needs.
>
>     TCP/IP was ready enough to go "into the field", but was known to
>     be not
>     yet "done".? There was a list of outstanding issues that the ICCB
>     kept,
>     of things that needed to be addressed but were not yet resolved by us
>     "techies".? Many of the issues involved routing, as well as how to
>     best
>     support a mix of traffic types with different needs for "type of
>     service".? These were all things that us techies simply didn't
>     know how
>     to do yet.
>
>     While the then-current version of TCP/IP (V4) was deployed and
>     operational experience gathered, the outstanding issues could be
>     addressed by the ongoing Research Community, to discuss, debate,
>     test,
>     and choose appropriate mechanisms for each of the pending issues, and
>     incorporate them in the next release of TCP/IP Specifications.
>
>     Meanwhile, the limitations of the current release were understood and
>     avoided.?? IP Fragmentation is one example; we knew it didn't work
>     very
>     well, but the "Don't Fragment" bit was added to provide a way to
>     avoid it.
>
>     So, important "features" weren't "omitted".? They were targetted
>     to be
>     solved and incorporated in a future release, once the technical
>     experts
>     reached "rough consensus and running code".
>
>     The Defense Research Internet (DRI) was supposed to be a new
>     high-speed
>     network to provide a foundation for continuing such research, such as
>     the "policy routing" and "type of service" requirements that were
>     on the
>     to-do list.
>
>     I don't myself know much about the DRI though, or what role it might
>     have played in creating the "next release" of TCP/IP? (V6?). Or if
>     DRI
>     ever got built at all.? Perhaps someone else does.
>
>     I think the whole Internet world changed quite a bit when NSF got
>     involved, and when the commercial world chose TCP/IP as their target
>     architecture.? The military became just one of a global list of
>     customers.?? NSF instigated the creation of a bunch of regional
>     networks, with a mandate and deadline to become self-sufficient, and
>     public ISPs started to spread as a result - leading to The
>     Internet we
>     know today.
>
>     Jack Haverty
>
>     On 4/25/25 15:17, Greg Skinner wrote:
>     > Just to clarify, I have listened to the computer-freaks podcasts
>     about
>     > Joe Haughney.? He (and his successors) had access to information
>     about
>     > the TCP/IP implementations that were discussed at the meetings
>     > summarized in the IEN notes.? So in theory, there was a means
>     for them
>     > to raise concerns about retransmission algorithms, or collect
>     > information that could be passed on to people who had those
>     concerns.
>     > ?Furthermore, they were getting feedback on the tcp-ip list about
>     > implementation concerns, in general. [1]
>     >
>     > So far, based on what I?ve read, I don?t see any evidence that the
>     > concerns of the military, or users of lossy networks, were given
>     > insufficient consideration.? I see that there were features left
>     out
>     > of RFC 793 that could have mitigated some retransmission issues
>     that
>     > impacted performance.? But there were DCA people involved who, in
>     > theory, could have questioned the wisdom of omitting those
>     features,
>     > at least.
>     >
>     > --gregbo
>     >
>     > [1] https://www.columbia.edu/~rh120/other/tcpdigest_paper.txt
>     >
>     >
>     >> On Apr 25, 2025, at 11:11?AM, Jack Haverty <jack at 3kitty.org> wrote:
>     >>
>     >> Since I'm listed as one of the speakers, I was probably there.?
>     But I
>     >> don't remember that particular seminar at all.? OTOH, during the
>     >> early 1980s I went from Boston to DC probably at least once a
>     week,
>     >> often to brief someone or some group on The Internet.? I do recall
>     >> going to NBS, but can't remember exactly why. It certainly
>     could have
>     >> been to give a talk on TCP for an hour to some audience.
>     >>
>     >> That seminar was almost certainly part of DCA's efforts to support
>     >> the standardization of TCP as a DoD Standard.? See, for
>     example, RFC
>     >> 761, published in January 1980 - with a seminar scheduled for
>     November.
>     >>
>     >> The adoption of TCP as a requirement for DoD procurements (not
>     just
>     >> research contracts) triggered a lot of big and small government
>     >> contractors to get interested in exactly what this thing was that
>     >> they were going to have to implement.? I recall even getting a
>     phone
>     >> call from a cousin, who worked at a big government shop, to get a
>     >> little free education and advice.
>     >>
>     >> So the NBS seminar was probably more of an educational venue for
>     >> people new to TCP; it was likely not a place where nuances of
>     >> retransmission algorithms would be of interest.
>     >>
>     >> At the time, the ARPANET had been transferred from ARPA to DCA.
>     >> Research results were progressing towards operation, part of the
>     >> "technology transfer" impetus.? Joe Haughney was in charge of the
>     >> ARPANET in DCA Code 535.? IIRC, there's a lot more detail in the
>     >> podcasts which Joe's daughter Christine put together recently -
>     see
>     >> https://www.inc.com/podcasts/computer-freaks
>     >>
>     >> Jack Haverty
>     >
>
>     -- 
>     Internet-history mailing list
>     Internet-history at elists.isoc.org
>     https://elists.isoc.org/mailman/listinfo/internet-history
>
>
>
> -- 
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250426/12a7a695/attachment.asc>

From jack at 3kitty.org  Sun Apr 27 11:48:37 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Sun, 27 Apr 2025 11:48:37 -0700
Subject: [ih] NBS seminar on TCP/IP (was TCP RTT Estimator)
In-Reply-To: <CAAFtm_XcQbKiANQP6YA6-4cKbZnayQySDmxSZ2dZ8Ns_8v_NiQ@mail.gmail.com>
References: <BA9AA438-ACC1-45B0-BF22-6136194B436B@comcast.net>
 <170AAE14-29E7-4100-9A7E-4B4066B40503@strayalpha.com>
 <aa99d487-5225-4862-a1c3-6a748ba3aea6@3kitty.org>
 <E2C8A7DE-0033-467C-964A-F93D3818C432@icloud.com>
 <e1946492-6be9-4b3a-b273-02b6376a88d8@3kitty.org>
 <318C6912-939C-4E3B-B87E-7F4F2B3E8771@icloud.com>
 <6f6c08fe-1402-4fa4-bb14-f87cd4e1a99c@3kitty.org>
 <CAHxHggfF8watWE3Z6h5JRkTay-X2X-70vsuJ75S8_XeBw-XW_A@mail.gmail.com>
 <52c0c468-8a90-4cb0-ac1d-a05e6a11cbb9@3kitty.org>
 <CAAFtm_XcQbKiANQP6YA6-4cKbZnayQySDmxSZ2dZ8Ns_8v_NiQ@mail.gmail.com>
Message-ID: <74671b82-92ae-438b-b18a-1396dce4aaf5@3kitty.org>

I'm working on it.....

On 4/27/25 06:11, vinton cerf wrote:
> thanks?for a great story, Jack! Your adventures in Internet-land 
> deserve a book of its own.
>
> v
>
>
> On Sat, Apr 26, 2025 at 3:55?PM Jack Haverty via Internet-history 
> <internet-history at elists.isoc.org> wrote:
>
>     The TCP implementation I did for Unix on a PDP-11/40 was for use
>     in the
>     BCR project.? I also had lots of performance issues, some of which
>     were
>     finally traced to hardware issues such as connectors!
>
>     In the late 1960s as an undergraduate I had a student job
>     programming a
>     PDP-8 doing data collection at the MIT Instrumentation Lab (also
>     known
>     as "The ILab").? The group I worked for was designing and deploying
>     inertial navigation systems.? At the time their focus was on the
>     Apollo
>     moon missions and "PIGA" devices (Pendulous Integrating Gyroscopic
>     Accelerometers), but their technology had been in use for years in
>     older
>     systems such as the Minuteman ICBMs.?? (Google "minuteman piga" if
>     you're curious).
>
>     In EE classes, we had been learning about all sorts of Engineering
>     techniques for optimizing circuit designs - things like Karnaugh
>     maps.
>     One day while sitting at my desk in the ILab, I realized that the
>     engineer sitting at the next desk was an actual "rocket scientist"
>     working on rocket stuff.? So I asked him what Engineering
>     principles and
>     techniques he found most useful in his design work.
>
>     His answer surprised me -- "Connectors are all that matters!".? All
>     designs were focussed on minimizing the number of connectors. Nothing
>     else was considered important, as long as it fit in the size, weight,
>     and power budget.
>
>     Over years of accumulated field data, they had determined that
>     failures
>     were mainly associated with connectors.? A few extra logic gates
>     didn't
>     matter.? An extra connector made the system noticeably less reliable.
>
>     That's why computer problems even today sometimes disappear if you
>     simply unplug and replug the cables.?? Any sliding metal-metal
>     contact
>     (i.e., a "connector") eventually corrodes and disrupts whatever
>     signal
>     was travelling through it. The sliding action of replugging usually
>     cleans the contacts and things work again.
>
>     Plugging and replugging connectors isn't easy when the connector is
>     somewhere between the Earth and Moon, or deep inside a missile
>     buried in
>     some farmer's field.? So that engineer told me that they avoided such
>     problems by assuring that every circuit passing through a connector
>     always had some tiny current flowing through it.?? Even a few
>     microamps
>     was enough to avoid corrosion.? That was another crucial design
>     principle.
>
>     They didn't teach such things in school back then.?? I wonder if
>     that's
>     changed.
>
>     My desk neighbor was Oriental, and told me of an old "Confucian
>     Curse",
>     from a time far before electricity was discovered.? It applies to all
>     sorts of "interfaces" and undoubtedly loses in the translation,
>     but he
>     said today's curse would be "May You Be In Charge Of Connectors!"
>
>     TCP does a wonderful job of hiding such problems.? Such
>     experiences were
>     what motivated me later to push hard for SNMP as instrumentation --
>     including instrumentation of TCP behavior in end-users computers.
>
>     My Unix TCP had counters for things like duplicates, retransmissions,
>     and the like.? Such data was invaluable to even detect that something
>     wasn't working as it should, whether it was a bug in the software, a
>     defect in the protocol, or a flaky connector under the floor.??
>     When I
>     was later involved in operating a large intranet, such mechanisms
>     were
>     very useful in figuring out why the users were rightly complaining
>     about
>     network performance.
>
>     Connectors in networking, whether they are plugs/sockets,
>     protocols, or
>     APIs, matter.
>
>     Jack Haverty
>
>
>     On 4/26/25 03:58, Vint Cerf wrote:
>     > I worked closely with Ed Cain at DCEC. In fact, while I was
>     still at
>     > Stanford, I used to fly in on the red-eye to Dulles, go to DCEC
>     > building which is now walking distance from my Reston Office at
>     > Google, and worked on the BCR project.I would take a late afternoon
>     > flight to get back to SFO and go to my morning lectures the next
>     day.
>     > If memory serves, some of the BCRs were installed at DCEC, on
>     Wiehle
>     > Ave/Sunset Blvd. I even seem to recall that BCR TCP retransmissions
>     > hid a flaky connection until we realized the data rates we were
>     > getting were much worse than reasonably expected. Ed or someone
>     > reporting to him pulled up a floor plate to discover the flaky
>     connector.
>     >
>     > v
>     >
>     >
>     > On Fri, Apr 25, 2025 at 7:13?PM Jack Haverty via Internet-history
>     > <internet-history at elists.isoc.org> wrote:
>     >
>     >? ? ?The managers in the military hierarchy mostly had to trust their
>     >? ? ?technical staff, who were either within the military or one
>     of their
>     >? ? ?contractors, for technical issues.??? DCA was responsible for
>     >? ? ?operating
>     >? ? ?communications infrastructure and changing it as new
>     technologies
>     >? ? ?became
>     >? ? ?viable.?? ARPA was responsible for supplying a stream of new
>     >? ? ?technologies.?? Together they ran the "pipeline" to move
>     ideas from
>     >? ? ?research to operational systems.
>     >
>     >? ? ?DCA had a "lab" arm, called the Defense Communications
>     Engineering
>     >? ? ?Center (DCEC) where technologies, such as TCP/IP, were
>     tested and
>     >? ? ?judged
>     >? ? ?to be, or not yet be, appropriate, for general deployment
>     throughout
>     >? ? ?DoD.? Ed Cain was in charge of a lab for evaluating TCP/IP.
>     He was
>     >? ? ?also a member of Vint's ICCB.? So DCA was aware of the
>     outstanding
>     >? ? ?issues.
>     >
>     >? ? ?But other issues are usually surfaced as any new technology goes
>     >? ? ?into an
>     >? ? ?operational environment. Getting "in the field" experience as
>     >? ? ?early as
>     >? ? ?possible provides a way to shake out those operational
>     issues, and
>     >? ? ?feed
>     >? ? ?them back into the technical evolution.
>     >
>     >? ? ?SATNET had been operated by ARPA for a while, but MATNET, a
>     clone of
>     >? ? ?SATNET, was also being evaluated by a Navy lab, run by Frank
>     >? ? ?Deckelman,
>     >? ? ?with its nodes on ships such as the USS Carl Vinson. Similarly,
>     >? ? ?Packet
>     >? ? ?Radio networks were in use at places like Fort Bragg and
>     elsewhere to
>     >? ? ?get similar operational experience in the Army.? All such
>     testbeds
>     >? ? ?could
>     >? ? ?generate feedback of issues important to military needs.
>     >
>     >? ? ?TCP/IP was ready enough to go "into the field", but was known to
>     >? ? ?be not
>     >? ? ?yet "done".? There was a list of outstanding issues that the
>     ICCB
>     >? ? ?kept,
>     >? ? ?of things that needed to be addressed but were not yet
>     resolved by us
>     >? ? ?"techies".? Many of the issues involved routing, as well as
>     how to
>     >? ? ?best
>     >? ? ?support a mix of traffic types with different needs for "type of
>     >? ? ?service".? These were all things that us techies simply didn't
>     >? ? ?know how
>     >? ? ?to do yet.
>     >
>     >? ? ?While the then-current version of TCP/IP (V4) was deployed and
>     >? ? ?operational experience gathered, the outstanding issues could be
>     >? ? ?addressed by the ongoing Research Community, to discuss, debate,
>     >? ? ?test,
>     >? ? ?and choose appropriate mechanisms for each of the pending
>     issues, and
>     >? ? ?incorporate them in the next release of TCP/IP Specifications.
>     >
>     >? ? ?Meanwhile, the limitations of the current release were
>     understood and
>     >? ? ?avoided.?? IP Fragmentation is one example; we knew it
>     didn't work
>     >? ? ?very
>     >? ? ?well, but the "Don't Fragment" bit was added to provide a way to
>     >? ? ?avoid it.
>     >
>     >? ? ?So, important "features" weren't "omitted".? They were targetted
>     >? ? ?to be
>     >? ? ?solved and incorporated in a future release, once the technical
>     >? ? ?experts
>     >? ? ?reached "rough consensus and running code".
>     >
>     >? ? ?The Defense Research Internet (DRI) was supposed to be a new
>     >? ? ?high-speed
>     >? ? ?network to provide a foundation for continuing such
>     research, such as
>     >? ? ?the "policy routing" and "type of service" requirements that
>     were
>     >? ? ?on the
>     >? ? ?to-do list.
>     >
>     >? ? ?I don't myself know much about the DRI though, or what role
>     it might
>     >? ? ?have played in creating the "next release" of TCP/IP (V6?).
>     Or if
>     >? ? ?DRI
>     >? ? ?ever got built at all.? Perhaps someone else does.
>     >
>     >? ? ?I think the whole Internet world changed quite a bit when
>     NSF got
>     >? ? ?involved, and when the commercial world chose TCP/IP as
>     their target
>     >? ? ?architecture.? The military became just one of a global list of
>     >? ? ?customers.?? NSF instigated the creation of a bunch of regional
>     >? ? ?networks, with a mandate and deadline to become
>     self-sufficient, and
>     >? ? ?public ISPs started to spread as a result - leading to The
>     >? ? ?Internet we
>     >? ? ?know today.
>     >
>     >? ? ?Jack Haverty
>     >
>     >? ? ?On 4/25/25 15:17, Greg Skinner wrote:
>     >? ? ?> Just to clarify, I have listened to the computer-freaks
>     podcasts
>     >? ? ?about
>     >? ? ?> Joe Haughney.? He (and his successors) had access to
>     information
>     >? ? ?about
>     >? ? ?> the TCP/IP implementations that were discussed at the meetings
>     >? ? ?> summarized in the IEN notes.? So in theory, there was a means
>     >? ? ?for them
>     >? ? ?> to raise concerns about retransmission algorithms, or collect
>     >? ? ?> information that could be passed on to people who had those
>     >? ? ?concerns.
>     >? ? ?> ?Furthermore, they were getting feedback on the tcp-ip
>     list about
>     >? ? ?> implementation concerns, in general. [1]
>     >? ? ?>
>     >? ? ?> So far, based on what I?ve read, I don?t see any evidence
>     that the
>     >? ? ?> concerns of the military, or users of lossy networks, were
>     given
>     >? ? ?> insufficient consideration.? I see that there were
>     features left
>     >? ? ?out
>     >? ? ?> of RFC 793 that could have mitigated some retransmission
>     issues
>     >? ? ?that
>     >? ? ?> impacted performance.? But there were DCA people involved
>     who, in
>     >? ? ?> theory, could have questioned the wisdom of omitting those
>     >? ? ?features,
>     >? ? ?> at least.
>     >? ? ?>
>     >? ? ?> --gregbo
>     >? ? ?>
>     >? ? ?> [1] https://www.columbia.edu/~rh120/other/tcpdigest_paper.txt
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>> On Apr 25, 2025, at 11:11?AM, Jack Haverty
>     <jack at 3kitty.org> wrote:
>     >? ? ?>>
>     >? ? ?>> Since I'm listed as one of the speakers, I was probably
>     there.
>     >? ? ?But I
>     >? ? ?>> don't remember that particular seminar at all.? OTOH,
>     during the
>     >? ? ?>> early 1980s I went from Boston to DC probably at least once a
>     >? ? ?week,
>     >? ? ?>> often to brief someone or some group on The Internet.? I
>     do recall
>     >? ? ?>> going to NBS, but can't remember exactly why. It certainly
>     >? ? ?could have
>     >? ? ?>> been to give a talk on TCP for an hour to some audience.
>     >? ? ?>>
>     >? ? ?>> That seminar was almost certainly part of DCA's efforts
>     to support
>     >? ? ?>> the standardization of TCP as a DoD Standard.? See, for
>     >? ? ?example, RFC
>     >? ? ?>> 761, published in January 1980 - with a seminar scheduled for
>     >? ? ?November.
>     >? ? ?>>
>     >? ? ?>> The adoption of TCP as a requirement for DoD procurements
>     (not
>     >? ? ?just
>     >? ? ?>> research contracts) triggered a lot of big and small
>     government
>     >? ? ?>> contractors to get interested in exactly what this thing
>     was that
>     >? ? ?>> they were going to have to implement.? I recall even
>     getting a
>     >? ? ?phone
>     >? ? ?>> call from a cousin, who worked at a big government shop,
>     to get a
>     >? ? ?>> little free education and advice.
>     >? ? ?>>
>     >? ? ?>> So the NBS seminar was probably more of an educational
>     venue for
>     >? ? ?>> people new to TCP; it was likely not a place where nuances of
>     >? ? ?>> retransmission algorithms would be of interest.
>     >? ? ?>>
>     >? ? ?>> At the time, the ARPANET had been transferred from ARPA
>     to DCA.
>     >? ? ?>> Research results were progressing towards operation, part
>     of the
>     >? ? ?>> "technology transfer" impetus.? Joe Haughney was in
>     charge of the
>     >? ? ?>> ARPANET in DCA Code 535.? IIRC, there's a lot more detail
>     in the
>     >? ? ?>> podcasts which Joe's daughter Christine put together
>     recently -
>     >? ? ?see
>     >? ? ?>> https://www.inc.com/podcasts/computer-freaks
>     >? ? ?>>
>     >? ? ?>> Jack Haverty
>     >? ? ?>
>     >
>     >? ? ?--
>     >? ? ?Internet-history mailing list
>     > Internet-history at elists.isoc.org
>     > https://elists.isoc.org/mailman/listinfo/internet-history
>     >
>     >
>     >
>     > --
>     > Please send any postal/overnight deliveries to:
>     > Vint Cerf
>     > Google, LLC
>     > 1900 Reston Metro Plaza, 16th Floor
>     > Reston, VA 20190
>     > +1 (571) 213 1346
>     >
>     >
>     > until further notice
>     >
>     >
>     >
>
>     -- 
>     Internet-history mailing list
>     Internet-history at elists.isoc.org
>     https://elists.isoc.org/mailman/listinfo/internet-history
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250427/1213520c/attachment.asc>

From mfidelman at meetinghouse.net  Wed Apr 23 04:56:52 2025
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Wed, 23 Apr 2025 07:56:52 -0400
Subject: [ih] A comment on the seven layer model
In-Reply-To: <967634e2-b4c1-44db-9d2f-b094ef5e48cf@3kitty.org>
References: <CAHxHggenT+aPv1oKDLouyj9LJebqN-bjHDCb1fmmtCZ8tPe20A@mail.gmail.com>
 <0BD088A1-2B87-4608-9601-55616D6ED048@comcast.net>
 <CAEf-zriY0GZB9WG-BYxWKQi3yzYLoiTuBCvri0oArbULMV7Q3g@mail.gmail.com>
 <CAEf-zrjx0XRM56H0L7VEwgNc_Y3=N5u1hWs+Sjvk+UrL22dE=A@mail.gmail.com>
 <CAAFtm_UQFskWy+O989oV8qMRdCwj=0cpGc76yU5WqRwp0UBPzA@mail.gmail.com>
 <DE62AA40-5C92-4F11-8E92-51C3436B47EB@comcast.net>
 <CABf5zv+qpkanTSEtN-RE1cPuhy=L4AYsjndavMdDTOV8FYDXjQ@mail.gmail.com>
 <1c01b66e-0979-4bbb-a953-2bec35318a10@Julf.com>
 <20250422142400.2DA12C5A86D5@ary.qy>
 <CAHQj4Cc6j7Q+m38gg_U4VOhmwpkXG72V5s0nzw5cRdUQHABZVA@mail.gmail.com>
 <401cbd61a1063d7c@orthanc.ca>
 <CAEf-zrjdTQrOJ9bJSiGVB-7VJPvLQA2MiajAHzQvRgwL1Do1LQ@mail.gmail.com>
 <401cbe00edefdb0f@orthanc.ca>
 <CAC20D2N5Ni3qwCp6peVQrzLDVAAwBFv1=vfYKu407xsZeK+1_A@mail.gmail.com>
 <22962f74-0b50-44f5-a8c1-c2d1aef8c104@3kitty.org>
 <CABf5zv+O=pmNiqP8EUMR=8OHvqzLkgZWQXckzeiX6DraExtMhw@mail.gmail.com>
 <967634e2-b4c1-44db-9d2f-b094ef5e48cf@3kitty.org>
Message-ID: <c2679288-099a-27b7-ff5d-c785d9ef4a4f@meetinghouse.net>

Jack Haverty via Internet-history wrote:
> On 4/22/25 13:58, Steve Crocker wrote:
>> Jack,
>>
>> I liked your comment, "I gave up long ago on trying to stuff this 
>> into a 7-layer diagram and explain it."
>>
>
> My first encounter with Networking was when I became one of Lick's 
> thesis students, and got thoroughly indoctrinated into his 
> "Intergalactic Network" vision. ? Later he was my boss as we worked to 
> implement some of his vision with not enough computer or networking 
> power.?? Computers would be somehow connected through networks, every 
> user would have their own "personal computer", and those computers 
> would interact to help humans do whatever humans do, only occasionally 
> actually interacting with the human through some kind of UI.
>
In 1968, Licklider & Taylor wrote "In a few years, men will be able to 
communicate more effectively through a machine than face to face."

In 1971, I arrived at MIT, Lick was back at MIT haunting the 545 Tech 
Square break room, I had an account on the AI Lab PDP-10, Ray Tomlinson 
sent the first email, Ken Pogran brought it to Multics, Alan Kay 
proclaimed "the best way to predict the future is to invent it," and the 
world of "rough consensus & running code" was off and running.? I caught 
a bug about email ruling the world, went off to launch a small email 
hosting company, build military systems at Sanders, then off to BBN to 
stay up late with wizards, networking the planet.? I had the great 
pleasure & privilege of working for Ken, and with Ray.? In 1992, the 
Internet opened to the public, Dave Clark coined the phrase "Rough 
Consensus & Running Code," and I launched the Center for Civic 
Networking - to bring IETF-style town-meeting democracy & infrastructure 
governance to the world.

Larry Lessig famously wrote, "code is law" - to which I add, "protocols 
implement law."? Rules of Engagement, Rules of Order, Standard Operating 
Procedures, Plans & Programs, the MDMP (Military Decision Making 
Process), RFPs & Proposals, the RFC process, crowdsourcing & grand 
challenges - all examples of high-level protocols, "cognitive protocols" 
or protocols of thought, protocols of community, collaboration, and 
creation if you will. The stuff of John Lilly & "Programming & 
Metaprogramming in the Human Biocomputer."

And now that we've networked the planet, connected 6 billion of us into 
an Internet of Minds, it's time to start thinking about what succeeds 
Roberts Rules for thinking & working together as a planetary scale human 
enterprise.

My sense is that these take the form of protocols that look a lot like 
language & engineering process - particularly Systems Engineering & 
Systems Engineering Management processes - Internet Engineering, and 
Infrastructure Acquisitions, Operations, Administration, Maintenance, 
and Governance processes as they're emerging from the open source world 
(massive concurrency, loose coupling, rough consensus, local initiative, 
tied together by Distributed Autonomous Organizations linked by 
protocols supporting massive replication).

----
Steve... I have to thank you for the writing prompt, the timing is 
perfect.? I think I've just written the preface to my next book, which 
is going to be titled something like:

Protocols Of Community, Collaboration, and Creation
Programming, Metaprogramming, Systems Programming, and Microprogramming 
for an Internet of Mind
The Art, Science, Technology & Craft of Building Worlds & Making History

along with the CONOPS & Systems Engineering Management Plan for Civic.Net
with the Mission Goal of Applying IETF & FOSS Models to Restoring Town 
Meeting Democracy, Rebuilding Neighborhood Infrastructure, and Rebooting 
America for another 250 Years of Life, Liberty, and the Pursuit of 
Happiness (or maybe Truth, Justice, and the American Way)

.... it's time to make some new Internet History!

Miles







-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown