From dave.taht at gmail.com Sun Feb 5 06:40:31 2023 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 5 Feb 2023 06:40:31 -0800 Subject: [ih] anyone know of a martin broadhurst? Message-ID: Recently I stumbled across a series of articles by him that were lovingly illustrative, incredibly clearly well written, and appeared to use a C library that I don't have, covering a ton of fundamental algorithms that I would like to have in my toolkit, still, in C, because that is how I still think. I first found him whilst I was looking for a binpacking algorithm(s) and benchmarks for how well they performed on modern hardware. https://web.archive.org/web/20190530024749/http://www.martinbroadhurst.com/tag/bin-packing And then I started reading the rest of his canon: Wow: https://web.archive.org/web/20190704202816/http://www.martinbroadhurst.com/author/martin Stuff like: http://www.martinbroadhurst.com/bellman-ford-algorithm-in-c.html http://www.martinbroadhurst.com/avl-tree-in-c.html Anyway, given that the site is down, and he hasn?t posted anything in a year, I fear he has passed on. I did find an obituary that had about the right timing... Did/does anyone here know him? -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz Dave T?ht CEO, TekLibre, LLC From jmamodio at gmail.com Sun Feb 5 10:55:08 2023 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 5 Feb 2023 12:55:08 -0600 Subject: [ih] anyone know of a martin broadhurst? In-Reply-To: References: Message-ID: Domain name seems to be active .... Domain Name: martinbroadhurst.com Registry Domain ID: 1614824179_DOMAIN_COM-VRSN Registrar WHOIS Server: WHOIS.ENOM.COM Registrar URL: WWW.ENOM.COM Updated Date: 2022-08-12T15:48:05.00Z Creation Date: 2010-09-08T15:32:17.00Z Registrar Registration Expiration Date: 2023-09-08T15:32:00.00Z Registrar: ENOM, INC. Registrar IANA ID: 48 DNS shows A and MX records ... ; <<>> DiG 9.16.1-Ubuntu <<>> martinbroadhurst.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40972 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;martinbroadhurst.com. IN A ;; ANSWER SECTION: martinbroadhurst.com. 7180 IN A 212.227.94.32 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Sun Feb 05 18:51:03 GMT 2023 ;; MSG SIZE rcvd: 65 ; <<>> DiG 9.16.1-Ubuntu <<>> -t mx martinbroadhurst.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36011 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;martinbroadhurst.com. IN MX ;; ANSWER SECTION: martinbroadhurst.com. 300 IN MX 10 mx.core.plus.net. ;; Query time: 147 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Sun Feb 05 18:51:27 GMT 2023 ;; MSG SIZE rcvd: 81 Didn't you find any contact info on the archives ? -J On Sun, Feb 5, 2023 at 10:09 AM Dave Taht via Internet-history < internet-history at elists.isoc.org> wrote: > Recently I stumbled across a series of articles by him that were > lovingly illustrative, incredibly clearly well written, and appeared > to use a C library that I don't have, covering a ton of fundamental > algorithms that I would like to have in my toolkit, still, in C, > because that is how I still think. > > I first found him whilst I was looking for a binpacking algorithm(s) > and benchmarks for how well they performed on modern hardware. > > > https://web.archive.org/web/20190530024749/http://www.martinbroadhurst.com/tag/bin-packing > > And then I started reading the rest of his canon: Wow: > > > https://web.archive.org/web/20190704202816/http://www.martinbroadhurst.com/author/martin > > Stuff like: > > http://www.martinbroadhurst.com/bellman-ford-algorithm-in-c.html > > http://www.martinbroadhurst.com/avl-tree-in-c.html > > Anyway, given that the site is down, and he hasn?t posted anything in > a year, I fear he has passed on. I did find an obituary that had about > the right timing... Did/does anyone here know him? > > > -- > This song goes out to all the folk that thought Stadia would work: > > https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz > Dave T?ht CEO, TekLibre, LLC > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From ralph.holz at gmail.com Tue Feb 7 08:00:05 2023 From: ralph.holz at gmail.com (Ralph Holz) Date: Tue, 7 Feb 2023 17:00:05 +0100 Subject: [ih] Design choices in SMTP Message-ID: Hi everyone, During a lecture today, the following question came up: SMTP requires quite a few round-trips to deliver an email. Why was this design choice made, i.e., why does a submitting client not just send everything to the server in one RTT? Apart from the client-server philosophy at play, I am wondering if that was because we wanted a receiver to terminate the delivery process as early as possible, i.e., before sending the body, if anything was amiss. Does anyone have insights on that or maybe even know a nice write-up? I checked a few sites that discuss the history of SMTP, but so far no luck with this aspect. Many thanks, Ralph From dhc at dcrocker.net Tue Feb 7 08:10:32 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 7 Feb 2023 08:10:32 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: On 2/7/2023 8:00 AM, Ralph Holz via Internet-history wrote: > Hi everyone, > > During a lecture today, the following question came up: SMTP requires quite > a few round-trips to deliver an email. Why was this design choice made, > i.e., why does a submitting client not just send everything to the server > in one RTT? 1. Save bandwidth -- in 1982, that matter a lot more than it does today, but even today, not all transactions are across extremely high bandwidth paths. 2. Save server capacity > Apart from the client-server philosophy at play, I am wondering if that was > because we wanted a receiver to terminate the delivery process as early as > possible, i.e., before sending the body, if anything was amiss. Yes. > Does anyone have insights on that or maybe even know a nice write-up? I > checked a few sites that discuss the history of SMTP, but so far no luck > with this aspect. Eventually there was enough motivation to have a transaction be conducted in a batched fashion: The Batch SMTP Media Type datatracker.ietf.org RFC ft-freed-bsmtp: The Batch SMTP Media Type <#> The Batch SMTP Media Type (RFC 2442, November 1998 ? https://datatracker.ietf.org/doc/html/rfc2442 Shortly after that, the capability to pipeline the transaction over an SMTP connection was developed.? This does not change the nature of the connection, but removes most of the latency delays to the session. SMTP Service Extension for Command Pipelining www.rfc-editor.org RFC 2920: SMTP Service Extension for Command Pipelining <#> ? https://www.rfc-editor.org/rfc/rfc2920 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From craig at tereschau.net Tue Feb 7 08:22:40 2023 From: craig at tereschau.net (Craig Partridge) Date: Tue, 7 Feb 2023 09:22:40 -0700 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: And just because this is a history list, and capturing stories like this are useful. Regarding pipelining. My recollection, perhaps wrong and certainly fuzzy, is that the original idea for pipelining came from Phil Karn. Phil mentioned it to me and I misunderstood him to say he'd implemented it -- and mentioned it to Van Jacobson, who thought it was a great idea to help TCP performance (as SMTP is hard on TCP window size estimation -- you send a bunch of little segments, which open the window, and then boom, hit the connection with an entire message -- the result was often congestion loss). Van started to implement pipelining in Sendmail, hit snags, reached out to Phil and me to discover Phil had not implemented it, just speculated, and then Van --- annoyed but too intrigued not to do it, -- with help from others, pushed forward to a prototype which revealed issues with many SMTPs clearing the TCP connection of all data on each exchange. Craig On Tue, Feb 7, 2023 at 9:10 AM Dave Crocker via Internet-history < internet-history at elists.isoc.org> wrote: > On 2/7/2023 8:00 AM, Ralph Holz via Internet-history wrote: > > Hi everyone, > > > > During a lecture today, the following question came up: SMTP requires > quite > > a few round-trips to deliver an email. Why was this design choice made, > > i.e., why does a submitting client not just send everything to the server > > in one RTT? > > 1. Save bandwidth -- in 1982, that matter a lot more than it does today, > but even today, not all transactions are across extremely high bandwidth > paths. > > 2. Save server capacity > > > > Apart from the client-server philosophy at play, I am wondering if that > was > > because we wanted a receiver to terminate the delivery process as early > as > > possible, i.e., before sending the body, if anything was amiss. > > Yes. > > > > Does anyone have insights on that or maybe even know a nice write-up? I > > checked a few sites that discuss the history of SMTP, but so far no luck > > with this aspect. > > Eventually there was enough motivation to have a transaction be > conducted in a batched fashion: > > The Batch SMTP Media Type > > datatracker.ietf.org > > RFC ft-freed-bsmtp: The Batch SMTP Media Type <#> > > The Batch SMTP Media Type (RFC 2442, November 1998 > > ? https://datatracker.ietf.org/doc/html/rfc2442 > > > Shortly after that, the capability to pipeline the transaction over an > SMTP connection was developed. This does not change the nature of the > connection, but removes most of the latency delays to the session. > > SMTP Service Extension for Command Pipelining > > www.rfc-editor.org > > RFC 2920: SMTP Service Extension for Command Pipelining <#> > > ? https://www.rfc-editor.org/rfc/rfc2920 > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker at mastodon.social > -- > 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 b_a_denny at yahoo.com Tue Feb 7 08:58:21 2023 From: b_a_denny at yahoo.com (Barbara Denny) Date: Tue, 7 Feb 2023 16:58:21 +0000 (UTC) Subject: [ih] Sad news about Don Provan References: <1300701444.1505164.1675789101118.ref@mail.yahoo.com> Message-ID: <1300701444.1505164.1675789101118@mail.yahoo.com> With a heavy heart,? I want to send the news that Don Provan passed away the day after Christmas. He wrote the TCP/IP implementation for the TOPS-10 which was used by Johnny Eriksson. I believe the implementation was done for the the cut over in 1983. barbara From jklensin at gmail.com Tue Feb 7 09:26:59 2023 From: jklensin at gmail.com (John Klensin) Date: Tue, 7 Feb 2023 12:26:59 -0500 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: Ralph, I was not involved with the original SMTP design and don't remember ever explicitly discussing those choices, but my guess is that the answer would involve at least some of the following: * SMTP was designed along the model of FTP, which preceded it as the mail transport mechanism, and that made the command-response model seem natural * At the time SMTP was designed, the network backbone and most communications paths to it were running at 56 Kpbs, agonizingly slow by today's standards. Computers were much slower too. Especially because all of those round trips were within a single TCP session, that might have contributed to exactly your suggestion that the intent was to get an SMTP session that was doomed to fail over as soon as possible, in particular before the payload was transmitted. * Possibly more significant in retrospect than at the time, but a command-response model like "did I reach the right server?", "are you willing to accept mail from this address?", "is this destination ok?", "how about that destination?" has some privacy advantages over a "here is the envelope and payload, please do the right thing" model, even if the latter is supplemented by a footer that has become common in some places. one that essentially says "if this message was not really intended for you, please un-read and delete it" . You didn't ask but I hope your discussion noted that, for situations in which minimizing round trips is considered important, the "pipelining" option was introduced in 1995 (RFC 1854, succeeded by RFC 2920). john On Tue, Feb 7, 2023 at 11:00 AM Ralph Holz via Internet-history < internet-history at elists.isoc.org> wrote: > Hi everyone, > > During a lecture today, the following question came up: SMTP requires quite > a few round-trips to deliver an email. Why was this design choice made, > i.e., why does a submitting client not just send everything to the server > in one RTT? > > Apart from the client-server philosophy at play, I am wondering if that was > because we wanted a receiver to terminate the delivery process as early as > possible, i.e., before sending the body, if anything was amiss. > > Does anyone have insights on that or maybe even know a nice write-up? I > checked a few sites that discuss the history of SMTP, but so far no luck > with this aspect. > > Many thanks, > Ralph > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From dhc at dcrocker.net Tue Feb 7 09:39:05 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 7 Feb 2023 09:39:05 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: <6f53b480-dcf0-46da-4900-d60f8ab6e0ba@dcrocker.net> On 2/7/2023 8:22 AM, Craig Partridge via Internet-history wrote: > And just because this is a history list, and capturing stories like this > are useful. As I recall, I had little or no contact with the SMTP pipelining effort, other than joining in the general community support of the effort. (One took a position against the views of Ned, Van or Phil at one's peril.? Not as a matter of their personalities but their irritatingly consistent tendency to be right.) Also, I'd learned about the miracle of pipelining around 1981, with MMDF.? Another grad student, Ed Szurkowski, had done the link-level protocol that MMDF used over telephone connections. (30-120 Bps, back then...).? It was a lock-step exchange, essentially half-duplex.? As our base of client sites for CSNet increased, the wasted bandwidth eventually became intolerable. Looking for a cheap way to do better, I modified his code to allow 2 outstanding packets rather than one.? The result was that the modem transmit light was pinned on, with no loss of reliability or functionality. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From julf at Julf.com Tue Feb 7 09:44:30 2023 From: julf at Julf.com (Johan Helsingius) Date: Tue, 7 Feb 2023 18:44:30 +0100 Subject: [ih] Design choices in SMTP In-Reply-To: <6f53b480-dcf0-46da-4900-d60f8ab6e0ba@dcrocker.net> References: <6f53b480-dcf0-46da-4900-d60f8ab6e0ba@dcrocker.net> Message-ID: On 07/02/2023 18:39, Dave Crocker via Internet-history wrote: > Looking for a cheap way to do better, I modified his code to allow 2 > outstanding packets rather than one.? The result was that the modem > transmit light was pinned on, with no loss of reliability or functionality. I experiences something similar - I implemented an outstanding packet window in the archaic but popular Kermit protocol used over serial lines, and boy did it improve performance. Julf From dhc at dcrocker.net Tue Feb 7 09:52:34 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 7 Feb 2023 09:52:34 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: References: <6f53b480-dcf0-46da-4900-d60f8ab6e0ba@dcrocker.net> Message-ID: <8b903ec8-e462-ef4e-5809-30465dbdf82d@dcrocker.net> On 2/7/2023 9:44 AM, Johan Helsingius via Internet-history wrote: > On 07/02/2023 18:39, Dave Crocker via Internet-history wrote: > >> Looking for a cheap way to do better, I modified his code to allow 2 >> outstanding packets rather than one.? The result was that the modem >> transmit light was pinned on, with no loss of reliability or >> functionality. > > I experiences something similar - I implemented an outstanding > packet window in the archaic but popular Kermit protocol used > over serial lines, and boy did it improve performance. Indeed.? And since you've played with a phone-based link-level protocol, I'll mention that the unusual bit of Szurkowski['s phonenet protocol was that it was adaptable to the details of the remote site. When coming in through the user-oriented terminal interface, every system had/has special characters that are treated semantically.? Enter/Return (CR) is an obvious example. At initial connection, Ed's protocol had a called site send a list of its interpreted characters, so the caller wouldn't use them as data.? The goal was to give the caller the widest array of characters that could be sent as-is, without needed to recast them in hex, or the like. (I don't remember which of the usual schemes he used.) d/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From dhc at dcrocker.net Tue Feb 7 09:58:09 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 7 Feb 2023 09:58:09 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: On 2/7/2023 9:26 AM, John Klensin via Internet-history wrote: > * SMTP was designed along the model of FTP, which preceded it as the mail > transport mechanism, and that made the command-response model seem natural As I recall, there was discussion about whether the exchange should do a transaction for each addressee, versus for the entire set of addressees.? I believe per-addressee was chosen to greatly simplify failure analysis. If addresses had been done as a single part of the transaction, there's the task of figuring out which one(s) were the problem. Simplicity and diagnosability were strong forces in the design of Arpanet/Internet application protocols. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From julf at Julf.com Tue Feb 7 10:05:40 2023 From: julf at Julf.com (Johan Helsingius) Date: Tue, 7 Feb 2023 19:05:40 +0100 Subject: [ih] Design choices in SMTP In-Reply-To: <8b903ec8-e462-ef4e-5809-30465dbdf82d@dcrocker.net> References: <6f53b480-dcf0-46da-4900-d60f8ab6e0ba@dcrocker.net> <8b903ec8-e462-ef4e-5809-30465dbdf82d@dcrocker.net> Message-ID: <6d1833fe-acf7-3205-623c-413b60eeca87@Julf.com> On 07/02/2023 18:52, Dave Crocker wrote: > At initial connection, Ed's protocol had a called site send a list of > its interpreted characters, so the caller wouldn't use them as data. The > goal was to give the caller the widest array of characters that could be > sent as-is, without needed to recast them in hex, or the like. (I don't > remember which of the usual schemes he used.) Interesting! I wonder how much more efficient that was than the usual schemes of using just non-control ASCII characters. Julf From dhc at dcrocker.net Tue Feb 7 10:15:35 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 7 Feb 2023 10:15:35 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: <6d1833fe-acf7-3205-623c-413b60eeca87@Julf.com> References: <6f53b480-dcf0-46da-4900-d60f8ab6e0ba@dcrocker.net> <8b903ec8-e462-ef4e-5809-30465dbdf82d@dcrocker.net> <6d1833fe-acf7-3205-623c-413b60eeca87@Julf.com> Message-ID: On 2/7/2023 10:05 AM, Johan Helsingius wrote: > Interesting! I wonder how much more efficient that was than the usual > schemes of using just non-control ASCII characters. I haven't looked at the code or thought about this, in some decades. The answer is basically a matter of the basic math of encoding alternatives and the basic statistics of character frequencies. To the extent the answer is important, responding to the answer pretty much mandates including a data compression scheme in the mix. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From galmes at tamu.edu Tue Feb 7 10:37:30 2023 From: galmes at tamu.edu (Guy Almes) Date: Tue, 7 Feb 2023 13:37:30 -0500 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: Dave, Ralph, et al., I'm enjoying and learning from the various comments on SMTP and its early history. But, largely for the sake of non-baby-boomers on the list, let me just emphasize Dave's first point. In the 1980s, the speed of light was much greater than it is now. So for an IP packet to go end-to-end, there are three components of delay: <> each hop has to transmit the packet at 56kb/s or sometimes less. That's 7 bytes/msec. The total of these transmissions along the path was the big source of delay and, for a message, doesn't matter *much* whether it comes in large or small packets or the whole 'message'. By 2000, wide area trunks and LANs both exceed 10 Mb/s. <> processing delay at each hop. Moore's law eventually made this tiny. <> and the speed of light got worse. I mostly mean this in the sense that it didn't get any better, while processing and transmission both got much faster. But it's also true in the literal sense that wide-area networks were largely built with microwave in the 1980s (or geosynchronous satellites), while they are built with fiber optic circuits now. And the speed of light through fiber is about 2/3 the speed of light through air (or space). (The new generation of LEO satellite networks could change this in some interesting ways, but that's still an emerging technology.) So nowadays, all those round trips really matter, while in the 1980s they more or less didn't. So, while the TCP and application layer stories are fascinating, the IP layer has also changed in these performance senses. -- Guy On 2/7/23 11:10 AM, Dave Crocker via Internet-history wrote: > On 2/7/2023 8:00 AM, Ralph Holz via Internet-history wrote: >> Hi everyone, >> >> During a lecture today, the following question came up: SMTP requires quite >> a few round-trips to deliver an email. Why was this design choice made, >> i.e., why does a submitting client not just send everything to the server >> in one RTT? > > 1. Save bandwidth -- in 1982, that matter a lot more than it does today, > but even today, not all transactions are across extremely high bandwidth > paths. > > 2. Save server capacity > > >> Apart from the client-server philosophy at play, I am wondering if that was >> because we wanted a receiver to terminate the delivery process as early as >> possible, i.e., before sending the body, if anything was amiss. > > Yes. > > >> Does anyone have insights on that or maybe even know a nice write-up? I >> checked a few sites that discuss the history of SMTP, but so far no luck >> with this aspect. > > Eventually there was enough motivation to have a transaction be > conducted in a batched fashion: > > The Batch SMTP Media Type > > datatracker.ietf.org > > RFC ft-freed-bsmtp: The Batch SMTP Media Type <#> > > The Batch SMTP Media Type (RFC 2442, November 1998 > > ?https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc2442__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM48BPxdi2Q$ > > > > Shortly after that, the capability to pipeline the transaction over an > SMTP connection was developed.? This does not change the nature of the > connection, but removes most of the latency delays to the session. > > SMTP Service Extension for Command Pipelining > > https://urldefense.com/v3/__http://www.rfc-editor.org__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4-mQ9jCDg$ > > RFC 2920: SMTP Service Extension for Command Pipelining <#> > > ?https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc2920__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4_tSWmXlA$ > > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker at mastodon.social > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!D5KGdylWP8ghhn0JWR-l58pMADGmoJwWS7_isc4ndgVJIygb4j7ROdDS-UcCObepyvI-VgMf8EPygm3l8XGwM4-YgQh5PQ$ > From jack at 3kitty.org Tue Feb 7 10:44:43 2023 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 7 Feb 2023 10:44:43 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: <727f1410-52d4-a3ed-23fb-bbbba57edc70@3kitty.org> IMHO, the key to understanding the design decisions of SMTP is the "S". Back in the mid 1970s, the ARPANET era, there was a lot of interest in using computers and networks to assist human-human communications.? Professor Licklider, at MIT at the time, was a proponent of this both at MIT and during his tenure at ARPA.? I was one of Lick's students/staff and built one of the first mail systems.?? RFC 713 documented a part of that system, as a piece of implementing Lick's vision, which included what we now know as email, forums, mailing lists, texting, social media, archival storage, notarization, workflow, user authentication, and other aspects of human-human communication.?? The "Message-ID" field you still see today in email headers ("View Full Headers" to see it) was put into the header protocol as a part of that design, providing a "unique ID" for every piece of email sent, enabling them to someday be linked together in various kinds of relations - similar to how URLs now enable linking of web pages. The system envisioned in Lick's "Galactic Network" was quite complex, and powerful, but deemed too big to implement for all the hosts on the ARPANET.? After much discussion and debate, mostly lost since it was done using email which was rarely archived at that time, a simplified first step was defined and documented by Sluizer and Postel (see https://www.rfc-editor.org/rfc/rfc772 and https://www.rfc-editor.org/rfc/rfc780 ).? This was MTP - the Message Transfer Protocol. The mail system envisioned by 772 and 780 was also fairly complex and powerful, but also deemed too big as a "first step" for all hosts to implement.? Something else was needed, that could be easily and quickly implemented, to provide basic universal human-human communications over the ARPANET and the emerging Internet. Something SIMPLE was needed -- and so the Simple Mail Transfer Protocol was defined and implemented everywhere as an interim solution. So, IMHO, design decisions for SMTP were driven by Simplicity - the "S" in SMTP. Seems like 40 years should be long enough.....maybe someone will take the next step. Jack From internet-history at gtaylor.tnetconsulting.net Tue Feb 7 11:35:48 2023 From: internet-history at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 7 Feb 2023 12:35:48 -0700 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: <3803c27e-dea5-f301-3c66-9ce3d63ce248@spamtrap.tnetconsulting.net> On 2/7/23 11:37 AM, Guy Almes via Internet-history wrote: > <> and the speed of light got worse.? I mostly mean this in the sense > that it didn't get any better, while processing and transmission both > got much faster. This is an interesting take on -- what I believe is called -- the propagation delay becoming a larger proportion / percentage of the delay as things around it got better / faster. > But it's also true in the literal sense that wide-area networks > were largely built with microwave in the 1980s (or geosynchronous > satellites), while they are built with fiber optic circuits now. > And the speed of light through fiber is about 2/3 the speed of > light through air (or space). This floored me the first time I heard about it. > (The new generation of LEO satellite networks could change this in > some interesting ways, but that's still an emerging technology.) }:-) -- Grant. . . . unix || die From dhc at dcrocker.net Tue Feb 7 12:00:07 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 7 Feb 2023 12:00:07 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: <7702f254-a34e-c257-3496-4bf94df7aeeb@dcrocker.net> On 2/7/2023 10:37 AM, Guy Almes via Internet-history wrote: > ? So nowadays, all those round trips really matter, while in the 1980s > they more or less didn't. They matter sometimes.? Other times, not so much. Their relative effect on the time needed to complete a single, overall exchange? Sure. In absolute terms, it rasies the unit cost. The end-to-end effect on UX, for author and recipient of email? Nah. One of the nice things about email is how much cruft can be tolerated, as long as it is in the background. What about for real-time chat?? I bet nah to that, too, as long as overall server performance remains good.? (See below.) Real-time video?? Probably a big yah. And an orthogonal issue is overall systems effects, at scale. When servicing gillions of user mail on the same server, does the aggregate of all those micro-interactions affect system performance?? My understanding is yah, again.? Not necessarily obviously, having to hold onto the message longer messes with queue sizes, I believe. d/ ps. For obvious reasons, geosync paths alter the real-time UX calculus fundamentally.? Extra round-trips a problematic. pps. Going from SMTP to ESMTP was accomplished with a design process that paid quite a lot of attention to keeping the micro-transaction count the same. -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From dhc at dcrocker.net Tue Feb 7 12:20:33 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 7 Feb 2023 12:20:33 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: <727f1410-52d4-a3ed-23fb-bbbba57edc70@3kitty.org> References: <727f1410-52d4-a3ed-23fb-bbbba57edc70@3kitty.org> Message-ID: On 2/7/2023 10:44 AM, Jack Haverty via Internet-history wrote: > Seems like 40 years should be long enough.....maybe someone will take > the next step. Hmmm.? This seems too close to the "it's been around time, so it should be replaced' assertion that is often made about long-standing, successful protocols. What is typically missing is a) a very clear problem statement, in terms that explain the very significant, real benefits to be sought, and b) a constituency that is eager for that superior capability to be delivered. A lesson of a number of protocols in use today is how well they have supported enhancement, rather than replacement. So, yes, there will come a time, for each of these, when replacement is better than enhancement.? But the extreme momentum of an installed base at scale means there must be very strong market demand. By way of example, IMAP is generally assessed as having serious flaws, with JMAP being developed as a replacement.? Have you heard of JMAP before?? Any idea how its adoption curve is proceeding? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From dhc at dcrocker.net Tue Feb 7 12:23:49 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 7 Feb 2023 12:23:49 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: <3803c27e-dea5-f301-3c66-9ce3d63ce248@spamtrap.tnetconsulting.net> References: <3803c27e-dea5-f301-3c66-9ce3d63ce248@spamtrap.tnetconsulting.net> Message-ID: <68ed075c-85f0-bfff-5401-759f63c89cb9@dcrocker.net> On 2/7/2023 11:35 AM, Grant Taylor via Internet-history wrote: > >> But it's also true in the literal sense that wide-area networks were >> largely built with microwave in the 1980s (or geosynchronous >> satellites), while they are built with fiber optic circuits now. And >> the speed of light through fiber is about 2/3 the speed of light >> through air (or space). > > This floored me the first time I heard about it. While still an undergrad -- before going on to become a founding employee of Silicon Graphics -- was doing a project for the department chair.? The chair had had a career at Xerox and the current project was a bit of printer hardware.? One day the undergrad commented to me that electricity though a circuit did not travel at the speed of light and he was discovering this was important to know... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From jack at 3kitty.org Tue Feb 7 13:19:18 2023 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 7 Feb 2023 13:19:18 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: References: <727f1410-52d4-a3ed-23fb-bbbba57edc70@3kitty.org> Message-ID: Personally I don't care whether something is enhanced or replaced. The important requirement is that the "new functionality" is easy for the end user to deploy, preferably being accomplished invisibly.?? I've never heard of "JMAP", or seen any ISP or Mail software mention it, or any plan for deployment and transition. AFAIK, I'm still using IMAP. Re a "problem statement"... Fifty years ago, email was just starting but people who "got on email" could all communicate with each other.? For a while, several mail universes existed ARPANET, UUCP, MCI, AOL, etc.) and they typically were somehow interconnected so everyone could still communicate with each other.?? Email was about as reliable as the underlying networks.? You could trust that an email you received from someone actually came from that person, and an email you sent would get delivered to the intended recipient.? Some such characteristics were mostly because of the collegial aspect of the network community at the time, but people were working on technological solutions (e.g., PGP). Today, the email world is full of silos and walled gardens.?? So I have to check my various SMTP mailboxes, LinkedIn, Facebook, Twitter, and other social media sites, and lots of "forums", plus SMS/MMS and various "secure" mailboxes for my accounts at places like banks and companies that don't trust SMTP mail, just to see if I have any message I should read or answer.?? Sometimes it's called something different, like "DM" or "PM", but it's all persons-persons messaging. It's difficult or impossible (or I just haven't discovered the magic incantations) to reply to, forward, save, search, or otherwise process mail involving correspondents who aren't in the same silo. If I want to find a message I saw a few months ago, I have to somehow remember whether it was on one of my SMTP accounts, or Facebook, or SMS, etc., or search all of them.?? If I want to engage several others in a conversation, I have to do it in each silo they use. Also of course I have to deal with all sorts of spam filters, settings, and mechanisms that seem to be sometimes good at blackholing legitimate messages while still delivering a lot of actual spam, and sometimes deliver messages that have been forged. I get mail purporting to be from someone (even myself) that isn't. Sometimes a message doesn't get delivered because it is deemed too large by some handler along the way. It seems common now to hear "I never got your email", and also to be wary of acting on information in an incoming message. I would like the reliability, pervasiveness, and trustworthiness of the 70s email restored.? So, my "problem statement" would be something like: "Provide a system for human-human communications that can be used on whatever kind of computer a person has at the time, accessing whatever kind of network that computer can utilize at the time, with high reliability, privacy, and guarantee of identity, for all humans, companies, organizations, governmental units, business partners, and other entities I want to communicate with, including the ability to store, archive, search, share, and authenticate messages sent and received over time.? The system must be inherently upgradable to reflect changes in underlying computers and networks, as well as its own internal evolution." Multimedia of course...this is the 21st century. Jack On 2/7/23 12:20, Dave Crocker wrote: > On 2/7/2023 10:44 AM, Jack Haverty via Internet-history wrote: >> Seems like 40 years should be long enough.....maybe someone will take >> the next step. > > Hmmm.? This seems too close to the "it's been around time, so it > should be replaced' assertion that is often made about long-standing, > successful protocols. > > What is typically missing is a) a very clear problem statement, in > terms that explain the very significant, real benefits to be sought, > and b) a constituency that is eager for that superior capability to be > delivered. > > A lesson of a number of protocols in use today is how well they have > supported enhancement, rather than replacement. > > So, yes, there will come a time, for each of these, when replacement > is better than enhancement.? But the extreme momentum of an installed > base at scale means there must be very strong market demand. > > By way of example, IMAP is generally assessed as having serious flaws, > with JMAP being developed as a replacement.? Have you heard of JMAP > before?? Any idea how its adoption curve is proceeding? > > d/ > From touch at strayalpha.com Tue Feb 7 15:16:58 2023 From: touch at strayalpha.com (touch at strayalpha.com) Date: Tue, 7 Feb 2023 15:16:58 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: <3803c27e-dea5-f301-3c66-9ce3d63ce248@spamtrap.tnetconsulting.net> References: <3803c27e-dea5-f301-3c66-9ce3d63ce248@spamtrap.tnetconsulting.net> Message-ID: <698CC935-ACCA-4CFA-9F1E-256921F71831@strayalpha.com> > On Feb 7, 2023, at 11:35 AM, Grant Taylor via Internet-history wrote: > > On 2/7/23 11:37 AM, Guy Almes via Internet-history wrote: >> <> and the speed of light got worse. I mostly mean this in the sense that it didn't get any better, while processing and transmission both got much faster. > > This is an interesting take on -- what I believe is called -- the propagation delay becoming a larger proportion / percentage of the delay as things around it got better / faster. Everybody talks about the speed of light, but nobody every does anything about it! >> But it's also true in the literal sense that wide-area networks were largely built with microwave in the 1980s (or geosynchronous satellites), while they are built with fiber optic circuits now. And the speed of light through fiber is about 2/3 the speed of light through air (or space). > > This floored me the first time I heard about it. Latency is both multidimensional and those dimensions combine in nonlinear ways. Propagation delay is only one of those dimensions, the other parts of which include symbol rate (which affects message rate), encoding latency (symbol layer, encryption, and error correction), whether the channel supports pipelining and/or parallelism, as well as server access and computational delays. Not to mention that none of this is a property of a given channel - it?s a property *of a given message* (or exchange) over a given channel. Note that 2/3 (67%) is the ratio for fiber to free space, fiber is basically the same propagation speed as coax and most twisted pair. Twin-lead is actually faster - 80%. The only common media that comes close to air/vacuum is open-ladder wire. Joe From vgcerf at gmail.com Tue Feb 7 16:38:17 2023 From: vgcerf at gmail.com (vinton cerf) Date: Tue, 7 Feb 2023 19:38:17 -0500 Subject: [ih] Sad news about Don Provan In-Reply-To: <1300701444.1505164.1675789101118@mail.yahoo.com> References: <1300701444.1505164.1675789101118.ref@mail.yahoo.com> <1300701444.1505164.1675789101118@mail.yahoo.com> Message-ID: So sorry to hear that, Barbara, but thank you for letting us know. Getting late in the game now. v On Tue, Feb 7, 2023 at 11:58 AM Barbara Denny via Internet-history < internet-history at elists.isoc.org> wrote: > With a heavy heart, I want to send the news that Don Provan passed away > the day after Christmas. He wrote the TCP/IP implementation for the TOPS-10 > which was used by Johnny Eriksson. I believe the implementation was done > for the the cut over in 1983. > barbara > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From johnl at iecc.com Tue Feb 7 17:31:04 2023 From: johnl at iecc.com (John Levine) Date: 7 Feb 2023 20:31:04 -0500 Subject: [ih] Design choices in SMTP In-Reply-To: Message-ID: <20230208013104.EE65B90CFD8E@ary.qy> It appears that Dave Crocker via Internet-history said: >On 2/7/2023 9:26 AM, John Klensin via Internet-history wrote: >> * SMTP was designed along the model of FTP, which preceded it as the mail >> transport mechanism, and that made the command-response model seem natural > >As I recall, there was discussion about whether the exchange should do a >transaction for each addressee, versus for the entire set of >addressees.? I believe per-addressee was chosen to greatly simplify >failure analysis. > >If addresses had been done as a single part of the transaction, there's >the task of figuring out which one(s) were the problem. It was pretty clever the way pipelinng solved that for free. We still have the question of what does the server say if it finds after it has received the message that some of the recipients can accept it and some can't, but we've lived with that for 40 years. There were and to some degree still are a lot of assumptions in the design, like bandwidth is expensive, round-trips are relatively cheap. When Dan Bernstein wrote qmail in 1998 he not so much challenged as ignored many of those assumptions. He observed that mail servers generally have a whole lot of mail in flight, and people care more about the overall number of messages delivered per minute or per hour so he tuned it so it could handle lots of incoming and outgoing connections to fill up the pipe rather than trying to optimize each connection. His most contentious decision was that it delivered one message to one recipient at a time, and if you sent a message to 10 people at a recipient system, it sent ten copies. A lot of people got bent out of shape at that (some still are) but in retrospect he was right. These days most bulk mail systems customize each recipient's message a little, so it's all single recipient sent in parallel anyway. R's, John From jeanjour at comcast.net Tue Feb 7 18:06:30 2023 From: jeanjour at comcast.net (John Day) Date: Tue, 7 Feb 2023 21:06:30 -0500 Subject: [ih] Fwd: Design choices in SMTP References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> Message-ID: <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> > > I am fuzzy on all this but was this always the case? > > As John points out, mail was originally part of FTP and mailboxes were files not directories. If one had multiple pieces of mail to deliver to the same mailbox would they have been done individually or all at once? If so, when did delivering mail one at a time start? In SMTP? When mailboxes became directories? > > (I would also note that Multics was uneasy giving an anonymous user Write access to a file so created Append access for use by mail.) > >> On Feb 7, 2023, at 12:26, John Klensin via Internet-history wrote: >> >> Ralph, >> >> I was not involved with the original SMTP design and don't remember ever >> explicitly discussing those choices, but my guess is that the answer would >> involve at least some of the following: >> >> * SMTP was designed along the model of FTP, which preceded it as the mail >> transport mechanism, and that made the command-response model seem natural >> >> * At the time SMTP was designed, the network backbone and most >> communications paths to it were running at 56 Kpbs, agonizingly slow by >> today's standards. Computers were much slower too. Especially because all >> of those round trips were within a single TCP session, that might have >> contributed to exactly your suggestion that the intent was to get an SMTP >> session that was doomed to fail over as soon as possible, in particular >> before the payload was transmitted. >> >> * Possibly more significant in retrospect than at the time, but a >> command-response model like "did I reach the right server?", "are you >> willing to accept mail from this address?", "is this destination ok?", "how >> about that destination?" has some privacy advantages over a "here is the >> envelope and payload, please do the right thing" model, even if the latter >> is supplemented by a footer that has become common in some places. one that >> essentially says "if this message was not really intended for you, please >> un-read and delete it" . >> >> You didn't ask but I hope your discussion noted that, for situations in >> which minimizing round trips is considered important, the "pipelining" >> option was introduced in 1995 (RFC 1854, succeeded by RFC 2920). >> >> john >> >> >> On Tue, Feb 7, 2023 at 11:00 AM Ralph Holz via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> Hi everyone, >>> >>> During a lecture today, the following question came up: SMTP requires quite >>> a few round-trips to deliver an email. Why was this design choice made, >>> i.e., why does a submitting client not just send everything to the server >>> in one RTT? >>> >>> Apart from the client-server philosophy at play, I am wondering if that was >>> because we wanted a receiver to terminate the delivery process as early as >>> possible, i.e., before sending the body, if anything was amiss. >>> >>> Does anyone have insights on that or maybe even know a nice write-up? I >>> checked a few sites that discuss the history of SMTP, but so far no luck >>> with this aspect. >>> >>> Many thanks, >>> Ralph >>> -- >>> 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 dhc at dcrocker.net Tue Feb 7 18:23:42 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 7 Feb 2023 18:23:42 -0800 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> Message-ID: On 2/7/2023 6:06 PM, John Day via Internet-history wrote: > As John points out, mail was originally part of FTP and mailboxes were files not directories. If one had multiple pieces of mail to deliver to the same mailbox would they have been done individually or all at once? The FTP mechanism was one addressee per transfer.? As I recall, the major incentive for doing SMTP was to allow a transfer to be to multiple addressees. The UA/MTA distinction, with separate software doing user interaction, from the software that did transfer, started appearing in the latter 1970s.? By 1980, there were enough examples of that architectural approach to justify a pre-X.400 effort (IFIP WG 6.5) that introduced the UA/MTA construct. Given that the Arpanet and corporate networks like Xerox's and Digital Equipment's had fulltime connectivity among hosts, the operational approach was to send immediately upon user submission, doing queuing and retrying only after initial failure. Given the paltry traffic load of those days, it made no sense to wait and send a batch to the same place, since there was no benefit in waiting and no cost differential in packaging mail to a site together. The exception was telephone-based transfers, given the cost of long-distance calls in those days.? And indeed, phone-base mail relaying systems DID batch messages to the same site, to get time-of-day benefits.? Some also allowed mixed connection initiation, so that either side might connect when rates were best for them.? Then any waiting mail would flow as needed. > If so, when did delivering mail one at a time start? In SMTP? When mailboxes became directories? see above. It is a bit ironic that bulk mail these days typically is sent one addressee per transaction, due to content customization. > (I would also note that Multics was uneasy giving an anonymous user Write access to a file so created Append access for use by mail.) Giving any daemon privileges is always a risk. As I recall, sendmail gave superuser status to the entire program.? For MMDF I only gave it to the local delivery process. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From 8a0a73507e8e at ewoof.net Wed Feb 8 04:47:41 2023 From: 8a0a73507e8e at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 8 Feb 2023 12:47:41 +0000 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: On 7 Feb 2023 13:37 -0500, from internet-history at elists.isoc.org (Guy Almes via Internet-history): > <> and the speed of light got worse. I mostly mean this in the sense that > it didn't get any better, while processing and transmission both got much > faster. I have for a long time found Cliff Stoll's postulation about the distance to the hacker in _The Cuckoo's Egg_ to be an interesting illustration of this. I don't recall the exact details of the account in his book off the top of my head, but basically, he measured transmission response delays between his computers in western USA and the hacker's unknown location and, applying a simple speed-of-light calculation, determined that the hacker must have been on the Moon; whereas a few real-life tests indicated a distance pointing to somewhere in Europe. (It turned out in the end to be West Germany.) The only culprit that could plausible explain the discrepancy was retransmission delays. -- Michael Kj?rling ??https://michael.kjorling.se ?Remember when, on the Internet, nobody cared that you were a dog?? From jklensin at gmail.com Wed Feb 8 08:13:15 2023 From: jklensin at gmail.com (John Klensin) Date: Wed, 8 Feb 2023 11:13:15 -0500 Subject: [ih] Design choices in SMTP In-Reply-To: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> Message-ID: John, We are getting toward distinctions here that probably have little to do with Ralph's question/ request, but, at the risk of a trip down the rabbit hole... IIR, the most common user interfaces to FTP were single command line things: one source, one destination, one file, no ability (or only obscure ones) to distinguish between ASCII, EBCDIC, and Binary files; file structures; transmission modes; and so on. But the protocol did not require, or even suggest, a command line interface or those restrictions. There were more capable interfaces (including just running scripts over Telnet connections). With one of those interfaces, if I wanted to transmit more than one message to the same mailbox, I could certainly do that over a single TCP connection. Could I transmit separate messages to different recipients early on? Don't remember but I don't recall any version of FTP that supported mail-related commands (MAIL, MLFL, etc.) that would prohibit using more than one of those commands, with different user parameters, in the same FTP (Telnet) session. Of course, in SMTP, it has always been possible to initiate a session, send a MAIL command and then send several RCPT commands and DATA (one message, multiple destinations) and equally possible to send a new MAIL command after a prior mail transaction was completed and start over (multiple messages to the same destination host (server), potentially with different origin and/or destination mailboxes). So I don't see a difference there. The 1980 version of FTP (RFC 765/ IEN 149) even contains commands that are obvious predecessors of SMTP's SEND, SAML, and SOML capabilities. All of that was removed in RFC 959, after the publication of the SMTP spec. One could, on that basis, argue that RFC 765-vintage FTP was really ur-SMTP and we need to talk about earlier times, but that leads to even worse hair-splitting. Similarly, the file/directory distinction, as I recall, was (and still is) an implementation decision on the receiver-SMTP side. Some treated "Append to mailbox" as "add another block to an archive-like file", others as "put it into the mailbox's directory". Even the distinction between "archive-like file" and "directory" can be a bit fuzzy: most implementations of "archives" involve a single file that has to be scanned sequentially to find and identify the individual files. That can be a big deal for a mail-reading split UA protocol like IMAP that does considerable work on the server side. As soon as one adds an index to the archive-like file, allowing one to go to a message directly rather than scanning sequentially from the beginning, the conceptual difference from a directory largely vanishes even though it may be very significant to the underlying file system. In any event, none of those distinctions about how messages are stored are visible to SMTP (or even RFC 765-vintage FTP). I'm not even sure your comment about Multics is completely correct. There may be people on this list who would remember or we could check with that list (or I could get motivated to start digging through documentation I have here, but I don't feel that motivation rising very quickly at the moment). Remember that mail was well-established on CTSS considerably before Multics stabilized enough to support end users and that the ring structure allowed controls that were (and are) not available for file systems that only support (flat) ACLs or equivalent. So, was Append access created specifically for mail? Don't remember but it somehow does not feel right. best, john On Tue, Feb 7, 2023 at 8:52 PM John Day wrote: > I am fuzzy on all this but was this always the case? > > As John points out, mail was originally part of FTP and mailboxes were > files not directories. If one had multiple pieces of mail to deliver to the > same mailbox would they have been done individually or all at once? If so, > when did delivering mail one at a time start? In SMTP? When mailboxes > became directories? > > (I would also note that Multics was uneasy giving an anonymous user Write > access to a file so created Append access for use by mail.) > > > On Feb 7, 2023, at 12:26, John Klensin via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > Ralph, > > > > I was not involved with the original SMTP design and don't remember ever > > explicitly discussing those choices, but my guess is that the answer > would > > involve at least some of the following: > > > > * SMTP was designed along the model of FTP, which preceded it as the mail > > transport mechanism, and that made the command-response model seem > natural > > > > * At the time SMTP was designed, the network backbone and most > > communications paths to it were running at 56 Kpbs, agonizingly slow by > > today's standards. Computers were much slower too. Especially because > all > > of those round trips were within a single TCP session, that might have > > contributed to exactly your suggestion that the intent was to get an SMTP > > session that was doomed to fail over as soon as possible, in particular > > before the payload was transmitted. > > > > * Possibly more significant in retrospect than at the time, but a > > command-response model like "did I reach the right server?", "are you > > willing to accept mail from this address?", "is this destination ok?", > "how > > about that destination?" has some privacy advantages over a "here is the > > envelope and payload, please do the right thing" model, even if the > latter > > is supplemented by a footer that has become common in some places. one > that > > essentially says "if this message was not really intended for you, please > > un-read and delete it" . > > > > You didn't ask but I hope your discussion noted that, for situations in > > which minimizing round trips is considered important, the "pipelining" > > option was introduced in 1995 (RFC 1854, succeeded by RFC 2920). > > > > john > > > > > > On Tue, Feb 7, 2023 at 11:00 AM Ralph Holz via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> Hi everyone, > >> > >> During a lecture today, the following question came up: SMTP requires > quite > >> a few round-trips to deliver an email. Why was this design choice made, > >> i.e., why does a submitting client not just send everything to the > server > >> in one RTT? > >> > >> Apart from the client-server philosophy at play, I am wondering if that > was > >> because we wanted a receiver to terminate the delivery process as early > as > >> possible, i.e., before sending the body, if anything was amiss. > >> > >> Does anyone have insights on that or maybe even know a nice write-up? I > >> checked a few sites that discuss the history of SMTP, but so far no luck > >> with this aspect. > >> > >> Many thanks, > >> Ralph > >> -- > >> 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 dhc at dcrocker.net Wed Feb 8 09:30:11 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Wed, 8 Feb 2023 09:30:11 -0800 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> Message-ID: <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> On 2/7/2023 6:06 PM, John Day via Internet-history wrote: > mail was originally part of FTP Just realized that this needs a bit of clarification.? Thanks to Ray Tomlinson, networked email originally used the Tenex CPYNET file transfer capability.? He linked it to the Tenex SNDMSG command. Why this fact is more than a reference to the creation of networked mail and actually covers "original use" is due to the popularity of Tenex around the Arpanet, and the delay until email commands were added to FTP. * Ray did his thing at the end of 1971. I don't know the propagation rate it had to the rest of the community, but it was quick. (My involvement in the Arpanet didn't start until Spring of 1972.? I can't claim memories about this topic that early.) * RFC 458 (2/73) set the foundation for MAIL and MLFL. It appears to be one of the outputs from a meeting that month about FTP and included discussion of adding email capabilities.? But it was only a discussion piece. * RFC 475 also discusses the topic and introduces the MAIL and MLFL constructs. * Yet the Aug, 1973 FTP revision (RFC 542) still does not include MAIL or MLFL. In fact, it has text that says mail should be a separate protocol, even as it defines a mail Reply code... * The mail commands did not show up in the FTP specification document until 1980 (RFC 765)!? Although they had, of course, been in widespread use long before that. While I have no memory or documentation of when these commands were deployed in FTP, it's clear that it was not immediately after Ray created networked mail, and yet email was quickly widely used. Offhand, I'd guess the delay for the FTP commands was in the 1-2 year range.? Possibly longer? Ergo, an original /use/ claim needs to cite CPYNET, not FTP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From dhc at dcrocker.net Wed Feb 8 09:43:02 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Wed, 8 Feb 2023 09:43:02 -0800 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> Message-ID: On 2/8/2023 9:30 AM, Dave Crocker via Internet-history wrote: > * Ray did his thing at the end of 1971. btw, it is worth noting that Ray 'did his thing' in direct response to community discussions that were underway, marching towards a very different model of email, which mostly was in terms of producing printed output... I didn't know this until relatively recently, when the 'invention' of email became a matter of public consideration and he commented about his motivation.? Arguably his work was comparable to the creation of simple Unix, in reaction to concerns about complex Multics...) RFC 196 (7/1971) embodied the thinking Ray was reacting to. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From mfidelman at meetinghouse.net Wed Feb 8 13:00:55 2023 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 8 Feb 2023 16:00:55 -0500 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> Message-ID: <9003ba84-e6b3-2afd-19d8-da3b61582498@meetinghouse.net> Dave Crocker via Internet-history wrote: > On 2/7/2023 6:06 PM, John Day via Internet-history wrote: >> mail was originally part of FTP > > Just realized that this needs a bit of clarification.? Thanks to Ray > Tomlinson, networked email originally used the Tenex CPYNET file > transfer capability.? He linked it to the Tenex SNDMSG command. > > Why this fact is more than a reference to the creation of networked > mail and actually covers "original use" is due to the popularity of > Tenex around the Arpanet, and the delay until email commands were > added to FTP. > > ?* Ray did his thing at the end of 1971. I don't know the propagation > ?? rate it had to the rest of the community, but it was quick. (My > ?? involvement in the Arpanet didn't start until Spring of 1972. I > ?? can't claim memories about this topic that early.) > ?* RFC 458 (2/73) set the foundation for MAIL and MLFL. It appears to > ?? be one of the outputs from a meeting that month about FTP and > ?? included discussion of adding email capabilities.? But it was only a > ?? discussion piece. > ?* RFC 475 also discusses the topic and introduces the MAIL and MLFL > ?? constructs. > ?* Yet the Aug, 1973 FTP revision (RFC 542) still does not include MAIL > ?? or MLFL. In fact, it has text that says mail should be a separate > ?? protocol, even as it defines a mail Reply code... > ?* The mail commands did not show up in the FTP specification document > ?? until 1980 (RFC 765)!? Although they had, of course, been in > ?? widespread use long before that. > > While I have no memory or documentation of when these commands were > deployed in FTP, it's clear that it was not immediately after Ray > created networked mail, and yet email was quickly widely used. > Offhand, I'd guess the delay for the FTP commands was in the 1-2 year > range.? Possibly longer? > > Ergo, an original /use/ claim needs to cite CPYNET, not FTP. > > I got to MIT in 1971, immediately got an account on the AI Lab's PDP-10 (running ITS!), and a few weeks later, Ray sent that famous email between two machines at BBN.? Then, he announced it to the community, via what was then a regular POSTAL mail distribution - and very shortly thereafter, email programs started showing up for different platforms, and spread across the community in less than a year - followed by email lists, virtual teams & communities, the whole nine yards.? I had the privilege of a front-row seat.? I later had the opportunity to work for Ken Pogran, who wrote the Multics implementation, and later to have Ray kind-a-sorta working for me (I was product manager for BBN/Slate for a bit, Terry Crowley was lead developer, Ray was another developer, kind of a dotted line relationship.? Great fun, with great people.) Miles Fidelman -- 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 From steffen at sdaoden.eu Wed Feb 8 13:02:56 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 08 Feb 2023 22:02:56 +0100 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> Message-ID: <20230208210256.wNce0%steffen@sdaoden.eu> dcrocker at bbiw.net wrote in <81d699a5-2be9-1ff4-08a9-c4c7daddff6e at dcrocker.net>: |On 2/7/2023 6:06 PM, John Day via Internet-history wrote: |> mail was originally part of FTP | |Just realized that this needs a bit of clarification.? Thanks to Ray |Tomlinson, networked email originally used the Tenex CPYNET file |transfer capability.? He linked it to the Tenex SNDMSG command. | |Why this fact is more than a reference to the creation of networked mail |and actually covers "original use" is due to the popularity of Tenex |around the Arpanet, and the delay until email commands were added to FTP. | | * Ray did his thing at the end of 1971. I don't know the propagation | rate it had to the rest of the community, but it was quick. (My | involvement in the Arpanet didn't start until Spring of 1972.? I | can't claim memories about this topic that early.) Here RFC 354 (THE FILE TRANSFER PROTOCOL) and RFC 385 (COMMENTS ON THE FILE TRANSFER PROTOCOL) are missing, the latter includes MAIL and MLFL. And there is also RFC 561 "Standardizing Network Mail Headers". (Now, i really would have to read them again, i was born in June 1972, you know.) | * RFC 458 (2/73) set the foundation for MAIL and MLFL. It appears to | be one of the outputs from a meeting that month about FTP and | included discussion of adding email capabilities.? But it was only a | discussion piece. They seem to | * RFC 475 also discusses the topic and introduces the MAIL and MLFL | constructs. | * Yet the Aug, 1973 FTP revision (RFC 542) still does not include MAIL | or MLFL. In fact, it has text that says mail should be a separate | protocol, even as it defines a mail Reply code... This is ARPANET specific? Now, i really have no idea, but it seems a differenciation is necessary. (I personally have and would _always_ make a difference in between humans born in the USA and US politics/military, as it always seemed to be overly necessary. Even with Carter, when i was a kid. (That balloon was also shot if i recall correctly.) Imho.) | * The mail commands did not show up in the FTP specification document | until 1980 (RFC 765)!? Although they had, of course, been in | widespread use long before that. | |While I have no memory or documentation of when these commands were |deployed in FTP, it's clear that it was not immediately after Ray |created networked mail, and yet email was quickly widely used. Offhand, |I'd guess the delay for the FTP commands was in the 1-2 year range.? |Possibly longer? | |Ergo, an original /use/ claim needs to cite CPYNET, not FTP. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From dhc at dcrocker.net Wed Feb 8 13:23:51 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Wed, 8 Feb 2023 13:23:51 -0800 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: <20230208210256.wNce0%steffen@sdaoden.eu> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> Message-ID: <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> On 2/8/2023 1:02 PM, Steffen Nurpmeso wrote: > > Here RFC 354 (THE FILE TRANSFER PROTOCOL) and RFC 385 (COMMENTS ON > THE FILE TRANSFER PROTOCOL) are missing, the latter includes MAIL > and MLFL. Count me as both befuddled and embarrassed.? No idea why/how I missed 385. I left off 354 because it doesn't provide any email protocol specification. The fact that 385 explicitly specifies MAIL and MLFL makes the fact that neither are in the RFC 542 version of FTP quite odd.. > And there is also RFC 561 "Standardizing Network Mail Right. My focus was strictly on interconnection, not the nature of the content being moved exchanged. While all sorts of message formats were flying around for years over the Arpanet, and RFC 561 gets credit as the first format standard, it was deemed a failure, with nothing stabilizing the topic until 1977, with RFC 733. > Headers". (Now, i really would have to read them again, i was > born in June 1972, you know.) You were just in time for the first public demonstration of the Arpanet. I'm sure your remember that... > | * RFC 475 also discusses the topic and introduces the MAIL and MLFL > | constructs. > | * Yet the Aug, 1973 FTP revision (RFC 542) still does not include MAIL > | or MLFL. In fact, it has text that says mail should be a separate > | protocol, even as it defines a mail Reply code... > > This is ARPANET specific? All of this was entirely Arpanet-specific.? Eventually, independent efforts including uucp-based Unix exchanges and Bitnet IBM-based exchange developed.? And the work in Europe. Interconnection efforts were entirely ad hoc, until the late 1970s.? Uniform addressing, among them, didn't emerge until the mid-/late- 1980s. Remember, the Arpanet -- and btw the Internet -- were intended as research, not national or global production service.? That took another 20 years to move into.? Through most of that time, the expectation was that the actual, global standards would come from ISO and CCITT (ITU). d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From craig at tereschau.net Wed Feb 8 13:45:31 2023 From: craig at tereschau.net (Craig Partridge) Date: Wed, 8 Feb 2023 14:45:31 -0700 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> Message-ID: On Wed, Feb 8, 2023 at 2:24 PM Dave Crocker via Internet-history < internet-history at elists.isoc.org> wrote: > On 2/8/2023 1:02 PM, Steffen Nurpmeso wrote: > > > > Here RFC 354 (THE FILE TRANSFER PROTOCOL) and RFC 385 (COMMENTS ON > > THE FILE TRANSFER PROTOCOL) are missing, the latter includes MAIL > > and MLFL. > > Count me as both befuddled and embarrassed. No idea why/how I missed 385. > > I left off 354 because it doesn't provide any email protocol specification. > > The fact that 385 explicitly specifies MAIL and MLFL makes the fact that > neither are in the RFC 542 version of FTP quite odd.. > > My recollection, from the digging into this that I did for the article on the history of email for IEEE Annals, is there was a tension between the FTP and email teams. There was a meeting about FTP at MIT in March 1973 (that led to 542) where the FTP team had decided to punt on email issues, only to have their DARPA PM (Steve Crocker) show up and tell them that email mattered. After the meeting, the group decided (in some sense, flouting Steve) that email should really be in a separate annex and left email commands out of RFC 542. (As I recall, they were on a page by Jon Postel in the ARPANET Protocol Handbook but may be misremembering). Craig -- ***** Craig Partridge's email account for professional society activities and mailing lists. From steffen at sdaoden.eu Wed Feb 8 14:54:22 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 08 Feb 2023 23:54:22 +0100 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> Message-ID: <20230208225422.rwtCJ%steffen@sdaoden.eu> Craig Partridge wrote in : |On Wed, Feb 8, 2023 at 2:24 PM Dave Crocker via Internet-history < |internet-history at elists.isoc.org> wrote: |> On 2/8/2023 1:02 PM, Steffen Nurpmeso wrote: |>> |>> Here RFC 354 (THE FILE TRANSFER PROTOCOL) and RFC 385 (COMMENTS ON |>> THE FILE TRANSFER PROTOCOL) are missing, the latter includes MAIL |>> and MLFL. |> |> Count me as both befuddled and embarrassed. No idea why/how I missed \ |> 385. |> |> I left off 354 because it doesn't provide any email protocol specificati\ |> on. |> |> The fact that 385 explicitly specifies MAIL and MLFL makes the fact that |> neither are in the RFC 542 version of FTP quite odd.. |> |My recollection, from the digging into this that I did for the article on |the history of email for IEEE Annals, is there |was a tension between the FTP and email teams. There was a meeting about |FTP at MIT in March 1973 (that led to 542) where the FTP team |had decided to punt on email issues, only to have their DARPA PM (Steve |Crocker) show up and tell them that email mattered. |After the meeting, the group decided (in some sense, flouting Steve) that |email should really be in a separate annex and left email |commands out of RFC 542. (As I recall, they were on a page by Jon Postel |in the ARPANET Protocol Handbook but may be misremembering). I am noting that 542 neither mentions 385 nor 475 at all. RFC 475 states This paper describes my understanding of the results of the Network Mail System meeting SRI-ARC on February 23, 1973, and the implications for FTP (File Transfer Protocol). There was general agreement at the meeting that network mail function should be within FTP. FTP currently provides two commands for handling mail.[.] [.]Local mail and SNDMSG programs have been modified at many sites to include network mailing (e.g., USER at HOST at BBN_TENEX and MAIL host user at MIT-DMCG). And this does not sound to me as if it would have been wishful thinking, but rather that it was actively being used? RFC 542 states in "MISCELLANEOUS COMMANDS" There are several functions that utilize the services of file transfer but go beyond it in scope. These are the Mail and Remote Job Entry functions. It is suggested that these become auxiliary protocols that can assume recognition of file transfer commands on the part of the server, i.e., they may depend on the core of FTP commands. The command sets specific to Mail and RJE will be given in separate documents. It also defines response status bits for mail. My local RFC pool does not have the necessary bits to do sleuthing. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From dhc at dcrocker.net Wed Feb 8 15:16:35 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Wed, 8 Feb 2023 15:16:35 -0800 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: <20230208225422.rwtCJ%steffen@sdaoden.eu> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> Message-ID: <5b245e06-7fde-7c0e-81ef-1b066b77cc1d@dcrocker.net> On 2/8/2023 2:54 PM, Steffen Nurpmeso wrote: > [.]Local mail and SNDMSG > programs have been modified at many sites to include network mailing > (e.g., USER at HOST at BBN_TENEX and MAIL host user at MIT-DMCG). > > And this does not sound to me as if it would have been wishful > thinking, but rather that it was actively being used? I take that portion of his text as a pretty clear indication that FTP for email exchange had meaningful traction by that time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From steve at shinkuro.com Wed Feb 8 15:18:20 2023 From: steve at shinkuro.com (Steve Crocker) Date: Wed, 8 Feb 2023 18:18:20 -0500 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> Message-ID: Well, since I'm mentioned... On Wed, Feb 8, 2023 at 4:45 PM Craig Partridge via Internet-history < internet-history at elists.isoc.org> wrote: > > My recollection, from the digging into this that I did for the article on > the history of email for IEEE Annals, is there > was a tension between the FTP and email teams. There was a meeting about > FTP at MIT in March 1973 (that led to 542) where the FTP team > had decided to punt on email issues, only to have their DARPA PM (Steve > Crocker) show up and tell them that email mattered. > After the meeting, the group decided (in some sense, flouting Steve) that > email should really be in a separate annex and left email > commands out of RFC 542. (As I recall, they were on a page by Jon Postel > in the ARPANET Protocol Handbook but may be misremembering). > > Craig > I moved from UCLA to (D)ARPA in mid 1971. At that point, most of my attention was focused on AI and related programs. I didn't try to actively manage Arpanet activities, but I did occasionally get involved in meetings, discussions, etc. I don't recall the meeting referred to here, but a couple of points resonate: - Email had indeed become important. It was one of the few applications working on the early Arpanet, and it was making a huge difference. We were using it heavily within the Agency, and Steve Lukasik, the DARPA director, mandated that each of his direct reports, i.e. the directors of each of the Offices, had to use email. - Thus, I'm sure that I would have said email mattered. - When we first started thinking about email, it seemed to me that it could be implemented on top of FTP. As I said, I don't recall the meeting referenced above, but I'm fairly certain that if someone suggested leaving email aside I would have responded vigorously. - That email was split off later from FTP was fine with me. That meant the community had accumulated enough experience to make a more informed design choice. Steve From jnc at mercury.lcs.mit.edu Wed Feb 8 16:53:02 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 8 Feb 2023 19:53:02 -0500 (EST) Subject: [ih] Fwd: Design choices in SMTP Message-ID: <20230209005302.2EA9F18C07B@mercury.lcs.mit.edu> > On Wed, Feb 8, 2023 at 4:45 PM Craig Partridge wrote: > (As I recall, they were on a page by Jon Postel in the ARPANET Protocol > Handbook but may be misremembering). I looked in my hardcopy 1978 ARPANET Protocol Handbook - ToC here: http://mercury.lcs.mit.edu/~jnc/tech/arpaprot.html and there's a section for MAIL, but apart from a copy of RFC733, there's only a one-page thing, "Mail Protocol" (NIC 29588), in it. I put that online a long time ago: http://ana-3.lcs.mit.edu/~jnc/history/Mail_Protocol.txt Noel From bill.n1vux at gmail.com Wed Feb 8 17:00:31 2023 From: bill.n1vux at gmail.com (Bill Ricker) Date: Wed, 8 Feb 2023 20:00:31 -0500 Subject: [ih] Speed of Light (meandering offtopic from Re: Design choices in SMTP) In-Reply-To: <698CC935-ACCA-4CFA-9F1E-256921F71831@strayalpha.com> References: <3803c27e-dea5-f301-3c66-9ce3d63ce248@spamtrap.tnetconsulting.net> <698CC935-ACCA-4CFA-9F1E-256921F71831@strayalpha.com> Message-ID: On Tue, Feb 7, 2023 at 6:17 PM touch--- via Internet-history < internet-history at elists.isoc.org> wrote: > > On Feb 7, 2023, at 11:35 AM, Grant Taylor via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > On 2/7/23 11:37 AM, Guy Almes via Internet-history wrote: > >> <> and the speed of light got worse. I mostly mean this in the sense > that it didn't get any better, while processing and transmission both got > much faster. > Love it ! >> But it's also true in the literal sense that wide-area networks were > largely built with microwave in the 1980s > (or geosynchronous satellites), > while they are built with fiber optic circuits now. > True! Before fiber (fibre), laying cables to handle the long-lines bandwidth required by the growing demand for telecommunications wasn't practical except along RR rights of ways (where telegraphy had started!). But later, conveniently after discovery of fibre, the limited number of channels that increasingly complex baud encoding schemes could fit in each microwave frequency "channel" was a limit on bandwidth available for still growing telecommunications demand. While directional horns prevented circuits going in different directions from interfering (much), one couldn't reuse the frequencies between Manhattan and Pougkeepsie to double the bandwidth available except by going way off path, which would interfere with a different direction. As most of us have learned the hard-way, the slow twist of twisted pair doesn't prevent all cross-talk; it's not bad, but it's not good. There are limits to how many TP circuits one can include in the same jacket, and their bandwidth is uh limited (a lot better than we thought once, but still limited). The _isolation_ of fibre or coax allowed packing multiple circuits reusing the same several frequencies (colors) of light into a small trench along that RR right of way. (Back of envelope SWAG, a single dark fibre in that bundle has more bandwidth than all the transcontinental circuits in microwave-tower days, and uses less energy?) And the speed of light through fiber is about 2/3 the speed of light > through air (or space). > True > This floored me the first time I heard about it. > Indeed, after all repetitions of the relativistic "*the speed of light is a constant*" * mantra we'd absorbed, finding out that* different* speeds of light? are *why* lenses and prisms are useful is a "*can i think two thoughts*" cognitive-dissonance problem until one works through in Physics class it and sees they're two sides of the same coin. *(same WRTO different reference frames/observers, but always referring to* freespace vacuum,* even outside gravity wells until you get to General Relativity) ?(different WRTO different *media*) (*In these overspecialized times, whether a future telecoms manager gets the Physics class that works through that is a different matter.*) Note that 2/3 (67%) is the ratio for fiber to free space, fiber is > basically the same propagation speed as coax and most twisted pair. > Twin-lead is actually faster - 80%. > The only common media that comes close to air/vacuum is open-ladder wire. Yes. It's roughly a speed of propagation vs leakage (power efficiency & privacy) tradeoff. (HOWEVER the usual reasons for preferring Twin-lead or ladder-line (whether "open" or "window)" vs Coax, fibre, or twisted pair is rarely the phase-velocity aka speed limit. Almost always the choice is by power limit, power efficiency/dielectric losses at frequency, and/or impedance matching. Which is why Ethernet and two-way radio use 50? coax, but Cable-TV, long-run TV antenna leads, etc use 75? coax.) Even an evacuated metal waveguide is slower than freespace air/vacuum, because the power efficiency (defeating 1/r? law, which is a power law in both senses) is gained by reflections off the walls, so next extra distance travelled, zig-zag, was the pre-relativistic explanation for the delay. (Coax or waveguide with dielectric filling gets even slower but gets more bendable and less likely to have spark breakdown or short circuits, but more tradeoffs vs wavelength there too.) Air is technically slower than Physics's platonic freespace vacuum, but the refractive index of air is so low * n(air)=vp/c=~ 1.0003* that it's phase-velocity *vp = 0.9997 ? c* , so those are both usually negligibly different from exactly integer 1 (value at freespace vacuum), as compared to ? or 80% *c* for practical signal paths. (At microwave frequency, the moisture in clouds changes *v*p and *n* sufficiently that instead of scattering as light does, clouds can act as a lens or prism. The difference between light and microwaves is how well the water molecules or droplets couple with the E-M wave; shorter wavelength light treats each droplet as a lens/prism/reflector, hence rainbows and also scattering; longer microwaves treat the cloud of droplets as an aggregate dielectric foam 'nano material'. As that might imply, certain varieties of common craft/buiders' foam-board can be layered to build microwave lenses. ) NOW if speed *really* matters ... say one is a High-Speed financial trader trying to shave milli-seconds off time to receive and react to a price change before the other dude when arbitraging Chicago vs NY exchanges ... dedicated microwave point to point links may still be worth the expense, along with simplistic JFDI protocols instead of the fancy routing that we discuss here; but the modulation/demodulation adds another layer of router-like delay, particularly if it's an error-correcting coding. (Which if not including TCP error detection/retransmission would be a good idea!) So it's elephants tradeoffs all the way down. / Bill Ricker From gnu at toad.com Wed Feb 8 18:43:34 2023 From: gnu at toad.com (John Gilmore) Date: Wed, 08 Feb 2023 18:43:34 -0800 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: <20230208013104.EE65B90CFD8E@ary.qy> References: <20230208013104.EE65B90CFD8E@ary.qy> Message-ID: <29581.1675910614@hop.toad.com> John Levine via Internet-history wrote: > These days most bulk mail systems customize each recipient's message a > little, so it's all single recipient sent in parallel anyway. <[[get off my lawn]]> Yes, who could have expected that in 2023, each message sent to a mailing list would have unique spyware carefully inserted into each recipient's message in the hope of developing a database of detailed information about where, when, and by whom each message ever sent was read, re-read, and/or forwarded? What's even more surprising to me is how the Internet community didn't run those covertly spying bastards off of our lawn on a rail, for adopting spammer tactics and then monetizing them to sell the info to advertisers and governments. That was my reaction! At the start, commercial companies wouldn't adopt the spyware because it made them look too much like spammers. So the spyware companies marketed to nonprofits, which were too non-tech-savvy to notice. A whole generation of email-marketing students were taught that secretly spying on your donors' daily online activities was the preferred way to get them to give you money. I ceased my substantial donations to a bunch of nonprofits who would not reconsider the decision to start including spyware in their emails (the largest of which was the Drug Policy Alliance, early on). This has saved me hundreds of thousands of dollars per year, while motivating a few savvy nonprofits to learn enough from me about what was being done in their name by their subcontractor, to avoid spying on their best supporters and biggest donors. But the Internet community in general welcomed the spyware companies in! Perhaps on a mistaken theory that this was somehow contributing to anti-spam efforts? It's gotten to the point that now, it takes real negotiation for even a large pre-existing mailing list to move to a different bulk email provider without requiring the insertion of spyware links and web bugs into every message they send. (For example, the Internet Archive found itself unable to send fundraising mails without explicitly agreeing that they could not suppress the spyware that their new vendor demanded to inject into each message sent.) Meanwhile, the same bulk email vendors, particularly MailChimp, don't even offer the recipients of actual spam sent by the vendor a way to tell the vendor that the email the recipient is trying to unsubscribe from WAS spam that the recipient had never signed up to receive. Apparently the vendors would rather NOT KNOW that they are taking money from spammers to send out spams. But they are happy, no, they insist!, to develop detailed information about every recipient of every innocuous wanted piece of email. John From johnl at iecc.com Wed Feb 8 18:58:58 2023 From: johnl at iecc.com (John R. Levine) Date: 8 Feb 2023 21:58:58 -0500 Subject: [ih] Design choices in SMTP (custom emails per recipient) Message-ID: <214206c6-ee56-6250-ab08-925b92265151@iecc.com> > <[[get off my lawn]]> > > Yes, who could have expected that in 2023, each message sent to a > mailing list would have unique spyware carefully inserted into each > recipient's message in the hope of developing a database of detailed > information about where, when, and by whom each message ever sent was > read, re-read, and/or forwarded? Please, sir, step away from the kool-aid. The main reason bulk mail is customized these days is to put in unsubscribe links that let recipients unsub with one click without having to guess what address it was sent to. I suppose some mail has web bugs, but these days most MUAs don't fetch them, and the big webmail systems use proxy farms so even if they do fetch them, the senders can't tell who or what clicked on them. Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From internet-history at gtaylor.tnetconsulting.net Wed Feb 8 22:47:55 2023 From: internet-history at gtaylor.tnetconsulting.net (Grant Taylor) Date: Wed, 8 Feb 2023 23:47:55 -0700 Subject: [ih] Design choices in SMTP In-Reply-To: References: Message-ID: <0641efd8-4faa-3eeb-44b9-9119ebff7b36@spamtrap.tnetconsulting.net> On 2/8/23 5:47 AM, Michael Kj?rling via Internet-history wrote: > I have for a long time found Cliff Stoll's postulation about the > distance to the hacker in _The Cuckoo's Egg_ to be an interesting > illustration of this. Your comment reminded me of the case of the 500-mile email by Trey Harris. Link - The case of the 500-mile email - https://www.ibiblio.org/harris/500milemail.html -- Grant. . . . unix || die From dhc at dcrocker.net Thu Feb 9 06:16:14 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Thu, 9 Feb 2023 06:16:14 -0800 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> References: <20230208013104.EE65B90CFD8E@ary.qy> <29581.1675910614@hop.toad.com> <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> Message-ID: > The main reason bulk mail is customized these days is to put in > unsubscribe links that let recipients unsub with one click without > having to guess what address it was sent to. The other main reason is to measure things like click-through rates, and to send more emails, to bug you for not having clicked through yet. There might be a few other main reasons. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From craig at tereschau.net Thu Feb 9 06:20:12 2023 From: craig at tereschau.net (Craig Partridge) Date: Thu, 9 Feb 2023 07:20:12 -0700 Subject: [ih] Fwd: Design choices in SMTP In-Reply-To: <20230209005302.2EA9F18C07B@mercury.lcs.mit.edu> References: <20230209005302.2EA9F18C07B@mercury.lcs.mit.edu> Message-ID: Thanks Noel - that's the page I'm remembering and I believe that's the FTP section that is missing from RFC 542. On Wed, Feb 8, 2023 at 5:53 PM Noel Chiappa wrote: > > On Wed, Feb 8, 2023 at 4:45 PM Craig Partridge wrote: > > > (As I recall, they were on a page by Jon Postel in the ARPANET > Protocol > > Handbook but may be misremembering). > > I looked in my hardcopy 1978 ARPANET Protocol Handbook - ToC here: > > http://mercury.lcs.mit.edu/~jnc/tech/arpaprot.html > > and there's a section for MAIL, but apart from a copy of RFC733, there's > only > a one-page thing, "Mail Protocol" (NIC 29588), in it. I put that online a > long > time ago: > > http://ana-3.lcs.mit.edu/~jnc/history/Mail_Protocol.txt > > Noel > -- ***** Craig Partridge's email account for professional society activities and mailing lists. From jeanjour at comcast.net Thu Feb 9 07:25:33 2023 From: jeanjour at comcast.net (John Day) Date: Thu, 9 Feb 2023 10:25:33 -0500 Subject: [ih] Design choices in SMTP In-Reply-To: <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> Message-ID: <3CAA4145-001C-4181-A0B8-BFFAD244ED6E@comcast.net> > > While I have no memory or documentation of when these commands were deployed in FTP, it's clear that it was not immediately after Ray created networked mail, and yet email was quickly widely used. Offhand, I'd guess the delay for the FTP commands was in the 1-2 year range. Possibly longer? MAIL and MLFL were put into FTP at the March 1973 meeting (RFC 542) (and at the very end of the meeting when Steve Crocker showed up and said we had to do it. People grumbled a bit and did it.) And of course it was the most useful thing the whole meeting did. ;-) The question then is how soon did implementations include the new commands. Take care, John > > Ergo, an original /use/ claim needs to cite CPYNET, not FTP. > > > d/ > > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker at mastodon.social > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From jeanjour at comcast.net Thu Feb 9 07:27:20 2023 From: jeanjour at comcast.net (John Day) Date: Thu, 9 Feb 2023 10:27:20 -0500 Subject: [ih] Design choices in SMTP In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> Message-ID: <397F100A-BDBF-405D-BD85-D9A446BB67B9@comcast.net> What I get for not keeping up with the list. ;-) > On Feb 8, 2023, at 16:45, Craig Partridge via Internet-history wrote: > > On Wed, Feb 8, 2023 at 2:24 PM Dave Crocker via Internet-history < > internet-history at elists.isoc.org> wrote: > >> On 2/8/2023 1:02 PM, Steffen Nurpmeso wrote: >>> >>> Here RFC 354 (THE FILE TRANSFER PROTOCOL) and RFC 385 (COMMENTS ON >>> THE FILE TRANSFER PROTOCOL) are missing, the latter includes MAIL >>> and MLFL. >> >> Count me as both befuddled and embarrassed. No idea why/how I missed 385. >> >> I left off 354 because it doesn't provide any email protocol specification. >> >> The fact that 385 explicitly specifies MAIL and MLFL makes the fact that >> neither are in the RFC 542 version of FTP quite odd.. >> >> > My recollection, from the digging into this that I did for the article on > the history of email for IEEE Annals, is there > was a tension between the FTP and email teams. There was a meeting about > FTP at MIT in March 1973 (that led to 542) where the FTP team > had decided to punt on email issues, only to have their DARPA PM (Steve > Crocker) show up and tell them that email mattered. > After the meeting, the group decided (in some sense, flouting Steve) that > email should really be in a separate annex and left email > commands out of RFC 542. (As I recall, they were on a page by Jon Postel > in the ARPANET Protocol Handbook but may be misremembering). > > 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 jeanjour at comcast.net Thu Feb 9 07:31:50 2023 From: jeanjour at comcast.net (John Day) Date: Thu, 9 Feb 2023 10:31:50 -0500 Subject: [ih] Design choices in SMTP In-Reply-To: <20230208225422.rwtCJ%steffen@sdaoden.eu> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> Message-ID: NETRJE didn?t get a lot of use because the systems that could support a Server FTP didn?t need the NETRJE. (Can someone correct me about that?) What did get a lot of use of was CCNRJE written by Bob Braden for the UCLA CCN 360/91. It opened a Telnet connection to the CCNRJE server and then did data transfers with connections a fixed offset from the Telnet connection: one for input, one for output. (Remember all of these applications were using Initial Connection Protocol (ICP) to move the initial connection off the well-known socket. Take care, John > On Feb 8, 2023, at 17:54, Steffen Nurpmeso via Internet-history wrote: > > Craig Partridge wrote in > : > |On Wed, Feb 8, 2023 at 2:24 PM Dave Crocker via Internet-history < > |internet-history at elists.isoc.org> wrote: > |> On 2/8/2023 1:02 PM, Steffen Nurpmeso wrote: > |>> > |>> Here RFC 354 (THE FILE TRANSFER PROTOCOL) and RFC 385 (COMMENTS ON > |>> THE FILE TRANSFER PROTOCOL) are missing, the latter includes MAIL > |>> and MLFL. > |> > |> Count me as both befuddled and embarrassed. No idea why/how I missed \ > |> 385. > |> > |> I left off 354 because it doesn't provide any email protocol specificati\ > |> on. > |> > |> The fact that 385 explicitly specifies MAIL and MLFL makes the fact that > |> neither are in the RFC 542 version of FTP quite odd.. > |> > |My recollection, from the digging into this that I did for the article on > |the history of email for IEEE Annals, is there > |was a tension between the FTP and email teams. There was a meeting about > |FTP at MIT in March 1973 (that led to 542) where the FTP team > |had decided to punt on email issues, only to have their DARPA PM (Steve > |Crocker) show up and tell them that email mattered. > |After the meeting, the group decided (in some sense, flouting Steve) that > |email should really be in a separate annex and left email > |commands out of RFC 542. (As I recall, they were on a page by Jon Postel > |in the ARPANET Protocol Handbook but may be misremembering). > > I am noting that 542 neither mentions 385 nor 475 at all. > RFC 475 states > > This paper describes my understanding of the results of the Network > Mail System meeting SRI-ARC on February 23, 1973, and the > implications for FTP (File Transfer Protocol). There was general > agreement at the meeting that network mail function should be within > FTP. > > FTP currently provides two commands for handling mail.[.] > > [.]Local mail and SNDMSG > programs have been modified at many sites to include network mailing > (e.g., USER at HOST at BBN_TENEX and MAIL host user at MIT-DMCG). > > And this does not sound to me as if it would have been wishful > thinking, but rather that it was actively being used? > > RFC 542 states in "MISCELLANEOUS COMMANDS" > > There are several functions that utilize the services of file > transfer but go beyond it in scope. These are the Mail and Remote > Job Entry functions. It is suggested that these become auxiliary > protocols that can assume recognition of file transfer commands on > the part of the server, i.e., they may depend on the core of FTP > commands. The command sets specific to Mail and RJE will be given in > separate documents. > > It also defines response status bits for mail. My local RFC pool > does not have the necessary bits to do sleuthing. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From jhlowry at mac.com Thu Feb 9 07:59:37 2023 From: jhlowry at mac.com (John Lowry) Date: Thu, 9 Feb 2023 10:59:37 -0500 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: References: <20230208013104.EE65B90CFD8E@ary.qy> <29581.1675910614@hop.toad.com> <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> Message-ID: Another reason that I ran into when standing up mail lists for my non-profits was to have automatic handling of bounced emails. My open source CRM app/database can insert tags and records into email. If mail gets returned/rejected, then there are many things that can be done about it. I don?t use it that way on principle but then my mailing lists are pretty small. I distinctly remember using telnet to send email as a diagnostic for rules and addressing, but also in a scripts to send software build results to distributed teams. I suppose that would be hard today and there may be ?better? ways. John > On Feb 9, 2023, at 09:16, Dave Crocker via Internet-history wrote: > > >> The main reason bulk mail is customized these days is to put in unsubscribe links that let recipients unsub with one click without having to guess what address it was sent to. > > > The other main reason is to measure things like click-through rates, and to send more emails, to bug you for not having clicked through yet. > > There might be a few other main reasons. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker at mastodon.social > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From craig at tereschau.net Thu Feb 9 08:09:04 2023 From: craig at tereschau.net (Craig Partridge) Date: Thu, 9 Feb 2023 09:09:04 -0700 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: References: <20230208013104.EE65B90CFD8E@ary.qy> <29581.1675910614@hop.toad.com> <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> Message-ID: Telneting to the SMTP port and hand typing email was a great source of fun in the 1970s and 1980s. The trick was to get all the 733/822 fields right. As I recall, From: The Great God Almighty <....>, was common. Though the uucp kremvax email still has to claim precedence as the best email spoof. (https://en.wikipedia.org/wiki/Kremvax). Craig On Thu, Feb 9, 2023 at 8:59 AM John Lowry via Internet-history < internet-history at elists.isoc.org> wrote: > > > I distinctly remember using telnet to send email as a diagnostic for rules > and > addressing, but also in a scripts to send software build results to > distributed > teams. I suppose that would be hard today and there may be ?better? ways. > > John > > -- ***** Craig Partridge's email account for professional society activities and mailing lists. From steve at shinkuro.com Thu Feb 9 08:10:42 2023 From: steve at shinkuro.com (Steve Crocker) Date: Thu, 9 Feb 2023 11:10:42 -0500 Subject: [ih] Design choices in SMTP In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> Message-ID: Heh, heh. Here's an unexpected consequence. UCLA's 360/91, the centerpiece of the Campus Computing Network (CCN) was one of the supercomputers of the day. DARPA/IPTO purchased a large chunk of computing time to support the climate dynamics research work we were doing. One of the key investigators was at Rand Corp in Santa Monica. The CCNRJE protocol made it possible for the Rand folks to interact with CCN without driving to UCLA. In 1974, I left DARPA and moved back to Los Angeles. I started working at ISI, but I still needed to complete my PhD thesis at UCLA. Although I didn't need to take any more classes, I noticed an interesting course in the catalog on Public Systems Analysis, taught by Jan Chaiken. Chaiken was on the staff at Rand and was teaching the course on the side. It looked interesting, so I signed up for the course. Chaiken organized the course to move from basic material on various public systems, e.g. location of fire stations, and math stuff progressing toward more practical problems. For the third quarter, we took on the problem of reorganizing the scheduling elective surgeries at the Kaiser Permanente Health System. They were experiencing 108% occupancy in the middle of each week, with patients sleeping on gurneys in the hallways. However, on the weekends, occupancy dropped to something like 70%. The solution to rescheduling turned out to be a very manageable integer programming problem. (Integer programming is the same as linear programming except the solution points have to be at integer lattice points within the feasible space.) One of the application packages available at CCN was a linear and integer programming package, so all we had to do was gather the necessary data and submit it to CCN for processing. In prior years when the class needed to use CCN for the class project, Chaiken would meet with students at UCLA to submit programs to CCN and wait for the results. I pointed out he could do the same from Rand. Thus, in spring 1975, we sat in air conditioned offices at Rand one day while we iterated our submissions. Chaiken declared it was the best thing he had learned in several years of teaching the course ;) Steve On Thu, Feb 9, 2023 at 10:32 AM John Day via Internet-history < internet-history at elists.isoc.org> wrote: > NETRJE didn?t get a lot of use because the systems that could support a > Server FTP didn?t need the NETRJE. (Can someone correct me about that?) > > What did get a lot of use of was CCNRJE written by Bob Braden for the UCLA > CCN 360/91. It opened a Telnet connection to the CCNRJE server and then did > data transfers with connections a fixed offset from the Telnet connection: > one for input, one for output. (Remember all of these applications were > using Initial Connection Protocol (ICP) to move the initial connection off > the well-known socket. > > Take care, > John > > > On Feb 8, 2023, at 17:54, Steffen Nurpmeso via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > Craig Partridge wrote in > > : > > |On Wed, Feb 8, 2023 at 2:24 PM Dave Crocker via Internet-history < > > |internet-history at elists.isoc.org> wrote: > > |> On 2/8/2023 1:02 PM, Steffen Nurpmeso wrote: > > |>> > > |>> Here RFC 354 (THE FILE TRANSFER PROTOCOL) and RFC 385 (COMMENTS ON > > |>> THE FILE TRANSFER PROTOCOL) are missing, the latter includes MAIL > > |>> and MLFL. > > |> > > |> Count me as both befuddled and embarrassed. No idea why/how I missed > \ > > |> 385. > > |> > > |> I left off 354 because it doesn't provide any email protocol > specificati\ > > |> on. > > |> > > |> The fact that 385 explicitly specifies MAIL and MLFL makes the fact > that > > |> neither are in the RFC 542 version of FTP quite odd.. > > |> > > |My recollection, from the digging into this that I did for the article > on > > |the history of email for IEEE Annals, is there > > |was a tension between the FTP and email teams. There was a meeting > about > > |FTP at MIT in March 1973 (that led to 542) where the FTP team > > |had decided to punt on email issues, only to have their DARPA PM (Steve > > |Crocker) show up and tell them that email mattered. > > |After the meeting, the group decided (in some sense, flouting Steve) > that > > |email should really be in a separate annex and left email > > |commands out of RFC 542. (As I recall, they were on a page by Jon > Postel > > |in the ARPANET Protocol Handbook but may be misremembering). > > > > I am noting that 542 neither mentions 385 nor 475 at all. > > RFC 475 states > > > > This paper describes my understanding of the results of the Network > > Mail System meeting SRI-ARC on February 23, 1973, and the > > implications for FTP (File Transfer Protocol). There was general > > agreement at the meeting that network mail function should be within > > FTP. > > > > FTP currently provides two commands for handling mail.[.] > > > > [.]Local mail and SNDMSG > > programs have been modified at many sites to include network mailing > > (e.g., USER at HOST at BBN_TENEX and MAIL host user at MIT-DMCG). > > > > And this does not sound to me as if it would have been wishful > > thinking, but rather that it was actively being used? > > > > RFC 542 states in "MISCELLANEOUS COMMANDS" > > > > There are several functions that utilize the services of file > > transfer but go beyond it in scope. These are the Mail and Remote > > Job Entry functions. It is suggested that these become auxiliary > > protocols that can assume recognition of file transfer commands on > > the part of the server, i.e., they may depend on the core of FTP > > commands. The command sets specific to Mail and RJE will be given in > > separate documents. > > > > It also defines response status bits for mail. My local RFC pool > > does not have the necessary bits to do sleuthing. > > > > --steffen > > | > > |Der Kragenbaer, The moon bear, > > |der holt sich munter he cheerfully and one by one > > |einen nach dem anderen runter wa.ks himself off > > |(By Robert Gernhardt) > > -- > > 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 dhc at dcrocker.net Thu Feb 9 11:22:33 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Thu, 9 Feb 2023 11:22:33 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> Message-ID: <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> > NETRJE didn?t get a lot of use because the systems that could support > a Server FTP didn?t need the NETRJE. (Can someone correct me about that?) > > What did get a lot of use of was CCNRJE written by Bob Braden for the > UCLA CCN 360/91. I used the RJE program, available at ISI, to submit jobs to the UCLA CCN 360/91.? But I would have sworn the author was someone other than Braden. The nature of the use was not as straightforward as Steve's example. My job was user support and documentation at the UCLA Arpanet project.? A year or two before getting hired, I'd become a fan of the NLS system at SRI, even including the text-only interface. (Prior to dropping out and getting hired for this job, I wrote a text formatter, with inline commands, that emulated the hierarchical text model in NLS.? I developed and ran it at my place of work which was the other 360/91 on campus, the NIH-funded Health Sciences Computing.? There were only 18 of those machines built. This was also my only major foray into using PL/1.) Anyhow, I taught the department secretaries -- remember when that was what they were called? -- to use the remote system.? After editing, we needed to be able to print documents.? The one's they'd been editing and the ones from the NIC, of course. So I had them FTP the document down to ISI and run the RJE program to send the document to the high-speed, upper and lower case printer at CCN.? The fastest U/L printer we had in the department was 120 cps, so this was /much/ better. This also wound up generating a serious bit of learning about computer science and statistics. (Before and after dropping out, I studied Psychology and had taken 1 really basic stats course and no CS courses.) The secretaries quickly got facile with the process, but they started complaining that the sequence would often fail.? I turned to my office mate, Jon Postel, and asked whether he had any suggestions. He had me explain the total sequence being used and asked how often things were failing and what the symptoms were. I noted that there were widely different systems, but that the overall failure rate seemed to be about 50%, He? asked how reliable our department Sigma 7 was, I suggested a good, but not outstanding number and he agreed.? Then he asked about the net itself, and we agreed it was highly reliable, maybe 90%. Then SRI, which wasn't great, and ISI, which had gotten quite good, then CCN, which was not great. Cumulative probably came out almost exactly at 50% I later hear that the failure to perform a similar, aggregate failure rate exercise was the reason the Russians beat us to space... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From jeanjour at comcast.net Thu Feb 9 12:24:27 2023 From: jeanjour at comcast.net (John Day) Date: Thu, 9 Feb 2023 15:24:27 -0500 Subject: [ih] Design choices in SMTP In-Reply-To: <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> Message-ID: Wasn?t it called NETRJS and was defined in RFC 189? Which had Braden?s name on it. John > On Feb 9, 2023, at 14:22, Dave Crocker via Internet-history wrote: > > >> NETRJE didn?t get a lot of use because the systems that could support a Server FTP didn?t need the NETRJE. (Can someone correct me about that?) >> >> What did get a lot of use of was CCNRJE written by Bob Braden for the UCLA CCN 360/91. > > > I used the RJE program, available at ISI, to submit jobs to the UCLA CCN 360/91. But I would have sworn the author was someone other than Braden. > > > The nature of the use was not as straightforward as Steve's example. > > My job was user support and documentation at the UCLA Arpanet project. A year or two before getting hired, I'd become a fan of the NLS system at SRI, even including the text-only interface. (Prior to dropping out and getting hired for this job, I wrote a text formatter, with inline commands, that emulated the hierarchical text model in NLS. I developed and ran it at my place of work which was the other 360/91 on campus, the NIH-funded Health Sciences Computing. There were only 18 of those machines built. This was also my only major foray into using PL/1.) > > Anyhow, I taught the department secretaries -- remember when that was what they were called? -- to use the remote system. After editing, we needed to be able to print documents. The one's they'd been editing and the ones from the NIC, of course. > > So I had them FTP the document down to ISI and run the RJE program to send the document to the high-speed, upper and lower case printer at CCN. The fastest U/L printer we had in the department was 120 cps, so this was /much/ better. > > This also wound up generating a serious bit of learning about computer science and statistics. (Before and after dropping out, I studied Psychology and had taken 1 really basic stats course and no CS courses.) > > The secretaries quickly got facile with the process, but they started complaining that the sequence would often fail. I turned to my office mate, Jon Postel, and asked whether he had any suggestions. He had me explain the total sequence being used and asked how often things were failing and what the symptoms were. > > I noted that there were widely different systems, but that the overall failure rate seemed to be about 50%, > > He asked how reliable our department Sigma 7 was, I suggested a good, but not outstanding number and he agreed. Then he asked about the net itself, and we agreed it was highly reliable, maybe 90%. Then SRI, which wasn't great, and ISI, which had gotten quite good, then CCN, which was not great. > > Cumulative probably came out almost exactly at 50% > > I later hear that the failure to perform a similar, aggregate failure rate exercise was the reason the Russians beat us to space... > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > 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 Thu Feb 9 13:03:09 2023 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 9 Feb 2023 13:03:09 -0800 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: References: <20230208013104.EE65B90CFD8E@ary.qy> <29581.1675910614@hop.toad.com> <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> Message-ID: <3b3a2dad-f983-dc10-7981-5bc59ed0cdb6@3kitty.org> I remember that hack.? You could send email posing as anyone you liked, by just putting whatever you wanted into the From: header field.?? It drove me crazy trying to get my mail server, which tried to parse and verify those fields, to deal with all the poetry people put into email headers. Sadly, it's not just a problem of the ancient 1970s/80s.? I regularly receive emails now, in 2023, which look like I sent them.?? I can recognize them as phishing blackmail, but I suspect many people cannot tell that they're forged. Here's one below that I got recently.?? Allegedly I sent it to myself.? By looking at the message source, I can tell from the 103.167.66.22 address that it actually came from somewhere in the Philippines.?? And trust me -- I didn't send it.? So it's apparently still easy to forge the source and author of messages, probably using a different technique instead of Telnet to port 25. After 50 years of technology progress, I would have expected such vulnerabilities of the 70s research networks to have been addressed by now.? Perhaps Historians can explain why that hasn't happened? Jack? (check this message's source if you suspect it's forged.....) PS - Here's a piece of a recent forged message source: =========================== Return-Path: Delivered-To:jack at 3kitty.org Received: (qmail 23808 invoked by uid 80); 5 Feb 2023 23:29:14 -0000 Received: from unknown (HELO atl4mhib66.registeredsite.com) (209.17.115.201) by abimarierecords.net with SMTP; 5 Feb 2023 23:29:14 -0000 Received: from [103.167.66.22] ([103.167.66.22]) by atl4mhib66.registeredsite.com (8.14.4/8.14.4) with ESMTP id 315NTCa1039068 for; Sun, 5 Feb 2023 18:29:13 -0500 Message-ID: <64121F8F6D6982FD8B8616F4F01B6412 at CTW7FJC8M> From: To: Subject: You have an outstanding payment. ====================================== On 2/9/23 08:09, Craig Partridge via Internet-history wrote: > Telneting to the SMTP port and hand typing email was a great source of fun > in the 1970s and 1980s. The trick was to get all the 733/822 fields right. > > As I recall, From: The Great God Almighty <....>, was common. > > Though the uucp kremvax email still has to claim precedence as the best > email spoof. (https://en.wikipedia.org/wiki/Kremvax). > > Craig > > On Thu, Feb 9, 2023 at 8:59 AM John Lowry via Internet-history < > internet-history at elists.isoc.org> wrote: > >> >> I distinctly remember using telnet to send email as a diagnostic for rules >> and >> addressing, but also in a scripts to send software build results to >> distributed >> teams. I suppose that would be hard today and there may be ?better? ways. >> >> John >> >> From dhc at dcrocker.net Thu Feb 9 13:27:57 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Thu, 9 Feb 2023 13:27:57 -0800 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: <3b3a2dad-f983-dc10-7981-5bc59ed0cdb6@3kitty.org> References: <20230208013104.EE65B90CFD8E@ary.qy> <29581.1675910614@hop.toad.com> <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> <3b3a2dad-f983-dc10-7981-5bc59ed0cdb6@3kitty.org> Message-ID: <97e5e2bb-6fbc-382e-8bf6-622b153419ba@dcrocker.net> On 2/9/2023 1:03 PM, Jack Haverty via Internet-history wrote: > I remember that hack.? You could send email posing as anyone you > liked, by just putting whatever you wanted into the From: header > field.?? It drove me crazy trying to get my mail server, which tried > to parse and verify those fields, to deal with all the poetry people > put into email headers. > > Sadly, it's not just a problem of the ancient 1970s/80s.? I regularly > receive emails now, in 2023, which look like I sent them.?? I can > recognize them as phishing blackmail, but I suspect many people cannot > tell that they're forged. Note: 1. The content From: header field has 3 components:? Free-form display 'name', author mailbox, and author domain. 2. There is a continuing constituency of anti-abuse folk who want to find a way to restrict the 'abuses' of the display-name. They have never come up with anything that has any hope of doing a generally useful job.? Some sites, however, do reject or sideline mail that has a display-name with the syntax of an email address. 3. There is literally no empirical evidence that any of this affects recipient behavior.? Users are primarily affect by the actual content, not the From field. DMARC was created to prevent spoofing the From: field domain name. It's effective, but created serious collateral damage for mail going through alias forwarders and mailing lists. Among the anti-abuse community, people are quite cavalier about the collateral damage. In response to the damage, it is common for mailing lists to now recast the From field, along the lines of what this list does: They replace the From: field with the address of the mailing list, recase display-name to annotate that they've messed with the field, and set Reply-To: to be the author's address.? The irony is that this is now an accepted means of bypassing DMARC protection. In architectural terms, this has turned the From: field pretty much into what was (and is) originally the semantics of the Sender: field. In response, I recently did RFC 9057, Email Author Header Field, to provide a place for unmodified author information.? While I'm amused to see exactly three people are sending mail to my inbox using that field, I believe it has, so far, had virtually no uptake. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From jack at 3kitty.org Thu Feb 9 14:18:48 2023 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 9 Feb 2023 14:18:48 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> Message-ID: RJE was another priority of Lick at MIT.?? So I implemented an RJE for our PDP-10 to enable users to submit their "card decks" and get their "printout" after their job was run.?? Checking to see if the job had been run was part of the RJE protocol, but there was no way to have the CCN system proactively tell you your output was ready. So I had to build a "daemon" for the PDP-10 (ITS OS) to interact with the CCN over the ARPANET, submitting the card deck, polling periodically to see if the job was done (there was no way to ask about the job queue), and then retrieve the output (whatever would have come out on the CCN printer). AFAIK, there was very little if any use of this system at MIT.? Most people had had their fill of punch cards and waiting for listings. But the testing I did indicated an annoyingly high failure rate. Not as bad as 50%, but far less than 99%. So, debugging time..... Since the polling nature of the interaction meant that the human user might not be online, a daemon process had to run on the system to do the interactions with CCN whenever CCN was ready.?? I had already written a mail server daemon, so it was an obvious design choice to simply add RJE functionality to the mail server.?? To "submit a card deck", you would prepare the card deck in your favorite editor, then use it as the text of a "message".? But instead of "sending" the message, you would "submit to CCN".?? The mail server would then fire up an RJE connection rather than an SMTP one, and carry out all of the needed interactions with the CCN system.?? When the job output was ready, the daemon would retrieve the listing from CCN, and inform the originating user that the output was available.? That output looked like just another message, which could be archived, forwarded, sent to the printer, sent to the Datacomputer for posterity, or whatever else you could do with "email".?? Essentially from a user's view you emailed your card deck to CCN, and somewhat later got a reply containing the printer output. The use of a daemon meant that all of the interactions over the ARPANET were computer-computer rather than human-computer.?? This followed Lick's vision of having the computer and network help people do stuff.?? We assumed people would have their local computers connected to the network, where traditionally people would have their terminal connected to the network, logged in to some remote computer over a Telnet-style connection. I found the source of the unreliability. Sadly, although our design was based on computer-computer interactions, the RJE protocol mechanisms were based on human-computer interactions.? RJE assumed that there was a human at the other end of the connection.? The commands and responses were pretty well defined, so my code could generally imitate a human pretty effectively and handle submitting a card deck and retrieving the results. But since the system assumed there was a human in the picture.... Looking at the logs, I noticed that the protocol interactions, all those nicely formatted commands and responses, would occasionally be interrupted by "noise" on the connection.?? You would occasionally see something like: MESSAGE FROM SYSOP!!!?? Remember CCN will be down this Saturday and Sunday for installation of additional disk drives! Such "noise" would really screw up the state machine dealing with the RJE exchanges.?? It could happen at any time, even in the middle of an important protocol word, and would simply appear in the ascii stream that was carrying all of the RJE protocol commands. This experience and other similar encounters with trying to use a human-computer connection for computer-computer interactions (email headers were a big one, as well as the idiosyncracies of the FTP "MAIL" command) motivated me to write RFC 722 -- https://www.rfc-editor.org/rfc/rfc722 to try and capture some design principles for computer-computer interactions that were crucial to Lick's vision. Fun times, if sometimes a bit frustrating. Jack On 2/9/23 11:22, Dave Crocker via Internet-history wrote: > >> NETRJE didn?t get a lot of use because the systems that could support >> a Server FTP didn?t need the NETRJE. (Can someone correct me about >> that?) >> >> What did get a lot of use of was CCNRJE written by Bob Braden for the >> UCLA CCN 360/91. > > > I used the RJE program, available at ISI, to submit jobs to the UCLA > CCN 360/91.? But I would have sworn the author was someone other than > Braden. > > > The nature of the use was not as straightforward as Steve's example. > > My job was user support and documentation at the UCLA Arpanet > project.? A year or two before getting hired, I'd become a fan of the > NLS system at SRI, even including the text-only interface. (Prior to > dropping out and getting hired for this job, I wrote a text formatter, > with inline commands, that emulated the hierarchical text model in > NLS.? I developed and ran it at my place of work which was the other > 360/91 on campus, the NIH-funded Health Sciences Computing.? There > were only 18 of those machines built. This was also my only major > foray into using PL/1.) > > Anyhow, I taught the department secretaries -- remember when that was > what they were called? -- to use the remote system.? After editing, we > needed to be able to print documents.? The one's they'd been editing > and the ones from the NIC, of course. > > So I had them FTP the document down to ISI and run the RJE program to > send the document to the high-speed, upper and lower case printer at > CCN.? The fastest U/L printer we had in the department was 120 cps, so > this was /much/ better. > > This also wound up generating a serious bit of learning about computer > science and statistics. (Before and after dropping out, I studied > Psychology and had taken 1 really basic stats course and no CS courses.) > > The secretaries quickly got facile with the process, but they started > complaining that the sequence would often fail.? I turned to my office > mate, Jon Postel, and asked whether he had any suggestions. He had me > explain the total sequence being used and asked how often things were > failing and what the symptoms were. > > I noted that there were widely different systems, but that the overall > failure rate seemed to be about 50%, > > He? asked how reliable our department Sigma 7 was, I suggested a good, > but not outstanding number and he agreed.? Then he asked about the net > itself, and we agreed it was highly reliable, maybe 90%. Then SRI, > which wasn't great, and ISI, which had gotten quite good, then CCN, > which was not great. > > Cumulative probably came out almost exactly at 50% > > I later hear that the failure to perform a similar, aggregate failure > rate exercise was the reason the Russians beat us to space... > > d/ > From lk at cs.ucla.edu Thu Feb 9 14:44:00 2023 From: lk at cs.ucla.edu (Leonard Kleinrock) Date: Thu, 9 Feb 2023 14:44:00 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> Message-ID: <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> Lurking as I observe this really interesting exchange, I smile as I think about the attempts by you folks to use the early ARPANET while my measurement and evaluation team was busy trying to break the net with nasty traffic patterns and loads. Lovely! We seldom heard any complaints, and now I can guess that the users were too busy being plagued with the kind of frustrations you have been chronicling! As a side point, I recall that Bill Kehl of UCLA?s CCN purchased an increase to the core memory for his 360/91 by a megabyte and a short time later, IBM announced a dramatic price reduction which was too late for UCLA! Ouch! Best, Len > On Feb 9, 2023, at 2:18 PM, Jack Haverty via Internet-history wrote: > > RJE was another priority of Lick at MIT. So I implemented an RJE for our PDP-10 to enable users to submit their "card decks" and get their "printout" after their job was run. Checking to see if the job had been run was part of the RJE protocol, but there was no way to have the CCN system proactively tell you your output was ready. So I had to build a "daemon" for the PDP-10 (ITS OS) to interact with the CCN over the ARPANET, submitting the card deck, polling periodically to see if the job was done (there was no way to ask about the job queue), and then retrieve the output (whatever would have come out on the CCN printer). > > AFAIK, there was very little if any use of this system at MIT. Most people had had their fill of punch cards and waiting for listings. But the testing I did indicated an annoyingly high failure rate. Not as bad as 50%, but far less than 99%. > > So, debugging time..... > > Since the polling nature of the interaction meant that the human user might not be online, a daemon process had to run on the system to do the interactions with CCN whenever CCN was ready. I had already written a mail server daemon, so it was an obvious design choice to simply add RJE functionality to the mail server. To "submit a card deck", you would prepare the card deck in your favorite editor, then use it as the text of a "message". But instead of "sending" the message, you would "submit to CCN". The mail server would then fire up an RJE connection rather than an SMTP one, and carry out all of the needed interactions with the CCN system. When the job output was ready, the daemon would retrieve the listing from CCN, and inform the originating user that the output was available. That output looked like just another message, which could be archived, forwarded, sent to the printer, sent to the Datacomputer for posterity, or whatever else you could do with "email". Essentially from a user's view you emailed your card deck to CCN, and somewhat later got a reply containing the printer output. > > The use of a daemon meant that all of the interactions over the ARPANET were computer-computer rather than human-computer. This followed Lick's vision of having the computer and network help people do stuff. We assumed people would have their local computers connected to the network, where traditionally people would have their terminal connected to the network, logged in to some remote computer over a Telnet-style connection. > > I found the source of the unreliability. > > Sadly, although our design was based on computer-computer interactions, the RJE protocol mechanisms were based on human-computer interactions. RJE assumed that there was a human at the other end of the connection. The commands and responses were pretty well defined, so my code could generally imitate a human pretty effectively and handle submitting a card deck and retrieving the results. > > But since the system assumed there was a human in the picture.... > > Looking at the logs, I noticed that the protocol interactions, all those nicely formatted commands and responses, would occasionally be interrupted by "noise" on the connection. You would occasionally see something like: > > MESSAGE FROM SYSOP!!! Remember CCN will be down this Saturday and Sunday for installation of additional disk drives! > > Such "noise" would really screw up the state machine dealing with the RJE exchanges. It could happen at any time, even in the middle of an important protocol word, and would simply appear in the ascii stream that was carrying all of the RJE protocol commands. > > This experience and other similar encounters with trying to use a human-computer connection for computer-computer interactions (email headers were a big one, as well as the idiosyncracies of the FTP "MAIL" command) motivated me to write RFC 722 -- https://www.rfc-editor.org/rfc/rfc722 to try and capture some design principles for computer-computer interactions that were crucial to Lick's vision. > > Fun times, if sometimes a bit frustrating. > > Jack > > > > > On 2/9/23 11:22, Dave Crocker via Internet-history wrote: >> >>> NETRJE didn?t get a lot of use because the systems that could support a Server FTP didn?t need the NETRJE. (Can someone correct me about that?) >>> >>> What did get a lot of use of was CCNRJE written by Bob Braden for the UCLA CCN 360/91. >> >> >> I used the RJE program, available at ISI, to submit jobs to the UCLA CCN 360/91. But I would have sworn the author was someone other than Braden. >> >> >> The nature of the use was not as straightforward as Steve's example. >> >> My job was user support and documentation at the UCLA Arpanet project. A year or two before getting hired, I'd become a fan of the NLS system at SRI, even including the text-only interface. (Prior to dropping out and getting hired for this job, I wrote a text formatter, with inline commands, that emulated the hierarchical text model in NLS. I developed and ran it at my place of work which was the other 360/91 on campus, the NIH-funded Health Sciences Computing. There were only 18 of those machines built. This was also my only major foray into using PL/1.) >> >> Anyhow, I taught the department secretaries -- remember when that was what they were called? -- to use the remote system. After editing, we needed to be able to print documents. The one's they'd been editing and the ones from the NIC, of course. >> >> So I had them FTP the document down to ISI and run the RJE program to send the document to the high-speed, upper and lower case printer at CCN. The fastest U/L printer we had in the department was 120 cps, so this was /much/ better. >> >> This also wound up generating a serious bit of learning about computer science and statistics. (Before and after dropping out, I studied Psychology and had taken 1 really basic stats course and no CS courses.) >> >> The secretaries quickly got facile with the process, but they started complaining that the sequence would often fail. I turned to my office mate, Jon Postel, and asked whether he had any suggestions. He had me explain the total sequence being used and asked how often things were failing and what the symptoms were. >> >> I noted that there were widely different systems, but that the overall failure rate seemed to be about 50%, >> >> He asked how reliable our department Sigma 7 was, I suggested a good, but not outstanding number and he agreed. Then he asked about the net itself, and we agreed it was highly reliable, maybe 90%. Then SRI, which wasn't great, and ISI, which had gotten quite good, then CCN, which was not great. >> >> Cumulative probably came out almost exactly at 50% >> >> I later hear that the failure to perform a similar, aggregate failure rate exercise was the reason the Russians beat us to space... >> >> d/ >> > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From dhc at dcrocker.net Thu Feb 9 14:57:45 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Thu, 9 Feb 2023 14:57:45 -0800 Subject: [ih] Design choices in SMTP In-Reply-To: <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> Message-ID: <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> > As a side point, I recall that Bill Kehl of UCLA?s CCN purchased an increase to the core memory for his 360/91 by a megabyte and a short time later, IBM announced a dramatic price reduction which was too late for UCLA! Ouch! The 360/91 had a maximum primary memory limit of 2MB.? Down at Health Sciences, that's what we lived with. CCN had 4MB.? The extra two were run off of peripheral storage control.? This mean that the amount of time and the amount of money, to run a job, depended on which memory it landed in. And as long as we are doing anecdotes... One of my early tasks on the Arpanet project was various scut work in aid of the Arpanet coming out party in DC.? One Saturday, Vint dragged me along to a meeting at CCN. We were sitting at a table in the machine room when the system crashed.? We all looked up for a moment and then went back to discussions.? Maybe 20 minutes later I looked up and the shift lead was still on the phone talking to whoever.? I asked the senior CCN person at the table what he thought was going on and he said they were checking whether to call an IBM engineer in. With pretty much no thought -- as in, being thoughtless -- I said it was bad memory module.? The guy stared at me and I explained that the top rows of red lights -- hardware error lights -- had lots of lights on in a random pattern and that that always meant bad memory. Until that moment, I had no realized just how good our training had been, down at the lean mean Health Sciences computing machine, where I'd been an part-time operator for 4 years. ps. The modules were call Basic Operating Memory until IBM got a call from the FBI noting that it was a bit discocerting to airport staff when IBM called to asked whether the BOM they were shipping had arrived yet.? It was then re-named Basic Storage Module, which of course everyone called BOM.? Such is the lesson of installed base momentum. -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From brian.e.carpenter at gmail.com Thu Feb 9 14:58:12 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 10 Feb 2023 11:58:12 +1300 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: <97e5e2bb-6fbc-382e-8bf6-622b153419ba@dcrocker.net> References: <20230208013104.EE65B90CFD8E@ary.qy> <29581.1675910614@hop.toad.com> <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> <3b3a2dad-f983-dc10-7981-5bc59ed0cdb6@3kitty.org> <97e5e2bb-6fbc-382e-8bf6-622b153419ba@dcrocker.net> Message-ID: <56fd1b55-439d-aa27-8d86-e4adcb143d43@gmail.com> > I recently did RFC 9057 And it's Experimental/independent stream, which won't get the attention of many product managers. Theoretically, any Thunderbird user can set it up for themself, but that will only be a few geeks, and I suppose there might be unintended consequences. Brian On 10-Feb-23 10:27, Dave Crocker via Internet-history wrote: > On 2/9/2023 1:03 PM, Jack Haverty via Internet-history wrote: >> I remember that hack.? You could send email posing as anyone you >> liked, by just putting whatever you wanted into the From: header >> field.?? It drove me crazy trying to get my mail server, which tried >> to parse and verify those fields, to deal with all the poetry people >> put into email headers. >> >> Sadly, it's not just a problem of the ancient 1970s/80s.? I regularly >> receive emails now, in 2023, which look like I sent them.?? I can >> recognize them as phishing blackmail, but I suspect many people cannot >> tell that they're forged. > > Note: > > 1. The content From: header field has 3 components:? Free-form display > 'name', author mailbox, and author domain. > 2. There is a continuing constituency of anti-abuse folk who want to > find a way to restrict the 'abuses' of the display-name. They have > never come up with anything that has any hope of doing a generally > useful job.? Some sites, however, do reject or sideline mail that > has a display-name with the syntax of an email address. > 3. There is literally no empirical evidence that any of this affects > recipient behavior.? Users are primarily affect by the actual > content, not the From field. > > DMARC was created to prevent spoofing the From: field domain name. It's > effective, but created serious collateral damage for mail going through > alias forwarders and mailing lists. Among the anti-abuse community, > people are quite cavalier about the collateral damage. > > In response to the damage, it is common for mailing lists to now recast > the From field, along the lines of what this list does: They replace the > From: field with the address of the mailing list, recase display-name to > annotate that they've messed with the field, and set Reply-To: to be the > author's address.? The irony is that this is now an accepted means of > bypassing DMARC protection. > > In architectural terms, this has turned the From: field pretty much into > what was (and is) originally the semantics of the Sender: field. > > In response, I recently did RFC 9057, Email Author Header Field, to > provide a place for unmodified author information.? While I'm amused to > see exactly three people are sending mail to my inbox using that field, > I believe it has, so far, had virtually no uptake. > > d/ > From brian.e.carpenter at gmail.com Thu Feb 9 15:00:47 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 10 Feb 2023 12:00:47 +1300 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: <56fd1b55-439d-aa27-8d86-e4adcb143d43@gmail.com> References: <20230208013104.EE65B90CFD8E@ary.qy> <29581.1675910614@hop.toad.com> <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> <3b3a2dad-f983-dc10-7981-5bc59ed0cdb6@3kitty.org> <97e5e2bb-6fbc-382e-8bf6-622b153419ba@dcrocker.net> <56fd1b55-439d-aa27-8d86-e4adcb143d43@gmail.com> Message-ID: And this is whatever Thunderbird produces... Regards Brian On 10-Feb-23 11:58, Brian E Carpenter wrote: >> I recently did RFC 9057 > > And it's Experimental/independent stream, which won't get the attention > of many product managers. Theoretically, any Thunderbird user can set it > up for themself, but that will only be a few geeks, and I suppose there > might be unintended consequences. > > Brian > > On 10-Feb-23 10:27, Dave Crocker via Internet-history wrote: >> On 2/9/2023 1:03 PM, Jack Haverty via Internet-history wrote: >>> I remember that hack.? You could send email posing as anyone you >>> liked, by just putting whatever you wanted into the From: header >>> field.?? It drove me crazy trying to get my mail server, which tried >>> to parse and verify those fields, to deal with all the poetry people >>> put into email headers. >>> >>> Sadly, it's not just a problem of the ancient 1970s/80s.? I regularly >>> receive emails now, in 2023, which look like I sent them.?? I can >>> recognize them as phishing blackmail, but I suspect many people cannot >>> tell that they're forged. >> >> Note: >> >> 1. The content From: header field has 3 components:? Free-form display >> 'name', author mailbox, and author domain. >> 2. There is a continuing constituency of anti-abuse folk who want to >> find a way to restrict the 'abuses' of the display-name. They have >> never come up with anything that has any hope of doing a generally >> useful job.? Some sites, however, do reject or sideline mail that >> has a display-name with the syntax of an email address. >> 3. There is literally no empirical evidence that any of this affects >> recipient behavior.? Users are primarily affect by the actual >> content, not the From field. >> >> DMARC was created to prevent spoofing the From: field domain name. It's >> effective, but created serious collateral damage for mail going through >> alias forwarders and mailing lists. Among the anti-abuse community, >> people are quite cavalier about the collateral damage. >> >> In response to the damage, it is common for mailing lists to now recast >> the From field, along the lines of what this list does: They replace the >> From: field with the address of the mailing list, recase display-name to >> annotate that they've messed with the field, and set Reply-To: to be the >> author's address.? The irony is that this is now an accepted means of >> bypassing DMARC protection. >> >> In architectural terms, this has turned the From: field pretty much into >> what was (and is) originally the semantics of the Sender: field. >> >> In response, I recently did RFC 9057, Email Author Header Field, to >> provide a place for unmodified author information.? While I'm amused to >> see exactly three people are sending mail to my inbox using that field, >> I believe it has, so far, had virtually no uptake. >> >> d/ >> From jack at 3kitty.org Thu Feb 9 18:16:51 2023 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 9 Feb 2023 18:16:51 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> Message-ID: <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> On 2/9/23 14:57, Dave Crocker via Internet-history wrote: > Such is the lesson of installed base momentum. I agree - the installed base is a formidable obstacle to getting any kind of replacement propagated.?? Stagnation and fragmentation into silos seems to be the result, as players introduce a desired new technology into just the components that they can control. But I also wonder -- How did TCP overcome the momentum of the installed base? At the time, in the 1990ish timeframe, there was a huge installed base of network technology.?? Hundreds of thousands of computers utilizing networks based on SNA, SPX, XNS, Decnet, etc. etc. ? TCP existed, but was a small player, confined largely to the academic and research communities. But almost overnight, actually over just a few years, TCP became a real player, and then the dominant player, and by now all of the other technologies of that installed base have simply disappeared. The installed base of 1990 is gone without a trace.? Are there any computers anywhere still running those well-established technologies??? I haven't encountered any, but I wouldn't be surprised if some still existed.?? Perhaps something running Cobol somewhere. So how did TCP manage to blast through that momentum of the installed base, creating such a chaos in the collision??? And how did it do it so rapidly? Curiously, that collision of TCP with the installed base involved TCP/IP V4.?? TCP/IP V6 has come along and its been quite a few years in transition.?? It seems that the momentum of the installed base of TCP/IP V4 has blunted the adoption of TCP/IP V6.?? Why?? What's different? A similar situation seems to exist in other network areas, e.g., the mechanisms of electronic mail that we've been discussing.? New technologies can get invented and documented, but often never get widely deployed.? Why??? What magic incantations were used to deploy TCP in the 1990s that have been apparently now lost. Perhaps some historian has some answers.... Jack From brian.e.carpenter at gmail.com Thu Feb 9 18:52:32 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 10 Feb 2023 15:52:32 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> Message-ID: <8a4de8c5-35ed-b7b1-5bf9-edf7fe988cd2@gmail.com> On 10-Feb-23 15:16, Jack Haverty via Internet-history wrote: > On 2/9/23 14:57, Dave Crocker via Internet-history wrote: >> Such is the lesson of installed base momentum. > I agree - the installed base is a formidable obstacle to getting any > kind of replacement propagated.?? Stagnation and fragmentation into > silos seems to be the result, as players introduce a desired new > technology into just the components that they can control. > > But I also wonder -- How did TCP overcome the momentum of the installed > base? Easy. It came for free with BSD Unix (and DEC Ultrix iirc) with a full suite of applications. So it came on Sun, Silicon Graphics, Cray, and there were X-terminals. There were cheap TCP/IP packages for PCs, and Wollongong was reasonably priced for DEC/VMS. Everything else was proprietary (SNA, Novell Netware, DECnet, etc.) or imaginary (OSI). (IBM mainframes were a sticking point for a while.) The timeframe was actually 1985-1990. The game was already over by 1990, although it took another few years and the launch of Mosaic and Netscape before management mainly realised it. > > At the time, in the 1990ish timeframe, there was a huge installed base > of network technology.?? Hundreds of thousands of computers utilizing > networks based on SNA, SPX, XNS, Decnet, etc. etc. ? TCP existed, but > was a small player, confined largely to the academic and research > communities. But we had an open network, and for most of the industry, that was still a dream. It was interesting in the early 90s talking to the European IT industry about what academia was doing - they simply couldn't understand what we were talking about or why we wanted 34 Mbps international links, when they thought 9600 baud was high speed. > > But almost overnight, actually over just a few years, TCP became a real > player, and then the dominant player, and by now all of the other > technologies of that installed base have simply disappeared. The > installed base of 1990 is gone without a trace.? Are there any computers > anywhere still running those well-established technologies??? I haven't > encountered any, but I wouldn't be surprised if some still existed. > Perhaps something running Cobol somewhere. > > So how did TCP manage to blast through that momentum of the installed > base, creating such a chaos in the collision??? And how did it do it so > rapidly? Suppressed demand, I think, and expectations aroused by OSI hype. And from 1995, the Web. > > Curiously, that collision of TCP with the installed base involved TCP/IP > V4.?? TCP/IP V6 has come along and its been quite a few years in > transition.?? It seems that the momentum of the installed base of TCP/IP > V4 has blunted the adoption of TCP/IP V6.?? Why?? What's different? We probably started IPv6 too soon, thinking very long term, so we over- designed. But that long term process was also to some extent obviated by the practical success of NAT, which took some of the urgency out of deploying IPv6. Google stats have IPv6 usage at 38% of the total now. Up a bit every month. https://www.ietf.org/archive/id/draft-ietf-v6ops-ipv6-deployment-10.html > > A similar situation seems to exist in other network areas, e.g., the > mechanisms of electronic mail that we've been discussing.? New > technologies can get invented and documented, but often never get widely > deployed.? Why??? What magic incantations were used to deploy TCP in the > 1990s that have been apparently now lost. Oh, I think it's an application by common consent of the adage "If it ain't broke, don't fix it." Email isn't badly enough broken, apparently. Brian > > Perhaps some historian has some answers.... > > Jack From jack at 3kitty.org Thu Feb 9 19:08:40 2023 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 9 Feb 2023 19:08:40 -0800 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: <97e5e2bb-6fbc-382e-8bf6-622b153419ba@dcrocker.net> References: <20230208013104.EE65B90CFD8E@ary.qy> <29581.1675910614@hop.toad.com> <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> <3b3a2dad-f983-dc10-7981-5bc59ed0cdb6@3kitty.org> <97e5e2bb-6fbc-382e-8bf6-622b153419ba@dcrocker.net> Message-ID: From the source of the message you just sent: ================= Reply-To:dcrocker at bbiw.net Subject: Re: [ih] Design choices in SMTP (custom emails per recipient) To: Jack Haverty From: Dave Crocker ========================= So you're saying that as a simple-minded mail user today, I should: - ignore the "Dave Crocker" that appears in my Inbox, since it might be forged - ignore the fact that I received this message from "Dave Crocker" rather than the preceding ones that were from "Dave Crocker via Internet-history" (I know the list tries to suppress duplicates) - somehow notice and remember that "dhc at crocker.net", which my mail program (Thunderbird) doesn't even normally display, is actually the person I've known for decades - not be concerned that "dcrocker at bbiw.net" might not be the same person to get this reply. Seems like a pretty poor UX design, IMHO. Jack On 2/9/23 13:27, Dave Crocker wrote: > On 2/9/2023 1:03 PM, Jack Haverty via Internet-history wrote: >> I remember that hack.? You could send email posing as anyone you >> liked, by just putting whatever you wanted into the From: header >> field.?? It drove me crazy trying to get my mail server, which tried >> to parse and verify those fields, to deal with all the poetry people >> put into email headers. >> >> Sadly, it's not just a problem of the ancient 1970s/80s.? I regularly >> receive emails now, in 2023, which look like I sent them.?? I can >> recognize them as phishing blackmail, but I suspect many people >> cannot tell that they're forged. > > Note: > > 1. The content From: header field has 3 components:? Free-form > display 'name', author mailbox, and author domain. > 2. There is a continuing constituency of anti-abuse folk who want to > find a way to restrict the 'abuses' of the display-name.? They > have never come up with anything that has any hope of doing a > generally useful job.? Some sites, however, do reject or sideline > mail that has a display-name with the syntax of an email address. > 3. There is literally no empirical evidence that any of this affects > recipient behavior.? Users are primarily affect by the actual > content, not the From field. > > DMARC was created to prevent spoofing the From: field domain name. > It's effective, but created serious collateral damage for mail going > through alias forwarders and mailing lists. Among the anti-abuse > community, people are quite cavalier about the collateral damage. > > In response to the damage, it is common for mailing lists to now > recast the From field, along the lines of what this list does:? They > replace the From: field with the address of the mailing list, recase > display-name to annotate that they've messed with the field, and set > Reply-To: to be the author's address.? The irony is that this is now > an accepted means of bypassing DMARC protection. > > In architectural terms, this has turned the From: field pretty much > into what was (and is) originally the semantics of the Sender: field. > > In response, I recently did RFC 9057, Email Author Header Field, to > provide a place for unmodified author information. While I'm amused to > see exactly three people are sending mail to my inbox using that > field, I believe it has, so far, had virtually no uptake. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker at mastodon.social From dhc at dcrocker.net Thu Feb 9 20:07:46 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Thu, 9 Feb 2023 20:07:46 -0800 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: References: <20230208013104.EE65B90CFD8E@ary.qy> <29581.1675910614@hop.toad.com> <51453575-a1f2-7328-0e8a-9c00fdbbcf9b@johnlevine.com> <3b3a2dad-f983-dc10-7981-5bc59ed0cdb6@3kitty.org> <97e5e2bb-6fbc-382e-8bf6-622b153419ba@dcrocker.net> Message-ID: <4803b4d7-ae6d-1311-4bbf-0408fb29cee0@dcrocker.net> On 2/9/2023 7:08 PM, Jack Haverty wrote: > Seems like a pretty poor UX design, IMHO. Oh it definitely is. Just like real-life. Whoever designed this reality really did an awful job. I mean, when someone calls and says who they are, I never know whether to believe them. And when I meet someone in a city and they tell me who they are and what they do, I'm never quite sure whether they are telling the truth. Email should, of course, be completely different from the rest of reality.? (Well, in some ways, I suppose it is.? But not this one.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From dhc at dcrocker.net Thu Feb 9 20:20:38 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Thu, 9 Feb 2023 20:20:38 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> Message-ID: <4d413470-f4f2-26ce-b777-40c32fa18953@dcrocker.net> On 2/9/2023 6:16 PM, Jack Haverty via Internet-history wrote: > On 2/9/23 14:57, Dave Crocker via Internet-history wrote: >> Such is the lesson of installed base momentum. > I agree - the installed base is a formidable obstacle to getting any > kind of replacement propagated.?? Stagnation and fragmentation into > silos seems to be the result, as players introduce a desired new > technology into just the components that they can control. > > But I also wonder -- How did TCP overcome the momentum of the > installed base? How did Jan 1, 1983 succeed?? Money and mandate.? Benign authoritarianism can be a good thing. Or how did the entire world move from its rich array of proprietary networks over to TCP/IP? In the latter case, the inability to communicate between silos was increasingly irritating to the market.? And the OSI world did a really excellent job of marketing the idea of a seamless interoperability, though of course, it didn't deliver a workable solution.? As the market interest increased, there was only one viable solution.... It's not as if the entire world embraced TCP/IP smoothly or willingly.? The oft-cited wars were many and oft-ugly. > But almost overnight, actually over just a few years, TCP became a > real player, ;It wasn't overnight.? As I recall, there was a growth curve charter from, I think, 1983, and what happened in the early 90s, fit the curve.? It just happened to be the knee of the curve. But there was a real commercial market for TCP/IP in the latter 1980s.? Which means that the explosion around 1994, when the Internet went mass-market, took around 10 years to develop. > Curiously, that collision of TCP with the installed base involved > TCP/IP V4.?? TCP/IP V6 has come along and its been quite a few years > in transition. Oh. You think 30 years is quite a few? > It seems that the momentum of the installed base of TCP/IP V4 has > blunted the adoption of TCP/IP V6.?? Why?? What's different? Almost no market demand.? And really, really poor roll-out of the capability.? Looked a lot like the OSI approach, actually. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From craig at tereschau.net Fri Feb 10 06:48:25 2023 From: craig at tereschau.net (Craig Partridge) Date: Fri, 10 Feb 2023 07:48:25 -0700 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> Message-ID: On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > > > At the time, in the 1990ish timeframe, there was a huge installed base > of network technology. Hundreds of thousands of computers utilizing > networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but > was a small player, confined largely to the academic and research > communities. > > ... > > So how did TCP manage to blast through that momentum of the installed > base, creating such a chaos in the collision? And how did it do it so > rapidly? > > Hi Jack: I'll start with a shout out to Brian's point that the transition was already well underway by 1990. Absolutely fits my experience. I would argue that a critical issue was communicating outside one's organization and/or over long distance. The various technologies you list, except for DECNET, did not focus on solving problems across organizational boundaries. Recall Netware was the biggest networking technology of the time and, while it adapted somewhat, was designed to connect an office or suite of offices. Meanwhile, by 1987, we'd built a relatively homogeneous email environment across the Internet, USENET, CSNET, and (thanks to BITNET and EARN) the academic SNA networks. I remember at a DC Interop c. 1990, someone observing that they had discovered couldn't hire new computing graduates if they weren't connected to the RFC 822/domain name email network. So the tech mindset, among the younger generation, was that they should be able to communicate with anyone via email. This pushed folks towards TCP/IP -- or, at least, email compatibility with the Internet. At a bits-and-bytes level, long-distance reliable communications networks are hard to do. I remember Dave Clark talking about this around 1985 and discussing how protocol suites designed around the local network didn't scale. He used the struggles by the LOCUS distributed file system (which worked great on a LAN) to work over the ARPANET as an example. In the late 1980s, only two networking architectures had engaged with and worked through those issues: TCP/IP and DECNET. Nicely, the most prominent and complementary papers on congestion issues, one by Van Jacobson (TCP/IP) and one by Raj Jain and KK Ramakrishnan (DECNET), were presented back-to-back at the ACM SIGCOMM conference in 1988. So if you were looking to build (or soon after via NSFNET, connect to) a sturdy wide-area network, unless you were a DEC VMS organization, your best choice was TCP/IP. I'll note it was, in my view, a near thing sometimes. NSFNET was a tremendous gamble and for parts of 1987 and 1988 was not a very good service (I'm told a scientist complained loudly at the National Academy about this non-functional network they were trying to use for important science). We figured out congestion collapse well enough for the time (pace buffer-bloat folks) just as it was threatening to make the Internet unusable. But I distinctly remember that roughly around the end of 1988 or beginning of 1989, Internet folks began to realize that when they were talking with engineers building other networking technologies there was a whole suite of community knowledge that the Internet folks had and nobody else (except the wonderful DEC networking team) did. Craig -- ***** Craig Partridge's email account for professional society activities and mailing lists. From b_a_denny at yahoo.com Fri Feb 10 08:33:38 2023 From: b_a_denny at yahoo.com (Barbara Denny) Date: Fri, 10 Feb 2023 16:33:38 +0000 (UTC) Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> Message-ID: <1331585175.3138795.1676046818865@mail.yahoo.com> Let's not forget about ATM. I? think ATM was also a big area of focus for many people in this time frame.?? barbara On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge via Internet-history wrote: On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > > > At the time, in the 1990ish timeframe, there was a huge installed base > of network technology.? Hundreds of thousands of computers utilizing > networks based on SNA, SPX, XNS, Decnet, etc. etc.? TCP existed, but > was a small player, confined largely to the academic and research > communities. > > ... > > So how did TCP manage to blast through that momentum of the installed > base, creating such a chaos in the collision?? And how did it do it so > rapidly? > > Hi Jack: I'll start with a shout out to Brian's point that the transition was already well underway by 1990.? Absolutely fits my experience. I would argue that a critical issue was communicating outside one's organization and/or over long distance.? The various technologies you list, except for DECNET, did not focus on solving problems across organizational boundaries.? Recall Netware was the biggest networking technology of the time and, while it adapted somewhat, was designed to connect an office or suite of offices. Meanwhile, by 1987, we'd built a relatively homogeneous email environment across the Internet, USENET, CSNET, and (thanks to BITNET and EARN) the academic SNA networks.? I remember at a DC Interop c. 1990, someone observing that they had discovered couldn't hire new computing graduates if they weren't connected to the RFC 822/domain name email network.? So the tech mindset, among the younger generation, was that they should be able to communicate with anyone via email.? This pushed folks towards TCP/IP -- or, at least, email compatibility with the Internet. At a bits-and-bytes level, long-distance reliable communications networks are hard to do.? I remember Dave Clark talking about this around 1985 and discussing how protocol suites designed around the local network didn't scale.? He used the struggles by the LOCUS distributed file system (which worked great on a LAN) to work over the ARPANET as an example.? In the late 1980s, only two networking architectures had engaged with and worked through those issues: TCP/IP and DECNET.? Nicely, the most prominent and complementary papers on congestion issues, one by Van Jacobson (TCP/IP) and one by Raj Jain and KK Ramakrishnan (DECNET), were presented back-to-back at the ACM SIGCOMM conference in 1988.? So if you were looking to build (or soon after via NSFNET, connect to) a sturdy wide-area network, unless you were a DEC VMS organization, your best choice was TCP/IP. I'll note it was, in my view, a near thing sometimes.? NSFNET was a tremendous gamble and for parts of 1987 and 1988 was not a very good service (I'm told a scientist complained loudly at the National Academy about this non-functional network they were trying to use for important science).? We figured out congestion collapse well enough for the time (pace buffer-bloat folks) just as it was threatening to make the Internet unusable.? But I distinctly remember that roughly around the end of 1988 or beginning of 1989, Internet folks began to realize that when they were talking with engineers building other networking technologies there was a whole suite of community knowledge that the Internet folks had and nobody else (except the wonderful DEC networking team) did. 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 vgcerf at gmail.com Fri Feb 10 09:05:58 2023 From: vgcerf at gmail.com (vinton cerf) Date: Fri, 10 Feb 2023 12:05:58 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <1331585175.3138795.1676046818865@mail.yahoo.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> Message-ID: and frame relay v On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < internet-history at elists.isoc.org> wrote: > Let's not forget about ATM. I think ATM was also a big area of focus for > many people in this time frame. > barbara > > On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge via > Internet-history wrote: > > On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > > > > At the time, in the 1990ish timeframe, there was a huge installed base > > of network technology. Hundreds of thousands of computers utilizing > > networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but > > was a small player, confined largely to the academic and research > > communities. > > > > ... > > > > So how did TCP manage to blast through that momentum of the installed > > base, creating such a chaos in the collision? And how did it do it so > > rapidly? > > > > > Hi Jack: > > I'll start with a shout out to Brian's point that the transition was > already well underway by 1990. Absolutely > fits my experience. > > I would argue that a critical issue was communicating outside one's > organization and/or over long distance. The various technologies you list, > except for DECNET, did not focus on solving problems across organizational > boundaries. Recall Netware was the > biggest networking technology of the time and, while it adapted somewhat, > was designed to connect an office or suite > of offices. > > Meanwhile, by 1987, we'd built a relatively homogeneous email environment > across the Internet, USENET, CSNET, and > (thanks to BITNET and EARN) the academic SNA networks. I remember at a DC > Interop c. 1990, someone observing > that they had discovered couldn't hire new computing graduates if they > weren't connected to the RFC 822/domain name email > network. So the tech mindset, among the younger generation, was that they > should be able to communicate with anyone via > email. This pushed folks towards TCP/IP -- or, at least, email > compatibility with the Internet. > > At a bits-and-bytes level, long-distance reliable communications networks > are hard to do. I remember Dave Clark talking about > this around 1985 and discussing how protocol suites designed around the > local network didn't scale. He used the struggles by > the LOCUS distributed file system (which worked great on a LAN) to work > over the ARPANET as an example. In the late 1980s, > only two networking architectures had engaged with and worked through those > issues: TCP/IP and DECNET. Nicely, the most prominent and > complementary papers on congestion issues, one by Van Jacobson (TCP/IP) and > one by Raj Jain and KK Ramakrishnan (DECNET), > were presented back-to-back at the ACM SIGCOMM conference in 1988. So if > you were looking to build (or soon after via NSFNET, connect > to) a sturdy wide-area network, unless you were a DEC VMS organization, > your best choice was TCP/IP. > > I'll note it was, in my view, a near thing sometimes. NSFNET was a > tremendous gamble and for parts of 1987 and 1988 was not > a very good service (I'm told a scientist complained loudly at the National > Academy about this non-functional network they were > trying to use for important science). We figured out congestion collapse > well enough for the time (pace buffer-bloat folks) just as > it was threatening to make the Internet unusable. But I distinctly > remember that roughly around the end of 1988 or beginning of 1989, > Internet folks began to realize that when they were talking with engineers > building other networking technologies there was a whole > suite of community knowledge that the Internet folks had and nobody else > (except the wonderful DEC networking team) did. > > 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 > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From agmalis at gmail.com Fri Feb 10 09:25:25 2023 From: agmalis at gmail.com (Andrew G. Malis) Date: Fri, 10 Feb 2023 12:25:25 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> Message-ID: Frame Relay (and to a lesser extent, ATM) wasn't a competitor to TCP/IP. In fact, they were both L2 technologies, and certainly the greatest amount of FR revenue was in tail circuits carrying IP from an ISP or a corporate HQ to a remote corporate office. At the time, FR was MUCH less expensive and faster than leased lines. Cheers, Andy On Fri, Feb 10, 2023 at 12:06 PM vinton cerf via Internet-history < internet-history at elists.isoc.org> wrote: > and frame relay > v > > > On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < > internet-history at elists.isoc.org> wrote: > > > Let's not forget about ATM. I think ATM was also a big area of focus > for > > many people in this time frame. > > barbara > > > > On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge via > > Internet-history wrote: > > > > On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > > > > > > > > > At the time, in the 1990ish timeframe, there was a huge installed base > > > of network technology. Hundreds of thousands of computers utilizing > > > networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but > > > was a small player, confined largely to the academic and research > > > communities. > > > > > > ... > > > > > > So how did TCP manage to blast through that momentum of the installed > > > base, creating such a chaos in the collision? And how did it do it so > > > rapidly? > > > > > > > > Hi Jack: > > > > I'll start with a shout out to Brian's point that the transition was > > already well underway by 1990. Absolutely > > fits my experience. > > > > I would argue that a critical issue was communicating outside one's > > organization and/or over long distance. The various technologies you > list, > > except for DECNET, did not focus on solving problems across > organizational > > boundaries. Recall Netware was the > > biggest networking technology of the time and, while it adapted somewhat, > > was designed to connect an office or suite > > of offices. > > > > Meanwhile, by 1987, we'd built a relatively homogeneous email environment > > across the Internet, USENET, CSNET, and > > (thanks to BITNET and EARN) the academic SNA networks. I remember at a > DC > > Interop c. 1990, someone observing > > that they had discovered couldn't hire new computing graduates if they > > weren't connected to the RFC 822/domain name email > > network. So the tech mindset, among the younger generation, was that > they > > should be able to communicate with anyone via > > email. This pushed folks towards TCP/IP -- or, at least, email > > compatibility with the Internet. > > > > At a bits-and-bytes level, long-distance reliable communications networks > > are hard to do. I remember Dave Clark talking about > > this around 1985 and discussing how protocol suites designed around the > > local network didn't scale. He used the struggles by > > the LOCUS distributed file system (which worked great on a LAN) to work > > over the ARPANET as an example. In the late 1980s, > > only two networking architectures had engaged with and worked through > those > > issues: TCP/IP and DECNET. Nicely, the most prominent and > > complementary papers on congestion issues, one by Van Jacobson (TCP/IP) > and > > one by Raj Jain and KK Ramakrishnan (DECNET), > > were presented back-to-back at the ACM SIGCOMM conference in 1988. So if > > you were looking to build (or soon after via NSFNET, connect > > to) a sturdy wide-area network, unless you were a DEC VMS organization, > > your best choice was TCP/IP. > > > > I'll note it was, in my view, a near thing sometimes. NSFNET was a > > tremendous gamble and for parts of 1987 and 1988 was not > > a very good service (I'm told a scientist complained loudly at the > National > > Academy about this non-functional network they were > > trying to use for important science). We figured out congestion collapse > > well enough for the time (pace buffer-bloat folks) just as > > it was threatening to make the Internet unusable. But I distinctly > > remember that roughly around the end of 1988 or beginning of 1989, > > Internet folks began to realize that when they were talking with > engineers > > building other networking technologies there was a whole > > suite of community knowledge that the Internet folks had and nobody else > > (except the wonderful DEC networking team) did. > > > > 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 > > > > -- > > 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 sob at sobco.com Fri Feb 10 09:34:24 2023 From: sob at sobco.com (Scott Bradner) Date: Fri, 10 Feb 2023 12:34:24 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> Message-ID: <7DF0C0E4-5243-4C19-B1F2-28C4505A7B89@sobco.com> of course its true that ATM & FR are L2 but that did not stop the ATM Forum and other ATM fans from pushing ATM as a full replacement for IP and at least a partial replacement for TCP after all, ATM had routing, subnets, flow control, guaranteed data delivery - and ATM available bit rate (ABR) was quite a technical achievement (at least in the specification, maybe not so much in the implementation) this was my opinion in 1998 https://www.sobco.com/nww/1998/bradner-1998-09-14.html Scott > On Feb 10, 2023, at 12:25 PM, Andrew G. Malis via Internet-history wrote: > > Frame Relay (and to a lesser extent, ATM) wasn't a competitor to TCP/IP. In > fact, they were both L2 technologies, and certainly the greatest amount of > FR revenue was in tail circuits carrying IP from an ISP or a corporate HQ > to a remote corporate office. At the time, FR was MUCH less expensive and > faster than leased lines. > > Cheers, > Andy > > > On Fri, Feb 10, 2023 at 12:06 PM vinton cerf via Internet-history < > internet-history at elists.isoc.org> wrote: > >> and frame relay >> v >> >> >> On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> Let's not forget about ATM. I think ATM was also a big area of focus >> for >>> many people in this time frame. >>> barbara >>> >>> On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge via >>> Internet-history wrote: >>> >>> On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>> >>>> >>>> >>>> At the time, in the 1990ish timeframe, there was a huge installed base >>>> of network technology. Hundreds of thousands of computers utilizing >>>> networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but >>>> was a small player, confined largely to the academic and research >>>> communities. >>>> >>>> ... >>>> >>>> So how did TCP manage to blast through that momentum of the installed >>>> base, creating such a chaos in the collision? And how did it do it so >>>> rapidly? >>>> >>>> >>> Hi Jack: >>> >>> I'll start with a shout out to Brian's point that the transition was >>> already well underway by 1990. Absolutely >>> fits my experience. >>> >>> I would argue that a critical issue was communicating outside one's >>> organization and/or over long distance. The various technologies you >> list, >>> except for DECNET, did not focus on solving problems across >> organizational >>> boundaries. Recall Netware was the >>> biggest networking technology of the time and, while it adapted somewhat, >>> was designed to connect an office or suite >>> of offices. >>> >>> Meanwhile, by 1987, we'd built a relatively homogeneous email environment >>> across the Internet, USENET, CSNET, and >>> (thanks to BITNET and EARN) the academic SNA networks. I remember at a >> DC >>> Interop c. 1990, someone observing >>> that they had discovered couldn't hire new computing graduates if they >>> weren't connected to the RFC 822/domain name email >>> network. So the tech mindset, among the younger generation, was that >> they >>> should be able to communicate with anyone via >>> email. This pushed folks towards TCP/IP -- or, at least, email >>> compatibility with the Internet. >>> >>> At a bits-and-bytes level, long-distance reliable communications networks >>> are hard to do. I remember Dave Clark talking about >>> this around 1985 and discussing how protocol suites designed around the >>> local network didn't scale. He used the struggles by >>> the LOCUS distributed file system (which worked great on a LAN) to work >>> over the ARPANET as an example. In the late 1980s, >>> only two networking architectures had engaged with and worked through >> those >>> issues: TCP/IP and DECNET. Nicely, the most prominent and >>> complementary papers on congestion issues, one by Van Jacobson (TCP/IP) >> and >>> one by Raj Jain and KK Ramakrishnan (DECNET), >>> were presented back-to-back at the ACM SIGCOMM conference in 1988. So if >>> you were looking to build (or soon after via NSFNET, connect >>> to) a sturdy wide-area network, unless you were a DEC VMS organization, >>> your best choice was TCP/IP. >>> >>> I'll note it was, in my view, a near thing sometimes. NSFNET was a >>> tremendous gamble and for parts of 1987 and 1988 was not >>> a very good service (I'm told a scientist complained loudly at the >> National >>> Academy about this non-functional network they were >>> trying to use for important science). We figured out congestion collapse >>> well enough for the time (pace buffer-bloat folks) just as >>> it was threatening to make the Internet unusable. But I distinctly >>> remember that roughly around the end of 1988 or beginning of 1989, >>> Internet folks began to realize that when they were talking with >> engineers >>> building other networking technologies there was a whole >>> suite of community knowledge that the Internet folks had and nobody else >>> (except the wonderful DEC networking team) did. >>> >>> 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 >>> >>> -- >>> 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 From sob at sobco.com Fri Feb 10 09:38:24 2023 From: sob at sobco.com (Scott Bradner) Date: Fri, 10 Feb 2023 12:38:24 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <7DF0C0E4-5243-4C19-B1F2-28C4505A7B89@sobco.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <7DF0C0E4-5243-4C19-B1F2-28C4505A7B89@sobco.com> Message-ID: <3EBBBE7D-B233-466F-9EF3-88177806034C@sobco.com> ps - a follow up opinion from 2001 https://www.sobco.com/nww/2001/bradner-2001-07-23.html > On Feb 10, 2023, at 12:34 PM, Scott Bradner via Internet-history wrote: > > of course its true that ATM & FR are L2 but that did not stop the ATM Forum and other > ATM fans from pushing ATM as a full replacement for IP and at least a partial replacement for TCP > > after all, ATM had routing, subnets, flow control, guaranteed data delivery - and > ATM available bit rate (ABR) was quite a technical achievement (at least in the specification, > maybe not so much in the implementation) > > this was my opinion in 1998 > https://www.sobco.com/nww/1998/bradner-1998-09-14.html > > Scott > > >> On Feb 10, 2023, at 12:25 PM, Andrew G. Malis via Internet-history wrote: >> >> Frame Relay (and to a lesser extent, ATM) wasn't a competitor to TCP/IP. In >> fact, they were both L2 technologies, and certainly the greatest amount of >> FR revenue was in tail circuits carrying IP from an ISP or a corporate HQ >> to a remote corporate office. At the time, FR was MUCH less expensive and >> faster than leased lines. >> >> Cheers, >> Andy >> >> >> On Fri, Feb 10, 2023 at 12:06 PM vinton cerf via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> and frame relay >>> v >>> >>> >>> On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>> >>>> Let's not forget about ATM. I think ATM was also a big area of focus >>> for >>>> many people in this time frame. >>>> barbara >>>> >>>> On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge via >>>> Internet-history wrote: >>>> >>>> On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < >>>> internet-history at elists.isoc.org> wrote: >>>> >>>>> >>>>> >>>>> At the time, in the 1990ish timeframe, there was a huge installed base >>>>> of network technology. Hundreds of thousands of computers utilizing >>>>> networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but >>>>> was a small player, confined largely to the academic and research >>>>> communities. >>>>> >>>>> ... >>>>> >>>>> So how did TCP manage to blast through that momentum of the installed >>>>> base, creating such a chaos in the collision? And how did it do it so >>>>> rapidly? >>>>> >>>>> >>>> Hi Jack: >>>> >>>> I'll start with a shout out to Brian's point that the transition was >>>> already well underway by 1990. Absolutely >>>> fits my experience. >>>> >>>> I would argue that a critical issue was communicating outside one's >>>> organization and/or over long distance. The various technologies you >>> list, >>>> except for DECNET, did not focus on solving problems across >>> organizational >>>> boundaries. Recall Netware was the >>>> biggest networking technology of the time and, while it adapted somewhat, >>>> was designed to connect an office or suite >>>> of offices. >>>> >>>> Meanwhile, by 1987, we'd built a relatively homogeneous email environment >>>> across the Internet, USENET, CSNET, and >>>> (thanks to BITNET and EARN) the academic SNA networks. I remember at a >>> DC >>>> Interop c. 1990, someone observing >>>> that they had discovered couldn't hire new computing graduates if they >>>> weren't connected to the RFC 822/domain name email >>>> network. So the tech mindset, among the younger generation, was that >>> they >>>> should be able to communicate with anyone via >>>> email. This pushed folks towards TCP/IP -- or, at least, email >>>> compatibility with the Internet. >>>> >>>> At a bits-and-bytes level, long-distance reliable communications networks >>>> are hard to do. I remember Dave Clark talking about >>>> this around 1985 and discussing how protocol suites designed around the >>>> local network didn't scale. He used the struggles by >>>> the LOCUS distributed file system (which worked great on a LAN) to work >>>> over the ARPANET as an example. In the late 1980s, >>>> only two networking architectures had engaged with and worked through >>> those >>>> issues: TCP/IP and DECNET. Nicely, the most prominent and >>>> complementary papers on congestion issues, one by Van Jacobson (TCP/IP) >>> and >>>> one by Raj Jain and KK Ramakrishnan (DECNET), >>>> were presented back-to-back at the ACM SIGCOMM conference in 1988. So if >>>> you were looking to build (or soon after via NSFNET, connect >>>> to) a sturdy wide-area network, unless you were a DEC VMS organization, >>>> your best choice was TCP/IP. >>>> >>>> I'll note it was, in my view, a near thing sometimes. NSFNET was a >>>> tremendous gamble and for parts of 1987 and 1988 was not >>>> a very good service (I'm told a scientist complained loudly at the >>> National >>>> Academy about this non-functional network they were >>>> trying to use for important science). We figured out congestion collapse >>>> well enough for the time (pace buffer-bloat folks) just as >>>> it was threatening to make the Internet unusable. But I distinctly >>>> remember that roughly around the end of 1988 or beginning of 1989, >>>> Internet folks began to realize that when they were talking with >>> engineers >>>> building other networking technologies there was a whole >>>> suite of community knowledge that the Internet folks had and nobody else >>>> (except the wonderful DEC networking team) did. >>>> >>>> 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 >>>> >>>> -- >>>> 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 > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From jeanjour at comcast.net Fri Feb 10 09:56:09 2023 From: jeanjour at comcast.net (John Day) Date: Fri, 10 Feb 2023 12:56:09 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> Message-ID: <29CD3471-0AC8-403B-93B1-D7924D604541@comcast.net> ATM was a bad idea the day it was proposed. It was unbelievable how many people were taken in by it. But then in that time period, I also had people telling me that the amount of data traffic would never exceed the amount of voice traffic! All you could do was shake your head and wonder what they were smoking. I had a shaggy dog story I use to tell, about how I had worked for a stat mux company and they did this neat thing multiplexing a few characters from terminals onto larger packets and reshuffling them at every hop and it worked really well. Who was talking to was usually a good bellhead and was agreeing eagerly and remembering how great it was and nodding their heads a lot. And then I said, we should do that now and do ATM over IP. Then they stopped nodding with a confused look. ;-) > On Feb 10, 2023, at 12:25, Andrew G. Malis via Internet-history wrote: > > Frame Relay (and to a lesser extent, ATM) wasn't a competitor to TCP/IP. In > fact, they were both L2 technologies, and certainly the greatest amount of > FR revenue was in tail circuits carrying IP from an ISP or a corporate HQ > to a remote corporate office. At the time, FR was MUCH less expensive and > faster than leased lines. > > Cheers, > Andy > > > On Fri, Feb 10, 2023 at 12:06 PM vinton cerf via Internet-history < > internet-history at elists.isoc.org> wrote: > >> and frame relay >> v >> >> >> On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> Let's not forget about ATM. I think ATM was also a big area of focus >> for >>> many people in this time frame. >>> barbara >>> >>> On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge via >>> Internet-history wrote: >>> >>> On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>> >>>> >>>> >>>> At the time, in the 1990ish timeframe, there was a huge installed base >>>> of network technology. Hundreds of thousands of computers utilizing >>>> networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but >>>> was a small player, confined largely to the academic and research >>>> communities. >>>> >>>> ... >>>> >>>> So how did TCP manage to blast through that momentum of the installed >>>> base, creating such a chaos in the collision? And how did it do it so >>>> rapidly? >>>> >>>> >>> Hi Jack: >>> >>> I'll start with a shout out to Brian's point that the transition was >>> already well underway by 1990. Absolutely >>> fits my experience. >>> >>> I would argue that a critical issue was communicating outside one's >>> organization and/or over long distance. The various technologies you >> list, >>> except for DECNET, did not focus on solving problems across >> organizational >>> boundaries. Recall Netware was the >>> biggest networking technology of the time and, while it adapted somewhat, >>> was designed to connect an office or suite >>> of offices. >>> >>> Meanwhile, by 1987, we'd built a relatively homogeneous email environment >>> across the Internet, USENET, CSNET, and >>> (thanks to BITNET and EARN) the academic SNA networks. I remember at a >> DC >>> Interop c. 1990, someone observing >>> that they had discovered couldn't hire new computing graduates if they >>> weren't connected to the RFC 822/domain name email >>> network. So the tech mindset, among the younger generation, was that >> they >>> should be able to communicate with anyone via >>> email. This pushed folks towards TCP/IP -- or, at least, email >>> compatibility with the Internet. >>> >>> At a bits-and-bytes level, long-distance reliable communications networks >>> are hard to do. I remember Dave Clark talking about >>> this around 1985 and discussing how protocol suites designed around the >>> local network didn't scale. He used the struggles by >>> the LOCUS distributed file system (which worked great on a LAN) to work >>> over the ARPANET as an example. In the late 1980s, >>> only two networking architectures had engaged with and worked through >> those >>> issues: TCP/IP and DECNET. Nicely, the most prominent and >>> complementary papers on congestion issues, one by Van Jacobson (TCP/IP) >> and >>> one by Raj Jain and KK Ramakrishnan (DECNET), >>> were presented back-to-back at the ACM SIGCOMM conference in 1988. So if >>> you were looking to build (or soon after via NSFNET, connect >>> to) a sturdy wide-area network, unless you were a DEC VMS organization, >>> your best choice was TCP/IP. >>> >>> I'll note it was, in my view, a near thing sometimes. NSFNET was a >>> tremendous gamble and for parts of 1987 and 1988 was not >>> a very good service (I'm told a scientist complained loudly at the >> National >>> Academy about this non-functional network they were >>> trying to use for important science). We figured out congestion collapse >>> well enough for the time (pace buffer-bloat folks) just as >>> it was threatening to make the Internet unusable. But I distinctly >>> remember that roughly around the end of 1988 or beginning of 1989, >>> Internet folks began to realize that when they were talking with >> engineers >>> building other networking technologies there was a whole >>> suite of community knowledge that the Internet folks had and nobody else >>> (except the wonderful DEC networking team) did. >>> >>> 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 >>> >>> -- >>> 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 From odlyzko at umn.edu Fri Feb 10 10:03:33 2023 From: odlyzko at umn.edu (odlyzko at umn.edu) Date: Fri, 10 Feb 2023 12:03:33 -0600 (CST) Subject: [ih] Internet-history Digest, Vol 41, Issue 17 In-Reply-To: References: Message-ID: Kerry Coffman and I published some estimates of data traffic and data network capacities as of year-end 1997 in October 1998 in "The size and growth rate of the Internet." (This was primarily for the US. We were quite confident of the capacity estimates for private line and Frame Relay networks, and also of FR traffic, since AT&T had the lion's share of those markets, and we had access to internal data, even when we could not publish that.) https://firstmonday.org/ojs/index.php/fm/article/view/620/541 At that time, on FR was the largest public data network, but it, as well as ATM, were increasingly just carrying IP traffic. We could not get very good stats, but it appeared that at the time when the NSF backbone was being phased out, the internal AT&T network that carried billing information carried at least as much traffic. And it was IP! Although not just top AT&T, but also Bell Labs management was talking of how ATM was the future (I vividly recall an internal AT&T meeting around 1998 when a high-level AT&T executive, in response to a question about IP from one of our research group, said that the Internet was a toy network, full of porn, and ATM was going to be the real thing), the folks in charge of the company "crown jewels" decided it made more sense to run IP. I do not know how that decision was arrived at. Andrew ------------------------------ Date: Fri, 10 Feb 2023 12:34:24 -0500 From: Scott Bradner To: "Andrew G. Malis" Cc: vinton cerf , "internet-history at elists.isoc.org" Subject: Re: [ih] Installed base momentum (was Re: Design choices in SMTP) of course its true that ATM & FR are L2 but that did not stop the ATM Forum and other ATM fans from pushing ATM as a full replacement for IP and at least a partial replacement for TCP after all, ATM had routing, subnets, flow control, guaranteed data delivery - and ATM available bit rate (ABR) was quite a technical achievement (at least in the specification, maybe not so much in the implementation) this was my opinion in 1998 https://www.sobco.com/nww/1998/bradner-1998-09-14.html Scott > On Feb 10, 2023, at 12:25 PM, Andrew G. Malis via Internet-history wrote: > > Frame Relay (and to a lesser extent, ATM) wasn't a competitor to TCP/IP. In > fact, they were both L2 technologies, and certainly the greatest amount of > FR revenue was in tail circuits carrying IP from an ISP or a corporate HQ > to a remote corporate office. At the time, FR was MUCH less expensive and > faster than leased lines. > > Cheers, > Andy > > > On Fri, Feb 10, 2023 at 12:06 PM vinton cerf via Internet-history < > internet-history at elists.isoc.org> wrote: > >> and frame relay >> v >> >> >> On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> Let's not forget about ATM. I think ATM was also a big area of focus >> for >>> many people in this time frame. >>> barbara >>> >>> On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge via >>> Internet-history wrote: >>> >>> On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>> >>>> >>>> >>>> At the time, in the 1990ish timeframe, there was a huge installed base >>>> of network technology. Hundreds of thousands of computers utilizing >>>> networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but >>>> was a small player, confined largely to the academic and research >>>> communities. >>>> >>>> ... >>>> >>>> So how did TCP manage to blast through that momentum of the installed >>>> base, creating such a chaos in the collision? And how did it do it so >>>> rapidly? >>>> >>>> >>> Hi Jack: >>> >>> I'll start with a shout out to Brian's point that the transition was >>> already well underway by 1990. Absolutely >>> fits my experience. >>> >>> I would argue that a critical issue was communicating outside one's >>> organization and/or over long distance. The various technologies you >> list, >>> except for DECNET, did not focus on solving problems across >> organizational >>> boundaries. Recall Netware was the >>> biggest networking technology of the time and, while it adapted somewhat, >>> was designed to connect an office or suite >>> of offices. >>> >>> Meanwhile, by 1987, we'd built a relatively homogeneous email environment >>> across the Internet, USENET, CSNET, and >>> (thanks to BITNET and EARN) the academic SNA networks. I remember at a >> DC >>> Interop c. 1990, someone observing >>> that they had discovered couldn't hire new computing graduates if they >>> weren't connected to the RFC 822/domain name email >>> network. So the tech mindset, among the younger generation, was that >> they >>> should be able to communicate with anyone via >>> email. This pushed folks towards TCP/IP -- or, at least, email >>> compatibility with the Internet. >>> >>> At a bits-and-bytes level, long-distance reliable communications networks >>> are hard to do. I remember Dave Clark talking about >>> this around 1985 and discussing how protocol suites designed around the >>> local network didn't scale. He used the struggles by >>> the LOCUS distributed file system (which worked great on a LAN) to work >>> over the ARPANET as an example. In the late 1980s, >>> only two networking architectures had engaged with and worked through >> those >>> issues: TCP/IP and DECNET. Nicely, the most prominent and >>> complementary papers on congestion issues, one by Van Jacobson (TCP/IP) >> and >>> one by Raj Jain and KK Ramakrishnan (DECNET), >>> were presented back-to-back at the ACM SIGCOMM conference in 1988. So if >>> you were looking to build (or soon after via NSFNET, connect >>> to) a sturdy wide-area network, unless you were a DEC VMS organization, >>> your best choice was TCP/IP. >>> >>> I'll note it was, in my view, a near thing sometimes. NSFNET was a >>> tremendous gamble and for parts of 1987 and 1988 was not >>> a very good service (I'm told a scientist complained loudly at the >> National >>> Academy about this non-functional network they were >>> trying to use for important science). We figured out congestion collapse >>> well enough for the time (pace buffer-bloat folks) just as >>> it was threatening to make the Internet unusable. But I distinctly >>> remember that roughly around the end of 1988 or beginning of 1989, >>> Internet folks began to realize that when they were talking with >> engineers >>> building other networking technologies there was a whole >>> suite of community knowledge that the Internet folks had and nobody else >>> (except the wonderful DEC networking team) did. >>> >>> 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 >>> >>> -- >>> 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 From johnl at iecc.com Fri Feb 10 09:08:33 2023 From: johnl at iecc.com (John Levine) Date: 10 Feb 2023 12:08:33 -0500 Subject: [ih] Design choices in SMTP (custom emails per recipient) In-Reply-To: <4803b4d7-ae6d-1311-4bbf-0408fb29cee0@dcrocker.net> Message-ID: <20230210185001.7841593F10FF@ary.qy> It appears that Dave Crocker via Internet-history said: >On 2/9/2023 7:08 PM, Jack Haverty wrote: >> Seems like a pretty poor UX design, IMHO. > >Oh it definitely is. > >Just like real-life. > >Whoever designed this reality really did an awful job. I blame the Universal Postal Union, who let anyone put anyone else's return address on an envelope, but heedlessly deliver it anyway. R's, John PS: That's a physical paper envelope. From brian.e.carpenter at gmail.com Fri Feb 10 11:49:45 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 11 Feb 2023 08:49:45 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> Message-ID: <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> I have to say that in those years, I evaluated ATM (and frame relay, and ISDN for that matter) only by asking how well TCP/IP would run over it. (For ATM, the answer was "badly".) It was already the case that "it's the applications, stupid!", and all the useful apps ran over TCP/IP (apart from those that ran over DECnet). I remember Ellen Hancock from IBM's Network Hardware Division showing up on a Grand Tour of Europe, explaining how ATM was going to replace Token Ring as the solution to all networking problems. It wasn't until she left IBM that I was head hunted by them. The new IBM HQ building in Armonk NY was equipped with ATM to the desktop in about 1996. Bizarre. Regards Brian Carpenter On 11-Feb-23 06:25, Andrew G. Malis via Internet-history wrote: > Frame Relay (and to a lesser extent, ATM) wasn't a competitor to TCP/IP. In > fact, they were both L2 technologies, and certainly the greatest amount of > FR revenue was in tail circuits carrying IP from an ISP or a corporate HQ > to a remote corporate office. At the time, FR was MUCH less expensive and > faster than leased lines. > > Cheers, > Andy > > > On Fri, Feb 10, 2023 at 12:06 PM vinton cerf via Internet-history < > internet-history at elists.isoc.org> wrote: > >> and frame relay >> v >> >> >> On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> Let's not forget about ATM. I think ATM was also a big area of focus >> for >>> many people in this time frame. >>> barbara >>> >>> On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge via >>> Internet-history wrote: >>> >>> On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>> >>>> >>>> >>>> At the time, in the 1990ish timeframe, there was a huge installed base >>>> of network technology. Hundreds of thousands of computers utilizing >>>> networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but >>>> was a small player, confined largely to the academic and research >>>> communities. >>>> >>>> ... >>>> >>>> So how did TCP manage to blast through that momentum of the installed >>>> base, creating such a chaos in the collision? And how did it do it so >>>> rapidly? >>>> >>>> >>> Hi Jack: >>> >>> I'll start with a shout out to Brian's point that the transition was >>> already well underway by 1990. Absolutely >>> fits my experience. >>> >>> I would argue that a critical issue was communicating outside one's >>> organization and/or over long distance. The various technologies you >> list, >>> except for DECNET, did not focus on solving problems across >> organizational >>> boundaries. Recall Netware was the >>> biggest networking technology of the time and, while it adapted somewhat, >>> was designed to connect an office or suite >>> of offices. >>> >>> Meanwhile, by 1987, we'd built a relatively homogeneous email environment >>> across the Internet, USENET, CSNET, and >>> (thanks to BITNET and EARN) the academic SNA networks. I remember at a >> DC >>> Interop c. 1990, someone observing >>> that they had discovered couldn't hire new computing graduates if they >>> weren't connected to the RFC 822/domain name email >>> network. So the tech mindset, among the younger generation, was that >> they >>> should be able to communicate with anyone via >>> email. This pushed folks towards TCP/IP -- or, at least, email >>> compatibility with the Internet. >>> >>> At a bits-and-bytes level, long-distance reliable communications networks >>> are hard to do. I remember Dave Clark talking about >>> this around 1985 and discussing how protocol suites designed around the >>> local network didn't scale. He used the struggles by >>> the LOCUS distributed file system (which worked great on a LAN) to work >>> over the ARPANET as an example. In the late 1980s, >>> only two networking architectures had engaged with and worked through >> those >>> issues: TCP/IP and DECNET. Nicely, the most prominent and >>> complementary papers on congestion issues, one by Van Jacobson (TCP/IP) >> and >>> one by Raj Jain and KK Ramakrishnan (DECNET), >>> were presented back-to-back at the ACM SIGCOMM conference in 1988. So if >>> you were looking to build (or soon after via NSFNET, connect >>> to) a sturdy wide-area network, unless you were a DEC VMS organization, >>> your best choice was TCP/IP. >>> >>> I'll note it was, in my view, a near thing sometimes. NSFNET was a >>> tremendous gamble and for parts of 1987 and 1988 was not >>> a very good service (I'm told a scientist complained loudly at the >> National >>> Academy about this non-functional network they were >>> trying to use for important science). We figured out congestion collapse >>> well enough for the time (pace buffer-bloat folks) just as >>> it was threatening to make the Internet unusable. But I distinctly >>> remember that roughly around the end of 1988 or beginning of 1989, >>> Internet folks began to realize that when they were talking with >> engineers >>> building other networking technologies there was a whole >>> suite of community knowledge that the Internet folks had and nobody else >>> (except the wonderful DEC networking team) did. >>> >>> 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 >>> >>> -- >>> 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 vint at google.com Fri Feb 10 11:51:37 2023 From: vint at google.com (Vint Cerf) Date: Fri, 10 Feb 2023 14:51:37 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> Message-ID: ellen was viscerally opposed to TCP/IP - visited IBM HQ at one point and got an earful. v On Fri, Feb 10, 2023 at 2:50 PM Brian E Carpenter via Internet-history < internet-history at elists.isoc.org> wrote: > I have to say that in those years, I evaluated ATM (and frame relay, and > ISDN for that matter) only by asking how well TCP/IP would run over it. > (For ATM, the answer was "badly".) > > It was already the case that "it's the applications, stupid!", and > all the useful apps ran over TCP/IP (apart from those that ran over > DECnet). > > I remember Ellen Hancock from IBM's Network Hardware Division showing > up on a Grand Tour of Europe, explaining how ATM was going to replace > Token Ring as the solution to all networking problems. It wasn't until > she left IBM that I was head hunted by them. > > The new IBM HQ building in Armonk NY was equipped with ATM to the > desktop in about 1996. Bizarre. > > Regards > Brian Carpenter > > On 11-Feb-23 06:25, Andrew G. Malis via Internet-history wrote: > > Frame Relay (and to a lesser extent, ATM) wasn't a competitor to TCP/IP. > In > > fact, they were both L2 technologies, and certainly the greatest amount > of > > FR revenue was in tail circuits carrying IP from an ISP or a corporate HQ > > to a remote corporate office. At the time, FR was MUCH less expensive and > > faster than leased lines. > > > > Cheers, > > Andy > > > > > > On Fri, Feb 10, 2023 at 12:06 PM vinton cerf via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> and frame relay > >> v > >> > >> > >> On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < > >> internet-history at elists.isoc.org> wrote: > >> > >>> Let's not forget about ATM. I think ATM was also a big area of focus > >> for > >>> many people in this time frame. > >>> barbara > >>> > >>> On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge > via > >>> Internet-history wrote: > >>> > >>> On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < > >>> internet-history at elists.isoc.org> wrote: > >>> > >>>> > >>>> > >>>> At the time, in the 1990ish timeframe, there was a huge installed base > >>>> of network technology. Hundreds of thousands of computers utilizing > >>>> networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but > >>>> was a small player, confined largely to the academic and research > >>>> communities. > >>>> > >>>> ... > >>>> > >>>> So how did TCP manage to blast through that momentum of the installed > >>>> base, creating such a chaos in the collision? And how did it do it so > >>>> rapidly? > >>>> > >>>> > >>> Hi Jack: > >>> > >>> I'll start with a shout out to Brian's point that the transition was > >>> already well underway by 1990. Absolutely > >>> fits my experience. > >>> > >>> I would argue that a critical issue was communicating outside one's > >>> organization and/or over long distance. The various technologies you > >> list, > >>> except for DECNET, did not focus on solving problems across > >> organizational > >>> boundaries. Recall Netware was the > >>> biggest networking technology of the time and, while it adapted > somewhat, > >>> was designed to connect an office or suite > >>> of offices. > >>> > >>> Meanwhile, by 1987, we'd built a relatively homogeneous email > environment > >>> across the Internet, USENET, CSNET, and > >>> (thanks to BITNET and EARN) the academic SNA networks. I remember at a > >> DC > >>> Interop c. 1990, someone observing > >>> that they had discovered couldn't hire new computing graduates if they > >>> weren't connected to the RFC 822/domain name email > >>> network. So the tech mindset, among the younger generation, was that > >> they > >>> should be able to communicate with anyone via > >>> email. This pushed folks towards TCP/IP -- or, at least, email > >>> compatibility with the Internet. > >>> > >>> At a bits-and-bytes level, long-distance reliable communications > networks > >>> are hard to do. I remember Dave Clark talking about > >>> this around 1985 and discussing how protocol suites designed around the > >>> local network didn't scale. He used the struggles by > >>> the LOCUS distributed file system (which worked great on a LAN) to work > >>> over the ARPANET as an example. In the late 1980s, > >>> only two networking architectures had engaged with and worked through > >> those > >>> issues: TCP/IP and DECNET. Nicely, the most prominent and > >>> complementary papers on congestion issues, one by Van Jacobson (TCP/IP) > >> and > >>> one by Raj Jain and KK Ramakrishnan (DECNET), > >>> were presented back-to-back at the ACM SIGCOMM conference in 1988. So > if > >>> you were looking to build (or soon after via NSFNET, connect > >>> to) a sturdy wide-area network, unless you were a DEC VMS organization, > >>> your best choice was TCP/IP. > >>> > >>> I'll note it was, in my view, a near thing sometimes. NSFNET was a > >>> tremendous gamble and for parts of 1987 and 1988 was not > >>> a very good service (I'm told a scientist complained loudly at the > >> National > >>> Academy about this non-functional network they were > >>> trying to use for important science). We figured out congestion > collapse > >>> well enough for the time (pace buffer-bloat folks) just as > >>> it was threatening to make the Internet unusable. But I distinctly > >>> remember that roughly around the end of 1988 or beginning of 1989, > >>> Internet folks began to realize that when they were talking with > >> engineers > >>> building other networking technologies there was a whole > >>> suite of community knowledge that the Internet folks had and nobody > else > >>> (except the wonderful DEC networking team) did. > >>> > >>> 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 > >>> > >>> -- > >>> 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 chet.ramey at case.edu Fri Feb 10 12:11:04 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 10 Feb 2023 15:11:04 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> Message-ID: <4e3aaf6a-217f-e47b-3b80-7bc45cce056b@case.edu> On 2/10/23 2:49 PM, Brian E Carpenter via Internet-history wrote: > The new IBM HQ building in Armonk NY was equipped with ATM to the > desktop in about 1996. Bizarre. We (CWRU) tried that with our campus network. LANE killed 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 dhc at dcrocker.net Fri Feb 10 12:11:05 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Fri, 10 Feb 2023 12:11:05 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> Message-ID: On 2/10/2023 11:51 AM, Vint Cerf via Internet-history wrote: > ellen was viscerally opposed to TCP/IP - visited IBM HQ at one point and > got an earful. Lots of willful thinking during that time.? I have always treasured the panel you were on, with the OSI advocate from Boing, around 1990.? You had just commented that the TCP/IP world did not focus on formal, conformance tests but instead favoring actual interoperability exercises. One or two people on the panel after you made their comments. Then the Boeing OSI advocate commented that interoperability required formal conformance tests.? With you usual deadpan face, you slowly leaned forward, turned your head to look at her, held it for a beat, and then sat back. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From vgcerf at gmail.com Fri Feb 10 12:12:28 2023 From: vgcerf at gmail.com (vinton cerf) Date: Fri, 10 Feb 2023 15:12:28 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> Message-ID: LOL - I had not remembered that but thanks for the reminder!! v On Fri, Feb 10, 2023 at 3:11 PM Dave Crocker via Internet-history < internet-history at elists.isoc.org> wrote: > On 2/10/2023 11:51 AM, Vint Cerf via Internet-history wrote: > > ellen was viscerally opposed to TCP/IP - visited IBM HQ at one point and > > got an earful. > > Lots of willful thinking during that time. I have always treasured the > panel you were on, with the OSI advocate from Boing, around 1990. You > had just commented that the TCP/IP world did not focus on formal, > conformance tests but instead favoring actual interoperability exercises. > > One or two people on the panel after you made their comments. Then the > Boeing OSI advocate commented that interoperability required formal > conformance tests. With you usual deadpan face, you slowly leaned > forward, turned your head to look at her, held it for a beat, and then > sat back. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker at mastodon.social > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From sauer at technologists.com Fri Feb 10 12:29:28 2023 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Fri, 10 Feb 2023 14:29:28 -0600 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> Message-ID: <7e8288b7-462b-29e9-7902-7d166c8c983a@technologists.com> IBM people steeped in SNA had a hard time accepting TCP/IP. Fortunately for us working on AIX, Larry Loucks, even though he had been instrumental in SNA, particularly LU 6.2, saw the need for TCP/IP. Dale Reed was another SNA principal that became open minded about TCP/IP. CHS On 2/10/2023 1:51 PM, Vint Cerf via Internet-history wrote: > ellen was viscerally opposed to TCP/IP - visited IBM HQ at one point and > got an earful. > > v -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From dhc at dcrocker.net Fri Feb 10 12:31:58 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Fri, 10 Feb 2023 12:31:58 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <7e8288b7-462b-29e9-7902-7d166c8c983a@technologists.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> <7e8288b7-462b-29e9-7902-7d166c8c983a@technologists.com> Message-ID: <9b93e02e-ce26-860b-d742-ff9ac11acb9c@dcrocker.net> On 2/10/2023 12:29 PM, Charles H Sauer (he/him) via Internet-history wrote: > IBM people steeped in SNA had a hard time accepting TCP/IP. In 1985 I worked at a company with a very large IBM SNA network. I had quite a bit of trouble processing a tidbit that was mentioned in passing, about needing to take down the entire network to add a new node... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From brian.e.carpenter at gmail.com Fri Feb 10 12:58:29 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 11 Feb 2023 09:58:29 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <7e8288b7-462b-29e9-7902-7d166c8c983a@technologists.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> <7e8288b7-462b-29e9-7902-7d166c8c983a@technologists.com> Message-ID: When I joined IBM in early 1997, with the dubious job title "Program Director, Internet Standards and Technology", I found people everywhere in IBM, not least in Research Triangle Park, who very much saw the need for TCP/IP. The main problem was that each IBM operating system had its own implementation; but AIX was the gold standard. Regards Brian On 11-Feb-23 09:29, Charles H Sauer (he/him) via Internet-history wrote: > IBM people steeped in SNA had a hard time accepting TCP/IP. Fortunately > for us working on AIX, Larry Loucks, even though he had been > instrumental in SNA, particularly LU 6.2, saw the need for TCP/IP. Dale > Reed was another SNA principal that became open minded about TCP/IP. CHS > > On 2/10/2023 1:51 PM, Vint Cerf via Internet-history wrote: >> ellen was viscerally opposed to TCP/IP - visited IBM HQ at one point and >> got an earful. >> >> v > From johnl at iecc.com Fri Feb 10 14:26:03 2023 From: johnl at iecc.com (John Levine) Date: 10 Feb 2023 17:26:03 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <7e8288b7-462b-29e9-7902-7d166c8c983a@technologists.com> Message-ID: <20230210222604.2CA6794190A1@ary.qy> It appears that Charles H Sauer (he/him) via Internet-history said: >IBM people steeped in SNA had a hard time accepting TCP/IP. Fortunately >for us working on AIX, Larry Loucks, even though he had been >instrumental in SNA, particularly LU 6.2, saw the need for TCP/IP. Dale >Reed was another SNA principal that became open minded about TCP/IP. CHS I recall some discussions about us putting LU 6.2 into what became RT PC AIX. Urrgh. Thank heavens Larry figured things out. R's, John From brian.e.carpenter at gmail.com Fri Feb 10 15:11:10 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 11 Feb 2023 12:11:10 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <9b93e02e-ce26-860b-d742-ff9ac11acb9c@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> <7e8288b7-462b-29e9-7902-7d166c8c983a@technologists.com> <9b93e02e-ce26-860b-d742-ff9ac11acb9c@dcrocker.net> Message-ID: On 11-Feb-23 09:31, Dave Crocker via Internet-history wrote: > On 2/10/2023 12:29 PM, Charles H Sauer (he/him) via Internet-history wrote: >> IBM people steeped in SNA had a hard time accepting TCP/IP. > > In 1985 I worked at a company with a very large IBM SNA network. I had > quite a bit of trouble processing a tidbit that was mentioned in > passing, about needing to take down the entire network to add a new node... Right. I recall using the need for a sysgen and therefore the need to batch up changes and install them at 3 a.m. as one of the main arguments for why SNA would be a very, very bad idea at CERN (where, of course, physics ran 24x7). Brian From jnc at mercury.lcs.mit.edu Sat Feb 11 06:48:53 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 11 Feb 2023 09:48:53 -0500 (EST) Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) Message-ID: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> > On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty wrote: > So how did TCP manage to blast through that momentum of the installed > base, creating such a chaos in the collision? And how did it do it so > rapidly? Like most things in history, there was no single cause. These seem to me (building on resonses by others) to be the most important ones (the first, below, was IMO the most important): - The TCP/IP world had a _long_ head start in building a large (both in numbers and physical extent) multi-organizational network using heterogeneous systems. So in addition to the Metcalfe effect of community size, we ran into (and partially solved) various real scaling issues that anyone attempting to build such a thing would run into, before anyone else. The 'multi-organizational' one is not thought of much, but it was critical. - Our experience in actually using our network (the 'dogfood' effect) meant that the pieces (applications supported, and components available 'off the shelf') we had assembled actually quickly allowed useful work to be done. (More of a gating factor than a _driver_, of course, but a key gating factor). - We supported, as mentioned, heterogeneous systems; there was a TCP/IP implementation available for just about anything. This factor took out a lot of early contendors. - The TCP/IP world was _very_ open; our documents were freely available; anyone could turn up at an IETF meeting and participate _as a peer_, etc. It 'won' so quickly because of the Metcalfe effect, and its head start. > From: Craig Partridge > We figured out congestion collapse well enough for the time It should be remembered that the ARPANET people (hi!) had perhaps solved this problem a long time before. I'm trying to remember how explicitly they saw this as a separate problem from the issue of running out of buffer space for message re-assembly at the destination IMP, but I seem to recall that RFNMs were seen as a needed throttle to prevent the network as a whole from being overrun (i.e. what we now think of as 'congestion', although IIRC that term wasn't used then), as well as flow control to the source host (as we would now call it). I don't recall exactly where I saw that, but I'd try the BBN proposal to DARPA's RFP, and the first JFIPS paper ("The interface message processor for the ARPA computer network"). > From: Andrew Odlyzko > I vividly recall an internal AT&T meeting around 1998 when a high-level > AT&T executive, in response to a question about IP from one of our > research group, said that the Internet was a toy network, full of porn, > and ATM was going to be the real thing This brought a big smile to my face; those of us with long memories will recall that someone associated with the OSI effort had said _almost exactly_ the same thing - two decades before! The phrase that I recall was 'toy academic nework', and maybe something about 'roll it up and take it away'! (I wasn't there to hear it in person; it was conveyed to me by Dave Clark or David Reed.) Such comments, in reality, imparted a great impetus to contest, and suceed, of course. (Cue my story about Lyman Chapin and his 'not very politically sophisticated' comment! :-) Noel From touch at strayalpha.com Sat Feb 11 09:02:04 2023 From: touch at strayalpha.com (touch at strayalpha.com) Date: Sat, 11 Feb 2023 09:02:04 -0800 Subject: [ih] Design choices in SMTP Message-ID: <746AA354-DA94-4093-8541-3DDA12D24758@strayalpha.com> Posted for Greg. Joe (list admin) > From: Greg Skinner > > Subject: Re: [ih] Design choices in SMTP > Date: February 9, 2023 at 9:43:15 PM PST > To: dcrocker at bbiw.net > Cc: Internet-history >, Dave Crocker > > > The earliest implementation of an FTP server I?ve found that supports the MAIL and MLFL commands is from the SAILDART archive, dated 1973-05-06 [1]. It appears to be compatible with RFC385 [2]. > > [1] https://www.saildart.org/FTPS[NET,SYS]4 > > [2] https://www.rfc-editor.org/info/rfc385 > > --gregbo > gregskinner0 at icloud.com ? Dr. Joe Touch, temporal epistemologist www.strayalpha.com From mfidelman at meetinghouse.net Sat Feb 11 09:25:24 2023 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 11 Feb 2023 12:25:24 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> Message-ID: <0d194ce3-bcda-1749-d538-5471f5006b23@meetinghouse.net> I seem to recall ATM working just fine, as a backbone technology.? Heck, BBN even went off and started Lightstream to build ATM switches.? It's just another form of low-level multiplexing.? Even Frame Relay, when it was used at the link layer, worked just fine. Now ISDN, on the other hand... I spent a lot of time helping MILDEP communications commands sell Ethernet deployments in the face of ISDN pressure.? And then, working with municipalities around both enterprise services & municipal broadband. ("What, you want to sell us Centrex ISDN service, with metered packet service on the D channel?") It was rather odd how the telco types didn't get how useless ISDN data service was, particularly when they were charging by the packet.? "Who needs more than 64kpbs?"? And the D-channel packet service ... It really blew some minds when you did the simple calculation of how long it would take to send a 10meg file, and how much it would cost. The folks who knew what they were doing were out selling metro-area services - starting at 64kbps frame relay, and then T1 & T3 speed ATM - stuff that was actually useful. Miles Fidelman Brian E Carpenter via Internet-history wrote: > I have to say that in those years, I evaluated ATM (and frame relay, and > ISDN for that matter) only by asking how well TCP/IP would run over it. > (For ATM, the answer was "badly".) > > It was already the case that "it's the applications, stupid!", and > all the useful apps ran over TCP/IP (apart from those that ran over > DECnet). > > I remember Ellen Hancock from IBM's Network Hardware Division showing > up on a Grand Tour of Europe, explaining how ATM was going to replace > Token Ring as the solution to all networking problems. It wasn't until > she left IBM that I was head hunted by them. > > The new IBM HQ building in Armonk NY was equipped with ATM to the > desktop in about 1996. Bizarre. > > Regards > ?? Brian Carpenter > > On 11-Feb-23 06:25, Andrew G. Malis via Internet-history wrote: >> Frame Relay (and to a lesser extent, ATM) wasn't a competitor to >> TCP/IP. In >> fact, they were both L2 technologies, and certainly the greatest >> amount of >> FR revenue was in tail circuits carrying IP from an ISP or a >> corporate HQ >> to a remote corporate office. At the time, FR was MUCH less expensive >> and >> faster than leased lines. >> >> Cheers, >> Andy >> >> >> On Fri, Feb 10, 2023 at 12:06 PM vinton cerf via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> and frame relay >>> v >>> >>> >>> On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>> >>>> ? Let's not forget about ATM. I? think ATM was also a big area of >>>> focus >>> for >>>> many people in this time frame. >>>> barbara >>>> >>>> ???? On Friday, February 10, 2023 at 06:48:47 AM PST, Craig >>>> Partridge via >>>> Internet-history wrote: >>>> >>>> ? On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < >>>> internet-history at elists.isoc.org> wrote: >>>> >>>>> >>>>> >>>>> At the time, in the 1990ish timeframe, there was a huge installed >>>>> base >>>>> of network technology.? Hundreds of thousands of computers utilizing >>>>> networks based on SNA, SPX, XNS, Decnet, etc. etc.? TCP existed, but >>>>> was a small player, confined largely to the academic and research >>>>> communities. >>>>> >>>>> ... >>>>> >>>>> So how did TCP manage to blast through that momentum of the installed >>>>> base, creating such a chaos in the collision?? And how did it do >>>>> it so >>>>> rapidly? >>>>> >>>>> >>>> Hi Jack: >>>> >>>> I'll start with a shout out to Brian's point that the transition was >>>> already well underway by 1990.? Absolutely >>>> fits my experience. >>>> >>>> ? I would argue that a critical issue was communicating outside one's >>>> organization and/or over long distance.? The various technologies you >>> list, >>>> except for DECNET, did not focus on solving problems across >>> organizational >>>> boundaries.? Recall Netware was the >>>> biggest networking technology of the time and, while it adapted >>>> somewhat, >>>> was designed to connect an office or suite >>>> of offices. >>>> >>>> Meanwhile, by 1987, we'd built a relatively homogeneous email >>>> environment >>>> across the Internet, USENET, CSNET, and >>>> (thanks to BITNET and EARN) the academic SNA networks.? I remember >>>> at a >>> DC >>>> Interop c. 1990, someone observing >>>> that they had discovered couldn't hire new computing graduates if they >>>> weren't connected to the RFC 822/domain name email >>>> network.? So the tech mindset, among the younger generation, was that >>> they >>>> should be able to communicate with anyone via >>>> email.? This pushed folks towards TCP/IP -- or, at least, email >>>> compatibility with the Internet. >>>> >>>> At a bits-and-bytes level, long-distance reliable communications >>>> networks >>>> are hard to do.? I remember Dave Clark talking about >>>> this around 1985 and discussing how protocol suites designed around >>>> the >>>> local network didn't scale.? He used the struggles by >>>> the LOCUS distributed file system (which worked great on a LAN) to >>>> work >>>> over the ARPANET as an example.? In the late 1980s, >>>> only two networking architectures had engaged with and worked through >>> those >>>> issues: TCP/IP and DECNET.? Nicely, the most prominent and >>>> complementary papers on congestion issues, one by Van Jacobson >>>> (TCP/IP) >>> and >>>> one by Raj Jain and KK Ramakrishnan (DECNET), >>>> were presented back-to-back at the ACM SIGCOMM conference in 1988.? >>>> So if >>>> you were looking to build (or soon after via NSFNET, connect >>>> to) a sturdy wide-area network, unless you were a DEC VMS >>>> organization, >>>> your best choice was TCP/IP. >>>> >>>> I'll note it was, in my view, a near thing sometimes. NSFNET was a >>>> tremendous gamble and for parts of 1987 and 1988 was not >>>> a very good service (I'm told a scientist complained loudly at the >>> National >>>> Academy about this non-functional network they were >>>> trying to use for important science).? We figured out congestion >>>> collapse >>>> well enough for the time (pace buffer-bloat folks) just as >>>> it was threatening to make the Internet unusable.? But I distinctly >>>> remember that roughly around the end of 1988 or beginning of 1989, >>>> Internet folks began to realize that when they were talking with >>> engineers >>>> building other networking technologies there was a whole >>>> suite of community knowledge that the Internet folks had and nobody >>>> else >>>> (except the wonderful DEC networking team) did. >>>> >>>> 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 >>>> >>>> -- >>>> 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 >>> -- 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 From bob.hinden at gmail.com Sat Feb 11 09:42:41 2023 From: bob.hinden at gmail.com (Bob Hinden) Date: Sat, 11 Feb 2023 09:42:41 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <0d194ce3-bcda-1749-d538-5471f5006b23@meetinghouse.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> <0d194ce3-bcda-1749-d538-5471f5006b23@meetinghouse.net> Message-ID: <4FF67AED-9A86-4E73-9155-8347069FD94A@gmail.com> Miles, > On Feb 11, 2023, at 9:25 AM, Miles Fidelman via Internet-history wrote: > > I seem to recall ATM working just fine, as a backbone technology. Heck, BBN even went off and started Lightstream to build ATM switches. It's just another form of low-level multiplexing. Even Frame Relay, when it was used at the link layer, worked just fine. When ATM first came out, its 155Mbps speed was fast compared to what else existed at the time, like 10M Ethernet. I admit to having gotten sucked in for a while (BBN and Ipsilon). Now in hindsight, ATM?s small cell size (53 bytes) would become a problem at much higher speeds like 100Gbps, both from the cell/second rate needed and the percentage of overhead (5 bytes header and 48 bytes payload) in each cell. It didn?t scale up very well. I used to like saying that ATM was like ATM machines except that you only were allowed to put money in :-) Bob > > Now ISDN, on the other hand... I spent a lot of time helping MILDEP communications commands sell Ethernet deployments in the face of ISDN pressure. And then, working with municipalities around both enterprise services & municipal broadband. ("What, you want to sell us Centrex ISDN service, with metered packet service on the D channel?") > > It was rather odd how the telco types didn't get how useless ISDN data service was, particularly when they were charging by the packet. "Who needs more than 64kpbs?" And the D-channel packet service ... It really blew some minds when you did the simple calculation of how long it would take to send a 10meg file, and how much it would cost. > > The folks who knew what they were doing were out selling metro-area services - starting at 64kbps frame relay, and then T1 & T3 speed ATM - stuff that was actually useful. > > Miles Fidelman > > Brian E Carpenter via Internet-history wrote: >> I have to say that in those years, I evaluated ATM (and frame relay, and >> ISDN for that matter) only by asking how well TCP/IP would run over it. >> (For ATM, the answer was "badly".) >> >> It was already the case that "it's the applications, stupid!", and >> all the useful apps ran over TCP/IP (apart from those that ran over >> DECnet). >> >> I remember Ellen Hancock from IBM's Network Hardware Division showing >> up on a Grand Tour of Europe, explaining how ATM was going to replace >> Token Ring as the solution to all networking problems. It wasn't until >> she left IBM that I was head hunted by them. >> >> The new IBM HQ building in Armonk NY was equipped with ATM to the >> desktop in about 1996. Bizarre. >> >> Regards >> Brian Carpenter >> >> On 11-Feb-23 06:25, Andrew G. Malis via Internet-history wrote: >>> Frame Relay (and to a lesser extent, ATM) wasn't a competitor to TCP/IP. In >>> fact, they were both L2 technologies, and certainly the greatest amount of >>> FR revenue was in tail circuits carrying IP from an ISP or a corporate HQ >>> to a remote corporate office. At the time, FR was MUCH less expensive and >>> faster than leased lines. >>> >>> Cheers, >>> Andy >>> >>> >>> On Fri, Feb 10, 2023 at 12:06 PM vinton cerf via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>> >>>> and frame relay >>>> v >>>> >>>> >>>> On Fri, Feb 10, 2023 at 11:33 AM Barbara Denny via Internet-history < >>>> internet-history at elists.isoc.org> wrote: >>>> >>>>> Let's not forget about ATM. I think ATM was also a big area of focus >>>> for >>>>> many people in this time frame. >>>>> barbara >>>>> >>>>> On Friday, February 10, 2023 at 06:48:47 AM PST, Craig Partridge via >>>>> Internet-history wrote: >>>>> >>>>> On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty via Internet-history < >>>>> internet-history at elists.isoc.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> At the time, in the 1990ish timeframe, there was a huge installed base >>>>>> of network technology. Hundreds of thousands of computers utilizing >>>>>> networks based on SNA, SPX, XNS, Decnet, etc. etc. TCP existed, but >>>>>> was a small player, confined largely to the academic and research >>>>>> communities. >>>>>> >>>>>> ... >>>>>> >>>>>> So how did TCP manage to blast through that momentum of the installed >>>>>> base, creating such a chaos in the collision? And how did it do it so >>>>>> rapidly? >>>>>> >>>>>> >>>>> Hi Jack: >>>>> >>>>> I'll start with a shout out to Brian's point that the transition was >>>>> already well underway by 1990. Absolutely >>>>> fits my experience. >>>>> >>>>> I would argue that a critical issue was communicating outside one's >>>>> organization and/or over long distance. The various technologies you >>>> list, >>>>> except for DECNET, did not focus on solving problems across >>>> organizational >>>>> boundaries. Recall Netware was the >>>>> biggest networking technology of the time and, while it adapted somewhat, >>>>> was designed to connect an office or suite >>>>> of offices. >>>>> >>>>> Meanwhile, by 1987, we'd built a relatively homogeneous email environment >>>>> across the Internet, USENET, CSNET, and >>>>> (thanks to BITNET and EARN) the academic SNA networks. I remember at a >>>> DC >>>>> Interop c. 1990, someone observing >>>>> that they had discovered couldn't hire new computing graduates if they >>>>> weren't connected to the RFC 822/domain name email >>>>> network. So the tech mindset, among the younger generation, was that >>>> they >>>>> should be able to communicate with anyone via >>>>> email. This pushed folks towards TCP/IP -- or, at least, email >>>>> compatibility with the Internet. >>>>> >>>>> At a bits-and-bytes level, long-distance reliable communications networks >>>>> are hard to do. I remember Dave Clark talking about >>>>> this around 1985 and discussing how protocol suites designed around the >>>>> local network didn't scale. He used the struggles by >>>>> the LOCUS distributed file system (which worked great on a LAN) to work >>>>> over the ARPANET as an example. In the late 1980s, >>>>> only two networking architectures had engaged with and worked through >>>> those >>>>> issues: TCP/IP and DECNET. Nicely, the most prominent and >>>>> complementary papers on congestion issues, one by Van Jacobson (TCP/IP) >>>> and >>>>> one by Raj Jain and KK Ramakrishnan (DECNET), >>>>> were presented back-to-back at the ACM SIGCOMM conference in 1988. So if >>>>> you were looking to build (or soon after via NSFNET, connect >>>>> to) a sturdy wide-area network, unless you were a DEC VMS organization, >>>>> your best choice was TCP/IP. >>>>> >>>>> I'll note it was, in my view, a near thing sometimes. NSFNET was a >>>>> tremendous gamble and for parts of 1987 and 1988 was not >>>>> a very good service (I'm told a scientist complained loudly at the >>>> National >>>>> Academy about this non-functional network they were >>>>> trying to use for important science). We figured out congestion collapse >>>>> well enough for the time (pace buffer-bloat folks) just as >>>>> it was threatening to make the Internet unusable. But I distinctly >>>>> remember that roughly around the end of 1988 or beginning of 1989, >>>>> Internet folks began to realize that when they were talking with >>>> engineers >>>>> building other networking technologies there was a whole >>>>> suite of community knowledge that the Internet folks had and nobody else >>>>> (except the wonderful DEC networking team) did. >>>>> >>>>> 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 >>>>> >>>>> -- >>>>> 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 >>>> > > > -- > 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 > > -- > 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: From brian.e.carpenter at gmail.com Sat Feb 11 11:59:39 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 12 Feb 2023 08:59:39 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <4FF67AED-9A86-4E73-9155-8347069FD94A@gmail.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> <0d194ce3-bcda-1749-d538-5471f5006b23@meetinghouse.net> <4FF67AED-9A86-4E73-9155-8347069FD94A@gmail.com> Message-ID: <9bc24193-aa98-17d0-079d-50ebe52d18df@gmail.com> On 12-Feb-23 06:42, Bob Hinden via Internet-history wrote: > I used to like saying that ATM was like ATM machines except that you only were allowed to put money in :-) Oh, I simply have to quote this from my book: "I laughed at a press cutting from a Dutch computer industry newspaper, wherein the journalist reported me as saying that the future of high speed networking would be based on the 'gelduitbetalingsautomaat', the Dutch term for Automated Teller Machine." I no longer have the cutting, but this was probably late 1992 or early 1993. Brian From touch at strayalpha.com Sat Feb 11 16:20:09 2023 From: touch at strayalpha.com (touch at strayalpha.com) Date: Sat, 11 Feb 2023 16:20:09 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <9bc24193-aa98-17d0-079d-50ebe52d18df@gmail.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <042fe150-0164-db8c-0e5a-d560041ab3a3@gmail.com> <0d194ce3-bcda-1749-d538-5471f5006b23@meetinghouse.net> <4FF67AED-9A86-4E73-9155-8347069FD94A@gmail.com> <9bc24193-aa98-17d0-079d-50ebe52d18df@gmail.com> Message-ID: <9BF5D567-5215-4DD4-86C9-4E9A66145B7C@strayalpha.com> On Feb 11, 2023, at 11:59 AM, Brian E Carpenter via Internet-history wrote: > > On 12-Feb-23 06:42, Bob Hinden via Internet-history wrote: > > > >> I used to like saying that ATM was like ATM machines except that you only were allowed to put money in :-) > > Oh, I simply have to quote this from my book: > > "I laughed at a press cutting from a Dutch computer industry > newspaper, wherein the journalist reported me as saying that the future of high > speed networking would be based on the 'gelduitbetalingsautomaat', the Dutch > term for Automated Teller Machine." At $80/month for service, that?s not inaccurate, IMO. Joe From craig at tereschau.net Mon Feb 13 08:19:05 2023 From: craig at tereschau.net (Craig Partridge) Date: Mon, 13 Feb 2023 09:19:05 -0700 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> Message-ID: On Sat, Feb 11, 2023 at 7:48 AM Noel Chiappa via Internet-history < internet-history at elists.isoc.org> wrote: > > > > From: Craig Partridge > > > We figured out congestion collapse well enough for the time > > It should be remembered that the ARPANET people (hi!) had perhaps solved > this > problem a long time before. I'm trying to remember how explicitly they saw > this as a separate problem from the issue of running out of buffer space > for > message re-assembly at the destination IMP, but I seem to recall that RFNMs > were seen as a needed throttle to prevent the network as a whole from being > overrun (i.e. what we now think of as 'congestion', although IIRC that term > wasn't used then), as well as flow control to the source host (as we would > now call it). > > I don't recall exactly where I saw that, but I'd try the BBN proposal to > DARPA's RFP, and the first JFIPS paper ("The interface message processor > for > the ARPA computer network"). > I don't recall the details either, though I remember stories of Bob Kahn going to LA to beat up on the first few ARPANET nodes because he anticipated various issues, I think including congestion. And he found them and fixes were made. But remember ARPANET was homogeneous -- same speed for each link and a single control mechanism. I think John Nagle was the first to point out ("On packet switches with infinite storage") that connecting very different networks had its own challenges. And to my point, not something that a person working with X.25 would have understood terribly well (yes X.75 gateways existed but they typically throttled the window size to 2 packets, which hid a lot of issues). Craig -- ***** Craig Partridge's email account for professional society activities and mailing lists. From dhc at dcrocker.net Mon Feb 13 08:27:41 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 13 Feb 2023 08:27:41 -0800 Subject: [ih] Running long-term archives of this list? Message-ID: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> Reflecting, once again, on the? considerable depth and breadth of historical technical knowledge that is regularly demonstrated on this list, I'm wondering about how robustly is is archives and how easily the various archives can be accessed. Yes it's hosted by isoc, but I'm asking about long-term (museum-quality) data archival.? (We tend to think of back and archive as the same, but they aren't.) Also note I cited 'running' which means that even this message should hit those long-term archives pretty quickly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From vint at google.com Mon Feb 13 10:35:17 2023 From: vint at google.com (Vint Cerf) Date: Mon, 13 Feb 2023 13:35:17 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> Message-ID: Confirming Bob Kahn and Dave Walden came to UCLA in early 1970 to force various lockups. I helped to program artificial loads and to capture the data showing various lockups. V On Mon, Feb 13, 2023, 11:19 Craig Partridge via Internet-history < internet-history at elists.isoc.org> wrote: > On Sat, Feb 11, 2023 at 7:48 AM Noel Chiappa via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > > > > > From: Craig Partridge > > > > > We figured out congestion collapse well enough for the time > > > > It should be remembered that the ARPANET people (hi!) had perhaps solved > > this > > problem a long time before. I'm trying to remember how explicitly they > saw > > this as a separate problem from the issue of running out of buffer space > > for > > message re-assembly at the destination IMP, but I seem to recall that > RFNMs > > were seen as a needed throttle to prevent the network as a whole from > being > > overrun (i.e. what we now think of as 'congestion', although IIRC that > term > > wasn't used then), as well as flow control to the source host (as we > would > > now call it). > > > > I don't recall exactly where I saw that, but I'd try the BBN proposal to > > DARPA's RFP, and the first JFIPS paper ("The interface message processor > > for > > the ARPA computer network"). > > > > I don't recall the details either, though I remember stories of Bob Kahn > going to LA to beat up on the first few ARPANET nodes > because he anticipated various issues, I think including congestion. And > he found them and fixes were made. > > But remember ARPANET was homogeneous -- same speed for each link and a > single control mechanism. I think John Nagle was > the first to point out ("On packet switches with infinite storage") that > connecting very different networks had its own challenges. > And to my point, not something that a person working with X.25 would have > understood terribly well (yes X.75 gateways existed but > they typically throttled the window size to 2 packets, which hid a lot of > issues). > > 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 jeanjour at comcast.net Mon Feb 13 10:39:10 2023 From: jeanjour at comcast.net (John Day) Date: Mon, 13 Feb 2023 13:39:10 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> Message-ID: <973762D2-4416-49B0-A848-012E25AAF54B@comcast.net> Was the Christmas Eve lock up the first one? Or was that just an accident? > On Feb 13, 2023, at 13:35, Vint Cerf via Internet-history wrote: > > Confirming Bob Kahn and Dave Walden came to UCLA in early 1970 to force > various lockups. I helped to program artificial loads and to capture the > data showing various lockups. > > V > > On Mon, Feb 13, 2023, 11:19 Craig Partridge via Internet-history < > internet-history at elists.isoc.org> wrote: > >> On Sat, Feb 11, 2023 at 7:48 AM Noel Chiappa via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> >>> >>>> From: Craig Partridge >>> >>>> We figured out congestion collapse well enough for the time >>> >>> It should be remembered that the ARPANET people (hi!) had perhaps solved >>> this >>> problem a long time before. I'm trying to remember how explicitly they >> saw >>> this as a separate problem from the issue of running out of buffer space >>> for >>> message re-assembly at the destination IMP, but I seem to recall that >> RFNMs >>> were seen as a needed throttle to prevent the network as a whole from >> being >>> overrun (i.e. what we now think of as 'congestion', although IIRC that >> term >>> wasn't used then), as well as flow control to the source host (as we >> would >>> now call it). >>> >>> I don't recall exactly where I saw that, but I'd try the BBN proposal to >>> DARPA's RFP, and the first JFIPS paper ("The interface message processor >>> for >>> the ARPA computer network"). >>> >> >> I don't recall the details either, though I remember stories of Bob Kahn >> going to LA to beat up on the first few ARPANET nodes >> because he anticipated various issues, I think including congestion. And >> he found them and fixes were made. >> >> But remember ARPANET was homogeneous -- same speed for each link and a >> single control mechanism. I think John Nagle was >> the first to point out ("On packet switches with infinite storage") that >> connecting very different networks had its own challenges. >> And to my point, not something that a person working with X.25 would have >> understood terribly well (yes X.75 gateways existed but >> they typically throttled the window size to 2 packets, which hid a lot of >> issues). >> >> 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 >> > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From vint at google.com Mon Feb 13 10:41:36 2023 From: vint at google.com (Vint Cerf) Date: Mon, 13 Feb 2023 13:41:36 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <973762D2-4416-49B0-A848-012E25AAF54B@comcast.net> References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> <973762D2-4416-49B0-A848-012E25AAF54B@comcast.net> Message-ID: I think we forced Mexican standoff and reassembly lockup pretty early on. V On Mon, Feb 13, 2023, 13:39 John Day wrote: > Was the Christmas Eve lock up the first one? Or was that just an accident? > > > > > On Feb 13, 2023, at 13:35, Vint Cerf via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > Confirming Bob Kahn and Dave Walden came to UCLA in early 1970 to force > > various lockups. I helped to program artificial loads and to capture the > > data showing various lockups. > > > > V > > > > On Mon, Feb 13, 2023, 11:19 Craig Partridge via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> On Sat, Feb 11, 2023 at 7:48 AM Noel Chiappa via Internet-history < > >> internet-history at elists.isoc.org> wrote: > >> > >>> > >>> > >>>> From: Craig Partridge > >>> > >>>> We figured out congestion collapse well enough for the time > >>> > >>> It should be remembered that the ARPANET people (hi!) had perhaps > solved > >>> this > >>> problem a long time before. I'm trying to remember how explicitly they > >> saw > >>> this as a separate problem from the issue of running out of buffer > space > >>> for > >>> message re-assembly at the destination IMP, but I seem to recall that > >> RFNMs > >>> were seen as a needed throttle to prevent the network as a whole from > >> being > >>> overrun (i.e. what we now think of as 'congestion', although IIRC that > >> term > >>> wasn't used then), as well as flow control to the source host (as we > >> would > >>> now call it). > >>> > >>> I don't recall exactly where I saw that, but I'd try the BBN proposal > to > >>> DARPA's RFP, and the first JFIPS paper ("The interface message > processor > >>> for > >>> the ARPA computer network"). > >>> > >> > >> I don't recall the details either, though I remember stories of Bob Kahn > >> going to LA to beat up on the first few ARPANET nodes > >> because he anticipated various issues, I think including congestion. > And > >> he found them and fixes were made. > >> > >> But remember ARPANET was homogeneous -- same speed for each link and a > >> single control mechanism. I think John Nagle was > >> the first to point out ("On packet switches with infinite storage") that > >> connecting very different networks had its own challenges. > >> And to my point, not something that a person working with X.25 would > have > >> understood terribly well (yes X.75 gateways existed but > >> they typically throttled the window size to 2 packets, which hid a lot > of > >> issues). > >> > >> 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 > >> > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > From enervatron at gmail.com Mon Feb 13 10:56:48 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 10:56:48 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <138f6beb-b3fc-30a3-6e1c-ebcbc0fb7a82@mtcc.com> References: <138f6beb-b3fc-30a3-6e1c-ebcbc0fb7a82@mtcc.com> Message-ID: <5b635a4b-473f-ba68-9f9f-0b25c69000a9@gmail.com> [sorry if this is a little weirdly formatted... my normal email address is seemingly getting send to /dev/null on this list for some reason] On 2/10/23 6:48 AM, Craig Partridge via Internet-history wrote: > I'll start with a shout out to Brian's point that the transition was > already well underway by 1990. Absolutely > fits my experience. My experience as somebody completely on the outside looking in in the mid to late 80's is that we had no clue -- or care, honestly -- who was going to "win". We had all heard that OSI was the path forward, but it never materialized from what we could tell. Since we were a VMS house, we had pretty much expected it to take over but it never did. IP on the other hand had people actually asking for it (we were building networked widgets at the time). So we spent cycles on it as somebody was willing to pay for it. Since we were very host focused, we didn't have a dog in the routing fight, so Netware, SMB, Appletalk, DEC LAT and LPR and Telnet were pretty much if somebody wanted it, we'd design it. It wasn't until probably around 1991 or so when I went to my first Interop that it became clear that IP had won and the path to OSI was really the path to /dev/null. Mike From jack at 3kitty.org Mon Feb 13 11:37:17 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 11:37:17 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <5b635a4b-473f-ba68-9f9f-0b25c69000a9@gmail.com> References: <138f6beb-b3fc-30a3-6e1c-ebcbc0fb7a82@mtcc.com> <5b635a4b-473f-ba68-9f9f-0b25c69000a9@gmail.com> Message-ID: <366317a4-4d3e-c4fd-f293-a41fd9623aea@3kitty.org> On 2/13/23 10:56, Michael Thomas via Internet-history wrote: > [sorry if this is a little weirdly formatted... my normal email > address is seemingly getting send to /dev/null on this list for some > reason] > Me too.? I think there has been some kind of email outage.?? I sent a message yesterday to the list, a few minutes after Joe Touch's "Design choices in SMTP".?? But it never came back to me as "via internet-history" and it's also not in the list archives.?? It appears I also didn't receive other list mail over the weekend. I'll send my message again, if this one gets through.? Maybe the sun's solar flares and "vortex" are to blame.... Jack Haverty From enervatron at gmail.com Mon Feb 13 11:40:32 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 11:40:32 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <366317a4-4d3e-c4fd-f293-a41fd9623aea@3kitty.org> References: <138f6beb-b3fc-30a3-6e1c-ebcbc0fb7a82@mtcc.com> <5b635a4b-473f-ba68-9f9f-0b25c69000a9@gmail.com> <366317a4-4d3e-c4fd-f293-a41fd9623aea@3kitty.org> Message-ID: <2f67e9d0-39a7-6e84-a092-b9a0e8e34271@gmail.com> On 2/13/23 11:37 AM, Jack Haverty via Internet-history wrote: > On 2/13/23 10:56, Michael Thomas via Internet-history wrote: >> [sorry if this is a little weirdly formatted... my normal email >> address is seemingly getting send to /dev/null on this list for some >> reason] >> > Me too.? I think there has been some kind of email outage.?? I sent a > message yesterday to the list, a few minutes after Joe Touch's "Design > choices in SMTP".?? But it never came back to me as "via > internet-history" and it's also not in the list archives.?? It appears > I also didn't receive other list mail over the weekend. > > I'll send my message again, if this one gets through.? Maybe the sun's > solar flares and "vortex" are to blame.... > I sent like 3-4 messages and none of them ended up in the archive. Not sure what's going on, but happy that this account seems to be working. Mike From jack at 3kitty.org Mon Feb 13 11:40:36 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 11:40:36 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> Message-ID: <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> (retransmission - first transmission 2 says ago apparently got lost somewhere...) Thanks for all the observations about why TCP was a rare success story in its momentous (momentumous?) battle with the installed base.? Lots of good info and observations, but the root causes remain elusive to me at least.?? Why could TCP/IPV4 annihilate all of the preexisting other similar technologies? For example, I agree that many technologies have failed to be adopted because of "lack of market demand".?? But why was there such a lack?? Did the creators of the technology not understand the market??? Did the market change so fast that the technology was obsoleted as it was released?? Was there some missing feature or difficult requirement that made the technology unpalatable to the market??? Was the market successfully made aware of the new technology and why they should care? TCP's notion of "internet" had competition.? For a while in the 1990 timeframe, a popular notion was the "Global LAN", in which an organization could interconnect its LANs at its various sites, forming a composite "WLAN" or wide-area local area network.?? SNA, XNS, SPX, Appletalk et al provided such a capability to form such a global LAN.? TCP/IP did the same thing, allowing LANs at widespread sites to be interconnected to form an internet.? Router vendors created "multiprotocol routers" to enable a mix of different "global" technologies to utilize the same expensive communications circuits.? The TCP/IP machinery survives to this day; all of the others have disappeared.? They all competed in the same market conditions.? TCP didn't just become one of the "top three" in the competitive space.?? It became pretty much the ony one left standing.? Why did TCP/IP win? Second comment -- The metric of "adoption" when it's based on deployment of the new or replacement technology doesn't seem appropriate - e.g., the 30+% adoption of TCP/IP V6.? A better metric for evaluating how successfully a "new release" is being adopted, IMHO, would be the metric of the survival rate of the prior release - the one hopefully being replaced.? In other words, a metric for the success of deployment of IPV6 would be the diminishing rate of usage of IPV4. If a new technology is adopted at a certain rate, but the one it is supposed to replace does not fade away, the new technology is just YANP - Yet Another Network Protocol, making the operational system even more complex and difficult to operate and maintain.? Today, it seems to me that IPV6 is still YANP.? Many of the technologies defined in RFCs and some category of Standard may also be stuck in YANP limbo. Last comment -- We have been discussing what happened historically to cause what we see today.?? But perhaps equally important are things that did not happen, and thereby helped TCP/IP in the battle.?? What was important because it did not happen? I can relate one example from my personal experience.? I suspect there were a lot of others over the decades. In 1990, I joined Oracle as "Internet Architect".? Oracle's customers were global and involved in any industry you can imagine. Oracle's mission was to provide database software that would run on whatever computer, using whatever operating system, connected to whatever network a customer had chosen.?? To deliver that software, we had a very unusual kaleidoscopic computer center - instead of staid rows of blue, or red, or black, or whatever colored equipment from the chosen IT vendor, we had at least one of every kind of computer you could get.?? We also operated our own corporate network, using multiprotocol routers (Cisco), connecting our offices internationally.?? All of that was necessary to build and test the software, to assure that it would in fact run on any computer, and network, a customer might have.? Any (database) client could interact with any (database) server over whatever kind of network was involved. Running a multiprotocol network was not for the faint of heart. YANP on steroids.? Our customers? increasingly had the same situation. When prices fell far enough, they couldn't enforce a corporate network standard for IT, but rather might discover Appletalk in Marketing, some kind of PC LAN in Sales and Accounting, SNA in mainframe territory, perhaps DECNET in Manufacturing, etc. This struck me as entirely analogous to the situation that motivated TCP - too many different kinds of networks involved.? TCP bound them all together into a cohesive supernetwork.?? TCP was "One protocol to rule them all, one protocol to bind them" (did I get it right...?0 So we pursued a similar solution, following the lead of that ARPA research and Bilbo Baggins.? Instead of "gateways" (aka "routers"), we developed something we called an "Interchange".? This was simply software that would run on some or just a few machines that had the ability to use more than one network protocol (e.g., SPX and TCP). Every network protocol had some mechanism for creating "reliable byte streams".? The Interchange was a very simple "patch panel" that would take serial connections from each side and "plug them together" to create a composite "reliable serial byte-stream" from end to end.? By going through Interchanges, a client on any network could interact with a server on any other network.? So a client on an Appletalk machine could utilize a database on a DECNET machine, possibly traversing a TCP "backbone" along the way.?? For testing, we could set up such configurations just using our own multiprotocol internet. This "Interchange" mechanism was called TNS, or Transparent Networking Substrate, and enabled clients and servers to interact, no matter what kind of computers or networks they were on. I recall being frequently accosted, e.g,. at Interop, by people who wanted us to release TNS as a separate product and API, so that it could be used for other kinds of interactions across a mix of networks - e.g., transferring files from a PC on a LAN to an archival site on a mainframe.?? We thought about it, but decided not to do it for a lot of reasons.? We weren't a "network company" marketing protocol implementations.?? We understood how database software in clients and servers utilized the TNS, but undoubtedly lots of issues and problems would arise when other kinds of interactions were tried over TNS.?? Support knew how to troubleshoot database problems, but TNS problems with other activities would add another dimension of idiosyncracies.?? Lots of reasons, despite some indication of a market demand. So we never released TNS as a separate capability.?? But there was nothing particularly secret about how it worked, and nothing patented, so anybody could have created a similar "patch panel" mechanism.?? But no one did, AFAIK. If such a TNS general capability had been available, would it have disrupted TCP's battle to dominance, by removing many of the annoyances inherent in multiprotocol installations?? Perhaps, perhaps not.? But it seems that things that did not happen, like general availability of a TNS, might be important historically. Restricted to database activity, the TNS capability that we did deploy may even have helped TCP's advance.? With Interchanges, it was possible for our customers to plan and execute a more orderly and controlled transition to TCP.?? During interim and testing phases, Interchanges could be used to maintain client-server connectivity as the underlying networks were migrated to TCP.? The company could keep running, with no potentially suicidal "Flag Days" to fear.? Corporations like such methodical and careful approaches. IMHO, the 1980s and 1990s were a very complex period with lots of things being done, and not done.?? The TNS story was likely just one example of many. That's why I opined that some Historian may someday be able to sort it all out. Hope this helps, Jack Haverty On 2/9/23 18:16, Jack Haverty via Internet-history wrote: > On 2/9/23 14:57, Dave Crocker via Internet-history wrote: >> Such is the lesson of installed base momentum. > I agree - the installed base is a formidable obstacle to getting any > kind of replacement propagated.?? Stagnation and fragmentation into > silos seems to be the result, as players introduce a desired new > technology into just the components that they can control. > > But I also wonder -- How did TCP overcome the momentum of the > installed base? > > At the time, in the 1990ish timeframe, there was a huge installed base > of network technology.?? Hundreds of thousands of computers utilizing > networks based on SNA, SPX, XNS, Decnet, etc. etc. ? TCP existed, but > was a small player, confined largely to the academic and research > communities. > > But almost overnight, actually over just a few years, TCP became a > real player, and then the dominant player, and by now all of the other > technologies of that installed base have simply disappeared. The > installed base of 1990 is gone without a trace.? Are there any > computers anywhere still running those well-established > technologies??? I haven't encountered any, but I wouldn't be surprised > if some still existed.?? Perhaps something running Cobol somewhere. > > So how did TCP manage to blast through that momentum of the installed > base, creating such a chaos in the collision??? And how did it do it > so rapidly? > > Curiously, that collision of TCP with the installed base involved > TCP/IP V4.?? TCP/IP V6 has come along and its been quite a few years > in transition.?? It seems that the momentum of the installed base of > TCP/IP V4 has blunted the adoption of TCP/IP V6.?? Why? What's different? > > A similar situation seems to exist in other network areas, e.g., the > mechanisms of electronic mail that we've been discussing.? New > technologies can get invented and documented, but often never get > widely deployed.? Why??? What magic incantations were used to deploy > TCP in the 1990s that have been apparently now lost. > > Perhaps some historian has some answers.... > > Jack From sob at sobco.com Mon Feb 13 11:50:26 2023 From: sob at sobco.com (Scott Bradner) Date: Mon, 13 Feb 2023 14:50:26 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: for what its worth - here is my take on some of the reasons that the Internet (and specifically TCP/IP) took over the world Forks: Decisions that got us the Internet we have https://www.sobco.com/presentations/2020-06-25-forks.pdf Scott (I, along with Scott Shackelford, have a book on the subject that should be published at some point - the text is done & now in publisher wait) From enervatron at gmail.com Mon Feb 13 12:01:15 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 12:01:15 -0800 Subject: [ih] History of IoT Message-ID: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> Hi all, I've been trying to understand the history of what we'd now call the Internet of Things. I know about the internet coke machine which was in about 1983 and then the internet toaster in around 1990. but that's a lot of time in between that seems to be blank. It would shock me if students didn't follow suit with their own versions of coke machine like hacks in the mean time. The timelines I've seen credit the toaster as being the first IoT device, but I'm not sure why the coke machine doesn't qualify because it's just as much of a hack as the toaster. My personal stake -- and the reason for my curiosity -- is that I designed the software for an ethernet enabled laser printer in the mid 80's which is very likely to be the first (I'd be happy to hear otherwise) for a printer. We added IP to it a year or two later so it was definitely before 1990, but I've lost access to source control so it's really hard to verify my claims. So if it wasn't the first IoT device (and I don't think it was, the coke machine was really clever), it could have been the first IoT device that had commercial value. It was definitely a selling point even back then even though it was obviously still pretty niche. The company who contracted us for it sold to a lot of universities so they'd have had a ready audience. So does anybody have any memories of IoT in that era? Any good resources? I almost drove up to ISI for an IETF meeting after struggling with lprd which was not very well suited to the task of something embedded in a device. Alas, it was easier procrastinate. There probably wouldn't have been all that much interest since there were so many other fish to fry at that time as well. Hopefully the output of this a blog post that I'd like to put together. cheers, Mike From jeanjour at comcast.net Mon Feb 13 12:15:02 2023 From: jeanjour at comcast.net (John Day) Date: Mon, 13 Feb 2023 15:15:02 -0500 Subject: [ih] History of IoT In-Reply-To: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> Message-ID: <2D03CE85-6E8D-4FF5-97A7-080EDC9A753A@comcast.net> Network Management was the first IoT and still is. The architecture is the same just different object models. One of the things the current IoT fad likes to ignore is that they will have to manage and debug their ?IoT? installation. IoT is mostly about hype and making it sound like it is a new thing. In our investigations, we have found nothing really different (mostly degenerate cases) in the lower communication layers. The applications are as I said, mainly different object models. Take care, John > On Feb 13, 2023, at 15:01, Michael Thomas via Internet-history wrote: > > Hi all, > > I've been trying to understand the history of what we'd now call the Internet of Things. I know about the internet coke machine which was in about 1983 and then the internet toaster in around 1990. but that's a lot of time in between that seems to be blank. It would shock me if students didn't follow suit with their own versions of coke machine like hacks in the mean time. The timelines I've seen credit the toaster as being the first IoT device, but I'm not sure why the coke machine doesn't qualify because it's just as much of a hack as the toaster. > > My personal stake -- and the reason for my curiosity -- is that I designed the software for an ethernet enabled laser printer in the mid 80's which is very likely to be the first (I'd be happy to hear otherwise) for a printer. We added IP to it a year or two later so it was definitely before 1990, but I've lost access to source control so it's really hard to verify my claims. So if it wasn't the first IoT device (and I don't think it was, the coke machine was really clever), it could have been the first IoT device that had commercial value. It was definitely a selling point even back then even though it was obviously still pretty niche. The company who contracted us for it sold to a lot of universities so they'd have had a ready audience. > > So does anybody have any memories of IoT in that era? Any good resources? I almost drove up to ISI for an IETF meeting after struggling with lprd which was not very well suited to the task of something embedded in a device. Alas, it was easier procrastinate. There probably wouldn't have been all that much interest since there were so many other fish to fry at that time as well. > > Hopefully the output of this a blog post that I'd like to put together. > > cheers, Mike > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From craig at tereschau.net Mon Feb 13 12:28:05 2023 From: craig at tereschau.net (Craig Partridge) Date: Mon, 13 Feb 2023 13:28:05 -0700 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: HI Scott: Small nit. DARPA funded Berkeley to port the BBN Unix to BSD -- and Bill Joy chose to reimplement and develop sockets. Much behind the scenes fighting ensued (I was hired into that fight in 1983 when BBN concluded it needed to train someone to understand the BSD implementation). Led to various odd conversations years later -- I remember Van Jacobson justifying a TCP bug in the BSD implementation by saying it had been in the BBN implementation that Bill used as a reference -- c. 1989, long after BBN BSD TCP was gone. Craig On Mon, Feb 13, 2023 at 12:50 PM Scott Bradner via Internet-history < internet-history at elists.isoc.org> wrote: > for what its worth - here is my take on some of the reasons that the > Internet (and specifically > TCP/IP) took over the world > > Forks: Decisions that got us the Internet we have > https://www.sobco.com/presentations/2020-06-25-forks.pdf > > Scott > (I, along with Scott Shackelford, have a book on the subject that should > be published at some > point - the text is done & now in publisher wait) > -- > 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 jeanjour at comcast.net Mon Feb 13 12:35:00 2023 From: jeanjour at comcast.net (John Day) Date: Mon, 13 Feb 2023 15:35:00 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: <2A90F9DF-83D1-4B03-9777-14E9A5EB3FD3@comcast.net> So Berkeley?s position was that they were to port the BBN implementation bugs and all? And BBN is to blame for sockets? What a lost opportunity. The first Unix on the Net in 1975 didn?t do that. It used file_io. > On Feb 13, 2023, at 15:28, Craig Partridge via Internet-history wrote: > > HI Scott: > > Small nit. > > DARPA funded Berkeley to port the BBN Unix to BSD -- and Bill Joy chose to > reimplement and develop sockets. Much behind the scenes fighting ensued (I > was hired into that fight in 1983 when BBN concluded it needed to train > someone to understand the BSD implementation). Led to various odd > conversations years later -- I remember Van Jacobson justifying a TCP bug > in the BSD implementation by saying it had been in the BBN implementation > that Bill used as a reference -- c. 1989, long after BBN BSD TCP was gone. > > Craig > > On Mon, Feb 13, 2023 at 12:50 PM Scott Bradner via Internet-history < > internet-history at elists.isoc.org> wrote: > >> for what its worth - here is my take on some of the reasons that the >> Internet (and specifically >> TCP/IP) took over the world >> >> Forks: Decisions that got us the Internet we have >> https://www.sobco.com/presentations/2020-06-25-forks.pdf >> >> Scott >> (I, along with Scott Shackelford, have a book on the subject that should >> be published at some >> point - the text is done & now in publisher wait) >> -- >> 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 jack at 3kitty.org Mon Feb 13 12:44:05 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 12:44:05 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> Message-ID: <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> It seems that I didn't receive some messages over the weekend....sorry if anyone has already noted what I say below. Re the ARPANET and Congestion Control:?? This was definitely a hot topic, in particular after DCA took over operations and the network grew in size.?? There were DCA-managed contracts to rework the internal mechanisms of the ARPANET to handle the much larger and diverse networks of IMPs that evolved into the multiple IMP-based networks called the DDN.?? Congestion control was just one issue of several that interacted, e.g., routing, flow control, retransmission, buffer management, etc.? The IMP design, although a "packet network", in effect had a "serial byte stream" mechanism internally to make sure all data got from source host to destination.? The ARPANET had the equivalent of parts of a TCP built inside the IMPs to guarantee the delivery of a data stream. I'm not sure how much historical detail you'll find in traditionally published papers and journals.?? Outside of academia that wasn't a priority.? But there were extensive and detailed reports prepared as part of the ARPANET "operations" contracts and delivered to DCA. Here's one 3-volume, multi-year example that discusses a lot of the work in the early 80s on "congestion control" and new internal IMP mechanisms in general: https://apps.dtic.mil/sti/citations/ADA053450 https://apps.dtic.mil/sti/citations/ADA086338 https://apps.dtic.mil/sti/citations/ADA121350 There's hundreds of pages of detail in those reports and there are others available through DTiC.?? I was listed as author on some of these, because at the time that contract was one of "my" contracts -- which meant that I had to make sure that the report got written and delivered so we would get paid.?? I didn't personally work on the ARPANET technical research, but I did absorb some understanding of the issues and details.? The "IMP Group" was literally just down the hall. At the time (early 1980s), I was involved in the early Internet work, when TCP/IP V4 was being created and the various flow and congestion control mechanisms were being defined.? From the ARPANET experience, it was clear to me that the IMP gurus "down the hall" at BBN viewed congestion control as a major issue, and that sometimes surfaced as statements such as "TCP will never work".? TCP didn't address any of the issues of congestion, except by the rudimentary and unproven mechanism of "Source Quench". The expectation was that the Internet would work if congestion was avoided rather than controlled, which could be attempted by keeping network capacity above traffic demands, at least long enough that TCP's retransmission and backoff mechanisms in the hosts would throttle down as expected to match what the network substrate was capable of carrying at the time.?? Of course those mechanisms were now distributed among the several hosts and network switches (e.g., IMPs, Packet Radios, computer OS, gateways) involved, designed, built, and managed by different organizaions, which made it challenging to predict how it would all behave. Even today, as an end user, I can't tell if "congestion control" is implemented and working well, or if congestion is just mostly being avoided by deployment of lots of fiber and lots of buffer memory in all the switching locations where congestion might be expected. That of course results in the phenomenon of "buffer bloat".?? That's another question for the Historians.? Has "Congestion Control" in the Internet been solved?? Or avoided? Jack Haverty On 2/13/23 08:19, Craig Partridge via Internet-history wrote: > On Sat, Feb 11, 2023 at 7:48 AM Noel Chiappa via Internet-history < > internet-history at elists.isoc.org> wrote: > >> >> > From: Craig Partridge >> >> > We figured out congestion collapse well enough for the time >> >> It should be remembered that the ARPANET people (hi!) had perhaps solved >> this >> problem a long time before. I'm trying to remember how explicitly they saw >> this as a separate problem from the issue of running out of buffer space >> for >> message re-assembly at the destination IMP, but I seem to recall that RFNMs >> were seen as a needed throttle to prevent the network as a whole from being >> overrun (i.e. what we now think of as 'congestion', although IIRC that term >> wasn't used then), as well as flow control to the source host (as we would >> now call it). >> >> I don't recall exactly where I saw that, but I'd try the BBN proposal to >> DARPA's RFP, and the first JFIPS paper ("The interface message processor >> for >> the ARPA computer network"). >> > I don't recall the details either, though I remember stories of Bob Kahn > going to LA to beat up on the first few ARPANET nodes > because he anticipated various issues, I think including congestion. And > he found them and fixes were made. > > But remember ARPANET was homogeneous -- same speed for each link and a > single control mechanism. I think John Nagle was > the first to point out ("On packet switches with infinite storage") that > connecting very different networks had its own challenges. > And to my point, not something that a person working with X.25 would have > understood terribly well (yes X.75 gateways existed but > they typically throttled the window size to 2 packets, which hid a lot of > issues). > > Craig From steffen at sdaoden.eu Mon Feb 13 12:58:47 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 13 Feb 2023 21:58:47 +0100 Subject: [ih] Running long-term archives of this list? In-Reply-To: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> References: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> Message-ID: <20230213205847.mQMcv%steffen@sdaoden.eu> dcrocker at bbiw.net wrote in <46eaa3fc-3d54-7618-6833-0829ee0357a3 at dcrocker.net>: |Reflecting, once again, on the? considerable depth and breadth of |historical technical knowledge that is regularly demonstrated on this |list, I'm wondering about how robustly is is archives and how easily the |various archives can be accessed. | |Yes it's hosted by isoc, but I'm asking about long-term (museum-quality) |data archival.? (We tend to think of back and archive as the same, but |they aren't.) | |Also note I cited 'running' which means that even this message should |hit those long-term archives pretty quickly. It is not "museum-quality", but i would strongly suggest a "backup" on one of the public list archives. There is marc.info that is popular in open source world, but i personally really admire mail-archive.com. They are prowd of their uptime (100% last year, 99.80% over operation lifetime, 24 years, this year 25th anniversary; statistics go back to 2005). Right now they manage 174911436 archived postings on 2568 active mailing lists, which are quite impressive numbers. The nice thing is also that they offer good search capabilities[1], which the isoc thing does not at all! Jeff Breidenbach seems to be a sympathic and helpful guy, who even gave back donations as long as he was running it as a business. They offer importing existing archives[2]. I did so, he was super responsive. No problem. One of the guys who keep a real thing running silently (as via xkcd[3]). [1] https://www.mail-archive.com/faq.html#search [2] https://www.mail-archive.com/faq.html#import [3] https://xkcd.com/2347/ Museum quality? I hope the isoc people create real MBOX archives, and do not solely rely on that pipermail HTML mutilation. That would really be a pity! If so, then it would be tremendous if that single file archive would be made available somewhere!! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From enervatron at gmail.com Mon Feb 13 13:01:54 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 13:01:54 -0800 Subject: [ih] History of IoT In-Reply-To: References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> Message-ID: <8f9adfc3-e0b4-ccb7-9c12-cfe8733057d2@gmail.com> On 2/13/23 12:31 PM, Toerless Eckert wrote: > So, what is the proper definition then for an IoT device ? > > Sure: "got to have a proper host IP stack". > > But how "embedded" into the device does that stack have to be ? I doubt there is a proper definition, but my take is that it's a (mostly) headless host using embedded software which isn't involved in the control plane of the net. That is, it's host with its own embedded IP stack. > > We still have today likely the mayority of supposedly "IoT" devices > such as supposedly "Smart" meters that effectively are composed > modularily from a "stupid" device with some form of serial > interface connecting to a "gateway" device with the host-stack > (and web server and etc. pp.) running on that gateway. > And in most other "IoT" devices you may not see this modular > design, but they are still built in the same way. That's what > arduino, rasperry style SBC are popular for. When I first heard about "IoT" is was in the context of ipv6 and how its gigantic address space made enabling them much easier. I want to think it was Jari Arkko that gave the talk, but could easily be misremembering. > > My bachelor thesis in ca 1987 was to implement color postscript > rendering for a printer, but i quickly gave up on trying > to get the whole postscript rendering software to run on the > printer itself because there was absolutely no diagnostics > (download 20MByte source code.. wait, nothing happens - doh !), > so i ended up using a Sun workstation with lpr and the renderer > connecting via the printers serial port to only download and > print the rendered page image. Was that combination of printer > and Sun workstation an IoT device ? Are medical systems such > as XRay machines that pretty much continue this approach > until today IoT devices or not ? The company that contracted us to design the printer and software managed to get postscript on it, but not the Adobe stack partly because of that, but probably more likely because of the licensing fees. Was your printer an IoT device? I'd say no: it was just using normal host protocols to do what it did locally in the first place (ie, lpr). And shoe-horning LPRd into the printer itself was painful because lpr expected a disk to buffer everything. As I mentioned, I almost trotted up to ISI because of it. Mike From steve at shinkuro.com Mon Feb 13 13:01:50 2023 From: steve at shinkuro.com (Steve Crocker) Date: Mon, 13 Feb 2023 16:01:50 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> Message-ID: In my view, the answer to 'Has "Congestion Control" in the Internetbeen solved?' is clearly no. I view bufferbloat as one important part of the congestion control problem. Steve On Mon, Feb 13, 2023 at 3:44 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > It seems that I didn't receive some messages over the weekend....sorry > if anyone has already noted what I say below. > > Re the ARPANET and Congestion Control: This was definitely a hot > topic, in particular after DCA took over operations and the network grew > in size. There were DCA-managed contracts to rework the internal > mechanisms of the ARPANET to handle the much larger and diverse networks > of IMPs that evolved into the multiple IMP-based networks called the > DDN. Congestion control was just one issue of several that interacted, > e.g., routing, flow control, retransmission, buffer management, etc. > The IMP design, although a "packet network", in effect had a "serial > byte stream" mechanism internally to make sure all data got from source > host to destination. The ARPANET had the equivalent of parts of a TCP > built inside the IMPs to guarantee the delivery of a data stream. > > I'm not sure how much historical detail you'll find in traditionally > published papers and journals. Outside of academia that wasn't a > priority. But there were extensive and detailed reports prepared as > part of the ARPANET "operations" contracts and delivered to DCA. Here's > one 3-volume, multi-year example that discusses a lot of the work in the > early 80s on "congestion control" and new internal IMP mechanisms in > general: > > https://apps.dtic.mil/sti/citations/ADA053450 > https://apps.dtic.mil/sti/citations/ADA086338 > https://apps.dtic.mil/sti/citations/ADA121350 > > There's hundreds of pages of detail in those reports and there are > others available through DTiC. I was listed as author on some of > these, because at the time that contract was one of "my" contracts -- > which meant that I had to make sure that the report got written and > delivered so we would get paid. I didn't personally work on the > ARPANET technical research, but I did absorb some understanding of the > issues and details. The "IMP Group" was literally just down the hall. > > At the time (early 1980s), I was involved in the early Internet work, > when TCP/IP V4 was being created and the various flow and congestion > control mechanisms were being defined. From the ARPANET experience, it > was clear to me that the IMP gurus "down the hall" at BBN viewed > congestion control as a major issue, and that sometimes surfaced as > statements such as "TCP will never work". TCP didn't address any of the > issues of congestion, except by the rudimentary and unproven mechanism > of "Source Quench". > > The expectation was that the Internet would work if congestion was > avoided rather than controlled, which could be attempted by keeping > network capacity above traffic demands, at least long enough that TCP's > retransmission and backoff mechanisms in the hosts would throttle down > as expected to match what the network substrate was capable of carrying > at the time. Of course those mechanisms were now distributed among the > several hosts and network switches (e.g., IMPs, Packet Radios, computer > OS, gateways) involved, designed, built, and managed by different > organizaions, which made it challenging to predict how it would all behave. > > Even today, as an end user, I can't tell if "congestion control" is > implemented and working well, or if congestion is just mostly being > avoided by deployment of lots of fiber and lots of buffer memory in all > the switching locations where congestion might be expected. That of > course results in the phenomenon of "buffer bloat". That's another > question for the Historians. Has "Congestion Control" in the Internet > been solved? Or avoided? > > Jack Haverty > > > > On 2/13/23 08:19, Craig Partridge via Internet-history wrote: > > On Sat, Feb 11, 2023 at 7:48 AM Noel Chiappa via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> > >> > From: Craig Partridge > >> > >> > We figured out congestion collapse well enough for the time > >> > >> It should be remembered that the ARPANET people (hi!) had perhaps solved > >> this > >> problem a long time before. I'm trying to remember how explicitly they > saw > >> this as a separate problem from the issue of running out of buffer space > >> for > >> message re-assembly at the destination IMP, but I seem to recall that > RFNMs > >> were seen as a needed throttle to prevent the network as a whole from > being > >> overrun (i.e. what we now think of as 'congestion', although IIRC that > term > >> wasn't used then), as well as flow control to the source host (as we > would > >> now call it). > >> > >> I don't recall exactly where I saw that, but I'd try the BBN proposal to > >> DARPA's RFP, and the first JFIPS paper ("The interface message processor > >> for > >> the ARPA computer network"). > >> > > I don't recall the details either, though I remember stories of Bob Kahn > > going to LA to beat up on the first few ARPANET nodes > > because he anticipated various issues, I think including congestion. And > > he found them and fixes were made. > > > > But remember ARPANET was homogeneous -- same speed for each link and a > > single control mechanism. I think John Nagle was > > the first to point out ("On packet switches with infinite storage") that > > connecting very different networks had its own challenges. > > And to my point, not something that a person working with X.25 would have > > understood terribly well (yes X.75 gateways existed but > > they typically throttled the window size to 2 packets, which hid a lot of > > issues). > > > > Craig > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From touch at strayalpha.com Mon Feb 13 13:03:06 2023 From: touch at strayalpha.com (touch at strayalpha.com) Date: Mon, 13 Feb 2023 13:03:06 -0800 Subject: [ih] Running long-term archives of this list? In-Reply-To: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> References: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> Message-ID: Hi, all, I?ve looked into this before. The obvious choice would be the Computer History Museum, but they didn?t know what I was asking for the last time I tried them. Very few places actually run true museum-quality backups or storage of ANYTHING (libraries are the exception). Even university archives don?t - they don?t separate acid-free from not, etc. And nobody moves data from medium to medium as it evolves, i.e., so we can read things in the future without needing a non-existent 9-track tape drive. If anyone finds a solution that?d work for free, please do keep me posted. Until then, I figure we rely on the kindness of places like the Wayback Machine. Joe (list admin) ? Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Feb 13, 2023, at 8:27 AM, Dave Crocker via Internet-history wrote: > > Reflecting, once again, on the considerable depth and breadth of historical technical knowledge that is regularly demonstrated on this list, I'm wondering about how robustly is is archives and how easily the various archives can be accessed. > > Yes it's hosted by isoc, but I'm asking about long-term (museum-quality) data archival. (We tend to think of back and archive as the same, but they aren't.) > > Also note I cited 'running' which means that even this message should hit those long-term archives pretty quickly. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker at mastodon.social > > -- > 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 Mon Feb 13 13:03:52 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 14 Feb 2023 10:03:52 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: I gave my answer: TCP/IP came for free on Unix just when Unix was taking over the universe. We did "Interchange" solutions for email and file transfer at CERN. GIFT, the file transfer gateway, started in 1985; MINT, the mail interchange gateway, started in 1986. They were sinks for systems programmer and operational resource, and getting rid of them was the major driver for seeking a universal solution. By 1989, installing TCP/IP plus its apps everywhere was simpler and cheaper. > Today, it seems to me that IPV6 is still YANP. I really don't think so, because IPv4 really has run out of addresses and multiple layers of NAT are very, very painful. But the timescale is vastly different from what we anticipated in 1994, and we put too many features in IPv6. Regards Brian Carpenter On 14-Feb-23 08:40, Jack Haverty via Internet-history wrote: > (retransmission - first transmission 2 says ago apparently got lost > somewhere...) > > Thanks for all the observations about why TCP was a rare success story > in its momentous (momentumous?) battle with the installed base.? Lots of > good info and observations, but the root causes remain elusive to me at > least.?? Why could TCP/IPV4 annihilate all of the preexisting other > similar technologies? > > For example, I agree that many technologies have failed to be adopted > because of "lack of market demand".?? But why was there such a lack? > Did the creators of the technology not understand the market??? Did the > market change so fast that the technology was obsoleted as it was > released?? Was there some missing feature or difficult requirement that > made the technology unpalatable to the market??? Was the market > successfully made aware of the new technology and why they should care? > > TCP's notion of "internet" had competition.? For a while in the 1990 > timeframe, a popular notion was the "Global LAN", in which an > organization could interconnect its LANs at its various sites, forming a > composite "WLAN" or wide-area local area network.?? SNA, XNS, SPX, > Appletalk et al provided such a capability to form such a global LAN. > TCP/IP did the same thing, allowing LANs at widespread sites to be > interconnected to form an internet.? Router vendors created > "multiprotocol routers" to enable a mix of different "global" > technologies to utilize the same expensive communications circuits.? The > TCP/IP machinery survives to this day; all of the others have > disappeared.? They all competed in the same market conditions.? TCP > didn't just become one of the "top three" in the competitive space.?? It > became pretty much the ony one left standing.? Why did TCP/IP win? > > Second comment -- The metric of "adoption" when it's based on deployment > of the new or replacement technology doesn't seem appropriate - e.g., > the 30+% adoption of TCP/IP V6.? A better metric for evaluating how > successfully a "new release" is being adopted, IMHO, would be the metric > of the survival rate of the prior release - the one hopefully being > replaced.? In other words, a metric for the success of deployment of > IPV6 would be the diminishing rate of usage of IPV4. > > If a new technology is adopted at a certain rate, but the one it is > supposed to replace does not fade away, the new technology is just YANP > - Yet Another Network Protocol, making the operational system even more > complex and difficult to operate and maintain.? Today, it seems to me > that IPV6 is still YANP.? Many of the technologies defined in RFCs and > some category of Standard may also be stuck in YANP limbo. > > Last comment -- We have been discussing what happened historically to > cause what we see today.?? But perhaps equally important are things that > did not happen, and thereby helped TCP/IP in the battle.?? What was > important because it did not happen? > > I can relate one example from my personal experience.? I suspect there > were a lot of others over the decades. > > In 1990, I joined Oracle as "Internet Architect".? Oracle's customers > were global and involved in any industry you can imagine. Oracle's > mission was to provide database software that would run on whatever > computer, using whatever operating system, connected to whatever network > a customer had chosen.?? To deliver that software, we had a very unusual > kaleidoscopic computer center - instead of staid rows of blue, or red, > or black, or whatever colored equipment from the chosen IT vendor, we > had at least one of every kind of computer you could get.?? We also > operated our own corporate network, using multiprotocol routers (Cisco), > connecting our offices internationally.?? All of that was necessary to > build and test the software, to assure that it would in fact run on any > computer, and network, a customer might have.? Any (database) client > could interact with any (database) server over whatever kind of network > was involved. > > Running a multiprotocol network was not for the faint of heart. YANP on > steroids.? Our customers? increasingly had the same situation. When > prices fell far enough, they couldn't enforce a corporate network > standard for IT, but rather might discover Appletalk in Marketing, some > kind of PC LAN in Sales and Accounting, SNA in mainframe territory, > perhaps DECNET in Manufacturing, etc. > > This struck me as entirely analogous to the situation that motivated TCP > - too many different kinds of networks involved.? TCP bound them all > together into a cohesive supernetwork.?? TCP was "One protocol to rule > them all, one protocol to bind them" (did I get it right...?0 > > So we pursued a similar solution, following the lead of that ARPA > research and Bilbo Baggins.? Instead of "gateways" (aka "routers"), we > developed something we called an "Interchange".? This was simply > software that would run on some or just a few machines that had the > ability to use more than one network protocol (e.g., SPX and TCP). Every > network protocol had some mechanism for creating "reliable byte > streams".? The Interchange was a very simple "patch panel" that would > take serial connections from each side and "plug them together" to > create a composite "reliable serial byte-stream" from end to end.? By > going through Interchanges, a client on any network could interact with > a server on any other network.? So a client on an Appletalk machine > could utilize a database on a DECNET machine, possibly traversing a TCP > "backbone" along the way.?? For testing, we could set up such > configurations just using our own multiprotocol internet. > > This "Interchange" mechanism was called TNS, or Transparent Networking > Substrate, and enabled clients and servers to interact, no matter what > kind of computers or networks they were on. > > I recall being frequently accosted, e.g,. at Interop, by people who > wanted us to release TNS as a separate product and API, so that it could > be used for other kinds of interactions across a mix of networks - e.g., > transferring files from a PC on a LAN to an archival site on a > mainframe.?? We thought about it, but decided not to do it for a lot of > reasons.? We weren't a "network company" marketing protocol > implementations.?? We understood how database software in clients and > servers utilized the TNS, but undoubtedly lots of issues and problems > would arise when other kinds of interactions were tried over TNS. > Support knew how to troubleshoot database problems, but TNS problems > with other activities would add another dimension of idiosyncracies. > Lots of reasons, despite some indication of a market demand. > > So we never released TNS as a separate capability.?? But there was > nothing particularly secret about how it worked, and nothing patented, > so anybody could have created a similar "patch panel" mechanism.?? But > no one did, AFAIK. > > If such a TNS general capability had been available, would it have > disrupted TCP's battle to dominance, by removing many of the annoyances > inherent in multiprotocol installations?? Perhaps, perhaps not.? But it > seems that things that did not happen, like general availability of a > TNS, might be important historically. > > Restricted to database activity, the TNS capability that we did deploy > may even have helped TCP's advance.? With Interchanges, it was possible > for our customers to plan and execute a more orderly and controlled > transition to TCP.?? During interim and testing phases, Interchanges > could be used to maintain client-server connectivity as the underlying > networks were migrated to TCP.? The company could keep running, with no > potentially suicidal "Flag Days" to fear.? Corporations like such > methodical and careful approaches. > > IMHO, the 1980s and 1990s were a very complex period with lots of things > being done, and not done.?? The TNS story was likely just one example of > many. > > That's why I opined that some Historian may someday be able to sort it > all out. > > Hope this helps, > Jack Haverty > > > > > On 2/9/23 18:16, Jack Haverty via Internet-history wrote: >> On 2/9/23 14:57, Dave Crocker via Internet-history wrote: >>> Such is the lesson of installed base momentum. >> I agree - the installed base is a formidable obstacle to getting any >> kind of replacement propagated.?? Stagnation and fragmentation into >> silos seems to be the result, as players introduce a desired new >> technology into just the components that they can control. >> >> But I also wonder -- How did TCP overcome the momentum of the >> installed base? >> >> At the time, in the 1990ish timeframe, there was a huge installed base >> of network technology.?? Hundreds of thousands of computers utilizing >> networks based on SNA, SPX, XNS, Decnet, etc. etc. ? TCP existed, but >> was a small player, confined largely to the academic and research >> communities. >> >> But almost overnight, actually over just a few years, TCP became a >> real player, and then the dominant player, and by now all of the other >> technologies of that installed base have simply disappeared. The >> installed base of 1990 is gone without a trace.? Are there any >> computers anywhere still running those well-established >> technologies??? I haven't encountered any, but I wouldn't be surprised >> if some still existed.?? Perhaps something running Cobol somewhere. >> >> So how did TCP manage to blast through that momentum of the installed >> base, creating such a chaos in the collision??? And how did it do it >> so rapidly? >> >> Curiously, that collision of TCP with the installed base involved >> TCP/IP V4.?? TCP/IP V6 has come along and its been quite a few years >> in transition.?? It seems that the momentum of the installed base of >> TCP/IP V4 has blunted the adoption of TCP/IP V6.?? Why? What's different? >> >> A similar situation seems to exist in other network areas, e.g., the >> mechanisms of electronic mail that we've been discussing.? New >> technologies can get invented and documented, but often never get >> widely deployed.? Why??? What magic incantations were used to deploy >> TCP in the 1990s that have been apparently now lost. >> >> Perhaps some historian has some answers.... >> >> Jack From craig at tereschau.net Mon Feb 13 13:07:11 2023 From: craig at tereschau.net (Craig Partridge) Date: Mon, 13 Feb 2023 14:07:11 -0700 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <2A90F9DF-83D1-4B03-9777-14E9A5EB3FD3@comcast.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <2A90F9DF-83D1-4B03-9777-14E9A5EB3FD3@comcast.net> Message-ID: Hi John: Oh no, far more complicated than that. As I recall (and my memory on this is probably imperfect as I was young and learning and some things went over my head): - Bill rewrote the BBN TCP to make it more efficient. The BBN TCP used a function table that was indexed by connection state and TCP segment type (so you looked up the connection using the TCP/IP header, then grabbed the segment type, and called the indexed function along with the PCB and inbound segment). It made for tight and simple routines... but, as I recall, the VAX (the primary platform at the time) made function calls expensive, so Bill wanted a minimal number of function calls and produced long routines as a result (cf. tcp_input in 4.2BSD). - Bill (or someone) at Berkeley came up with the idea of sockets and the socket/bind/listen/connect API as they did not like /dev/tcp and ioctls (which BBN TCP used and which Dennis Ritchie independently came up with for System V UNIX). While ioctls and /dev/tcp may have fit the existing UNIX philosophy, having taught thousands of students in the 1990s sockets and had a few then encounter System V and say "ugh", Berkeley was probably right on this one. - Various innards of the BSD implementation were cribbed from the BBN TCP. A good example is mbufs -- invented by Rob Gurwitz when he ported an early TCP (Jack Haverty's???) to BSD. I seem to recall seeing a memo from Rob c. 1988 saying mbufs were a hack to solve an immediate porting problem and that he was surprised a better solution had not materialized. - The 4.1BSD BBN TCP was more stable than the 4.1c BSD (first socket) TCP and there was a period in which DARPA was (unhappily) funding both TCPs because many sites asked to have the BBN TCP so they could have reliable Internet connectivity. This lasted a certain number of years into 4.2BSD, but eventually went Berkeley's way. Craig On Mon, Feb 13, 2023 at 1:35 PM John Day wrote: > So Berkeley?s position was that they were to port the BBN implementation > bugs and all? > > And BBN is to blame for sockets? What a lost opportunity. > > The first Unix on the Net in 1975 didn?t do that. It used file_io. > > > > On Feb 13, 2023, at 15:28, Craig Partridge via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > HI Scott: > > > > Small nit. > > > > DARPA funded Berkeley to port the BBN Unix to BSD -- and Bill Joy chose > to > > reimplement and develop sockets. Much behind the scenes fighting ensued > (I > > was hired into that fight in 1983 when BBN concluded it needed to train > > someone to understand the BSD implementation). Led to various odd > > conversations years later -- I remember Van Jacobson justifying a TCP bug > > in the BSD implementation by saying it had been in the BBN implementation > > that Bill used as a reference -- c. 1989, long after BBN BSD TCP was > gone. > > > > Craig > > > > On Mon, Feb 13, 2023 at 12:50 PM Scott Bradner via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> for what its worth - here is my take on some of the reasons that the > >> Internet (and specifically > >> TCP/IP) took over the world > >> > >> Forks: Decisions that got us the Internet we have > >> https://www.sobco.com/presentations/2020-06-25-forks.pdf > >> > >> Scott > >> (I, along with Scott Shackelford, have a book on the subject that should > >> be published at some > >> point - the text is done & now in publisher wait) > >> -- > >> 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 > > -- ***** Craig Partridge's email account for professional society activities and mailing lists. From enervatron at gmail.com Mon Feb 13 13:20:07 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 13:20:07 -0800 Subject: [ih] History of IoT In-Reply-To: References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> Message-ID: On 2/13/23 12:53 PM, Clem Cole wrote: > > > On Mon, Feb 13, 2023 at 3:01 PM Michael Thomas via Internet-history > wrote: > > Hi all, > > I've been trying to understand the history of what we'd now call the > Internet of Things. I know about the internet coke machine which > was in > about 1983 and then the internet toaster in around 1990. > > FWIW - The CMU Coke machine was in the mid 1970s and was the Arpanet > before the?Internet - so you are missing?at least 8-10 years. It was > definitely running in '76, but I think was earlier than that - Guy > Alms who was there a few years before me, probably remembers when Jim > Teter did the original hack (in PDP-11 assembler and BLISS BTW].. What I've seen is that it was 83, but maybe they are just talking post-flag day. > > Well the term 'toaster' actually came from the C89 standard work. It > was the crude term we used to discuss a cheap embedded device [if you > look at the standard C actually has two ways of being deployed - > hosted or embedded - but that's not the discussion here].? I also > suspect many of those people don't know about/had little first hand > experience with BLISS/ESPOL/BCPL etc - which all predated B and C as > they were 1960s/1970s technologies - plus few places other than > CMU/MIT/Standford would have had 'free' PDP-11 cycles for a hack like > that give the cost of the systems at those times (IIRC - the Coke > machine ran off the original CS Front-End) > > I think IoT community picked up the term Toaster from the C89 work and > frankly, many folks?were ignorant of the work that predated it when > using $10-$30K Minicomputers, much less the $.5K-$1K microcomputers of > the 1970s.? Also remember the per host for an IMP connection in the > 1970s was huge - in the order of $100K-$150K / yr for each host [paid > for as part of your Arpa contract]. From my scrounging around, it seems that the toaster debuted at the 1990 Interop to big fanfare and called the first internet of things example, even though that phrase didn't come until later and seemingly ignores the coke machine guys which I really don't understand. But all of these definitions are rather fuzzy. LSI/11's were used extensively for controlling and monitoring stuff, but were they "embedded"? They ran standard off the shelf DEC OS's (and Unix, I think), so that's not exactly what I think of as embedded. > > > My personal stake -- and the reason for my curiosity -- is that I > designed the software for an ethernet enabled laser printer in the > mid > 80's which is very likely to be the first (I'd be happy to hear > otherwise) for a printer. > > Hmmmm - the printers at CMU/Stanford/MIT et al were networked in the > late 1970s. Also remember of course the network at PARC were also. > In fact, my own introduction to TCP was when we were working on the > CMU distributed Front-End. It had been originally moved from the > single 11/20 [which ran the Coke machine] to a 'network of LSI-11 on a > 3M Xerox ethernet.? I was part of the group trying to move the system > to bunch of Intel 8086 cards in a multibus.? TCP was still yet to be > fully defined. Phil Karn (my Lab partner at the time) had started to > play with writing a TCP for his Z80 system - that would eventually > become his famous release.? [ We had the RFCs from that work]. But were they networked with the network stack on the device itself? I think that's the distinction. A networked printer could be moved to another room without having drag an LSI/11 along with it. Mike From enervatron at gmail.com Mon Feb 13 13:24:24 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 13:24:24 -0800 Subject: [ih] History of IoT In-Reply-To: References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> <8f9adfc3-e0b4-ccb7-9c12-cfe8733057d2@gmail.com> Message-ID: <54cb42aa-5d69-7af9-f75d-1ae7addce180@gmail.com> On 2/13/23 1:20 PM, Toerless Eckert wrote: > On Mon, Feb 13, 2023 at 01:01:54PM -0800, Michael Thomas wrote: >> Was your printer an IoT device? I'd say no: it was just using normal host >> protocols to do what it did locally in the first place (ie, lpr). And >> shoe-horning LPRd into the printer itself was painful because lpr expected a >> disk to buffer everything. As I mentioned, I almost trotted up to ISI >> because of it. > [Device - serial port - computer(device-compute,app-stack/tcp/ip)] - ethernet/Internet > > If this [] combination is not an IoT device in your opinion, then i would > say > 90% of whats today called IoT devices are not IoT devices in your > definition because they can all be decomposed in some device connected > via an internal serial/parallel port to some internal "computer" device. I replied in another comment that if you had to drag a probably racked LSI/11 along with whatever the device was to move it, that doesn't seem very embedded and or a Thing. IoT to me implies that it's part of an integrated whole. Mike From brian.e.carpenter at gmail.com Mon Feb 13 13:28:21 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 14 Feb 2023 10:28:21 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: Thanks Scott. I'd add international spread as a major feature, and that was strongly affected by Larry Landweber (and others) who spread the meme widely in academia. Also: "Tim Berners-Lee developed..." is a bit hero-worshippy. Actually, Tim Berners-Lee and Robert Cailliau developed and propagated the Web. Robert's part has been consistently undersold. For those who don't know it, these crucial points: ? Provided the protocol specifications for free ? Provided the software for free ? Did not patent any aspect were due to those who wrote the CERN Convention in 1953, specifying that the results of CERN research must be published: ?The Organization shall have no concern with work for military requirements and the results of its experimental and theoretical work shall be published or otherwise made generally available.? To my personal knowledge, Berners-Lee and Cailliau persuaded CERN management to allow the WWW release to the public domain on the basis of those words. (http://cds.cern.ch/record/1164399) Brian On 14-Feb-23 08:50, Scott Bradner via Internet-history wrote: > for what its worth - here is my take on some of the reasons that the Internet (and specifically > TCP/IP) took over the world > > Forks: Decisions that got us the Internet we have > https://www.sobco.com/presentations/2020-06-25-forks.pdf > > Scott > (I, along with Scott Shackelford, have a book on the subject that should be published at some > point - the text is done & now in publisher wait) From ocl at gih.com Mon Feb 13 13:40:51 2023 From: ocl at gih.com (=?UTF-8?Q?Olivier_MJ_Cr=c3=a9pin-Leblond?=) Date: Mon, 13 Feb 2023 21:40:51 +0000 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <29CD3471-0AC8-403B-93B1-D7924D604541@comcast.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <29CD3471-0AC8-403B-93B1-D7924D604541@comcast.net> Message-ID: On 10/02/2023 17:56, John Day via Internet-history wrote: > ATM was a bad idea the day it was proposed. It was unbelievable how many people were taken in by it. ATM saw glory in PPPoA in ADSL - https://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_ATM As for why TCP/IP won over OSI, my take is that at the time OSI stacks really worked for large mainframe computers. The advent of PCs & desktop machines that could run early TCP/IP stacks killed the OSI stack. Credit goes in particular to: - KA9Q - https://en.wikipedia.org/wiki/KA9Q (incidentally why is Phil Karn not in the Internet Hall of Fame?) - Microsoft implementing TCP/IP in Win95 - Novell NetWare TCP/IP support in the early 90s & its NE2000 card (& compatibles) Mainframes lost the game and along did OSI. Best, Olivier From vgcerf at gmail.com Mon Feb 13 13:52:41 2023 From: vgcerf at gmail.com (vinton cerf) Date: Mon, 13 Feb 2023 16:52:41 -0500 Subject: [ih] Running long-term archives of this list? In-Reply-To: References: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> Message-ID: Carnegie-Mellon has an archive - check with Raj Reddy? v On Mon, Feb 13, 2023 at 4:03 PM touch--- via Internet-history < internet-history at elists.isoc.org> wrote: > Hi, all, > > I?ve looked into this before. The obvious choice would be the Computer > History Museum, but they didn?t know what I was asking for the last time I > tried them. > > Very few places actually run true museum-quality backups or storage of > ANYTHING (libraries are the exception). Even university archives don?t - > they don?t separate acid-free from not, etc. And nobody moves data from > medium to medium as it evolves, i.e., so we can read things in the future > without needing a non-existent 9-track tape drive. > > If anyone finds a solution that?d work for free, please do keep me posted. > Until then, I figure we rely on the kindness of places like the Wayback > Machine. > > Joe (list admin) > > ? > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com > > > On Feb 13, 2023, at 8:27 AM, Dave Crocker via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > Reflecting, once again, on the considerable depth and breadth of > historical technical knowledge that is regularly demonstrated on this list, > I'm wondering about how robustly is is archives and how easily the various > archives can be accessed. > > > > Yes it's hosted by isoc, but I'm asking about long-term (museum-quality) > data archival. (We tend to think of back and archive as the same, but they > aren't.) > > > > Also note I cited 'running' which means that even this message should > hit those long-term archives pretty quickly. > > > > d/ > > > > -- > > Dave Crocker > > Brandenburg InternetWorking > > bbiw.net > > mast:@dcrocker at mastodon.social > > > > -- > > 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 Feb 13 13:57:43 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 13:57:43 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <2A90F9DF-83D1-4B03-9777-14E9A5EB3FD3@comcast.net> Message-ID: <95bbf8a5-c3eb-ec94-fcf7-43ab4b9e4455@3kitty.org> Rob's Vax TCP was done from scratch IIRC.? I had written TCP for Unix on a PDP-11/40 (which AFAIK was the first Unix TCP).?? Because of the 11/40s hardware limitations, my TCP was written in PDP-11 assembler, using Jim Mathis' LSI-11 implementation from the Packet Radio work at SRI as a model and source of code fragments.?? I still have a listing. With the 11/40 constraints, TCP code wouldn't fit into the kernel so I designed it as a user process.?? That surfaced some issues in Unix design, in particular in the facilities "pipes" provided (and Rand's "ports" which were extensions of pipes for interprocess communications).?? There was no way we could find for a user process to sleep waiting for a wakeup from any of several possible inputs. That motivated the definition of two new Unix system calls, "await" and "capac", which were minimalistic because they had to fit in the extremely limited kernel memory space.?? We even visited Bell Labs to talk with Ritchie while figuring out how to implement TCP in Unix. Those new system calls were documented and published -- *Haverty*, JF, and *Rettberg*, RD,'Inter-process communications for a server in***UNIX*',? in COMPCON Fall 78 (September, 1978): pp. 312-15.?? I can't seem to find such ancient conference proceedings online today, but Google knows about it: https://www.google.com/books/edition/Proceedings_Compcon/Mf1VAAAAMAAJ?hl=en&gbpv=0&kptab=overview That work was available to Rob while he was implementing Vax TCP, as well as to Mike Wingfield, who was implementing TCP for PDP-11/70 under a contract with DCEC (engineering arm of DCA).?? For a while, all of these machines were housed in the same computer room/lab, connected to an in-house IMP network, which made brainstorming and testing pretty easy.?? Also juggling practice, something to do for a few minutes while waiting for the compile or assembly process to complete. My 11/40 TCP had little value for the future since such limited machines as the 11/40 were being replaced by more powerful machines.? But Rob's work was all provided to Berkeley for their use in BSD.?? I never heard whether or how they used it.? I was the contractor-side point man for the ARPA contract that funded all of this work, and ARPA had decided to consolidate its Unix OS efforts and focus on BSD.?? The "await" and "capac" system calls were a minimalist implementation of what sockets later provided on more powerful hardware. Jack On 2/13/23 13:07, Craig Partridge via Internet-history wrote: > Hi John: > > Oh no, far more complicated than that. As I recall (and my memory on this > is probably imperfect as I was young and learning and some things went over > my head): > > > - Bill rewrote the BBN TCP to make it more efficient. The BBN TCP used > a function table that was indexed by connection state and TCP segment type > (so you looked up the connection using the TCP/IP header, then grabbed the > segment type, and called the indexed function along with the PCB and > inbound segment). It made for tight and simple routines... but, as I > recall, the VAX (the primary platform at the time) made function calls > expensive, so Bill wanted a minimal number of function calls and produced > long routines as a result (cf. tcp_input in 4.2BSD). > - Bill (or someone) at Berkeley came up with the idea of sockets and the > socket/bind/listen/connect API as they did not like /dev/tcp and ioctls > (which BBN TCP used and which Dennis Ritchie independently came up with for > System V UNIX). While ioctls and /dev/tcp may have fit the existing UNIX > philosophy, having taught thousands of students in the 1990s sockets and > had a few then encounter System V and say "ugh", Berkeley was probably > right on this one. > - Various innards of the BSD implementation were cribbed from the BBN > TCP. A good example is mbufs -- invented by Rob Gurwitz when he ported an > early TCP (Jack Haverty's???) to BSD. I seem to recall seeing a memo from > Rob c. 1988 saying mbufs were a hack to solve an immediate porting problem > and that he was surprised a better solution had not materialized. > - The 4.1BSD BBN TCP was more stable than the 4.1c BSD (first socket) > TCP and there was a period in which DARPA was (unhappily) funding both TCPs > because many sites asked to have the BBN TCP so they could have reliable > Internet connectivity. This lasted a certain number of years into 4.2BSD, > but eventually went Berkeley's way. > > Craig > > On Mon, Feb 13, 2023 at 1:35 PM John Day wrote: > >> So Berkeley?s position was that they were to port the BBN implementation >> bugs and all? >> >> And BBN is to blame for sockets? What a lost opportunity. >> >> The first Unix on the Net in 1975 didn?t do that. It used file_io. >> >> >>> On Feb 13, 2023, at 15:28, Craig Partridge via Internet-history < >> internet-history at elists.isoc.org> wrote: >>> HI Scott: >>> >>> Small nit. >>> >>> DARPA funded Berkeley to port the BBN Unix to BSD -- and Bill Joy chose >> to >>> reimplement and develop sockets. Much behind the scenes fighting ensued >> (I >>> was hired into that fight in 1983 when BBN concluded it needed to train >>> someone to understand the BSD implementation). Led to various odd >>> conversations years later -- I remember Van Jacobson justifying a TCP bug >>> in the BSD implementation by saying it had been in the BBN implementation >>> that Bill used as a reference -- c. 1989, long after BBN BSD TCP was >> gone. >>> Craig >>> >>> On Mon, Feb 13, 2023 at 12:50 PM Scott Bradner via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>> >>>> for what its worth - here is my take on some of the reasons that the >>>> Internet (and specifically >>>> TCP/IP) took over the world >>>> >>>> Forks: Decisions that got us the Internet we have >>>> https://www.sobco.com/presentations/2020-06-25-forks.pdf >>>> >>>> Scott >>>> (I, along with Scott Shackelford, have a book on the subject that should >>>> be published at some >>>> point - the text is done & now in publisher wait) >>>> -- >>>> 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 jack at 3kitty.org Mon Feb 13 14:07:58 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 14:07:58 -0800 Subject: [ih] Running long-term archives of this list? In-Reply-To: References: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> Message-ID: <43b6c275-76fd-048b-9df0-8bf3841e97ed@3kitty.org> Yesterday I read a story about Google's small army of employees with yellow badges tasked with methodically scanning books in various libraries' collections to create a comprehensive digital archive, which unfortunately couldn't be available to the public for various reasons such as legal constaints of copyright et al.?? I assume it's all well archived and backed up. Perhaps we just need to publish the archives as a book.??? I suggest "Hairy Totter and the Denizens of The Internet". Jack On 2/13/23 13:52, vinton cerf via Internet-history wrote: > Carnegie-Mellon has an archive - check with Raj Reddy? > > v > > > On Mon, Feb 13, 2023 at 4:03 PM touch--- via Internet-history < > internet-history at elists.isoc.org> wrote: > >> Hi, all, >> >> I?ve looked into this before. The obvious choice would be the Computer >> History Museum, but they didn?t know what I was asking for the last time I >> tried them. >> >> Very few places actually run true museum-quality backups or storage of >> ANYTHING (libraries are the exception). Even university archives don?t - >> they don?t separate acid-free from not, etc. And nobody moves data from >> medium to medium as it evolves, i.e., so we can read things in the future >> without needing a non-existent 9-track tape drive. >> >> If anyone finds a solution that?d work for free, please do keep me posted. >> Until then, I figure we rely on the kindness of places like the Wayback >> Machine. >> >> Joe (list admin) >> >> ? >> Dr. Joe Touch, temporal epistemologist >> www.strayalpha.com >> >>> On Feb 13, 2023, at 8:27 AM, Dave Crocker via Internet-history < >> internet-history at elists.isoc.org> wrote: >>> Reflecting, once again, on the considerable depth and breadth of >> historical technical knowledge that is regularly demonstrated on this list, >> I'm wondering about how robustly is is archives and how easily the various >> archives can be accessed. >>> Yes it's hosted by isoc, but I'm asking about long-term (museum-quality) >> data archival. (We tend to think of back and archive as the same, but they >> aren't.) >>> Also note I cited 'running' which means that even this message should >> hit those long-term archives pretty quickly. >>> d/ >>> >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>> mast:@dcrocker at mastodon.social >>> >>> -- >>> 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 brian.e.carpenter at gmail.com Mon Feb 13 14:13:32 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 14 Feb 2023 11:13:32 +1300 Subject: [ih] History of IoT In-Reply-To: References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> Message-ID: <088c737d-2eb4-139c-5ace-d3c62bd367b6@gmail.com> Semantics question: are you asking about *Internet* of things, or *network* of things? Networks of things go back to the early 1970s at least**. I worked in process control then and one of the things we were controlling was the (original) CERN proton synchrotron. A few years later we put microprocessors in distributed CAMAC crates and controlled things by the hundreds. But if it's strictly *Internet*, it couldn't predate 1/1/1983, could it? ** You could make a case that SAGE was a network of things, starting in about 1958. Regards Brian Carpenter On 14-Feb-23 10:20, Michael Thomas via Internet-history wrote: > > On 2/13/23 12:53 PM, Clem Cole wrote: >> >> >> On Mon, Feb 13, 2023 at 3:01 PM Michael Thomas via Internet-history >> wrote: >> >> Hi all, >> >> I've been trying to understand the history of what we'd now call the >> Internet of Things. I know about the internet coke machine which >> was in >> about 1983 and then the internet toaster in around 1990. >> >> FWIW - The CMU Coke machine was in the mid 1970s and was the Arpanet >> before the?Internet - so you are missing?at least 8-10 years. It was >> definitely running in '76, but I think was earlier than that - Guy >> Alms who was there a few years before me, probably remembers when Jim >> Teter did the original hack (in PDP-11 assembler and BLISS BTW].. > What I've seen is that it was 83, but maybe they are just talking > post-flag day. >> >> Well the term 'toaster' actually came from the C89 standard work. It >> was the crude term we used to discuss a cheap embedded device [if you >> look at the standard C actually has two ways of being deployed - >> hosted or embedded - but that's not the discussion here].? I also >> suspect many of those people don't know about/had little first hand >> experience with BLISS/ESPOL/BCPL etc - which all predated B and C as >> they were 1960s/1970s technologies - plus few places other than >> CMU/MIT/Standford would have had 'free' PDP-11 cycles for a hack like >> that give the cost of the systems at those times (IIRC - the Coke >> machine ran off the original CS Front-End) >> >> I think IoT community picked up the term Toaster from the C89 work and >> frankly, many folks?were ignorant of the work that predated it when >> using $10-$30K Minicomputers, much less the $.5K-$1K microcomputers of >> the 1970s.? Also remember the per host for an IMP connection in the >> 1970s was huge - in the order of $100K-$150K / yr for each host [paid >> for as part of your Arpa contract]. > From my scrounging around, it seems that the toaster debuted at the > 1990 Interop to big fanfare and called the first internet of things > example, even though that phrase didn't come until later and seemingly > ignores the coke machine guys which I really don't understand. But all > of these definitions are rather fuzzy. LSI/11's were used extensively > for controlling and monitoring stuff, but were they "embedded"? They ran > standard off the shelf DEC OS's (and Unix, I think), so that's not > exactly what I think of as embedded. >> >> >> My personal stake -- and the reason for my curiosity -- is that I >> designed the software for an ethernet enabled laser printer in the >> mid >> 80's which is very likely to be the first (I'd be happy to hear >> otherwise) for a printer. >> >> Hmmmm - the printers at CMU/Stanford/MIT et al were networked in the >> late 1970s. Also remember of course the network at PARC were also. >> In fact, my own introduction to TCP was when we were working on the >> CMU distributed Front-End. It had been originally moved from the >> single 11/20 [which ran the Coke machine] to a 'network of LSI-11 on a >> 3M Xerox ethernet.? I was part of the group trying to move the system >> to bunch of Intel 8086 cards in a multibus.? TCP was still yet to be >> fully defined. Phil Karn (my Lab partner at the time) had started to >> play with writing a TCP for his Z80 system - that would eventually >> become his famous release.? [ We had the RFCs from that work]. > But were they networked with the network stack on the device itself? I > think that's the distinction. A networked printer could be moved to > another room without having drag an LSI/11 along with it. > > Mike > From enervatron at gmail.com Mon Feb 13 14:21:51 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 14:21:51 -0800 Subject: [ih] History of IoT In-Reply-To: <088c737d-2eb4-139c-5ace-d3c62bd367b6@gmail.com> References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> <088c737d-2eb4-139c-5ace-d3c62bd367b6@gmail.com> Message-ID: <7b07fc48-316f-66c6-853a-77fd7ae2564c@gmail.com> On 2/13/23 2:13 PM, Brian E Carpenter via Internet-history wrote: > Semantics question: are you asking about *Internet* of things, or > *network* of things? Definitely Internet of Things. > > Networks of things go back to the early 1970s at least**. I worked > in process control then and one of the things we were controlling > was the (original) CERN proton synchrotron. A few years later > we put microprocessors in distributed CAMAC crates and controlled > things by the hundreds. > > But if it's strictly *Internet*, it couldn't predate 1/1/1983, > could it? I suppose if you define it is as post flag day. The one thing I haven't gotten clarity on is whether the internet coke machine was just some sensor hardware that was just attached to a regular host in those days. What's occurring to me is that that might be what the distinction was being made with the toaster which was standalone, which seems valid. It might explain why other knock ons aren't really considered IoT since they would have very likely followed the host+gadgets kind of setup. PC's with the gadgets duct taped to them probably is more gray area. Mike From masinter at gmail.com Mon Feb 13 14:45:53 2023 From: masinter at gmail.com (Larry Masinter) Date: Mon, 13 Feb 2023 14:45:53 -0800 Subject: [ih] History of IoT In-Reply-To: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> Message-ID: <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> Look at the references for RFC 2324 (which might itself be the first IoT RFC not sure). I tried to find references for such things. At the time PARC had an initiative Mark Weiser called Ubiquitous Computing? which involved networking lots of things? and might be a better name or at least more evocative of why you might want such a thing and a big address space and likely the justification of participation with IPv6. -- LarryMasinter.net > On Feb 13, 2023, at 12:01 PM, Michael Thomas via Internet-history wrote: > > much of a hack as the toaster. From masinter at gmail.com Mon Feb 13 14:59:39 2023 From: masinter at gmail.com (Larry Masinter) Date: Mon, 13 Feb 2023 14:59:39 -0800 Subject: [ih] History of IoT In-Reply-To: <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> References: <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> Message-ID: <85EA1315-E31D-4AA5-BCBB-C79EDB5F7EE3@gmail.com> Also https://larrymasinter.net/0103-ipac-history.pdf for a 2001 IETF talk on the topic for a BOF -- LarryMasinter.net > On Feb 13, 2023, at 2:46 PM, Larry Masinter wrote: > > ?Look at the references for RFC 2324 (which might itself be the first IoT RFC not sure). > > I tried to find references for such things. > > At the time PARC had an initiative Mark Weiser called Ubiquitous Computing? which involved networking lots of things? and might be a better name or at least more evocative of why you might want such a thing and a big address space and likely the justification of participation with IPv6. > > -- > LarryMasinter.net > >> On Feb 13, 2023, at 12:01 PM, Michael Thomas via Internet-history wrote: >> >> much of a hack as the toaster. From bpurvy at gmail.com Mon Feb 13 15:10:51 2023 From: bpurvy at gmail.com (Bob Purvy) Date: Mon, 13 Feb 2023 15:10:51 -0800 Subject: [ih] Running long-term archives of this list? In-Reply-To: <43b6c275-76fd-048b-9df0-8bf3841e97ed@3kitty.org> References: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> <43b6c275-76fd-048b-9df0-8bf3841e97ed@3kitty.org> Message-ID: Well, that was by me, Jack! Are you one of my subscribers? "Albert Cory" is my pen name. "Cory" is my niece's married name, and "Albert" was my dad's brother, who was killed on his very first day on the job at Swift & Co. in the Chicago stockyards. I don't make any attempt to "hide" my real name. Anyhow, it probably IS archived, since books take up a surprisingly small amount of storage. I really doubt that Internet mailing lists are anywhere in that block of storage. Those were already in electronic form and didn't need scanning. Although Google is by no means a "good guy" in everything, I think on this issue, they bent over backwards to find some solution that was fair to authors, *especially* the ones who are dead and no current owner can be found. On Mon, Feb 13, 2023 at 2:08 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > Yesterday I read a story about Google's small army of employees with > yellow badges tasked with methodically scanning books in various > libraries' collections to create a comprehensive digital archive, which > unfortunately couldn't be available to the public for various reasons > such as legal constaints of copyright et al. I assume it's all well > archived and backed up. > > Perhaps we just need to publish the archives as a book. I suggest > "Hairy Totter and the Denizens of The Internet". > > Jack > > > On 2/13/23 13:52, vinton cerf via Internet-history wrote: > > Carnegie-Mellon has an archive - check with Raj Reddy? > > > > v > > > > > > On Mon, Feb 13, 2023 at 4:03 PM touch--- via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> Hi, all, > >> > >> I?ve looked into this before. The obvious choice would be the Computer > >> History Museum, but they didn?t know what I was asking for the last > time I > >> tried them. > >> > >> Very few places actually run true museum-quality backups or storage of > >> ANYTHING (libraries are the exception). Even university archives don?t - > >> they don?t separate acid-free from not, etc. And nobody moves data from > >> medium to medium as it evolves, i.e., so we can read things in the > future > >> without needing a non-existent 9-track tape drive. > >> > >> If anyone finds a solution that?d work for free, please do keep me > posted. > >> Until then, I figure we rely on the kindness of places like the Wayback > >> Machine. > >> > >> Joe (list admin) > >> > >> ? > >> Dr. Joe Touch, temporal epistemologist > >> www.strayalpha.com > >> > >>> On Feb 13, 2023, at 8:27 AM, Dave Crocker via Internet-history < > >> internet-history at elists.isoc.org> wrote: > >>> Reflecting, once again, on the considerable depth and breadth of > >> historical technical knowledge that is regularly demonstrated on this > list, > >> I'm wondering about how robustly is is archives and how easily the > various > >> archives can be accessed. > >>> Yes it's hosted by isoc, but I'm asking about long-term > (museum-quality) > >> data archival. (We tend to think of back and archive as the same, but > they > >> aren't.) > >>> Also note I cited 'running' which means that even this message should > >> hit those long-term archives pretty quickly. > >>> d/ > >>> > >>> -- > >>> Dave Crocker > >>> Brandenburg InternetWorking > >>> bbiw.net > >>> mast:@dcrocker at mastodon.social > >>> > >>> -- > >>> 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 > From enervatron at gmail.com Mon Feb 13 15:15:44 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 15:15:44 -0800 Subject: [ih] History of IoT In-Reply-To: <85EA1315-E31D-4AA5-BCBB-C79EDB5F7EE3@gmail.com> References: <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> <85EA1315-E31D-4AA5-BCBB-C79EDB5F7EE3@gmail.com> Message-ID: <814b6487-497c-db11-3f9f-43d07ed6d7f0@gmail.com> On 2/13/23 2:59 PM, Larry Masinter wrote: > Also https://larrymasinter.net/0103-ipac-history.pdf?for a 2001 IETF > talk on the topic for a BOF What I'm mostly interested in is what came before the toaster. Even if the internet coke machine in the early 80's wasn't what we'd call an IoT device (i really need to hunt down more info on it), it seems really unlikely that there would be a 7 year gap that nothing happening (modulo that we were working on it before 1990). I mean, young engineers love hacks like those. Mike > > -- > LarryMasinter.net > >> On Feb 13, 2023, at 2:46 PM, Larry Masinter wrote: >> >> ?Look at the references for RFC 2324 (which might itself be the first >> IoT RFC not sure). >> >> I tried to find references for such things. >> >> At the time PARC had an initiative Mark Weiser called Ubiquitous >> Computing? which involved networking lots of things? and might be a >> better name or at least more evocative of why you might want such a >> thing and a big address space and likely the justification of >> participation with IPv6. >> >> -- >> LarryMasinter.net >> >>> On Feb 13, 2023, at 12:01 PM, Michael Thomas via Internet-history >>> wrote: >>> >>> much of a hack as the toaster. From dhc at dcrocker.net Mon Feb 13 15:34:31 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 13 Feb 2023 15:34:31 -0800 Subject: [ih] History of IoT In-Reply-To: <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> Message-ID: <1289f0b4-e9e5-c9d8-4b8b-04562613bb1f@dcrocker.net> On 2/13/2023 2:45 PM, Larry Masinter via Internet-history wrote: > Look at the references for RFC 2324 (which might itself be the first IoT RFC not sure). Somewhere in the latter 1980s, Jeff Case used SNMP to monitor and respond to excessive noise from a neighboring exhibitor. The response to to send back to them the sound they were producing, at a slightly higher volume and with s slight time delay.? If was quite effective. But I thought Stanford had a vending machine attached, with Louie's pot stickers and with cigarettes, among other things. And I thought that was in the 70s.? Maybe mid 1980s. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From enervatron at gmail.com Mon Feb 13 15:36:28 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 15:36:28 -0800 Subject: [ih] History of IoT In-Reply-To: References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> <8f9adfc3-e0b4-ccb7-9c12-cfe8733057d2@gmail.com> Message-ID: <92485331-c19a-1fd8-5142-b82896f5f2da@gmail.com> On 2/13/23 1:20 PM, Toerless Eckert wrote: > On Mon, Feb 13, 2023 at 01:01:54PM -0800, Michael Thomas wrote: >> Was your printer an IoT device? I'd say no: it was just using normal host >> protocols to do what it did locally in the first place (ie, lpr). And >> shoe-horning LPRd into the printer itself was painful because lpr expected a >> disk to buffer everything. As I mentioned, I almost trotted up to ISI >> because of it. > [Device - serial port - computer(device-compute,app-stack/tcp/ip)] - ethernet/Internet > > If this [] combination is not an IoT device in your opinion, then i would > say > 90% of whats today called IoT devices are not IoT devices in your > definition because they can all be decomposed in some device connected > via an internal serial/parallel port to some internal "computer" device. Checking again on the internet coke machine, apparently the sensors were backhauled to a main computer which did the networking. Unsurprising for 1982. According to the article I quote below, they never actually updated it to IP, so I guess it's technically true that it wasn't the first (though, it's still really important since it showed "gosh lookie here, the internet can be used for more than endless email flame wars!" But yes, if you want to make that the definition you'd be correct but I think there's more to it than that. I think IoT implies some amount of purpose built to it. The toaster was obviously purpose built. Certainly the laser printer I designed was purpose built. The struggles I had with lprd were mainly because it was intended to go to a normal host with disk, etc not directly to the printer itself. So yeah, I think that's different. https://www.ibm.com/blogs/industries/little-known-story-first-iot-device/ Mike From jack at 3kitty.org Mon Feb 13 15:36:49 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 15:36:49 -0800 Subject: [ih] Running long-term archives of this list? In-Reply-To: References: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> <43b6c275-76fd-048b-9df0-8bf3841e97ed@3kitty.org> Message-ID: <363e6964-ef54-b990-e65f-e7b000f4fbd8@3kitty.org> Yep, I subscribed.?? Good stories, really convey the internal "feel" of Silicon Valley and High Tech.? I like historical tales written by someone who was actually there. I didn't know whether or not you wanted the exposure of internet-history (which I suspect has a lot of lurkers).? But now that I know you don't mind ... here's the episode I mentioned in my prior post: https://albertcory50.substack.com/p/working-at-google-maps Yes, the internet-history archives are already digitized.? But it shouldn't be too difficult for someone to write a script to go through all the pieces of the archives and concatenate them into a text file, with chapters titled by the dates involved.? Print it out, leave it on Google's doorstep, and it might be preserved for future historians.?? Perhaps also offer it for sale on Amazon as a print-on-demand book, so AWS will preserve a second copy? Jack On 2/13/23 15:10, Bob Purvy wrote: > Well, that was by me, Jack!? Are you one of my subscribers? > > "Albert Cory" is my pen name. "Cory" is my niece's married name, and > "Albert" was my dad's brother, who was killed on his very first day on > the job at Swift & Co. in the Chicago stockyards. I don't make any > attempt to "hide" my real name. > > Anyhow, it probably IS archived, since books take up a surprisingly > small amount of storage. I really doubt that Internet mailing lists > are anywhere in that block of storage. Those were already in > electronic form and didn't need scanning. > > Although Google is by no means a "good guy" in everything, I think on > this issue, they bent over backwards to find some solution that was > fair to authors, /especially/?the ones who are dead and no current > owner can be found. > > On Mon, Feb 13, 2023 at 2:08 PM Jack Haverty via Internet-history > wrote: > > Yesterday I read a story about Google's small army of employees with > yellow badges tasked with methodically scanning books in various > libraries' collections to create a comprehensive digital archive, > which > unfortunately couldn't be available to the public for various reasons > such as legal constaints of copyright et al.?? I assume it's all well > archived and backed up. > > Perhaps we just need to publish the archives as a book.??? I suggest > "Hairy Totter and the Denizens of The Internet". > > Jack > > > On 2/13/23 13:52, vinton cerf via Internet-history wrote: > > Carnegie-Mellon has an archive - check with Raj Reddy? > > > > v > > > > > > On Mon, Feb 13, 2023 at 4:03 PM touch--- via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> Hi, all, > >> > >> I?ve looked into this before. The obvious choice would be the > Computer > >> History Museum, but they didn?t know what I was asking for the > last time I > >> tried them. > >> > >> Very few places actually run true museum-quality backups or > storage of > >> ANYTHING (libraries are the exception). Even university > archives don?t - > >> they don?t separate acid-free from not, etc. And nobody moves > data from > >> medium to medium as it evolves, i.e., so we can read things in > the future > >> without needing a non-existent 9-track tape drive. > >> > >> If anyone finds a solution that?d work for free, please do keep > me posted. > >> Until then, I figure we rely on the kindness of places like the > Wayback > >> Machine. > >> > >> Joe (list admin) > >> > >> ? > >> Dr. Joe Touch, temporal epistemologist > >> www.strayalpha.com > >> > >>> On Feb 13, 2023, at 8:27 AM, Dave Crocker via Internet-history < > >> internet-history at elists.isoc.org> wrote: > >>> Reflecting, once again, on the? considerable depth and breadth of > >> historical technical knowledge that is regularly demonstrated > on this list, > >> I'm wondering about how robustly is is archives and how easily > the various > >> archives can be accessed. > >>> Yes it's hosted by isoc, but I'm asking about long-term > (museum-quality) > >> data archival.? (We tend to think of back and archive as the > same, but they > >> aren't.) > >>> Also note I cited 'running' which means that even this message > should > >> hit those long-term archives pretty quickly. > >>> d/ > >>> > >>> -- > >>> Dave Crocker > >>> Brandenburg InternetWorking > >>> bbiw.net > >>> mast:@dcrocker at mastodon.social > >>> > >>> -- > >>> 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 > From jack at 3kitty.org Mon Feb 13 16:02:59 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 16:02:59 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> Message-ID: IMHO, "buffer bloat" is a consequence of the use of "congestion avoidance" as an interim tactic, adopted in the early Internet research days to buy some time to figure out how to do "congestion control" in the Internet, experimenting with and defining protocols and algorithms for inclusion in TCP/IP V4's descendant.?? That was on the IAB (then ICCB) list of "things we need to work on" back in 1983 or so. "Buffer bloat" is a consequence of continuing in a "congestion avoidance" design, made easier as fiber, memory and processor prices plummeted.? It became easy to avoid congestion by adding more resources, with the unfortunate consequences on traffic latency. Congestion control is a hard problem, and permeates the entire network as a system level issue.? In the Internet, that system includes the "switches" of all kinds as well as the "hosts".?? The ARPANET research on congestion control tackled this problem when it was all contained within the IMPs algorithms and mechanisms.? It seems it is much more difficult with TCP, when you have to include mechanisms in all of the computers attached to networks - and now there are likely billions of them, as well as many players involved in the design and implementation of the components. Jack On 2/13/23 13:01, Steve Crocker wrote: > In my view, the answer to 'Has "Congestion Control" in the > Internetbeen solved?' is clearly no. I view bufferbloat as one > important part of the?congestion control problem. > > Steve > > > On Mon, Feb 13, 2023 at 3:44 PM Jack Haverty via Internet-history > wrote: > > It seems that I didn't receive some messages over the > weekend....sorry > if anyone has already noted what I say below. > > Re the ARPANET and Congestion Control:?? This was definitely a hot > topic, in particular after DCA took over operations and the > network grew > in size.?? There were DCA-managed contracts to rework the internal > mechanisms of the ARPANET to handle the much larger and diverse > networks > of IMPs that evolved into the multiple IMP-based networks called the > DDN.?? Congestion control was just one issue of several that > interacted, > e.g., routing, flow control, retransmission, buffer management, etc. > The IMP design, although a "packet network", in effect had a "serial > byte stream" mechanism internally to make sure all data got from > source > host to destination.? The ARPANET had the equivalent of parts of a > TCP > built inside the IMPs to guarantee the delivery of a data stream. > > I'm not sure how much historical detail you'll find in traditionally > published papers and journals.?? Outside of academia that wasn't a > priority.? But there were extensive and detailed reports prepared as > part of the ARPANET "operations" contracts and delivered to DCA. > Here's > one 3-volume, multi-year example that discusses a lot of the work > in the > early 80s on "congestion control" and new internal IMP mechanisms in > general: > > https://apps.dtic.mil/sti/citations/ADA053450 > https://apps.dtic.mil/sti/citations/ADA086338 > https://apps.dtic.mil/sti/citations/ADA121350 > > There's hundreds of pages of detail in those reports and there are > others available through DTiC.?? I was listed as author on some of > these, because at the time that contract was one of "my" contracts -- > which meant that I had to make sure that the report got written and > delivered so we would get paid.?? I didn't personally work on the > ARPANET technical research, but I did absorb some understanding of > the > issues and details.? The "IMP Group" was literally just down the hall. > > At the time (early 1980s), I was involved in the early Internet work, > when TCP/IP V4 was being created and the various flow and congestion > control mechanisms were being defined.? From the ARPANET > experience, it > was clear to me that the IMP gurus "down the hall" at BBN viewed > congestion control as a major issue, and that sometimes surfaced as > statements such as "TCP will never work".? TCP didn't address any > of the > issues of congestion, except by the rudimentary and unproven > mechanism > of "Source Quench". > > The expectation was that the Internet would work if congestion was > avoided rather than controlled, which could be attempted by keeping > network capacity above traffic demands, at least long enough that > TCP's > retransmission and backoff mechanisms in the hosts would throttle > down > as expected to match what the network substrate was capable of > carrying > at the time.?? Of course those mechanisms were now distributed > among the > several hosts and network switches (e.g., IMPs, Packet Radios, > computer > OS, gateways) involved, designed, built, and managed by different > organizaions, which made it challenging to predict how it would > all behave. > > Even today, as an end user, I can't tell if "congestion control" is > implemented and working well, or if congestion is just mostly being > avoided by deployment of lots of fiber and lots of buffer memory > in all > the switching locations where congestion might be expected. That of > course results in the phenomenon of "buffer bloat".?? That's another > question for the Historians.? Has "Congestion Control" in the > Internet > been solved?? Or avoided? > > Jack Haverty > > > > On 2/13/23 08:19, Craig Partridge via Internet-history wrote: > > On Sat, Feb 11, 2023 at 7:48 AM Noel Chiappa via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> > >>? ? ? > From: Craig Partridge > >> > >>? ? ? > We figured out congestion collapse well enough for the time > >> > >> It should be remembered that the ARPANET people (hi!) had > perhaps solved > >> this > >> problem a long time before. I'm trying to remember how > explicitly they saw > >> this as a separate problem from the issue of running out of > buffer space > >> for > >> message re-assembly at the destination IMP, but I seem to > recall that RFNMs > >> were seen as a needed throttle to prevent the network as a > whole from being > >> overrun (i.e. what we now think of as 'congestion', although > IIRC that term > >> wasn't used then), as well as flow control to the source host > (as we would > >> now call it). > >> > >> I don't recall exactly where I saw that, but I'd try the BBN > proposal to > >> DARPA's RFP, and the first JFIPS paper ("The interface message > processor > >> for > >> the ARPA computer network"). > >> > > I don't recall the details either, though I remember stories of > Bob Kahn > > going to LA to beat up on the first few ARPANET nodes > > because he anticipated various issues, I think including > congestion.? And > > he found them and fixes were made. > > > > But remember ARPANET was homogeneous -- same speed for each link > and a > > single control mechanism.? I think John Nagle was > > the first to point out ("On packet switches with infinite > storage") that > > connecting very different networks had its own challenges. > > And to my point, not something that a person working with X.25 > would have > > understood terribly well (yes X.75 gateways existed but > > they typically throttled the window size to 2 packets, which hid > a lot of > > issues). > > > > Craig > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From galmes at tamu.edu Mon Feb 13 16:32:59 2023 From: galmes at tamu.edu (Guy Almes) Date: Mon, 13 Feb 2023 19:32:59 -0500 Subject: [ih] History of IoT In-Reply-To: References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> Message-ID: <02bee092-8111-d7f3-b16c-c694d0b67f24@tamu.edu> Mike, Clem, et al., Check out for the truth. This shows the slipperiness of the IoT idea. The original CMU CS Coke machine hack was a very clever early-70s hardware/software hack motivated by the principle that if a hardworking CS grad student was going to spend 10 cents on a coke, s/he deserved a cold one. So, with an old-fashioned coke machine with columns of coke bottles, which column would have cold cokes. So the original hack was a program running on the PDP-10 system that anyone in the department had an account on, creatively referred to as CMUA. You'd access it by typing the command: r coke from the TOPS-10 command line. Clearly not yet an example of the IoT. Then, at some point in the late 1970s, Ivor Durham (a wonderful CS grad student from England) used the finger program (a wonderful contribution by Les Earnest) allow someone at another site to type something like: finger coke at cmua This is still ARPAnet time and finger would then find out the status of the CMU coke machine from any ARPAnet site, but the motivation was clearly for users on the CMU hosts other than CMUA. So you could interrogate the coke machine from anywhere on the ARPAnet, but still probably not IoT. The final step in having the coke machine itself be an Internet host occurred much later, probably about 1990, after the old-fashioned coke machine with its columns of coke bottles was gone. But this was clearly IoT, but equally clearly not among the first such. BTW, one minor piece of evidence of how the coke machine was integrated into the culture of CMU-CS relates to an early "star trek" type program that one could play in the terminal room. The screen would display the bridge of an imaginary space ship. The number of games that the 'user' had played in the current session was indicated by the number of empty coke bottles displayed on the bridge, with wins on one side and losses on the other. A subtle hint that the now-fully-cafenated grad student should get back to work. Ah, the sociology of the terminal room! -- Guy On 2/13/23 4:20 PM, Michael Thomas via Internet-history wrote: > On 2/13/23 12:53 PM, Clem Cole wrote: >> >> >> On Mon, Feb 13, 2023 at 3:01 PM Michael Thomas via Internet-history >> wrote: >> >> Hi all, >> >> I've been trying to understand the history of what we'd now call the >> Internet of Things. I know about the internet coke machine which >> was in >> about 1983 and then the internet toaster in around 1990. >> >> FWIW - The CMU Coke machine was in the mid 1970s and was the Arpanet >> before the?Internet - so you are missing?at least 8-10 years. It was >> definitely running in '76, but I think was earlier than that - Guy >> Alms who was there a few years before me, probably remembers when Jim >> Teter did the original hack (in PDP-11 assembler and BLISS BTW].. > What I've seen is that it was 83, but maybe they are just talking > post-flag day. >> >> ... > > Mike > > -- > Internet-history mailing list > Internet-history at elists.isoc.org >... From jack at 3kitty.org Mon Feb 13 16:46:15 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 16:46:15 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> IMHO by the early 90s, TCP had already won the competition, and organizations everywhere were working on transitioning to the Internet, or perhaps more commonly their own TCP-based corporate intranet, perhaps as a multiprotocol internet for a while.?? Other networking technologies still existed in the installed base, but TCP was getting all of the attention. The Web emergence in the mid 90s was possibly more a result of TCP's success in enabling universal connectivity rather than a cause of TCP's success.? Once it became obvious that TCP had "won", a company or technology vendor had to adapt to it, rather quickly, or die. There were earlier technologies that provided collaborative services similar to those of the Web.?? Lotus Notes is one I remember. Perhaps also services like Compuserve or LexisNexis.? IIRC, Notes was based on dial-up connections, not TCP.? IBM bought Lotus.?? I don't know if Notes became part of SNA.?? But they're both pretty much gone while the Web, based on TCP, explodes in size and reach. LexisNexis is still there, living on the Web. Jack On 2/13/23 13:03, Steven Ehrbar wrote: > On Mon, Feb 13, 2023 at 12:40 PM Jack Haverty via Internet-history > wrote: >> They all competed in the same market conditions. TCP >> didn't just become one of the "top three" in the competitive space. It >> became pretty much the ony one left standing. Why did TCP/IP win? > Because TCP/IP _didn't_ compete in the same market conditions. With > the World Wide Web/Mosaic/Netscape in the mid-90s, TCP/IP went out and > took over a completely different market than institutional networks, > the market for home computers users accessing public services. And > then all the personal computers in corporate networks had to be TCP/IP > enabled to access the public services being built for home users. > After which, the choice for corporations was no longer between using > TCP/IP or some other protocol in any given department; it was whether > they'd use TCP/IP or _both_ TCP/IP and some other protocol in any > given department. And while installed base meant a lot of companies > did the "both" for a while, the benefits of transitioning to just one > were obvious. From jack at 3kitty.org Mon Feb 13 16:59:31 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 16:59:31 -0800 Subject: [ih] History of IoT In-Reply-To: <02bee092-8111-d7f3-b16c-c694d0b67f24@tamu.edu> References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> <02bee092-8111-d7f3-b16c-c694d0b67f24@tamu.edu> Message-ID: My suspect for early IOT involving a bunch of "things" communicating over a network would be GM's MAP systems back in the early/mid 80s.?? See https://en.wikipedia.org/wiki/Manufacturing_Automation_Protocol Only big organizations with deep pockets could afford a large bunch of "things" to talk amongst themselves. Of course that work was based on Token Bus rather than Ethernet LANs, and ISO protocols rather than TCP.?? Not the best choices as history has shown, and MAP/TOP seems to have faded away.? So maybe it doesn't qualify as an "Internet Of Things". Jack On 2/13/23 16:32, Guy Almes via Internet-history wrote: > Mike, Clem, et al., > ? Check out for the > truth. > ? This shows the slipperiness of the IoT idea. > ? The original CMU CS Coke machine hack was a very clever early-70s > hardware/software hack motivated by the principle that if a > hardworking CS grad student was going to spend 10 cents on a coke, > s/he deserved a cold one.? So, with an old-fashioned coke machine with > columns of coke bottles, which column would have cold cokes. > ? So the original hack was a program running on the PDP-10 system that > anyone in the department had an account on, creatively referred to as > CMUA.? You'd access it by typing the command: > ????r coke > from the TOPS-10 command line. > > ? Clearly not yet an example of the IoT. > ? Then, at some point in the late 1970s, Ivor Durham (a wonderful CS > grad student from England) used the finger program (a wonderful > contribution by Les Earnest) allow someone at another site to type > something like: > ????finger coke at cmua > This is still ARPAnet time and finger would then find out the status > of the CMU coke machine from any ARPAnet site, but the motivation was > clearly for users on the CMU hosts other than CMUA. > ? So you could interrogate the coke machine from anywhere on the > ARPAnet, but still probably not IoT. > > ? The final step in having the coke machine itself be an Internet host > occurred much later, probably about 1990, after the old-fashioned coke > machine with its columns of coke bottles was gone. > ? But this was clearly IoT, but equally clearly not among the first such. > > ? BTW, one minor piece of evidence of how the coke machine was > integrated into the culture of CMU-CS relates to an early "star trek" > type program that one could play in the terminal room.? The screen > would display the bridge of an imaginary space ship.? The number of > games that the 'user' had played in the current session was indicated > by the number of empty coke bottles displayed on the bridge, with wins > on one side and losses on the other.? A subtle hint that the > now-fully-cafenated grad student should get back to work. > ? Ah, the sociology of the terminal room! > > ????-- Guy > > On 2/13/23 4:20 PM, Michael Thomas via Internet-history wrote: >> On 2/13/23 12:53 PM, Clem Cole wrote: >>> >>> >>> On Mon, Feb 13, 2023 at 3:01 PM Michael Thomas via Internet-history >>> wrote: >>> >>> ??? Hi all, >>> >>> ??? I've been trying to understand the history of what we'd now call >>> the >>> ??? Internet of Things. I know about the internet coke machine which >>> ??? was in >>> ??? about 1983 and then the internet toaster in around 1990. >>> FWIW - The CMU Coke machine was in the mid 1970s and was the Arpanet >>> before the?Internet - so you are missing?at least 8-10 years. It was >>> definitely running in '76, but I think was earlier than that - Guy >>> Alms who was there a few years before me, probably remembers when >>> Jim Teter did the original hack (in PDP-11 assembler and BLISS BTW].. >> What I've seen is that it was 83, but maybe they are just talking >> post-flag day. >>> >>> ... >> >> Mike >> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> ... From enervatron at gmail.com Mon Feb 13 17:16:59 2023 From: enervatron at gmail.com (Michael Thomas) Date: Mon, 13 Feb 2023 17:16:59 -0800 Subject: [ih] History of IoT In-Reply-To: References: <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> <85EA1315-E31D-4AA5-BCBB-C79EDB5F7EE3@gmail.com> <814b6487-497c-db11-3f9f-43d07ed6d7f0@gmail.com> Message-ID: On 2/13/23 5:04 PM, Greg Skinner wrote: > (Hoping this will reach the internet-history list) > > Perhaps the TCP implementation by Geof Cooper in this excerpt of a Usenet mod.protocols.tcp-ip thread [1] is more along the lines of what you?re looking for. He mentions using it to allow Imagen to boot its image processors using arpa-ftp. I couldn?t find anything definitive about Imagen?s image processors around that time (1986) via googling, but I remember we had Imagen printers at SRI around then that had enough of a UDP implementation that one could get something like Unix ?uptime? from them using it. > > [1] https://www.linux.co.cr/unix-source-code/review/1986/0513.htm Oh cool! We originally used Dec's MOP protocol on our terminal servers that we were working on but eventually supported bootp and tftp (I don't recall that we used ftp). I take it they weren't using it to get the images on/off the processors? Mike From jmamodio at gmail.com Mon Feb 13 17:19:07 2023 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 13 Feb 2023 19:19:07 -0600 Subject: [ih] History of IoT In-Reply-To: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> Message-ID: Search for "Smart connected objects" ... things connected before calling them IoT. -J On Mon, Feb 13, 2023 at 2:01 PM Michael Thomas via Internet-history < internet-history at elists.isoc.org> wrote: > Hi all, > > I've been trying to understand the history of what we'd now call the > Internet of Things. I know about the internet coke machine which was in > about 1983 and then the internet toaster in around 1990. but that's a > lot of time in between that seems to be blank. It would shock me if > students didn't follow suit with their own versions of coke machine like > hacks in the mean time. The timelines I've seen credit the toaster as > being the first IoT device, but I'm not sure why the coke machine > doesn't qualify because it's just as much of a hack as the toaster. > > My personal stake -- and the reason for my curiosity -- is that I > designed the software for an ethernet enabled laser printer in the mid > 80's which is very likely to be the first (I'd be happy to hear > otherwise) for a printer. We added IP to it a year or two later so it > was definitely before 1990, but I've lost access to source control so > it's really hard to verify my claims. So if it wasn't the first IoT > device (and I don't think it was, the coke machine was really clever), > it could have been the first IoT device that had commercial value. It > was definitely a selling point even back then even though it was > obviously still pretty niche. The company who contracted us for it sold > to a lot of universities so they'd have had a ready audience. > > So does anybody have any memories of IoT in that era? Any good > resources? I almost drove up to ISI for an IETF meeting after struggling > with lprd which was not very well suited to the task of something > embedded in a device. Alas, it was easier procrastinate. There probably > wouldn't have been all that much interest since there were so many other > fish to fry at that time as well. > > Hopefully the output of this a blog post that I'd like to put together. > > cheers, Mike > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From dhc at dcrocker.net Mon Feb 13 17:25:33 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 13 Feb 2023 17:25:33 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> Message-ID: <81b28e9e-afad-e8d2-0e45-281f36e28e2c@dcrocker.net> On 2/13/2023 4:46 PM, Jack Haverty via Internet-history wrote: > IMHO by the early 90s, TCP had already won the competition, and > organizations everywhere were working on transitioning to the Internet this was really by 1988.? We'd started on an OSI stack and were planning on TCP-to-OSI transition products and started talking with customers about their needs. There was no interest from any of them in this, but they were quite eager for OSI-to-TCP transition products. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From lk at cs.ucla.edu Mon Feb 13 17:26:46 2023 From: lk at cs.ucla.edu (Leonard Kleinrock) Date: Mon, 13 Feb 2023 17:26:46 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> Message-ID: Flow control was a central concern at the UCLA Network Measurement Center (NMC) from the earliest days of the ARPANET. We set out to push the fledgling network to its limit to determine where it would fail and experienced a number of such failures and studied them. There is considerable reporting of the flow control issues in my Queueing Systems, Volume II: Computer Applications, in particular in Chapter 6 and ?Computer-Communication Networks: Measurement, Flow Control, and ARPANET Traps?. We studied issues like store-and-forward lockup (which Bob Kahn had predicted), Christmas lockup, reassembly lockup, piggyback lockup, etc. Importantly, we identified the kinds of problems that can arise when flow control functionality is introduced at various points in the network without regard to other, possibly unknown, flow control mechanisms that exist elsewhere. I agree that the congestion control problem is still unsolved. I note that the RFNM came up recent email exchanges, and as a side point, it is interesting that we found that the use of RFNMs in the US-Norway satellite channel caused a ?capture? effect. When a stream of messages crossed one-way, say from US to Norway, it created a stream of RFNMs to return, and that sequence of message-RFNM exchanges hogged the half-duplex channel and effectively locked out messages that were waiting to travel the other way from Norway-US. Ha! Len > On Feb 13, 2023, at 4:46 PM, Jack Haverty via Internet-history wrote: > > IMHO by the early 90s, TCP had already won the competition, and organizations everywhere were working on transitioning to the Internet, or perhaps more commonly their own TCP-based corporate intranet, perhaps as a multiprotocol internet for a while. Other networking technologies still existed in the installed base, but TCP was getting all of the attention. > > The Web emergence in the mid 90s was possibly more a result of TCP's success in enabling universal connectivity rather than a cause of TCP's success. Once it became obvious that TCP had "won", a company or technology vendor had to adapt to it, rather quickly, or die. > > There were earlier technologies that provided collaborative services similar to those of the Web. Lotus Notes is one I remember. Perhaps also services like Compuserve or LexisNexis. IIRC, Notes was based on dial-up connections, not TCP. IBM bought Lotus. I don't know if Notes became part of SNA. But they're both pretty much gone while the Web, based on TCP, explodes in size and reach. LexisNexis is still there, living on the Web. > > Jack > > > On 2/13/23 13:03, Steven Ehrbar wrote: >> On Mon, Feb 13, 2023 at 12:40 PM Jack Haverty via Internet-history >> wrote: >>> They all competed in the same market conditions. TCP >>> didn't just become one of the "top three" in the competitive space. It >>> became pretty much the ony one left standing. Why did TCP/IP win? >> Because TCP/IP _didn't_ compete in the same market conditions. With >> the World Wide Web/Mosaic/Netscape in the mid-90s, TCP/IP went out and >> took over a completely different market than institutional networks, >> the market for home computers users accessing public services. And >> then all the personal computers in corporate networks had to be TCP/IP >> enabled to access the public services being built for home users. >> After which, the choice for corporations was no longer between using >> TCP/IP or some other protocol in any given department; it was whether >> they'd use TCP/IP or _both_ TCP/IP and some other protocol in any >> given department. And while installed base meant a lot of companies >> did the "both" for a while, the benefits of transitioning to just one >> were obvious. > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From touch at strayalpha.com Mon Feb 13 17:33:05 2023 From: touch at strayalpha.com (touch at strayalpha.com) Date: Mon, 13 Feb 2023 17:33:05 -0800 Subject: [ih] Running long-term archives of this list? In-Reply-To: References: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> Message-ID: The issue has typically been the difference between ?here, archive this? and a living list. The latter has been very difficult to get anyone to consider. Joe ? Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Feb 13, 2023, at 1:52 PM, vinton cerf wrote: > > Carnegie-Mellon has an archive - check with Raj Reddy? > > v > > > On Mon, Feb 13, 2023 at 4:03 PM touch--- via Internet-history > wrote: >> Hi, all, >> >> I?ve looked into this before. The obvious choice would be the Computer History Museum, but they didn?t know what I was asking for the last time I tried them. >> >> Very few places actually run true museum-quality backups or storage of ANYTHING (libraries are the exception). Even university archives don?t - they don?t separate acid-free from not, etc. And nobody moves data from medium to medium as it evolves, i.e., so we can read things in the future without needing a non-existent 9-track tape drive. >> >> If anyone finds a solution that?d work for free, please do keep me posted. Until then, I figure we rely on the kindness of places like the Wayback Machine. >> >> Joe (list admin) >> >> ? >> Dr. Joe Touch, temporal epistemologist >> www.strayalpha.com >> >> > On Feb 13, 2023, at 8:27 AM, Dave Crocker via Internet-history > wrote: >> > >> > Reflecting, once again, on the considerable depth and breadth of historical technical knowledge that is regularly demonstrated on this list, I'm wondering about how robustly is is archives and how easily the various archives can be accessed. >> > >> > Yes it's hosted by isoc, but I'm asking about long-term (museum-quality) data archival. (We tend to think of back and archive as the same, but they aren't.) >> > >> > Also note I cited 'running' which means that even this message should hit those long-term archives pretty quickly. >> > >> > d/ >> > >> > -- >> > Dave Crocker >> > Brandenburg InternetWorking >> > bbiw.net >> > mast:@dcrocker at mastodon.social >> > >> > -- >> > 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 vint at google.com Mon Feb 13 17:41:16 2023 From: vint at google.com (Vint Cerf) Date: Mon, 13 Feb 2023 20:41:16 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: brian, thanks for mentioning Cailliau; he certainly deserves more visibility than he has been afforded. v On Mon, Feb 13, 2023 at 4:28 PM Brian E Carpenter via Internet-history < internet-history at elists.isoc.org> wrote: > Thanks Scott. > > I'd add international spread as a major feature, and that was strongly > affected by Larry Landweber (and others) who spread the meme widely in > academia. > > Also: > "Tim Berners-Lee developed..." is a bit hero-worshippy. Actually, Tim > Berners-Lee and Robert Cailliau developed and propagated the Web. Robert's > part has been consistently undersold. > > For those who don't know it, these crucial points: > > ? Provided the protocol specifications for free > ? Provided the software for free > ? Did not patent any aspect > > were due to those who wrote the CERN Convention in 1953, specifying that > the results of CERN research must be published: > > ?The Organization shall have no concern with work for military > requirements and the results of its experimental and theoretical work shall > be published or otherwise made generally available.? > > To my personal knowledge, Berners-Lee and Cailliau persuaded CERN > management to allow the WWW release to the public domain on the basis of > those words. (http://cds.cern.ch/record/1164399) > > Brian > > > On 14-Feb-23 08:50, Scott Bradner via Internet-history wrote: > > for what its worth - here is my take on some of the reasons that the > Internet (and specifically > > TCP/IP) took over the world > > > > Forks: Decisions that got us the Internet we have > > https://www.sobco.com/presentations/2020-06-25-forks.pdf > > > > Scott > > (I, along with Scott Shackelford, have a book on the subject that should > be published at some > > point - the text is done & now in publisher wait) > -- > 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 dave.taht at gmail.com Mon Feb 13 17:48:29 2023 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 13 Feb 2023 17:48:29 -0800 Subject: [ih] congestion control... solved? In-Reply-To: References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> Message-ID: On Mon, Feb 13, 2023 at 1:02 PM Steve Crocker via Internet-history wrote: > > In my view, the answer to 'Has "Congestion Control" in the Internetbeen > solved?' is clearly no. I view bufferbloat as one important part of > the congestion control problem. Consider me nerdsniped. Imagine if you will, if somehow, by persistence and quality code, someone managed to get the flow queuing packet scheduling mechanism (as well as its close cousin, packet pacing) described in Toke's paper below into billions of machines, and many of the congested routers, on the internet, and for all we know, a ton of switches. http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1251687&dswid=-493 I would really prefer more folk read the paper and the math than me describe it briefly here, but what it does is that so long as the ingress rate of packets in a flow is slightly less than the total egress rate of all the other flows, it observes near-zero queuing. It was a nice advance over prior attempts at FQ, which always put new flows at the back of the list. The game theory is good. It incentivizes an application desiring low latency behavior to utilize delay, and pacing, to achieve that result. Other, more greedy, bursty flows, only hurt themselves. Historically, how we treated congestion control was to violently attempt to shove some other packets out of the way to clear room for themselves in slow start, and then slowly probe for more bandwidth, in a sawtooth that was stable, but not particularly desirable. Pacing is deeply embedded in Quic, long available in linux for cubic via the EDF scheduler also, and the slight difference between going out early when well paced, or seeing other traffic, and probing for more bandwidth, are detectable on different curves. There's some nifty work on "FQuic", leveraging multipath... There are of course, other issues to solve in congestion control, notably bursty macs like wifi, and other promising probing techniques like packet chirping and "flow start" that I could talk to in a later message... and still some use for AQM techniques inc ecn... but I like to think that the future for solving congestion control is bright, given the size of the deployment today, the now-observable benefits, and the adoption curve. (until I look at the mess that is 5G. I won't go there.) > > Steve > > > On Mon, Feb 13, 2023 at 3:44 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > > > It seems that I didn't receive some messages over the weekend....sorry > > if anyone has already noted what I say below. > > > > Re the ARPANET and Congestion Control: This was definitely a hot > > topic, in particular after DCA took over operations and the network grew > > in size. There were DCA-managed contracts to rework the internal > > mechanisms of the ARPANET to handle the much larger and diverse networks > > of IMPs that evolved into the multiple IMP-based networks called the > > DDN. Congestion control was just one issue of several that interacted, > > e.g., routing, flow control, retransmission, buffer management, etc. > > The IMP design, although a "packet network", in effect had a "serial > > byte stream" mechanism internally to make sure all data got from source > > host to destination. The ARPANET had the equivalent of parts of a TCP > > built inside the IMPs to guarantee the delivery of a data stream. > > > > I'm not sure how much historical detail you'll find in traditionally > > published papers and journals. Outside of academia that wasn't a > > priority. But there were extensive and detailed reports prepared as > > part of the ARPANET "operations" contracts and delivered to DCA. Here's > > one 3-volume, multi-year example that discusses a lot of the work in the > > early 80s on "congestion control" and new internal IMP mechanisms in > > general: > > > > https://apps.dtic.mil/sti/citations/ADA053450 > > https://apps.dtic.mil/sti/citations/ADA086338 > > https://apps.dtic.mil/sti/citations/ADA121350 > > > > There's hundreds of pages of detail in those reports and there are > > others available through DTiC. I was listed as author on some of > > these, because at the time that contract was one of "my" contracts -- > > which meant that I had to make sure that the report got written and > > delivered so we would get paid. I didn't personally work on the > > ARPANET technical research, but I did absorb some understanding of the > > issues and details. The "IMP Group" was literally just down the hall. > > > > At the time (early 1980s), I was involved in the early Internet work, > > when TCP/IP V4 was being created and the various flow and congestion > > control mechanisms were being defined. From the ARPANET experience, it > > was clear to me that the IMP gurus "down the hall" at BBN viewed > > congestion control as a major issue, and that sometimes surfaced as > > statements such as "TCP will never work". TCP didn't address any of the > > issues of congestion, except by the rudimentary and unproven mechanism > > of "Source Quench". > > > > The expectation was that the Internet would work if congestion was > > avoided rather than controlled, which could be attempted by keeping > > network capacity above traffic demands, at least long enough that TCP's > > retransmission and backoff mechanisms in the hosts would throttle down > > as expected to match what the network substrate was capable of carrying > > at the time. Of course those mechanisms were now distributed among the > > several hosts and network switches (e.g., IMPs, Packet Radios, computer > > OS, gateways) involved, designed, built, and managed by different > > organizaions, which made it challenging to predict how it would all behave. > > > > Even today, as an end user, I can't tell if "congestion control" is > > implemented and working well, or if congestion is just mostly being > > avoided by deployment of lots of fiber and lots of buffer memory in all > > the switching locations where congestion might be expected. That of > > course results in the phenomenon of "buffer bloat". That's another > > question for the Historians. Has "Congestion Control" in the Internet > > been solved? Or avoided? > > > > Jack Haverty > > > > > > > > On 2/13/23 08:19, Craig Partridge via Internet-history wrote: > > > On Sat, Feb 11, 2023 at 7:48 AM Noel Chiappa via Internet-history < > > > internet-history at elists.isoc.org> wrote: > > > > > >> > > >> > From: Craig Partridge > > >> > > >> > We figured out congestion collapse well enough for the time > > >> > > >> It should be remembered that the ARPANET people (hi!) had perhaps solved > > >> this > > >> problem a long time before. I'm trying to remember how explicitly they > > saw > > >> this as a separate problem from the issue of running out of buffer space > > >> for > > >> message re-assembly at the destination IMP, but I seem to recall that > > RFNMs > > >> were seen as a needed throttle to prevent the network as a whole from > > being > > >> overrun (i.e. what we now think of as 'congestion', although IIRC that > > term > > >> wasn't used then), as well as flow control to the source host (as we > > would > > >> now call it). > > >> > > >> I don't recall exactly where I saw that, but I'd try the BBN proposal to > > >> DARPA's RFP, and the first JFIPS paper ("The interface message processor > > >> for > > >> the ARPA computer network"). > > >> > > > I don't recall the details either, though I remember stories of Bob Kahn > > > going to LA to beat up on the first few ARPANET nodes > > > because he anticipated various issues, I think including congestion. And > > > he found them and fixes were made. > > > > > > But remember ARPANET was homogeneous -- same speed for each link and a > > > single control mechanism. I think John Nagle was > > > the first to point out ("On packet switches with infinite storage") that > > > connecting very different networks had its own challenges. > > > And to my point, not something that a person working with X.25 would have > > > understood terribly well (yes X.75 gateways existed but > > > they typically throttled the window size to 2 packets, which hid a lot of > > > issues). > > > > > > Craig > > > > -- > > 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 -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz Dave T?ht CEO, TekLibre, LLC From sauer at technologists.com Mon Feb 13 17:59:43 2023 From: sauer at technologists.com (Charles H. Sauer (he/him)) Date: Mon, 13 Feb 2023 19:59:43 -0600 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <81b28e9e-afad-e8d2-0e45-281f36e28e2c@dcrocker.net> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> <81b28e9e-afad-e8d2-0e45-281f36e28e2c@dcrocker.net> Message-ID: <1c2e525a-53bd-9cfa-35f6-218d8a3e99c1@technologists.com> Staying on topic of installed base momentum... In hindsight, the writing of TCP winning may seem to have been on the wall by the early 90s, but from a PC perspective that seems a decade early. The decision makers in Cupertino, Redmond, and Provo, saw need for, and perhaps even preferred, AppleTalk, IPX/SPX, and SMB, until this century. A few specifics: o Appletalk support stayed in macOS until 10.6 release in 2009 o Novell did not give preference to and natively support TCP/IP until NetWare 5 in October 1998. o Windows 95 was the first legacy Windows version to have acceptable TCP/IP o Windows NT 3.5 in September 1994 was the first NT based version to support TCP/IP o Microsoft did not drop IPX/SPX until Windows Vista in 2007 o Windows 11 still seems to have some allowances for SMB Charlie On 2/13/2023 7:25 PM, Dave Crocker via Internet-history wrote: > On 2/13/2023 4:46 PM, Jack Haverty via Internet-history wrote: >> IMHO by the early 90s, TCP had already won the competition, and >> organizations everywhere were working on transitioning to the Internet > > this was really by 1988.? We'd started on an OSI stack and were planning > on TCP-to-OSI transition products and started talking with customers > about their needs. > > There was no interest from any of them in this, but they were quite > eager for OSI-to-TCP transition products. > > d/ > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From jack at 3kitty.org Mon Feb 13 18:26:03 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 18:26:03 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <1c2e525a-53bd-9cfa-35f6-218d8a3e99c1@technologists.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> <81b28e9e-afad-e8d2-0e45-281f36e28e2c@dcrocker.net> <1c2e525a-53bd-9cfa-35f6-218d8a3e99c1@technologists.com> Message-ID: <14ba47c3-f9c9-bec9-3895-559db73bdad9@3kitty.org> My observation about the early 90s was based on conversations I had at the time with end-users - e.g., CTOs, CEOs, et al who were end-users of computing technology critical to their businesses, struggling to develop their own organization's networking strategy. When I met with such people in the early 90s, they had pretty much all committed to TCP as their target environment, with a plan to get there from their installed base.?? It surprised me at the time, but my background to then had been as a networking vendor. Networking and computing vendors were a little slower to realize TCP had won. Jack On 2/13/23 17:59, Charles H. Sauer (he/him) via Internet-history wrote: > > Staying on topic of installed base momentum... > > In hindsight, the writing of TCP winning may seem to have been on the > wall by the early 90s, but from a PC perspective that seems a decade > early. The decision makers in Cupertino, Redmond, and Provo, saw need > for, and perhaps even preferred, AppleTalk, IPX/SPX, and SMB, until > this century. > > A few specifics: > o Appletalk support stayed in macOS until 10.6 release in 2009 > o Novell did not give preference to and natively support TCP/IP until > NetWare 5 in October 1998. > o Windows 95 was the first legacy Windows version to have acceptable > TCP/IP > o Windows NT 3.5 in September 1994 was the first NT based version to > support TCP/IP > o Microsoft did not drop IPX/SPX until Windows Vista in 2007 > o Windows 11 still seems to have some allowances for SMB > > Charlie > > On 2/13/2023 7:25 PM, Dave Crocker via Internet-history wrote: >> On 2/13/2023 4:46 PM, Jack Haverty via Internet-history wrote: >>> IMHO by the early 90s, TCP had already won the competition, and >>> organizations everywhere were working on transitioning to the Internet >> >> this was really by 1988.? We'd started on an OSI stack and were >> planning on TCP-to-OSI transition products and started talking with >> customers about their needs. >> >> There was no interest from any of them in this, but they were quite >> eager for OSI-to-TCP transition products. >> >> d/ >> > From brian.e.carpenter at gmail.com Mon Feb 13 18:39:34 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 14 Feb 2023 15:39:34 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> Message-ID: <3d584d8b-6813-c09b-b7f3-486b1b2fc644@gmail.com> > The Web emergence in the mid 90s was possibly more a result of TCP's > success in enabling universal connectivity rather than a cause of TCP's > success. Both. It was a perfect example of a virtuous circle. Berners-Lee and Cailliau chose Telnet/TCP/IP because it was there, on *all* target systems of interest in the high-energy physics community, and then Internet users chose WWW because it was everywhere after its release to the public domain. Regards Brian On 14-Feb-23 13:46, Jack Haverty via Internet-history wrote: > IMHO by the early 90s, TCP had already won the competition, and > organizations everywhere were working on transitioning to the Internet, > or perhaps more commonly their own TCP-based corporate intranet, perhaps > as a multiprotocol internet for a while.?? Other networking technologies > still existed in the installed base, but TCP was getting all of the > attention. > > The Web emergence in the mid 90s was possibly more a result of TCP's > success in enabling universal connectivity rather than a cause of TCP's > success.? Once it became obvious that TCP had "won", a company or > technology vendor had to adapt to it, rather quickly, or die. > > There were earlier technologies that provided collaborative services > similar to those of the Web.?? Lotus Notes is one I remember. Perhaps > also services like Compuserve or LexisNexis.? IIRC, Notes was based on > dial-up connections, not TCP.? IBM bought Lotus.?? I don't know if Notes > became part of SNA.?? But they're both pretty much gone while the Web, > based on TCP, explodes in size and reach. LexisNexis is still there, > living on the Web. > > Jack > > > On 2/13/23 13:03, Steven Ehrbar wrote: >> On Mon, Feb 13, 2023 at 12:40 PM Jack Haverty via Internet-history >> wrote: >>> They all competed in the same market conditions. TCP >>> didn't just become one of the "top three" in the competitive space. It >>> became pretty much the ony one left standing. Why did TCP/IP win? >> Because TCP/IP _didn't_ compete in the same market conditions. With >> the World Wide Web/Mosaic/Netscape in the mid-90s, TCP/IP went out and >> took over a completely different market than institutional networks, >> the market for home computers users accessing public services. And >> then all the personal computers in corporate networks had to be TCP/IP >> enabled to access the public services being built for home users. >> After which, the choice for corporations was no longer between using >> TCP/IP or some other protocol in any given department; it was whether >> they'd use TCP/IP or _both_ TCP/IP and some other protocol in any >> given department. And while installed base meant a lot of companies >> did the "both" for a while, the benefits of transitioning to just one >> were obvious. > From brian.e.carpenter at gmail.com Mon Feb 13 18:43:16 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 14 Feb 2023 15:43:16 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <14ba47c3-f9c9-bec9-3895-559db73bdad9@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> <81b28e9e-afad-e8d2-0e45-281f36e28e2c@dcrocker.net> <1c2e525a-53bd-9cfa-35f6-218d8a3e99c1@technologists.com> <14ba47c3-f9c9-bec9-3895-559db73bdad9@3kitty.org> Message-ID: On 14-Feb-23 15:26, Jack Haverty via Internet-history wrote: > My observation about the early 90s was based on conversations I had at > the time with end-users - e.g., CTOs, CEOs, et al who were end-users of > computing technology critical to their businesses, struggling to develop > their own organization's networking strategy. When I met with such > people in the early 90s, they had pretty much all committed to TCP as > their target environment, with a plan to get there from their installed > base.?? It surprised me at the time, but my background to then had been > as a networking vendor. > > Networking and computing vendors were a little slower to realize TCP had > won. 100% correct. And (just as SNA remained a cash cow for IBM for years after it was overtaken by events), the other proprietary networking suites went on generating cashflow... until they didn't. I hear there are parts of the universe where OSI is still generating cashflow. Brian > > Jack > > > On 2/13/23 17:59, Charles H. Sauer (he/him) via Internet-history wrote: >> >> Staying on topic of installed base momentum... >> >> In hindsight, the writing of TCP winning may seem to have been on the >> wall by the early 90s, but from a PC perspective that seems a decade >> early. The decision makers in Cupertino, Redmond, and Provo, saw need >> for, and perhaps even preferred, AppleTalk, IPX/SPX, and SMB, until >> this century. >> >> A few specifics: >> o Appletalk support stayed in macOS until 10.6 release in 2009 >> o Novell did not give preference to and natively support TCP/IP until >> NetWare 5 in October 1998. >> o Windows 95 was the first legacy Windows version to have acceptable >> TCP/IP >> o Windows NT 3.5 in September 1994 was the first NT based version to >> support TCP/IP >> o Microsoft did not drop IPX/SPX until Windows Vista in 2007 >> o Windows 11 still seems to have some allowances for SMB >> >> Charlie >> >> On 2/13/2023 7:25 PM, Dave Crocker via Internet-history wrote: >>> On 2/13/2023 4:46 PM, Jack Haverty via Internet-history wrote: >>>> IMHO by the early 90s, TCP had already won the competition, and >>>> organizations everywhere were working on transitioning to the Internet >>> >>> this was really by 1988.? We'd started on an OSI stack and were >>> planning on TCP-to-OSI transition products and started talking with >>> customers about their needs. >>> >>> There was no interest from any of them in this, but they were quite >>> eager for OSI-to-TCP transition products. >>> >>> d/ >>> >> > From dhc at dcrocker.net Mon Feb 13 19:00:53 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 13 Feb 2023 19:00:53 -0800 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <3d584d8b-6813-c09b-b7f3-486b1b2fc644@gmail.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> <3d584d8b-6813-c09b-b7f3-486b1b2fc644@gmail.com> Message-ID: <9ec04fab-3fbc-d281-40b3-ed97b5ec8c4a@dcrocker.net> On 2/13/2023 6:39 PM, Brian E Carpenter via Internet-history wrote: > Both. It was a perfect example of a virtuous circle. Berners-Lee and > Cailliau chose Telnet/TCP/IP because it was there, This sort of topic is difficult to discuss without being swayed by the bias of one's preferences, as well as the inability to do a rigorous assessment, what with the vagaries and ambiguities of human behavior.? Which is to say, there is no certainty in what follows, no matter how strong my certitude... Nonetheless, consider that the Internet was on a very steady growth curve throughout the 80s, continuing along the curve for years afterward. It had become a viable commercial market -- not yet a /mass/ market, but still a viable one -- before the Web was created.? EMail as quite an active, inter-enterprise service. Then consider that gopher was already around and gaining ground. When the web appeared, it demonstrated much better functionality and usability; so it's not as if it did not significantly add to the appeal of the Internet. Stkll, from what I watched and participated in, by the late 1980s,? it was entirely clear that the Internet was going to go global and dominate.? There was increasing market demand and no viable alternative.? With or without the Web.? The Web, however, made that dominate significantly nicer and more functional. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From brian.e.carpenter at gmail.com Mon Feb 13 19:01:46 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 14 Feb 2023 16:01:46 +1300 Subject: [ih] History of IoT In-Reply-To: <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> Message-ID: <952e67ee-7602-e8d2-b4de-b8639a294bf9@gmail.com> On 14-Feb-23 11:45, Larry Masinter via Internet-history wrote: > Look at the references for RFC 2324 (which might itself be the first IoT RFC not sure). I don't see why not. Jon Postel always insisted that RFCs in that must be completely implementable. RFC 1673 doesn't really qualify, but it made clear the notion of covering vast numbers of objects: "The addressing scheme must have essentially an unlimited address space to encompass an arbitrarily large number of information objects." In verbal discussions in the IPng directorate, there was certainly talk of addressing every street lamp etc. Brian > > I tried to find references for such things. > > At the time PARC had an initiative Mark Weiser called Ubiquitous Computing? which involved networking lots of things? and might be a better name or at least more evocative of why you might want such a thing and a big address space and likely the justification of participation with IPv6. > > -- > LarryMasinter.net > >> On Feb 13, 2023, at 12:01 PM, Michael Thomas via Internet-history wrote: >> >> much of a hack as the toaster. From jack at 3kitty.org Mon Feb 13 19:51:59 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 19:51:59 -0800 Subject: [ih] congestion control... solved? In-Reply-To: References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> Message-ID: <78308474-6ff2-0af6-ad53-e450db61d98f@3kitty.org> On 2/13/23 17:48, Dave Taht wrote: > Imagine ... someone managed to get the flow queuing packet scheduling mechanism ... into billions of machines, and many of the congested routers, on the internet, and for all we know, a ton of switches. This is "the" key issue, IMHO.? Personally, I don't consider something "solved" until it is deployed into the field and the original problem goes away.?? It's good to see that some science (math) has been developing in the networking problem space.?? But new algorithms and protocols aren't a solution unless they are deployable.?? I wrote a bit about this in RFC 722 after running into the issue in the ARPANET.?? Algorithms and mechanisms in a network must be designed to be not only functional but also deployable, ideally without the need to throw the existing systems away and start from scratch. The people who were working on ARPANET internals back in the 80s were confident that they were making progress on mechanisms for flow control, congestion control, and other networking issues that surfaced as the network was used and grew.?? Much of that work involved thinking about how any new mechanism would be introduced into the ARPANET in a non-disruptive way.?? I suspect that the people working on other network technologies - SPX/IPX, Appletalk, SNA, XNS, DECNET, ISO, etc., had similar goals. That was a hard problem. IMHO, the Internet architecture makes the problem even more difficult.?? In the ARPANET, there were only hundreds of switches and lines, and the topology, operation, and software development was all managed by one organization (BBN).? In the Internet, the same mechanisms are spread so that parts are in the switches (IP) and other parts are in the endusers' computers (TCP), now billions of them, designed, built, deployed, and operated by many different organizations and people. That's a really hard problem.... Jack From dhc at dcrocker.net Mon Feb 13 19:54:43 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 13 Feb 2023 19:54:43 -0800 Subject: [ih] History of IoT In-Reply-To: <952e67ee-7602-e8d2-b4de-b8639a294bf9@gmail.com> References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> <952e67ee-7602-e8d2-b4de-b8639a294bf9@gmail.com> Message-ID: <0683765d-19ae-a04a-b913-8b747a475998@dcrocker.net> On 2/13/2023 7:01 PM, Brian E Carpenter via Internet-history wrote: > I don't see why not. Jon Postel always insisted that RFCs in that > must be completely implementable. Indeed. I once submitted a draft April 1 RFC for doing IP over Email.? Jon rejected it because I had not resolved the question of the upper=level IP address usage with the lower-level IP address usage. sigh. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From jack at 3kitty.org Mon Feb 13 20:00:25 2023 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 13 Feb 2023 20:00:25 -0800 Subject: [ih] History of IoT In-Reply-To: <0683765d-19ae-a04a-b913-8b747a475998@dcrocker.net> References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> <952e67ee-7602-e8d2-b4de-b8639a294bf9@gmail.com> <0683765d-19ae-a04a-b913-8b747a475998@dcrocker.net> Message-ID: That was actually a relaxation of Jon's earlier stance - "Rough Consensus and Running Code".? You needed not just a design, but also an implementation.?? Preferably two distinct ones that could be seen to interoperate.? It seems the criteria for becoming a standard changed over history.? Running Code is no longer necessary?? /J On 2/13/23 19:54, Dave Crocker via Internet-history wrote: > On 2/13/2023 7:01 PM, Brian E Carpenter via Internet-history wrote: >> I don't see why not. Jon Postel always insisted that RFCs in that >> must be completely implementable. > > Indeed. I once submitted a draft April 1 RFC for doing IP over Email.? > Jon rejected it because I had not resolved the question of the > upper=level IP address usage with the lower-level IP address usage. > > sigh. > > d/ > From johnl at iecc.com Mon Feb 13 20:02:45 2023 From: johnl at iecc.com (John Levine) Date: 13 Feb 2023 23:02:45 -0500 Subject: [ih] Running long-term archives of this list? In-Reply-To: <43b6c275-76fd-048b-9df0-8bf3841e97ed@3kitty.org> Message-ID: <20230214040246.A07B8987B356@ary.qy> It appears that Jack Haverty via Internet-history said: >Yesterday I read a story about Google's small army of employees with >yellow badges tasked with methodically scanning books in various >libraries' collections to create a comprehensive digital archive, which >unfortunately couldn't be available to the public for various reasons >such as legal constaints of copyright et al.?? I assume it's all well >archived and backed up. Hathitrust is a consortium of midwestern academic libraries that maintains an archive of scanned books. It includes Google Books and scans from the Internet Archive and other stuff. There was a long contentious lawsuit a decade ago filed by the Authors Guild (which I quit because of that suit) that the Guild eventually lost, but the Hathitrust scans are mostly available only to member libraries other than books they are sure are in the public domain. If anyone knows people there, either directly or perhaps indirectly via Google or the Internet Archive, it might be interesting to talk to them. The Charles Babbage Institute at U of Minnesota should also be interested, dunno anyone there either. R's, John From dhc at dcrocker.net Mon Feb 13 20:03:57 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 13 Feb 2023 20:03:57 -0800 Subject: [ih] History of IoT In-Reply-To: References: <272dab10-d412-4a00-a8c2-201d05af435f@gmail.com> <1E334F6D-D32D-4A1C-88DC-505DE6DECB77@gmail.com> <952e67ee-7602-e8d2-b4de-b8639a294bf9@gmail.com> <0683765d-19ae-a04a-b913-8b747a475998@dcrocker.net> Message-ID: <316b990f-201d-87d1-60f8-e8291460088d@dcrocker.net> On 2/13/2023 8:00 PM, Jack Haverty via Internet-history wrote: > That was actually a relaxation of Jon's earlier stance - "Rough > Consensus and Running Code".? You needed not just a design, but also > an implementation.?? Preferably two distinct ones that could be seen > to interoperate.? It seems the criteria for becoming a standard > changed over history.? Running Code is no longer necessary?? /J For Full standard, there has always been a requirement for significant field experience. For Proposed standard the requirements have been highly variable.? Sometimes requiring implementation, sometimes requiring meaningful interoperability demonstrations, sometimes merely requiring a document with limited spelling errors. In terms of overall process, while things were sometimes onerous decades ago, they seem to be considerable more consistently onerous now. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From gnu at toad.com Mon Feb 13 21:34:53 2023 From: gnu at toad.com (John Gilmore) Date: Mon, 13 Feb 2023 21:34:53 -0800 Subject: [ih] Installed base momentum In-Reply-To: <14ba47c3-f9c9-bec9-3895-559db73bdad9@3kitty.org> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <34fe3877-0488-382d-c352-c38f4449c5d2@3kitty.org> <81b28e9e-afad-e8d2-0e45-281f36e28e2c@dcrocker.net> <1c2e525a-53bd-9cfa-35f6-218d8a3e99c1@technologists.com> <14ba47c3-f9c9-bec9-3895-559db73bd! ad9@3kitty.org> Message-ID: <24755.1676352893@hop.toad.com> Jack Haverty via Internet-history wrote: > Networking and computing vendors were a little slower to realize TCP had won. My perspective on this history comes from being a young "Tourist" on the ARPAnet (via Telenet and MIT-AI), and then being employee #5 of Sun in 1982, working there for five or six years. It was incredibly refreshing to be on the ARPAnet and have mailing lists where standards were discussed openly, for free, among anyone who wanted to participate. And with drafts and standards easily available on FTP sites, in plain ASCII text, for me to read, understand, and if I wanted to, implement. I had come from the IBM mainframe (APL and OS/MVT) world. There we had had two mainframes IN THE SAME ROOM and designed an email system that would move messages back and forth between them with timed transfers several times per day on manually moved 9-TRACK MAGTAPES! Because you really couldn't get an interface any better than a serial port that would talk between two mainframes, and IBM's software tended to suck. And non-ARPAnet standards documents were obtuse, obviously not designed to be easily understood. Jon Postel as the RFC author and editor completely shattered the mold there. By the time I joined Sun in 1982, everything we did was based on Ethernet and TCP/IP. Our original prototypes had 3-meg Experimental Ethernet multibus boards created by our founder, grad student Andy Bechtolsheim. These had been created at Stanford along with the first 8-MHz 68000 Sun CPU boards. There might have been a tiny bit of XNS or something around, inherited from Stanford, but everything we built and used was IP. Our software started with a UNIX V7 clone from Unisoft as a stopgap. After hiring Bill Shannon, Tom Lyon, and Bill Joy among the first 10 employees, we rapidly moved to 4.1[abc]BSD and 4.2BSD systems that included TCP/IP networking as a standard feature. This took our standalone UNIX systems and made them part of a tight network of cooperating systems by 1983. We adopted 3Com Multibus 10-megabit Ethernet boards -- with separate transceivers -- as soon as they were available. We adopted (and I maintained) sendmail as our networked email software. Tons of universities adopted our hardware and software, because we were cheaper than Vaxes, ran solid portable UNIX software, and came with high-resolution graphics displays and high speed networking. The high single-unit prices of disk drives and tape drives meant that you got much more storage per user dollar if you bought big drives and split them among multiple workstations. Bill Croft built a simple block-level storage sharing protocol (nd, network disk) that ran over UDP. The tape access commands like dump were hacked to work simply over TCP. Bill and I wrote the bootstrap code that enabled diskless workstations to boot across the Ethernet (again using UDP) from a local server. In parallel, Sun designed and eventually shipped and standardized the Network File System for object-level sharing of files and directories. Again, it ran over IP and UDP with some TCP, on 10-meg Ethernet. (Bill and I also invented and published BOOTP at the time, to automate getting your new machine's IP address. Sun didn't ship it then, because the NFS kernel people had picked Reverse ARP as their bootstrap method. BOOTP later became DHCP.) Eventually, Sun migrated the Ethernet interface right onto the motherboard, once we started building larger circuit boards. Sun had a healthy third-party catalog of applications that included OSI and SNA and Netware and X.25 and other networking protocols. Sun may have even adopted some of those products under its own brand. But they all were licensed at something like $1000 per workstation -- real money in 1983. TCP/IP came free and well debugged in the basic OS. And you couldn't boot the machine over SNA, or share drives that way, so you had to understand TCP/IP anyway and run it in parallel if you wanted any of those features. (A great short story of his early Sun history was posted last year by Sun emp#8, Tom Lyon, as a twitter thread here: https://twitter.com/aka_pugs/status/1521489115585421314 ) As most of this list knows, Berkeley Unix had TCP/IP because DARPA had funded UC Berkeley in 1978 to make it a standard feature in evolving 4.1BSD into 4.2BSD for the research community. I don't know how few or many dollars that investment cost them, but it got incredible bang for the buck! The result was that every UNIX system (except the lame microprocessor ones like Xenix) came standard with TCP/IP. Every research lab that was buying minicomputers like Pyramids, DEC Vaxes, Sequents, or workstations like Suns or SGIs, therefore had every reason to make their whole advanced-computing network use TCP/IP. Their email would interoperate locally over the LAN and be gatewayed by a server onto UUCP or BITNET or CSNET for global connectivity. And whenever they could beg, borrow, or steal a realtime IP connection to the wider Internet, then poof, their local machines just popped onto the worldwide network. This multi-vendor consortium rapidly pushing Ethernet and TCP/IP forward contrasted with every other wide-area networking technology, which was either owned by one company (like DECNET or SNA) or was managed by a slothful postal bureacracy like X.25. The impact of that UC Berkeley funding was akin to (and prerequisite to) the impact that came from the later research funding given to the National Center for Supercomputing Applications, which allowed them to create the Mosaic graphical web browser that jumpstarted public use of the WWW (over TCP/IP). Don't ignore the impact of Ethernet on the acceptance of TCP/IP. Ethernet provided the first solid standardized multi-megabit-per-second cable interface at reasonable prices. It would support any networking protocol, and was supported and evolved forward by hundreds of hardware and software companies. Ethernet was the "on-ramp" for TCP/IP, which would have gone nowhere if it had been limited to serial port or modem speeds (under 100 kbits/sec). I worked where Ethernet was adopted early, so it shortly became unremarkable to me. Later, I suddenly knew it had taken over the universe when I started seeing 8-pin modular jacks and Ethernet cables on cash registers in small ordinary shops. (Ethernet's evolution into back-end full duplex, fiber, higher speeds, and long haul networks only cemented its position as the standard network front end faster than modems.) TCP/IP went to most places that Ethernet went, in some ways riding on its coattails. John Gilmore From jeanjour at comcast.net Tue Feb 14 04:40:49 2023 From: jeanjour at comcast.net (John Day) Date: Tue, 14 Feb 2023 07:40:49 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <2A90F9DF-83D1-4B03-9777-14E9A5EB3FD3@comcast.net> Message-ID: Okay, thanks. There was an attempt by Michel Gien and Steve Bunch to convince Joy to do something sane, but he wasn?t persuaded. Yea, Unix didn?t support IPC and it had to be added. You could get NCP in the kernel, but not TCP in the early PDP-11s. It really was unfortunate that sockets was adopted. Another opportunity missed. Take care, John > On Feb 13, 2023, at 16:07, Craig Partridge wrote: > > Hi John: > > Oh no, far more complicated than that. As I recall (and my memory on this is probably imperfect as I was young and learning and some things went over my head): > > Bill rewrote the BBN TCP to make it more efficient. The BBN TCP used a function table that was indexed by connection state and TCP segment type (so you looked up the connection using the TCP/IP header, then grabbed the segment type, and called the indexed function along with the PCB and inbound segment). It made for tight and simple routines... but, as I recall, the VAX (the primary platform at the time) made function calls expensive, so Bill wanted a minimal number of function calls and produced long routines as a result (cf. tcp_input in 4.2BSD). > Bill (or someone) at Berkeley came up with the idea of sockets and the socket/bind/listen/connect API as they did not like /dev/tcp and ioctls (which BBN TCP used and which Dennis Ritchie independently came up with for System V UNIX). While ioctls and /dev/tcp may have fit the existing UNIX philosophy, having taught thousands of students in the 1990s sockets and had a few then encounter System V and say "ugh", Berkeley was probably right on this one. > Various innards of the BSD implementation were cribbed from the BBN TCP. A good example is mbufs -- invented by Rob Gurwitz when he ported an early TCP (Jack Haverty's???) to BSD. I seem to recall seeing a memo from Rob c. 1988 saying mbufs were a hack to solve an immediate porting problem and that he was surprised a better solution had not materialized. > The 4.1BSD BBN TCP was more stable than the 4.1c BSD (first socket) TCP and there was a period in which DARPA was (unhappily) funding both TCPs because many sites asked to have the BBN TCP so they could have reliable Internet connectivity. This lasted a certain number of years into 4.2BSD, but eventually went Berkeley's way. > Craig > > On Mon, Feb 13, 2023 at 1:35 PM John Day > wrote: > So Berkeley?s position was that they were to port the BBN implementation bugs and all? > > And BBN is to blame for sockets? What a lost opportunity. > > The first Unix on the Net in 1975 didn?t do that. It used file_io. > > > > On Feb 13, 2023, at 15:28, Craig Partridge via Internet-history > wrote: > > > > HI Scott: > > > > Small nit. > > > > DARPA funded Berkeley to port the BBN Unix to BSD -- and Bill Joy chose to > > reimplement and develop sockets. Much behind the scenes fighting ensued (I > > was hired into that fight in 1983 when BBN concluded it needed to train > > someone to understand the BSD implementation). Led to various odd > > conversations years later -- I remember Van Jacobson justifying a TCP bug > > in the BSD implementation by saying it had been in the BBN implementation > > that Bill used as a reference -- c. 1989, long after BBN BSD TCP was gone. > > > > Craig > > > > On Mon, Feb 13, 2023 at 12:50 PM Scott Bradner via Internet-history < > > internet-history at elists.isoc.org > wrote: > > > >> for what its worth - here is my take on some of the reasons that the > >> Internet (and specifically > >> TCP/IP) took over the world > >> > >> Forks: Decisions that got us the Internet we have > >> https://www.sobco.com/presentations/2020-06-25-forks.pdf > >> > >> Scott > >> (I, along with Scott Shackelford, have a book on the subject that should > >> be published at some > >> point - the text is done & now in publisher wait) > >> -- > >> 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 > > > > -- > ***** > Craig Partridge's email account for professional society activities and mailing lists. From jeanjour at comcast.net Tue Feb 14 04:59:50 2023 From: jeanjour at comcast.net (John Day) Date: Tue, 14 Feb 2023 07:59:50 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> Message-ID: <75E38451-64C2-410F-AF96-70E68C807291@comcast.net> Sorry just catching up on this. Glad you brought up congestion control again. From what I know of the history, it goes like this: The first discussion of congestion control for networks and what was later called datagram networks is in a proposal by Donald Davies in 1966. The CYCLADES group immediately recognized the problem when they applied datagrams with end-to-end transport in 1972 and initiated a contract with the University of Waterloo to investigate it. Merek Irland, a brilliant young grad student at Waterloo undertook the Work as his PhD thesis. There are early results in the 4th DataComm Symposium and two papers in the Symposium on Flow Control in Computer Networks held in 1979 at Versailles. Unfortunately, Irland?s work was lost until recently due to unfortunate events: the shutdown of CYCLADES and Irland?s death. (The 1979 symposium is dedicated to him.) I accidentally found out about it and tracked it down. Most of the results are in the thesis. The ARPANET team under Dave Walden was very much aware of the issue and went to great lengths in the IMP subnet to avoid it. This was helped by the fact that in the early ?Net, with the exception of the 2 or 3 cross country links, stop-and-wait was all that could be done between IMPs. An ARPANET message (not packet) at 56Kbps was several hundred miles long. Craig, earlier you said this: > Nicely, the most prominent and > complementary papers on congestion issues, one by Van Jacobson (TCP/IP) and > one by Raj Jain and KK Ramakrishnan (DECNET), > were presented back-to-back at the ACM SIGCOMM conference in 1988. So if > you were looking to build (or soon after via NSFNET, connect > to) a sturdy wide-area network, unless you were a DEC VMS organization, > your best choice was TCP/IP. Were you implying that Jain?s work was unique to DECNET? I have read both work carefully and I didn?t see anything in Jain?s report that was unique to DECNET. And I have to say that the 4 parts of report of Jain?s team is some of the finest computer science research I have ever seen. I wish we saw more of it. Take care, John > On Feb 13, 2023, at 15:44, Jack Haverty via Internet-history wrote: > > It seems that I didn't receive some messages over the weekend....sorry if anyone has already noted what I say below. > > Re the ARPANET and Congestion Control: This was definitely a hot topic, in particular after DCA took over operations and the network grew in size. There were DCA-managed contracts to rework the internal mechanisms of the ARPANET to handle the much larger and diverse networks of IMPs that evolved into the multiple IMP-based networks called the DDN. Congestion control was just one issue of several that interacted, e.g., routing, flow control, retransmission, buffer management, etc. The IMP design, although a "packet network", in effect had a "serial byte stream" mechanism internally to make sure all data got from source host to destination. The ARPANET had the equivalent of parts of a TCP built inside the IMPs to guarantee the delivery of a data stream. > > I'm not sure how much historical detail you'll find in traditionally published papers and journals. Outside of academia that wasn't a priority. But there were extensive and detailed reports prepared as part of the ARPANET "operations" contracts and delivered to DCA. Here's one 3-volume, multi-year example that discusses a lot of the work in the early 80s on "congestion control" and new internal IMP mechanisms in general: > > https://apps.dtic.mil/sti/citations/ADA053450 > https://apps.dtic.mil/sti/citations/ADA086338 > https://apps.dtic.mil/sti/citations/ADA121350 > > There's hundreds of pages of detail in those reports and there are others available through DTiC. I was listed as author on some of these, because at the time that contract was one of "my" contracts -- which meant that I had to make sure that the report got written and delivered so we would get paid. I didn't personally work on the ARPANET technical research, but I did absorb some understanding of the issues and details. The "IMP Group" was literally just down the hall. > > At the time (early 1980s), I was involved in the early Internet work, when TCP/IP V4 was being created and the various flow and congestion control mechanisms were being defined. From the ARPANET experience, it was clear to me that the IMP gurus "down the hall" at BBN viewed congestion control as a major issue, and that sometimes surfaced as statements such as "TCP will never work". TCP didn't address any of the issues of congestion, except by the rudimentary and unproven mechanism of "Source Quench". > > The expectation was that the Internet would work if congestion was avoided rather than controlled, which could be attempted by keeping network capacity above traffic demands, at least long enough that TCP's retransmission and backoff mechanisms in the hosts would throttle down as expected to match what the network substrate was capable of carrying at the time. Of course those mechanisms were now distributed among the several hosts and network switches (e.g., IMPs, Packet Radios, computer OS, gateways) involved, designed, built, and managed by different organizaions, which made it challenging to predict how it would all behave. > > Even today, as an end user, I can't tell if "congestion control" is implemented and working well, or if congestion is just mostly being avoided by deployment of lots of fiber and lots of buffer memory in all the switching locations where congestion might be expected. That of course results in the phenomenon of "buffer bloat". That's another question for the Historians. Has "Congestion Control" in the Internet been solved? Or avoided? > > Jack Haverty > > > > On 2/13/23 08:19, Craig Partridge via Internet-history wrote: >> On Sat, Feb 11, 2023 at 7:48 AM Noel Chiappa via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> >>> > From: Craig Partridge >>> >>> > We figured out congestion collapse well enough for the time >>> >>> It should be remembered that the ARPANET people (hi!) had perhaps solved >>> this >>> problem a long time before. I'm trying to remember how explicitly they saw >>> this as a separate problem from the issue of running out of buffer space >>> for >>> message re-assembly at the destination IMP, but I seem to recall that RFNMs >>> were seen as a needed throttle to prevent the network as a whole from being >>> overrun (i.e. what we now think of as 'congestion', although IIRC that term >>> wasn't used then), as well as flow control to the source host (as we would >>> now call it). >>> >>> I don't recall exactly where I saw that, but I'd try the BBN proposal to >>> DARPA's RFP, and the first JFIPS paper ("The interface message processor >>> for >>> the ARPA computer network"). >>> >> I don't recall the details either, though I remember stories of Bob Kahn >> going to LA to beat up on the first few ARPANET nodes >> because he anticipated various issues, I think including congestion. And >> he found them and fixes were made. >> >> But remember ARPANET was homogeneous -- same speed for each link and a >> single control mechanism. I think John Nagle was >> the first to point out ("On packet switches with infinite storage") that >> connecting very different networks had its own challenges. >> And to my point, not something that a person working with X.25 would have >> understood terribly well (yes X.75 gateways existed but >> they typically throttled the window size to 2 packets, which hid a lot of >> issues). >> >> Craig > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From jeanjour at comcast.net Tue Feb 14 05:03:12 2023 From: jeanjour at comcast.net (John Day) Date: Tue, 14 Feb 2023 08:03:12 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <29CD3471-0AC8-403B-93B1-D7924D604541@comcast.net> Message-ID: Yep, thanks. I use to have a slide that had (drawn to scale), 576 byte IP packets over 53 byte ATM cells, over 1500 byte SONET frames with caption, ?Why?" > On Feb 13, 2023, at 16:40, Olivier MJ Cr?pin-Leblond via Internet-history wrote: > > > > On 10/02/2023 17:56, John Day via Internet-history wrote: >> ATM was a bad idea the day it was proposed. It was unbelievable how many people were taken in by it. > > ATM saw glory in PPPoA in ADSL - https://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_ATM > > As for why TCP/IP won over OSI, my take is that at the time OSI stacks really worked for large mainframe computers. The advent of PCs & desktop machines that could run early TCP/IP stacks killed the OSI stack. Credit goes in particular to: > - KA9Q - https://en.wikipedia.org/wiki/KA9Q (incidentally why is Phil Karn not in the Internet Hall of Fame?) > - Microsoft implementing TCP/IP in Win95 > - Novell NetWare TCP/IP support in the early 90s & its NE2000 card (& compatibles) > > Mainframes lost the game and along did OSI. > Best, > > Olivier > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From jeanjour at comcast.net Tue Feb 14 05:23:33 2023 From: jeanjour at comcast.net (John Day) Date: Tue, 14 Feb 2023 08:23:33 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <2A90F9DF-83D1-4B03-9777-14E9A5EB3FD3@comcast.net> Message-ID: <8FC9E89F-AC21-4AAB-B82E-ADA4AE917D89@comcast.net> One other very late reply. The context was more or less set by Craig a long time ago: > I would argue that a critical issue was communicating outside one's > organization and/or over long distance. The various technologies you list, > except for DECNET, did not focus on solving problems across organizational > boundaries. Recall Netware was the > biggest networking technology of the time and, while it adapted somewhat, > was designed to connect an office or suite > of offices. As to why OSI failed: The big reason was the internal dissension. Nothing good could be done unless you were looking far enough ahead that the phone companies didn?t know it was important. Inviting the phone companies to join the effort was a mistake but at the time, Europe didn?t have much choice. The battle over connection/connectionless was fought tooth and nail there and compromise on every word. The result was not pretty. They also wrecked the Session Layer by making it not about sessions. Another minor contributor was that the major companies participating in the effort were targeting corporate networks which were the market at the time. There was no market yet for the Internet (it was coming, but was a ways off). Of course, that changed precipitously with the Web. The Internet was there with free software and an installed base and the major companies were caught flat-footed. (All through the OSI effort, it was amazing how little the commercial world was aware of the ARPANET/Internet. All in all, OSI killed itself with its internal dissension. Not only computer companies vs phone companies, but the computer companies were warring with each other to be the leaders and kept re-fighting the discussions in the standards committees over and over in NBS/NIST workshops, and COS, remember COS? Some good results did come out of it, but they were so well hidden by the phone company screw ups few noticed. Take care, John From craig at tereschau.net Tue Feb 14 06:56:12 2023 From: craig at tereschau.net (Craig Partridge) Date: Tue, 14 Feb 2023 07:56:12 -0700 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <75E38451-64C2-410F-AF96-70E68C807291@comcast.net> References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> <75E38451-64C2-410F-AF96-70E68C807291@comcast.net> Message-ID: On Tue, Feb 14, 2023 at 6:00 AM John Day via Internet-history < internet-history at elists.isoc.org> wrote: > > > Craig, earlier you said this: > > Nicely, the most prominent and > > complementary papers on congestion issues, one by Van Jacobson (TCP/IP) > and > > one by Raj Jain and KK Ramakrishnan (DECNET), > > were presented back-to-back at the ACM SIGCOMM conference in 1988. So if > > you were looking to build (or soon after via NSFNET, connect > > to) a sturdy wide-area network, unless you were a DEC VMS organization, > > your best choice was TCP/IP. > > Were you implying that Jain?s work was unique to DECNET? I have read both > work carefully and I didn?t see anything in Jain?s report that was unique > to DECNET. And I have to say that the 4 parts of report of Jain?s team is > some of the finest computer science research I have ever seen. I wish we > saw more of it. > Hi John: I think we're in agreement but to make sure. I was not suggesting that Jain & Ramakrishnan's work was unique to DECNET but rather that it was nurtured in DECNET. More generally, the research networking team at DEC in the late 1980s was a truly amazing group of people who did a lot of fundamental work that is applicable today. Craig -- ***** Craig Partridge's email account for professional society activities and mailing lists. From clemc at ccc.com Tue Feb 14 07:09:35 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 14 Feb 2023 10:09:35 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: below ... in line. On Mon, Feb 13, 2023 at 3:28 PM Craig Partridge via Internet-history < internet-history at elists.isoc.org> wrote: > HI Scott: > > Small nit. > Craig - I'm going to pick a few nits to your nits ... > > DARPA funded Berkeley to port the BBN Unix to BSD Right .... (more in a minute) > -- and Bill Joy chose to reimplement and develop sockets. I believe that this statement is actually backward - which I think is why it is often misunderstood; and why I'm going to offer a little history/the steps in the process - as it helps explain what happened and makes it easier to understand the thinking at the time. History might have proven some as good/bad, but this is what was going on at the time to the best that know/remember - which may help explain to people -- particularly those that did not live it - the bottom line - 4.2BSD, its socket API and networking implementation was extremely economical to many people and fit a need. First an important piece of background that seems to get lost to history, but turns out to be fundamental to prove the foundation/mechanism that would allow other actions top occur. In the 1960s UCB's EE Dept had set up the ILO - Industrial Laison Office, to help coordinate the research it was doing with is sponsors like Tektronix, HP, IBM, TI and the like. One of the fruits of that work was making freely available its "open source" SW tools [SPICE/SPLICE/MOTIS et al.] *to anyone* that asked for them and, in particular, its partners in industry and academia. Remember, CS is part of EE at UCB, and when UNIX came to UCB, the ILO started freely making the local modifications (a.k.a the Berkeley Software Distribution [BSD] for UNIX) available to its members and eventually anyone with a proper UNIX license. *The point is that UCB had the mechanism in the ILO to distribute things* (9-track mag tape) - long before the Internet/websites *et al. * So having the ILO expand on that mission/operation was fairly easy / made sense at the time.[1] Also, please remember that BSD begets 2BSD [both PDP-11], which begets 3BSD and later 4BSD and 4.1BSD for the VAX [these are basically available on TUHS.org for anyone interested]. These distributions became popular in the universities/research community diue to the AT&T 1956 concept degree and licensing arrangement. Those sites are superset of a great deal of the ARPA research community. ARPA eventually chose to stop funding the use of 36-bit PDP-10s and switch to the 32-bit VAX line [numerious battle ensues which I'm going to ignore although I was there at the time], but in the end, the UCB's CSRG (Joy et al.) was created and given a contract 'to support and enhance UNIX' for the DARPA since AT&T was not going too. By the way, DARPA set up a committee to try to "steer" that effort -- IIRC Al Nemeth may have chaired it [In my mind, those earlier meetings I think of as the processors to the IETFs]. But as Craig has pointed out, BBN had the ARPA contract to develop IP/TCP for several systems, *including UNIX for the VAX* [IIRC They did a 'portable' IP/TCP stack that was used for the DG/Nova and the HP3000 and as a side note - as I understand it, the original MBUF code came from that implementation -- Rob needed a hunk of memory he controlled that was easy to interface into number of different OSes - if 'portable C implementation of IP' code is known to exist - again we would like to added to the TUHS.org archives]. During this time, the CMU folks sends out the SPICE proposal [which I need to put online somewhere - I have a copy in my archives] - which ended up starting the Accent/Mach *et al* work. Stanford did the SUN, V Kernel, and the W windows system, MIT eventually created Athena, which would give us X-Windows and Steve Ward's group at MIT gave us the Nu machine/its UNIX ports and compilers. If you look at the original BBN (Gurwitz) UNIX IP/TCP stack implementation, Rob had used the traditional file API - open/close/read/write paradigm that UNIX always had -- similar to the University of Ill / Rand NCP and the MIT ChaosNet code base -- where a programmer could open a connection to a remote system by opening a path to a special file: "/dev/tcp/host" or some such. I've forgotten the complete syntax, although a copy of the sources/distribution is in the BBN archive on TUHS.org for the curious. Stanford V-Kernel, CMU's Accent (and later Mach) were all exploring distributed computing paradigms and different APIs to enable things. Also note that, the Accent PORT concept was considered quite elegant at the time (there were other schemes such as what DEMOS and V used, but being in the room as were, IMO Accent was the one that Joy seems to have a hang up). As part of Joy's work to support UNIX at the time ( in at least one UCB System seminar which I was present), he expressed his belief that he base his networking scheme using the traditional 'everything is a file idea but add new functionality that does some of the same tricks ports could do (like passing rights over an open file descriptor). He also felt that the open(path to special file) scheme was inelegant compared to "modern" OS concepts of them. You also need to remember that while the ARPA (CS) community was gungho about IP/TCP, other parts of the industry, including other parts of the US Gov, tended to have more industrial alignment with Boeing/Ford *et al.*, and were pushing ISO; Xerox, of course, has PUP - which begets XNS. So Bill created a new set of APIs for his enhanced UNIX for DARPA that was supposed to be protocol stack independent but still retains the traditional UNIX I/O semantics. Thus the sockets API was born ... Note at that time at UCB EECS dept, we already had the BBN code running on our *4.1BSD*-based Vaxen - just like what BBN had targeted. In fact, in Cory Hall, Eric Cooper and I had installed it in the CAD systems which I was associated at the time and IIRC Eric and Eric Allman brought it up on IngVax which was the UCB APRAnet connection originally (replacing Ing70). Sam, of course, had the BBN code base running on the Ethernet in Evans Hall where all the VAX750s and we had 10 M coax between to the two buildings. San would write the original routed(1) to keep our LANs updated (based on the something similar he had seen at PARC for PUP). The BBN code, as is, was not going to work in the new interface that Bill was imagining and thus he believed had to be implemented. But notice the new UCB IP/TCP creation inherits a lot of things (such as the MBUFS from BBN code base). When he was adding his new sockets code to the new kernel, Bill decided to rewrite pieces of the stack itself instead of trying to move it. My point here is that *Bill reimplemented BBN, but it was hardly a scratch rewrite*. To be honest, if you look at his implementation - such as the MBUF code, I probably would not have used it, if I were starting from scratch. In fact, I can say, when Stan and I wrote the original VMS IP stack at Tektronix a few years earlier, most of the time and debugging was around the memory code - as we learned how to call into Culter's memory system (I always found it interesting that Bill wrote the BSD memory system, and he still chose to use MBUFs). *Thus I believe what happened is that Bill grabbed an idea/implementation concept/maybe even a routine and then reformed it into what he needed; but that works was done decidedly after sockets were already created. *But the point is that the first sockets API went into BSD4.1A and as wnj was building them up and created an update/reimplemented stack. How much was new, how much was not was debatable. FWIW: Gurwitz and team re-wrote their stack (which I call BBN2 and also seems to be lost to time -- if anyone has a copy - please let me know offline - as I said, TUHS would like it for the archives], that did reimplement the BBN stack in the key of a later tickets [remember sockets went through a couple of changes 4.1ABSD sockets != 4.1C sockets although 4.1c is fairly close to what eventually came out in the 4.2BSD release.[2] What gets lost to time I think is that while the entire code in the stack that implements IP/TCP for 4.2BSD != BBN. You need to look at the sockets code independently of the networking stack implementation. Its true the #1 consumer would be IP/TCP and there is evidence [Marshall Rose's ISO stack for example and Novell XNS Stack] that WNJ's interface was really only reasonable for IP without more work, Bill did succeed in his idea as UNIX Domain sockets of getting what he set out to build. For getting the influence of other conteporary OS efforts and their APIs such Accent, DEMOS, V-Kernel and focussing only on the stack is likely to cause you to miss some important things that were the cause of what was the result/not ther other way around. I too am of the 'less is more' school and always found the open(special_file) call a tad similper to understand in terms of UNIX. That said, using that API reveals a great example of how UNIX's ioctl(2) ended up becoming the soft underbelly of many of those implementations. So there is a reasonable cause to believe that Bill may have been correct that a new system interfaces were needed. But of course, elegance is not good enough. The AT&T USG Streams implementation while in many ways more elegant than 'pure-joy' sockets, it failed because the stacks and what were behind them were not very good and the truth is sockets were good-enough. which as I have said many times: "Simple Economics always beats Sophisticated Design " Clem [1] You might ask - why is the ILO important to the Internet story? Well before the Internet, sharing SW in particular, was a bit more complicated - you had to share magtapes via physical mail/UPS. Yes, the small ARPANet community had FTP [but remember UCB is really an major ARPANet player when this all starts - but the ARPANET Researchers are primarily PDP-10s shops. Places like UCB are running CDC, SDS and maybe IBM gear]. Long before UCB was involved with UNIX, it already had a mechanism and a culture of making its work available. The Berkeley (UNIX) SW Distribution was just a natural result of an older practice and used that mechanism. As another side note, IMO the true 'father of open source software' [we did not have a name for it then] was the late Prof. Donald O. Pederson (a.k.a. "dop" to his students). At a time where CMU, Stanford, MIT et al, were often making licensing agreements for their work, dop gave everything away. His wisdom was expressed best with the words: *"If I license our work, I walk in the front door like any other salesman. But if we give it away, we get to walk in the backdoor. We are invited into their labs and we are asked to work with them becoming their partner."* [2] In fact at Stellar, we added sockets to a SRV3 kernel, then used the BBN2 stack not the BSD one, as we felt it was easier to all parallel executing too, (particularly because of course we were using a SRV3 Memory System, not a 4.2BSD one]. From vgcerf at gmail.com Tue Feb 14 07:21:29 2023 From: vgcerf at gmail.com (vinton cerf) Date: Tue, 14 Feb 2023 10:21:29 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: Clem, wow thanks for this lengthy history. So many familiar names. I sure hope this mailing list does get archived properly as it contains a wealth of information it would be hard to re-create in the future. The success of TCP/IP is a direct consequence of the many people who devoted so much time and effort to making it work, improving its operation and porting it to so many platforms. v On Tue, Feb 14, 2023 at 10:10 AM Clem Cole via Internet-history < internet-history at elists.isoc.org> wrote: > below ... in line. > > On Mon, Feb 13, 2023 at 3:28 PM Craig Partridge via Internet-history < > internet-history at elists.isoc.org> wrote: > > > HI Scott: > > > > Small nit. > > > Craig - I'm going to pick a few nits to your nits ... > > > > > DARPA funded Berkeley to port the BBN Unix to BSD > > Right .... (more in a minute) > > > > > > -- and Bill Joy chose to reimplement and develop sockets. > > I believe that this statement is actually backward - which I think is why > it is often misunderstood; and why I'm going to offer a little history/the > steps in the process - as it helps explain what happened and makes it > easier to understand the thinking at the time. History might have proven > some as good/bad, but this is what was going on at the time to the best > that know/remember - which may help explain to people -- particularly those > that did not live it - the bottom line - 4.2BSD, its socket API and > networking implementation was extremely economical to many people and fit a > need. > > First an important piece of background that seems to get lost to history, > but turns out to be fundamental to prove the foundation/mechanism that > would allow other actions top occur. > > In the 1960s UCB's EE Dept had set up the ILO - Industrial Laison Office, > to help coordinate the research it was doing with is sponsors like > Tektronix, HP, IBM, TI and the like. One of the fruits of that work was > making freely available its "open source" SW tools [SPICE/SPLICE/MOTIS et > al.] *to anyone* that asked for them and, in particular, its partners in > industry and academia. Remember, CS is part of EE at UCB, and when UNIX > came to UCB, the ILO started freely making the local modifications (a.k.a > the Berkeley Software Distribution [BSD] for UNIX) available to its members > and eventually anyone with a proper UNIX license. *The point is that UCB > had the mechanism in the ILO to distribute things* (9-track mag tape) - > long before the Internet/websites *et al. * So having the ILO expand on > that mission/operation was fairly easy / made sense at the time.[1] > > Also, please remember that BSD begets 2BSD [both PDP-11], which begets 3BSD > and later 4BSD and 4.1BSD for the VAX [these are basically available on > TUHS.org for anyone interested]. These distributions became popular in the > universities/research community diue to the AT&T 1956 concept degree and > licensing arrangement. Those sites are superset of a great deal of the ARPA > research community. > > ARPA eventually chose to stop funding the use of 36-bit PDP-10s and switch > to the 32-bit VAX line [numerious battle ensues which I'm going to ignore > although I was there at the time], but in the end, the UCB's CSRG (Joy et > al.) was created and given a contract 'to support and enhance UNIX' for the > DARPA since AT&T was not going too. By the way, DARPA set up a committee to > try to "steer" that effort -- IIRC Al Nemeth may have chaired it [In my > mind, those earlier meetings I think of as the processors to the IETFs]. > > But as Craig has pointed out, BBN had the ARPA contract to develop IP/TCP > for several systems, *including UNIX for the VAX* [IIRC They did a > 'portable' IP/TCP stack that was used for the DG/Nova and the HP3000 and > as a side note - as I understand it, the original MBUF code came from that > implementation -- Rob needed a hunk of memory he controlled that was easy > to interface into number of different OSes - if 'portable C implementation > of IP' code is known to exist - again we would like to added to the > TUHS.org archives]. > > During this time, the CMU folks sends out the SPICE proposal [which I need > to put online somewhere - I have a copy in my archives] - which ended up > starting the Accent/Mach *et al* work. Stanford did the SUN, V Kernel, and > the W windows system, MIT eventually created Athena, which would give us > X-Windows and Steve Ward's group at MIT gave us the Nu machine/its UNIX > ports and compilers. > > If you look at the original BBN (Gurwitz) UNIX IP/TCP stack implementation, > Rob had used the traditional file API - open/close/read/write paradigm that > UNIX always had -- similar to the University of Ill / Rand NCP and the MIT > ChaosNet code base -- where a programmer could open a connection to a > remote system by opening a path to a special file: "/dev/tcp/host" or some > such. I've forgotten the complete syntax, although a copy of the > sources/distribution is in the BBN archive on TUHS.org for the curious. > > > Stanford V-Kernel, CMU's Accent (and later Mach) were all exploring > distributed computing paradigms and different APIs to enable things. Also > note that, the Accent PORT concept was considered quite elegant at the time > (there were other schemes such as what DEMOS and V used, but being in the > room as were, IMO Accent was the one that Joy seems to have a hang up). As > part of Joy's work to support UNIX at the time ( in at least one UCB System > seminar which I was present), he expressed his belief that he base his > networking scheme using the traditional 'everything is a file idea but add > new functionality that does some of the same tricks ports could do (like > passing rights over an open file descriptor). He also felt that the > open(path to special file) scheme was inelegant compared to "modern" OS > concepts of them. You also need to remember that while the ARPA (CS) > community was gungho about IP/TCP, other parts of the industry, including > other parts of the US Gov, tended to have more industrial alignment with > Boeing/Ford *et al.*, and were pushing ISO; Xerox, of course, has PUP - > which begets XNS. So Bill created a new set of APIs for his enhanced UNIX > for DARPA that was supposed to be protocol stack independent but still > retains the traditional UNIX I/O semantics. > > Thus the sockets API was born ... > > Note at that time at UCB EECS dept, we already had the BBN code running on > our *4.1BSD*-based Vaxen - just like what BBN had targeted. In fact, in > Cory Hall, Eric Cooper and I had installed it in the CAD systems which I > was associated at the time and IIRC Eric and Eric Allman brought it up on > IngVax which was the UCB APRAnet connection originally (replacing Ing70). > Sam, of course, had the BBN code base running on the Ethernet in Evans Hall > where all the VAX750s and we had 10 M coax between to the two buildings. > San would write the original routed(1) to keep our LANs updated (based on > the something similar he had seen at PARC for PUP). > > The BBN code, as is, was not going to work in the new interface that Bill > was imagining and thus he believed had to be implemented. But notice the > new UCB IP/TCP creation inherits a lot of things (such as the MBUFS from > BBN code base). When he was adding his new sockets code to the new kernel, > Bill decided to rewrite pieces of the stack itself instead of trying to > move it. > > My point here is that *Bill reimplemented BBN, but it was hardly a scratch > rewrite*. To be honest, if you look at his implementation - such as the > MBUF code, I probably would not have used it, if I were starting from > scratch. In fact, I can say, when Stan and I wrote the original VMS IP > stack at Tektronix a few years earlier, most of the time and debugging was > around the memory code - as we learned how to call into Culter's memory > system (I always found it interesting that Bill wrote the BSD memory > system, and he still chose to use MBUFs). > > *Thus I believe what happened is that Bill grabbed an idea/implementation > concept/maybe even a routine and then reformed it into what he needed; but > that works was done decidedly after sockets were already created. *But > the point is that the first sockets API went into BSD4.1A and as wnj was > building them up and created an update/reimplemented stack. How much was > new, how much was not was debatable. > > FWIW: Gurwitz and team re-wrote their stack (which I call BBN2 and also > seems to be lost to time -- if anyone has a copy - please let me know > offline - as I said, TUHS would like it for the archives], that did > reimplement the BBN stack in the key of a later tickets [remember sockets > went through a couple of changes 4.1ABSD sockets != 4.1C sockets although > 4.1c is fairly close to what eventually came out in the 4.2BSD release.[2] > > What gets lost to time I think is that while the entire code in the stack > that implements IP/TCP for 4.2BSD != BBN. You need to look at the sockets > code independently of the networking stack implementation. Its true the #1 > consumer would be IP/TCP and there is evidence [Marshall Rose's ISO stack > for example and Novell XNS Stack] that WNJ's interface was really only > reasonable for IP without more work, Bill did succeed in his idea as UNIX > Domain sockets of getting what he set out to build. For getting the > influence of other conteporary OS efforts and their APIs such Accent, > DEMOS, V-Kernel and focussing only on the stack is likely to cause you to > miss some important things that were the cause of what was the result/not > ther other way around. > > I too am of the 'less is more' school and always found the > open(special_file) call a tad similper to understand in terms of UNIX. > That said, using that API reveals a great example of how UNIX's ioctl(2) > ended up becoming the soft underbelly of many of those implementations. So > there is a reasonable cause to believe that Bill may have been correct that > a new system interfaces were needed. But of course, elegance is not good > enough. The AT&T USG Streams implementation while in many ways more elegant > than 'pure-joy' sockets, it failed because the stacks and what were behind > them were not very good and the truth is sockets were good-enough. which as > I have said many times: "Simple Economics always beats Sophisticated > Design > " > > Clem > > > [1] You might ask - why is the ILO important to the Internet story? Well > before the Internet, sharing SW in particular, was a bit more complicated - > you had to share magtapes via physical mail/UPS. Yes, the small ARPANet > community had FTP [but remember UCB is really an major ARPANet player when > this all starts - but the ARPANET Researchers are primarily PDP-10s shops. > Places like UCB are running CDC, SDS and maybe IBM gear]. Long before UCB > was involved with UNIX, it already had a mechanism and a culture of making > its work available. The Berkeley (UNIX) SW Distribution was just a natural > result of an older practice and used that mechanism. As another side > note, IMO the true 'father of open source software' [we did not have a name > for it then] was the late Prof. Donald O. Pederson (a.k.a. "dop" to his > students). At a time where CMU, Stanford, MIT et al, were often making > licensing agreements for their work, dop gave everything away. His wisdom > was expressed best with the words: *"If I license our work, I walk in the > front door like any other salesman. But if we give it away, we get to > walk in the backdoor. We are invited into their labs and we are asked to > work with them becoming their partner."* > > [2] In fact at Stellar, we added sockets to a SRV3 kernel, then used the > BBN2 stack not the BSD one, as we felt it was easier to all parallel > executing too, (particularly because of course we were using a SRV3 Memory > System, not a 4.2BSD one]. > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From woody at pch.net Tue Feb 14 07:36:49 2023 From: woody at pch.net (Bill Woodcock) Date: Tue, 14 Feb 2023 16:36:49 +0100 Subject: [ih] Running long-term archives of this list? In-Reply-To: References: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> Message-ID: <03BFF67E-2339-4D84-BC28-732EE88A95FF@pch.net> The Internet Archive is not the first choice for some reason? -Bill > On Feb 14, 2023, at 2:33 AM, touch--- via Internet-history wrote: > > The issue has typically been the difference between ?here, archive this? and a living list. The latter has been very difficult to get anyone to consider. > > Joe > > ? > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com > >> On Feb 13, 2023, at 1:52 PM, vinton cerf wrote: >> >> Carnegie-Mellon has an archive - check with Raj Reddy? >> >> v >> >> >> On Mon, Feb 13, 2023 at 4:03 PM touch--- via Internet-history > wrote: >>> Hi, all, >>> >>> I?ve looked into this before. The obvious choice would be the Computer History Museum, but they didn?t know what I was asking for the last time I tried them. >>> >>> Very few places actually run true museum-quality backups or storage of ANYTHING (libraries are the exception). Even university archives don?t - they don?t separate acid-free from not, etc. And nobody moves data from medium to medium as it evolves, i.e., so we can read things in the future without needing a non-existent 9-track tape drive. >>> >>> If anyone finds a solution that?d work for free, please do keep me posted. Until then, I figure we rely on the kindness of places like the Wayback Machine. >>> >>> Joe (list admin) >>> >>> ? >>> Dr. Joe Touch, temporal epistemologist >>> www.strayalpha.com >>> >>>> On Feb 13, 2023, at 8:27 AM, Dave Crocker via Internet-history > wrote: >>>> >>>> Reflecting, once again, on the considerable depth and breadth of historical technical knowledge that is regularly demonstrated on this list, I'm wondering about how robustly is is archives and how easily the various archives can be accessed. >>>> >>>> Yes it's hosted by isoc, but I'm asking about long-term (museum-quality) data archival. (We tend to think of back and archive as the same, but they aren't.) >>>> >>>> Also note I cited 'running' which means that even this message should hit those long-term archives pretty quickly. >>>> >>>> d/ >>>> >>>> -- >>>> Dave Crocker >>>> Brandenburg InternetWorking >>>> bbiw.net >>>> mast:@dcrocker at mastodon.social >>>> >>>> -- >>>> 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 From touch at strayalpha.com Tue Feb 14 07:55:25 2023 From: touch at strayalpha.com (touch at strayalpha.com) Date: Tue, 14 Feb 2023 07:55:25 -0800 Subject: [ih] Running long-term archives of this list? In-Reply-To: <03BFF67E-2339-4D84-BC28-732EE88A95FF@pch.net> References: <46eaa3fc-3d54-7618-6833-0829ee0357a3@dcrocker.net> <03BFF67E-2339-4D84-BC28-732EE88A95FF@pch.net> Message-ID: <56EF8299-8173-47EC-92A9-C2F86104FE7B@strayalpha.com> That already happens because our archives are open and linked off the public ISOC pages. Joe ? Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Feb 14, 2023, at 7:36 AM, Bill Woodcock wrote: > > The Internet Archive is not the first choice for some reason? > > -Bill > > > >> On Feb 14, 2023, at 2:33 AM, touch--- via Internet-history wrote: >> >> The issue has typically been the difference between ?here, archive this? and a living list. The latter has been very difficult to get anyone to consider. >> >> Joe >> >> ? >> Dr. Joe Touch, temporal epistemologist >> www.strayalpha.com >> >>> On Feb 13, 2023, at 1:52 PM, vinton cerf wrote: >>> >>> Carnegie-Mellon has an archive - check with Raj Reddy? >>> >>> v >>> >>> >>> On Mon, Feb 13, 2023 at 4:03 PM touch--- via Internet-history > wrote: >>>> Hi, all, >>>> >>>> I?ve looked into this before. The obvious choice would be the Computer History Museum, but they didn?t know what I was asking for the last time I tried them. >>>> >>>> Very few places actually run true museum-quality backups or storage of ANYTHING (libraries are the exception). Even university archives don?t - they don?t separate acid-free from not, etc. And nobody moves data from medium to medium as it evolves, i.e., so we can read things in the future without needing a non-existent 9-track tape drive. >>>> >>>> If anyone finds a solution that?d work for free, please do keep me posted. Until then, I figure we rely on the kindness of places like the Wayback Machine. >>>> >>>> Joe (list admin) >>>> >>>> ? >>>> Dr. Joe Touch, temporal epistemologist >>>> www.strayalpha.com >>>> >>>>> On Feb 13, 2023, at 8:27 AM, Dave Crocker via Internet-history > wrote: >>>>> >>>>> Reflecting, once again, on the considerable depth and breadth of historical technical knowledge that is regularly demonstrated on this list, I'm wondering about how robustly is is archives and how easily the various archives can be accessed. >>>>> >>>>> Yes it's hosted by isoc, but I'm asking about long-term (museum-quality) data archival. (We tend to think of back and archive as the same, but they aren't.) >>>>> >>>>> Also note I cited 'running' which means that even this message should hit those long-term archives pretty quickly. >>>>> >>>>> d/ >>>>> >>>>> -- >>>>> Dave Crocker >>>>> Brandenburg InternetWorking >>>>> bbiw.net >>>>> mast:@dcrocker at mastodon.social >>>>> >>>>> -- >>>>> 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 > From jeanjour at comcast.net Tue Feb 14 08:00:12 2023 From: jeanjour at comcast.net (John Day) Date: Tue, 14 Feb 2023 11:00:12 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> <75E38451-64C2-410F-AF96-70E68C807291@comcast.net> Message-ID: <5A86D4C4-94B5-4C0B-8CE0-62138C999725@comcast.net> Agreed > On Feb 14, 2023, at 09:56, Craig Partridge wrote: > > > > On Tue, Feb 14, 2023 at 6:00 AM John Day via Internet-history > wrote: > > > Craig, earlier you said this: > > Nicely, the most prominent and > > complementary papers on congestion issues, one by Van Jacobson (TCP/IP) and > > one by Raj Jain and KK Ramakrishnan (DECNET), > > were presented back-to-back at the ACM SIGCOMM conference in 1988. So if > > you were looking to build (or soon after via NSFNET, connect > > to) a sturdy wide-area network, unless you were a DEC VMS organization, > > your best choice was TCP/IP. > > Were you implying that Jain?s work was unique to DECNET? I have read both work carefully and I didn?t see anything in Jain?s report that was unique to DECNET. And I have to say that the 4 parts of report of Jain?s team is some of the finest computer science research I have ever seen. I wish we saw more of it. > > Hi John: > > I think we're in agreement but to make sure. I was not suggesting that Jain & Ramakrishnan's work was unique to DECNET but rather that it was nurtured in DECNET. More generally, the research networking team at DEC in the late 1980s was a truly amazing group of people who did a lot of fundamental work that is applicable today. > > Craig > > -- > ***** > Craig Partridge's email account for professional society activities and mailing lists. From johnl at iecc.com Tue Feb 14 11:48:53 2023 From: johnl at iecc.com (John Levine) Date: 14 Feb 2023 14:48:53 -0500 Subject: [ih] Running long-term archives of this list? In-Reply-To: <20230213205847.mQMcv%steffen@sdaoden.eu> Message-ID: <20230214194853.B53B0990115C@ary.qy> It appears that Steffen Nurpmeso via Internet-history said: >Museum quality? I hope the isoc people create real MBOX archives, >and do not solely rely on that pipermail HTML mutilation. That >would really be a pity! If so, then it would be tremendous if >that single file archive would be made available somewhere!! Um, when I look at the archive page, I see a column "Gzip'd Text" which is an mbox file for each month. If you want to glue them together into one giant mbox, that'd be a pretty simple script. R's, John From brian.e.carpenter at gmail.com Tue Feb 14 12:02:23 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 15 Feb 2023 09:02:23 +1300 Subject: [ih] Running long-term archives of this list? In-Reply-To: <20230214040246.A07B8987B356@ary.qy> References: <20230214040246.A07B8987B356@ary.qy> Message-ID: <4f3b4819-fadc-c0e3-0aa9-336b92bcd8cc@gmail.com> On 14-Feb-23 17:02, John Levine via Internet-history wrote: ... > The Charles Babbage Institute at U of Minnesota should also be > interested, dunno anyone there either. James W. Cortada Senior Research Fellow Charles Babbage Institute University of Minnesota jcortada at umn.edu He's fairly active on the SIGCIS list but I don't know if he's much interested in Internet history. Brian From brian.e.carpenter at gmail.com Tue Feb 14 13:12:27 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 15 Feb 2023 10:12:27 +1300 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <29CD3471-0AC8-403B-93B1-D7924D604541@comcast.net> Message-ID: <9d5d7e87-2b5a-2306-442d-a88cad4e7771@gmail.com> On 15-Feb-23 02:03, John Day via Internet-history wrote: > Yep, thanks. > > I use to have a slide that had (drawn to scale), 576 byte IP packets over 53 byte ATM cells, over 1500 byte SONET frames with caption, ?Why?" There was a report by Ramon Caceras** in 1991 which (from memory) showed that based on the observed distribution of IPv4 packet sizes on the Internet, the worst possible cell size, i.e. the cell size that would lead to the maximum number of runt cells with partial payloads, was ~50. In other words, given that the alternative cell payload sizes considered by CCITT were 32 and 64, they chose the worst possible compromise, from the viewpoint of Internet traffic. I once sat at dinner with Jacques Saint-Blancat from IBM La Gaude (in France) who was secretary of that particular CCITT study group, and proudly told me that he personally was the first person to write down that "48" payload size in his meeting notes. ** http://www.icsi.berkeley.edu/pubs/techreports/tr-91-043.pdf Brian > >> On Feb 13, 2023, at 16:40, Olivier MJ Cr?pin-Leblond via Internet-history wrote: >> >> >> >> On 10/02/2023 17:56, John Day via Internet-history wrote: >>> ATM was a bad idea the day it was proposed. It was unbelievable how many people were taken in by it. >> >> ATM saw glory in PPPoA in ADSL - https://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_ATM >> >> As for why TCP/IP won over OSI, my take is that at the time OSI stacks really worked for large mainframe computers. The advent of PCs & desktop machines that could run early TCP/IP stacks killed the OSI stack. Credit goes in particular to: >> - KA9Q - https://en.wikipedia.org/wiki/KA9Q (incidentally why is Phil Karn not in the Internet Hall of Fame?) >> - Microsoft implementing TCP/IP in Win95 >> - Novell NetWare TCP/IP support in the early 90s & its NE2000 card (& compatibles) >> >> Mainframes lost the game and along did OSI. >> Best, >> >> Olivier >> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history > From jeanjour at comcast.net Tue Feb 14 14:26:06 2023 From: jeanjour at comcast.net (John Day) Date: Tue, 14 Feb 2023 17:26:06 -0500 Subject: [ih] Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <9d5d7e87-2b5a-2306-442d-a88cad4e7771@gmail.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <1331585175.3138795.1676046818865@mail.yahoo.com> <29CD3471-0AC8-403B-93B1-D7924D604541@comcast.net> <9d5d7e87-2b5a-2306-442d-a88cad4e7771@gmail.com> Message-ID: To some degree, Stratacom had the right idea and then ATM screwed it up. As I explained Yaakov at a SC6 meeting in the mid-90s in Seoul, the right next step was what became MPLS. But they screwed that up too. By then it was apparent where the problem was going, but there was still a lot of detail to work out. (It takes longer when it isn?t your job.) > On Feb 14, 2023, at 16:12, Brian E Carpenter wrote: > > On 15-Feb-23 02:03, John Day via Internet-history wrote: >> Yep, thanks. >> I use to have a slide that had (drawn to scale), 576 byte IP packets over 53 byte ATM cells, over 1500 byte SONET frames with caption, ?Why?" > > There was a report by Ramon Caceras** in 1991 which (from memory) showed that based on the observed distribution of IPv4 packet sizes on the Internet, the worst possible cell size, i.e. the cell size that would lead to the maximum number of runt cells with partial payloads, was ~50. In other words, given that the alternative cell payload sizes considered by CCITT were 32 and 64, they chose the worst possible compromise, from the viewpoint of Internet traffic. > > I once sat at dinner with Jacques Saint-Blancat from IBM La Gaude (in France) who was secretary of that particular CCITT study group, and proudly told me that he personally was the first person to write down that "48" payload size in his meeting notes. > > ** http://www.icsi.berkeley.edu/pubs/techreports/tr-91-043.pdf > > Brian > >>> On Feb 13, 2023, at 16:40, Olivier MJ Cr?pin-Leblond via Internet-history wrote: >>> >>> >>> >>> On 10/02/2023 17:56, John Day via Internet-history wrote: >>>> ATM was a bad idea the day it was proposed. It was unbelievable how many people were taken in by it. >>> >>> ATM saw glory in PPPoA in ADSL - https://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_ATM >>> >>> As for why TCP/IP won over OSI, my take is that at the time OSI stacks really worked for large mainframe computers. The advent of PCs & desktop machines that could run early TCP/IP stacks killed the OSI stack. Credit goes in particular to: >>> - KA9Q - https://en.wikipedia.org/wiki/KA9Q (incidentally why is Phil Karn not in the Internet Hall of Fame?) >>> - Microsoft implementing TCP/IP in Win95 >>> - Novell NetWare TCP/IP support in the early 90s & its NE2000 card (& compatibles) >>> >>> Mainframes lost the game and along did OSI. >>> Best, >>> >>> Olivier >>> >>> -- >>> Internet-history mailing list >>> Internet-history at elists.isoc.org >>> https://elists.isoc.org/mailman/listinfo/internet-history From gnu at toad.com Wed Feb 15 22:08:35 2023 From: gnu at toad.com (John Gilmore) Date: Wed, 15 Feb 2023 22:08:35 -0800 Subject: [ih] Archiving Internet history In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> Message-ID: <26854.1676527715@hop.toad.com> vinton cerf via Internet-history wrote: > wow thanks for this lengthy history. So many familiar names. I sure hope > this mailing list does get archived properly as it contains a wealth of > information it would be hard to re-create in the future. Besides the internet-history mailing list's archives here: https://elists.isoc.org/pipermail/internet-history/ I have also been using an Archive-It account to make periodic copies of that web site in the Internet Archive here: https://wayback.archive-it.org/15071/20230114211520/https://elists.isoc.org/pipermail/internet-history/ These are accessible via the Wayback Machine as well as via the page for this collection, here: Internet and Unix History https://archive-it.org/collections/15071 As you can see there, it's set up to periodically scan various other URLs; please suggest others that are of historic interest, and I can add them. FYI, the Wayback Machine does not necessarily get deep copies of every web site. Their focus is on breadth, so if a website has a thousand web pages, perhaps they will get 50 or 100 of them in each crawl. Also, there are enough websites which are designed to "trap" a web crawler and cause it to waste a lot of its time, storage and bandwidth uselessly, so the main crawler doesn't keep going. So, if there's a deep collection (for example, ALL the source code to reproduce a popular Linux distribution) that you think is worth saving for the future, Archive-It.org is one way to get it saved for posterity. Also FYI, the Internet Archive is an example of the philosophy of putting all your eggs in one basket and watching that basket intently. The (untested) theory is that the collection will be too valuable to let it fall apart later. A distributed system (like LOCKSS for example) would provide higher likelihood of stuff surviving the next hundred, thousand or 10,000 years. The Archive is keeping two or three replicated copies of each item they have, and copying them forward onto newer and fatter drives, but all of them are under the same administration and owned by the same nonprofit. Brewster Kahle is the sparkplug and the main funding source; control of that nonprofit will be in the hands of a small number of probably-less-competent-and-virtuous people after Brewster is no more. Hell, during the pandemic, ONE GUY was responsible for swapping out failed disk drives before the only second copy of a failed drive happened to also fail. Bit-rot sets in quickly, and five or ten years of merely incompetent system administration would make a shambles of this finely tuned machine. Not to mention the possibility of malicious intrusion, particularly by people or governments who want to destroy the historical evidence of whatever bad stuff they've been up to. It would be better if there were ten Internet Archive nonprofits (or government agencies) scattered around the planet. Each of them would ideally be taking copies of each others' full holdings, as well as doing their own crawls of the live web, and scanning in whatever physical cultural works they are particularly interested in. Anybody know any Internet billionaires or spy-agency VP's who want to catalyze and endow a second Internet Archive? The big advantage for spy agencies is stealth; you can look anywhere you want in your own archive, and nobody knows where you are looking. John From b_a_denny at yahoo.com Thu Feb 16 09:18:48 2023 From: b_a_denny at yahoo.com (Barbara Denny) Date: Thu, 16 Feb 2023 17:18:48 +0000 (UTC) Subject: [ih] Fw: Installed base momentum (was Re: Design choices in SMTP) In-Reply-To: <1477471854.1260638.1676332816959@mail.yahoo.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <2A90F9DF-83D1-4B03-9777-14E9A5EB3FD3@comcast.net> <95bbf8a5-c3eb-ec94-fcf7-43ab4b9e 4455@3kitty.org> <1477471854.1260638.1676332816959@mail.yahoo.com> Message-ID: <719106224.2719985.1676567928964@mail.yahoo.com> I have had problems sending this particular message to the list.? ?Hope it finally gets delivered.? barbara ----- Forwarded Message ----- From: Barbara Denny To: Internet-history Sent: Monday, February 13, 2023 at 04:00:17 PM PSTSubject: Re: [ih] Installed base momentum (was Re: Design choices in SMTP) It is very unfortunate Charlie Lynn is no longer with us so he could provide some info.? I could be wrong but I believe Charlie spent a lot of his time on TCP (for the TOPS -20) at BBN at least during 1981 - 1983 timeframe. This was the time I was working on packet radio at BBN.? During our weekly? meetings Charlie would report on TCP.? I am mentioning this in case someone wants to search for more information.? ?You might not realize you need to look at reports which include packet radio. Jil Westcott was the packet radio manager at that time so her name might be on most of the reports. BTW while I was searching briefly for project reports last summer I noticed Jil mentioned? contractually there had been a change. This would result in some efforts no longer being reported under this project.? I don't remember when this happened but I think it was after 1983. barbara From vgcerf at gmail.com Thu Feb 16 10:03:14 2023 From: vgcerf at gmail.com (vinton cerf) Date: Thu, 16 Feb 2023 13:03:14 -0500 Subject: [ih] Archiving Internet history In-Reply-To: <26854.1676527715@hop.toad.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <26854.1676527715@hop.toad.com> Message-ID: John, thanks for your thoughtful intervention. Your conclusion leads me to wonder about business models that might produce the desired resilience. Preservation by accident is not a plan and so often that's all that we achieve. v On Thu, Feb 16, 2023 at 1:08 AM John Gilmore wrote: > vinton cerf via Internet-history wrote: > > wow thanks for this lengthy history. So many familiar names. I sure hope > > this mailing list does get archived properly as it contains a wealth of > > information it would be hard to re-create in the future. > > Besides the internet-history mailing list's archives here: > > https://elists.isoc.org/pipermail/internet-history/ > > I have also been using an Archive-It account to make periodic copies of > that web site in the Internet Archive here: > > > https://wayback.archive-it.org/15071/20230114211520/https://elists.isoc.org/pipermail/internet-history/ > > These are accessible via the Wayback Machine as well as via > the page for this collection, here: > > Internet and Unix History > https://archive-it.org/collections/15071 > > As you can see there, it's set up to periodically scan various other URLs; > please suggest others that are of historic interest, and I can add them. > > FYI, the Wayback Machine does not necessarily get deep copies of every > web site. Their focus is on breadth, so if a website has a thousand web > pages, perhaps they will get 50 or 100 of them in each crawl. Also, > there are enough websites which are designed to "trap" a web crawler and > cause it to waste a lot of its time, storage and bandwidth uselessly, so > the main crawler doesn't keep going. So, if there's a deep collection > (for example, ALL the source code to reproduce a popular Linux > distribution) that you think is worth saving for the future, > Archive-It.org is one way to get it saved for posterity. > > Also FYI, the Internet Archive is an example of the philosophy of > putting all your eggs in one basket and watching that basket intently. > The (untested) theory is that the collection will be too valuable to let > it fall apart later. A distributed system (like LOCKSS for example) > would provide higher likelihood of stuff surviving the next hundred, > thousand or 10,000 years. The Archive is keeping two or three > replicated copies of each item they have, and copying them forward onto > newer and fatter drives, but all of them are under the same > administration and owned by the same nonprofit. Brewster Kahle is the > sparkplug and the main funding source; control of that nonprofit will be > in the hands of a small number of probably-less-competent-and-virtuous > people after Brewster is no more. Hell, during the pandemic, ONE GUY > was responsible for swapping out failed disk drives before the only > second copy of a failed drive happened to also fail. Bit-rot sets in > quickly, and five or ten years of merely incompetent system > administration would make a shambles of this finely tuned machine. Not > to mention the possibility of malicious intrusion, particularly by > people or governments who want to destroy the historical evidence of > whatever bad stuff they've been up to. > > It would be better if there were ten Internet Archive nonprofits (or > government agencies) scattered around the planet. Each of them would > ideally be taking copies of each others' full holdings, as well as doing > their own crawls of the live web, and scanning in whatever physical > cultural works they are particularly interested in. Anybody know any > Internet billionaires or spy-agency VP's who want to catalyze and endow > a second Internet Archive? The big advantage for spy agencies is > stealth; you can look anywhere you want in your own archive, and nobody > knows where you are looking. > > John > > From touch at strayalpha.com Thu Feb 16 10:08:45 2023 From: touch at strayalpha.com (Joe Touch) Date: Thu, 16 Feb 2023 10:08:45 -0800 Subject: [ih] Archiving Internet history In-Reply-To: References: Message-ID: <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C@strayalpha.com> FYI, even cemeteries don?t preserve things ?forever?. Plots are leased, not sold. Libraries disappear, universities dissolve, and churches are sold and rebuilt. I don?t think this group will find a new solution. > On Feb 16, 2023, at 10:03 AM, vinton cerf via Internet-history wrote: > > ?John, > thanks for your thoughtful intervention. Your conclusion leads me to wonder > about business models that might produce the desired resilience. > Preservation by accident is not a plan and so often that's all that we > achieve. > > v > > >> On Thu, Feb 16, 2023 at 1:08 AM John Gilmore wrote: >> >> vinton cerf via Internet-history wrote: >>> wow thanks for this lengthy history. So many familiar names. I sure hope >>> this mailing list does get archived properly as it contains a wealth of >>> information it would be hard to re-create in the future. >> >> Besides the internet-history mailing list's archives here: >> >> https://elists.isoc.org/pipermail/internet-history/ >> >> I have also been using an Archive-It account to make periodic copies of >> that web site in the Internet Archive here: >> >> >> https://wayback.archive-it.org/15071/20230114211520/https://elists.isoc.org/pipermail/internet-history/ >> >> These are accessible via the Wayback Machine as well as via >> the page for this collection, here: >> >> Internet and Unix History >> https://archive-it.org/collections/15071 >> >> As you can see there, it's set up to periodically scan various other URLs; >> please suggest others that are of historic interest, and I can add them. >> >> FYI, the Wayback Machine does not necessarily get deep copies of every >> web site. Their focus is on breadth, so if a website has a thousand web >> pages, perhaps they will get 50 or 100 of them in each crawl. Also, >> there are enough websites which are designed to "trap" a web crawler and >> cause it to waste a lot of its time, storage and bandwidth uselessly, so >> the main crawler doesn't keep going. So, if there's a deep collection >> (for example, ALL the source code to reproduce a popular Linux >> distribution) that you think is worth saving for the future, >> Archive-It.org is one way to get it saved for posterity. >> >> Also FYI, the Internet Archive is an example of the philosophy of >> putting all your eggs in one basket and watching that basket intently. >> The (untested) theory is that the collection will be too valuable to let >> it fall apart later. A distributed system (like LOCKSS for example) >> would provide higher likelihood of stuff surviving the next hundred, >> thousand or 10,000 years. The Archive is keeping two or three >> replicated copies of each item they have, and copying them forward onto >> newer and fatter drives, but all of them are under the same >> administration and owned by the same nonprofit. Brewster Kahle is the >> sparkplug and the main funding source; control of that nonprofit will be >> in the hands of a small number of probably-less-competent-and-virtuous >> people after Brewster is no more. Hell, during the pandemic, ONE GUY >> was responsible for swapping out failed disk drives before the only >> second copy of a failed drive happened to also fail. Bit-rot sets in >> quickly, and five or ten years of merely incompetent system >> administration would make a shambles of this finely tuned machine. Not >> to mention the possibility of malicious intrusion, particularly by >> people or governments who want to destroy the historical evidence of >> whatever bad stuff they've been up to. >> >> It would be better if there were ten Internet Archive nonprofits (or >> government agencies) scattered around the planet. Each of them would >> ideally be taking copies of each others' full holdings, as well as doing >> their own crawls of the live web, and scanning in whatever physical >> cultural works they are particularly interested in. Anybody know any >> Internet billionaires or spy-agency VP's who want to catalyze and endow >> a second Internet Archive? The big advantage for spy agencies is >> stealth; you can look anywhere you want in your own archive, and nobody >> knows where you are looking. >> >> John >> >> > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From leo at vegoda.org Thu Feb 16 10:25:57 2023 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 16 Feb 2023 10:25:57 -0800 Subject: [ih] Archiving Internet history In-Reply-To: <26854.1676527715@hop.toad.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <9503E594-B893-4577-9037-5F08E5AF8A3A@comcast.net> <81d699a5-2be9-1ff4-08a9-c4c7daddff6e@dcrocker.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <26854.1676527715@hop.toad.com> Message-ID: On Wed, 15 Feb 2023 at 22:08, John Gilmore via Internet-history wrote: [...] > It would be better if there were ten Internet Archive nonprofits (or > government agencies) scattered around the planet. Each of them would > ideally be taking copies of each others' full holdings, as well as doing > their own crawls of the live web, and scanning in whatever physical > cultural works they are particularly interested in. Anybody know any > Internet billionaires or spy-agency VP's who want to catalyze and endow > a second Internet Archive? The big advantage for spy agencies is > stealth; you can look anywhere you want in your own archive, and nobody > knows where you are looking. Many national libraries actively archive websites from their own countries. The UK example is: https://www.webarchive.org.uk/en/ukwa/info/nominate That is the page for nominating a site that should be archived. I hope I am right in assuming that people already working in Legal Deposit Libraries (https://www.bl.uk/legal-deposit/about-legal-deposit) think deeply about doing this well and preserving for centuries and beyond. I'd hope that we don't need to reinvent organisational structures that not only already exist but also have legal authority and public funding. Kind regards, Leo From jack at 3kitty.org Thu Feb 16 10:37:28 2023 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 16 Feb 2023 10:37:28 -0800 Subject: [ih] Archiving Internet history In-Reply-To: <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C@strayalpha.com> References: <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C@strayalpha.com> Message-ID: <310f863b-136b-4bb4-8127-d629611319ec@3kitty.org> My best thought for proactive archiving is based on a business model, involving giving an "archive" some value.?? My "print everything and make a book" suggestion was only partly whimsical. If a book exists, someone will sell it (priced low enough so anyone can afford it).?? The bookseller(s) du jour (e.g., Amazon) will treat it as part of their SKUs, and presumably preserve it as long as there is interest in it (i.e., buyers).?? Even if a company shifts priorities or goes out of business, their "assets" remain, including the books they've been selling, and will likely be sold to someone else.?? This has been happening with various kinds of media, e.g., movies, TV shows, recordings, etc.? When no one cares about the book any more it may disappear.? But if no one cares... My second choice is to simply transmit all of the content into deep space.?? It will travel forever at the speed of light, and can preserve an enormous amount of content.? Future researchers will be able to access the archive once they've solved the technical problem of how to catch up to it, and capture and decode the contents. Just like today's researchers are now able to look at what happened just after the Big Bang by looking at the signals that are just getting here using the JWST. Jack Haverty On 2/16/23 10:08, Joe Touch via Internet-history wrote: > FYI, even cemeteries don?t preserve things ?forever?. Plots are leased, not sold. Libraries disappear, universities dissolve, and churches are sold and rebuilt. > > I don?t think this group will find a new solution. > >> On Feb 16, 2023, at 10:03 AM, vinton cerf via Internet-history wrote: >> >> ?John, >> thanks for your thoughtful intervention. Your conclusion leads me to wonder >> about business models that might produce the desired resilience. >> Preservation by accident is not a plan and so often that's all that we >> achieve. >> >> v >> >> >>> On Thu, Feb 16, 2023 at 1:08 AM John Gilmore wrote: >>> >>> vinton cerf via Internet-history wrote: >>>> wow thanks for this lengthy history. So many familiar names. I sure hope >>>> this mailing list does get archived properly as it contains a wealth of >>>> information it would be hard to re-create in the future. >>> Besides the internet-history mailing list's archives here: >>> >>> https://elists.isoc.org/pipermail/internet-history/ >>> >>> I have also been using an Archive-It account to make periodic copies of >>> that web site in the Internet Archive here: >>> >>> >>> https://wayback.archive-it.org/15071/20230114211520/https://elists.isoc.org/pipermail/internet-history/ >>> >>> These are accessible via the Wayback Machine as well as via >>> the page for this collection, here: >>> >>> Internet and Unix History >>> https://archive-it.org/collections/15071 >>> >>> As you can see there, it's set up to periodically scan various other URLs; >>> please suggest others that are of historic interest, and I can add them. >>> >>> FYI, the Wayback Machine does not necessarily get deep copies of every >>> web site. Their focus is on breadth, so if a website has a thousand web >>> pages, perhaps they will get 50 or 100 of them in each crawl. Also, >>> there are enough websites which are designed to "trap" a web crawler and >>> cause it to waste a lot of its time, storage and bandwidth uselessly, so >>> the main crawler doesn't keep going. So, if there's a deep collection >>> (for example, ALL the source code to reproduce a popular Linux >>> distribution) that you think is worth saving for the future, >>> Archive-It.org is one way to get it saved for posterity. >>> >>> Also FYI, the Internet Archive is an example of the philosophy of >>> putting all your eggs in one basket and watching that basket intently. >>> The (untested) theory is that the collection will be too valuable to let >>> it fall apart later. A distributed system (like LOCKSS for example) >>> would provide higher likelihood of stuff surviving the next hundred, >>> thousand or 10,000 years. The Archive is keeping two or three >>> replicated copies of each item they have, and copying them forward onto >>> newer and fatter drives, but all of them are under the same >>> administration and owned by the same nonprofit. Brewster Kahle is the >>> sparkplug and the main funding source; control of that nonprofit will be >>> in the hands of a small number of probably-less-competent-and-virtuous >>> people after Brewster is no more. Hell, during the pandemic, ONE GUY >>> was responsible for swapping out failed disk drives before the only >>> second copy of a failed drive happened to also fail. Bit-rot sets in >>> quickly, and five or ten years of merely incompetent system >>> administration would make a shambles of this finely tuned machine. Not >>> to mention the possibility of malicious intrusion, particularly by >>> people or governments who want to destroy the historical evidence of >>> whatever bad stuff they've been up to. >>> >>> It would be better if there were ten Internet Archive nonprofits (or >>> government agencies) scattered around the planet. Each of them would >>> ideally be taking copies of each others' full holdings, as well as doing >>> their own crawls of the live web, and scanning in whatever physical >>> cultural works they are particularly interested in. Anybody know any >>> Internet billionaires or spy-agency VP's who want to catalyze and endow >>> a second Internet Archive? The big advantage for spy agencies is >>> stealth; you can look anywhere you want in your own archive, and nobody >>> knows where you are looking. >>> >>> John >>> >>> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history From steffen at sdaoden.eu Thu Feb 16 12:12:25 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 16 Feb 2023 21:12:25 +0100 Subject: [ih] Archiving Internet history In-Reply-To: <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C@strayalpha.com> References: <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C@strayalpha.com> Message-ID: <20230216201225.w-UC_%steffen@sdaoden.eu> Joe Touch wrote in <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C at strayalpha.com>: |FYI, even cemeteries don?t preserve things ?forever?. Plots are leased, \ |not sold. Libraries disappear, universities dissolve, and churches \ |are sold and rebuilt. It is indeed a rare thing. microfilms in tunnels are used in Germany for "worthy" things [1,2 (shows containers)]. I do think Gates uses something in pars comparable to preserve an archive of myriads of photos (also as a business, prints for cash) [1] https://en.wikipedia.org/wiki/Barbarastollen_underground_archive [2] https://de.wikipedia.org/wiki/Barbarastollen |I don?t think this group will find a new solution. I think sheer replication is a viable alternative until something has been proven "worthy" for permanent storage. Again to note that isoc does not provide searching, which i find *extremely* important for lists like this one or TUHS; ie, like what makes a book of Oxford Press outstanding, all the references and the index. (And Nelson Beebe is not here to provide BibTeX references? (He was not heard for certainly a year, anyhow.) P.S.: that reminds me that github.com has also something in permafrost. (Thing is, there _are_ two other archives i know, of seeds, one i think in north Norway, another in some cold mountain of Chile, or Peru?, iirc, the latter for the thousands of sorts of human-genetic-manipulation-free potatoes that once existed, i think the former is even a bit United Nations related, and, now that i think of it, that one is already a bit in troubles because the permafrost there is not longer as perma as it was thought to be.) Etc etc. P.P.S.: what is wrong with mail-archive.com ("The Mail Archive turns your mailing list into a searchable archive")? Ciao, P.P.P.S.: and totally off-topic, seen by sheer luck (i do not look, normally), and because there was a SMTP thread: Feb 14 20:48:56 postfix/smtpd[4718]: connect from gal.iecc.com[64.57.183.53] Feb 14 20:48:57 postfix/smtpd[4718]: Untrusted TLS connection established from gal.iecc.com[64.57.183.53]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server -signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256 Feb 14 20:48:59 postfix/smtpd[4718]: NOQUEUE: reject: RCPT from gal.iecc.com[64.57.183.53]: 450 4.2.0 : Sender address rejected: Service temporarily faded to Gray; from= to= proto=ESMTP helo= ...[gray listing, RFC 6647]... Feb 14 20:49:00 postfix/smtpd[4718]: disconnect from gal.iecc.com[64.57.183.53] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6 ... Feb 14 20:55:36 postfix/smtpd[4838]: connect from gal.iecc.com[64.57.183.53] Feb 14 20:55:36 postfix/smtpd[4838]: Untrusted TLS connection established from gal.iecc.com[64.57.183.53]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server -signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256 Feb 14 20:55:38 postfix/cleanup[4844]: 428DE1605C: message-id=<20230214195538.428DE1605C at sdaoden.eu> Feb 14 20:55:38 postfix/qmgr[2809]: 428DE1605C: from=, size=219, nrcpt=1 (queue active) ...[sender address verification -- this is very hip in Germany on the business front (from multiple senders, simultaneously even); ie, our main city hospital that uses Microsoft has a business partner who does nothing but that for them -- it is so easy to make money, unless you are a stupid left wing, ..whatever]... Feb 14 20:55:39 postfix/smtp[4845]: 428DE1605C: to=, relay=mx1.iecc.com[64.57.183.56]:25, delay=1.6, delays=0.01/0.1/1.4/0.12, dsn=5.0.0, status=undeliverable (host mx1.iecc.c om[64.57.183.56] said: 553 Blocked due to excessive spam. Contact hostmaster at iecc.com from another network if it is fixed. Requests without the specific IP address will be ignored. (in reply to RCPT TO command)) [it is like that for years, and i gave up trying; but here it was all initiated from the other side!] Feb 14 20:55:39 postfix/qmgr[2809]: 428DE1605C: removed Feb 14 20:55:41 postfix/smtpd[4838]: NOQUEUE: reject: RCPT from gal.iecc.com[64.57.183.53]: 450 4.1.7 : Sender address rejected: unverified address[...] --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From brian.e.carpenter at gmail.com Thu Feb 16 12:42:15 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 17 Feb 2023 09:42:15 +1300 Subject: [ih] Archiving Internet history In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <26854.1676527715@hop.toad.com> Message-ID: <7dd33129-9744-9f0e-327c-d40e9b5acc55@gmail.com> On 17-Feb-23 07:25, Leo Vegoda via Internet-history wrote: > On Wed, 15 Feb 2023 at 22:08, John Gilmore via Internet-history > wrote: > > [...] > >> It would be better if there were ten Internet Archive nonprofits (or >> government agencies) scattered around the planet. Each of them would >> ideally be taking copies of each others' full holdings, as well as doing >> their own crawls of the live web, and scanning in whatever physical >> cultural works they are particularly interested in. Anybody know any >> Internet billionaires or spy-agency VP's who want to catalyze and endow >> a second Internet Archive? The big advantage for spy agencies is >> stealth; you can look anywhere you want in your own archive, and nobody >> knows where you are looking. > > Many national libraries actively archive websites from their own > countries. The UK example is: > > https://www.webarchive.org.uk/en/ukwa/info/nominate But there's the problem right there. Similarly, archives.govt.nz does an annual crawl of "NZ" web sites. What we are talking about here is an archive of international material, which no traditional national library will care about. Brian > > That is the page for nominating a site that should be archived. > > I hope I am right in assuming that people already working in Legal > Deposit Libraries > (https://www.bl.uk/legal-deposit/about-legal-deposit) think deeply > about doing this well and preserving for centuries and beyond. > > I'd hope that we don't need to reinvent organisational structures that > not only already exist but also have legal authority and public > funding. > > Kind regards, > > Leo From leo at vegoda.org Thu Feb 16 12:44:48 2023 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 16 Feb 2023 12:44:48 -0800 Subject: [ih] Archiving Internet history In-Reply-To: <7dd33129-9744-9f0e-327c-d40e9b5acc55@gmail.com> References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <26854.1676527715@hop.toad.com> <7dd33129-9744-9f0e-327c-d40e9b5acc55@gmail.com> Message-ID: On Thu, 16 Feb 2023 at 12:42, Brian E Carpenter wrote: [...] > What we are talking about here is > an archive of international material, which no traditional national > library will care about. Do we know that because multiple national libraries were asked and all declined to add it to their archiving efforts? Kind regards, Leo From jack at 3kitty.org Thu Feb 16 12:54:37 2023 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 16 Feb 2023 12:54:37 -0800 (PST) Subject: [ih] Archiving Internet history In-Reply-To: References: <20230208210256.wNce0%steffen@sdaoden.eu> <6528e63b-84da-27a9-33c8-59da7259a2ad@dcrocker.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <26854.1676527715@hop.toad.com> <7dd33129-9744-9f0e-327c-d40e9b5acc55@gmail.com> Message-ID: <7283c253-b0d6-48ae-8c3e-ba4b434a6c8d@3kitty.org> Isn't contacting libraries something that isoc should do?? I think it hosts other mailing lists that may also be of historical interest related to the Internet and therefore worth archiving. Jack From brian.e.carpenter at gmail.com Thu Feb 16 12:59:09 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 17 Feb 2023 09:59:09 +1300 Subject: [ih] Archiving Internet history In-Reply-To: References: <5C874A58-D82D-4ECE-8AF1-D800D7BF1327@comcast.net> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <26854.1676527715@hop.toad.com> <7dd33129-9744-9f0e-327c-d40e9b5acc55@gmail.com> Message-ID: On 17-Feb-23 09:44, Leo Vegoda wrote: > On Thu, 16 Feb 2023 at 12:42, Brian E Carpenter > wrote: > > [...] > >> What we are talking about here is >> an archive of international material, which no traditional national >> library will care about. > > Do we know that because multiple national libraries were asked and all > declined to add it to their archiving efforts? No, it's simply what I've seen so far. Brian From brian.e.carpenter at gmail.com Thu Feb 16 13:01:32 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 17 Feb 2023 10:01:32 +1300 Subject: [ih] Archiving Internet history In-Reply-To: <7283c253-b0d6-48ae-8c3e-ba4b434a6c8d@3kitty.org> References: <20230208210256.wNce0%steffen@sdaoden.eu> <20230208225422.rwtCJ%steffen@sdaoden.eu> <8aba78bd-3c93-c046-6bb3-54d86f7c7506@dcrocker.net> <9CADB975-E581-45DB-BBFF-657D4A5955CF@cs.ucla.edu> <0b58eed9-6828-44d6-7e76-cfc0cfe31309@dcrocker.net> <9ae8511d-8b3e-948c-1345-deac2d8f1811@3kitty.org> <2fe6d7e0-1ed3-5dec-7c94-a4d45f1455c2@3kitty.org> <26854.1676527715@hop.toad.com> <7dd33129-9744-9f0e-327c-d40e9b5acc55@gmail.com> <7283c253-b0d6-48ae-8c3e-ba4b434a6c8d@3kitty.org> Message-ID: <0e971dde-fd03-55ab-5f4a-1704a1ff5430@gmail.com> On 17-Feb-23 09:54, Jack Haverty via Internet-history wrote: > Isn't contacting libraries something that isoc should do?? I think it hosts other mailing lists that may also be of historical interest related to the Internet and therefore worth archiving. FYI, the RFC Editor has been pro-active in getting RFCs into several reputable e-archives. Brian From beebe at math.utah.edu Thu Feb 16 14:13:07 2023 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 16 Feb 2023 15:13:07 -0700 Subject: [ih] Archiving Internet history Message-ID: >> Nelson Beebe is not here to provide BibTeX references? >> (He was not heard for certainly a year, anyhow.) I'm still around, and still active: bibtex=> select count(*) from bibtab where bibtimestamp > '2022.01'; count -------- 121291 bibtex=> select count(*) from bibtab where bibtimestamp > '2023'; count ------- 970 The reduced count of the last 6 weeks is because I'm actively working on software and a companion book. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From johnl at iecc.com Thu Feb 16 14:31:08 2023 From: johnl at iecc.com (John Levine) Date: 16 Feb 2023 17:31:08 -0500 Subject: [ih] Archiving Internet history In-Reply-To: <7283c253-b0d6-48ae-8c3e-ba4b434a6c8d@3kitty.org> Message-ID: <20230216223108.CFE979986324@ary.qy> It appears that Jack Haverty via Internet-history said: >Isn't contacting libraries something that isoc should do?? I think it hosts other mailing lists that may also be of historical >interest related to the Internet and therefore worth archiving. ISOC only hosts this list because I was on the board and asked them to do it, and they agreed it seemed like a reasonable idea. They are not normally in the history business. While I agree that this list is worth archiving, I think somone who does archiving should do it, not yet another thing on ISOC's plate. R's, John From touch at strayalpha.com Thu Feb 16 14:45:57 2023 From: touch at strayalpha.com (touch at strayalpha.com) Date: Thu, 16 Feb 2023 14:45:57 -0800 Subject: [ih] Archiving Internet history In-Reply-To: <20230216223108.CFE979986324@ary.qy> References: <20230216223108.CFE979986324@ary.qy> Message-ID: <32AE7EB4-1D94-4C12-A688-6902DF4D53E6@strayalpha.com> Hi, all, > On Feb 16, 2023, at 2:31 PM, John Levine via Internet-history wrote: > > It appears that Jack Haverty via Internet-history said: >> Isn't contacting libraries something that isoc should do? I think it hosts other mailing lists that may also be of historical >> interest related to the Internet and therefore worth archiving. > > ISOC only hosts this list because I was on the board and asked them to > do it, and they agreed it seemed like a reasonable idea. They are not > normally in the history business. > > While I agree that this list is worth archiving, I think somone who > does archiving should do it, not yet another thing on ISOC's plate. Agreed. Note that there are several things people are seeking: - a way to archive this list - a way to archive resources related to this list, but not strictly on the list itself (additional URLs or large uploads) I just run the list; if anyone finds either a way to archive it or a place we can post other items, I would be glad to link this list and its info page to that mechanism? Joe From jack at 3kitty.org Thu Feb 16 14:51:55 2023 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 16 Feb 2023 14:51:55 -0800 Subject: [ih] Archiving Internet history In-Reply-To: <20230216223108.CFE979986324@ary.qy> References: <20230216223108.CFE979986324@ary.qy> Message-ID: <7bed2f1f-f6dd-f0b3-e1b5-ff0fd6d89f15@3kitty.org> IIRC, there are lots of mailing lists hosted by ISOC, e.g., for Working Groups, IETF issues, etc.?? Although the contents of such lists are not yet "history", they will be someday.? One of the purposes of this internet-history list is to capture the fleeting memories of the people who were there in earlier times, and remember things that were unfortunately never archived, e.g., the discussions and debate on various early mailing lists, which held much that was never in any RFC. I thought ISOC would attempt to preserve all of its current work and discussions for history' sake? Jack On 2/16/23 14:31, John Levine wrote: > It appears that Jack Haverty via Internet-history said: >> Isn't contacting libraries something that isoc should do?? I think it hosts other mailing lists that may also be of historical >> interest related to the Internet and therefore worth archiving. > ISOC only hosts this list because I was on the board and asked them to > do it, and they agreed it seemed like a reasonable idea. They are not > normally in the history business. > > While I agree that this list is worth archiving, I think somone who > does archiving should do it, not yet another thing on ISOC's plate. > > R's, > John From jack at 3kitty.org Thu Feb 16 15:11:09 2023 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 16 Feb 2023 15:11:09 -0800 Subject: [ih] Archiving Internet history In-Reply-To: <13b51c4a-ebc1-b376-ef08-a142c0b621f7@johnlevine.com> References: <20230216223108.CFE979986324@ary.qy> <7bed2f1f-f6dd-f0b3-e1b5-ff0fd6d89f15@3kitty.org> <13b51c4a-ebc1-b376-ef08-a142c0b621f7@johnlevine.com> Message-ID: <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> OK, I probably don't understand the intertwined relationship of ISOC and IETF. Whoever is in charge of the IETF discussion groups/lists, I assume they're somehow being archived well, to preserve a historical record.? My question was whether that same mechanism, whatever it is, could also be used to preserve the discussion on this ISOC list. Jack On 2/16/23 14:55, John R. Levine wrote: >> IIRC, there are lots of mailing lists hosted by ISOC, e.g., for >> Working Groups, IETF issues, etc. > > The IETF's online infrastructure is completely separate from ISOC's.? > ISOC only hosts a handful of lists, most of which are people > pontificating about whatever they imagine Internet Governance means. > > R's, > John > > > ?? Although the contents of such lists are not yet >> "history", they will be someday.? One of the purposes of this >> internet-history list is to capture the fleeting memories of the >> people who were there in earlier times, and remember things that were >> unfortunately never archived, e.g., the discussions and debate on >> various early mailing lists, which held much that was never in any RFC. >> >> I thought ISOC would attempt to preserve all of its current work and >> discussions for history' sake? From vgcerf at gmail.com Thu Feb 16 15:13:18 2023 From: vgcerf at gmail.com (vinton cerf) Date: Thu, 16 Feb 2023 18:13:18 -0500 Subject: [ih] Archiving Internet history In-Reply-To: <310f863b-136b-4bb4-8127-d629611319ec@3kitty.org> References: <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C@strayalpha.com> <310f863b-136b-4bb4-8127-d629611319ec@3kitty.org> Message-ID: re: books - you have surely heard "out of print" for economic/demand reasons... v On Thu, Feb 16, 2023 at 1:37 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > My best thought for proactive archiving is based on a business model, > involving giving an "archive" some value. My "print everything and > make a book" suggestion was only partly whimsical. If a book exists, > someone will sell it (priced low enough so anyone can afford it). The > bookseller(s) du jour (e.g., Amazon) will treat it as part of their > SKUs, and presumably preserve it as long as there is interest in it > (i.e., buyers). Even if a company shifts priorities or goes out of > business, their "assets" remain, including the books they've been > selling, and will likely be sold to someone else. This has been > happening with various kinds of media, e.g., movies, TV shows, > recordings, etc. When no one cares about the book any more it may > disappear. But if no one cares... > > My second choice is to simply transmit all of the content into deep > space. It will travel forever at the speed of light, and can preserve > an enormous amount of content. Future researchers will be able to > access the archive once they've solved the technical problem of how to > catch up to it, and capture and decode the contents. Just like today's > researchers are now able to look at what happened just after the Big > Bang by looking at the signals that are just getting here using the JWST. > > Jack Haverty > > > On 2/16/23 10:08, Joe Touch via Internet-history wrote: > > FYI, even cemeteries don?t preserve things ?forever?. Plots are leased, > not sold. Libraries disappear, universities dissolve, and churches are sold > and rebuilt. > > > > I don?t think this group will find a new solution. > > > >> On Feb 16, 2023, at 10:03 AM, vinton cerf via Internet-history < > internet-history at elists.isoc.org> wrote: > >> > >> ?John, > >> thanks for your thoughtful intervention. Your conclusion leads me to > wonder > >> about business models that might produce the desired resilience. > >> Preservation by accident is not a plan and so often that's all that we > >> achieve. > >> > >> v > >> > >> > >>> On Thu, Feb 16, 2023 at 1:08 AM John Gilmore wrote: > >>> > >>> vinton cerf via Internet-history > wrote: > >>>> wow thanks for this lengthy history. So many familiar names. I sure > hope > >>>> this mailing list does get archived properly as it contains a wealth > of > >>>> information it would be hard to re-create in the future. > >>> Besides the internet-history mailing list's archives here: > >>> > >>> https://elists.isoc.org/pipermail/internet-history/ > >>> > >>> I have also been using an Archive-It account to make periodic copies of > >>> that web site in the Internet Archive here: > >>> > >>> > >>> > https://wayback.archive-it.org/15071/20230114211520/https://elists.isoc.org/pipermail/internet-history/ > >>> > >>> These are accessible via the Wayback Machine as well as via > >>> the page for this collection, here: > >>> > >>> Internet and Unix History > >>> https://archive-it.org/collections/15071 > >>> > >>> As you can see there, it's set up to periodically scan various other > URLs; > >>> please suggest others that are of historic interest, and I can add > them. > >>> > >>> FYI, the Wayback Machine does not necessarily get deep copies of every > >>> web site. Their focus is on breadth, so if a website has a thousand > web > >>> pages, perhaps they will get 50 or 100 of them in each crawl. Also, > >>> there are enough websites which are designed to "trap" a web crawler > and > >>> cause it to waste a lot of its time, storage and bandwidth uselessly, > so > >>> the main crawler doesn't keep going. So, if there's a deep collection > >>> (for example, ALL the source code to reproduce a popular Linux > >>> distribution) that you think is worth saving for the future, > >>> Archive-It.org is one way to get it saved for posterity. > >>> > >>> Also FYI, the Internet Archive is an example of the philosophy of > >>> putting all your eggs in one basket and watching that basket intently. > >>> The (untested) theory is that the collection will be too valuable to > let > >>> it fall apart later. A distributed system (like LOCKSS for example) > >>> would provide higher likelihood of stuff surviving the next hundred, > >>> thousand or 10,000 years. The Archive is keeping two or three > >>> replicated copies of each item they have, and copying them forward onto > >>> newer and fatter drives, but all of them are under the same > >>> administration and owned by the same nonprofit. Brewster Kahle is the > >>> sparkplug and the main funding source; control of that nonprofit will > be > >>> in the hands of a small number of probably-less-competent-and-virtuous > >>> people after Brewster is no more. Hell, during the pandemic, ONE GUY > >>> was responsible for swapping out failed disk drives before the only > >>> second copy of a failed drive happened to also fail. Bit-rot sets in > >>> quickly, and five or ten years of merely incompetent system > >>> administration would make a shambles of this finely tuned machine. Not > >>> to mention the possibility of malicious intrusion, particularly by > >>> people or governments who want to destroy the historical evidence of > >>> whatever bad stuff they've been up to. > >>> > >>> It would be better if there were ten Internet Archive nonprofits (or > >>> government agencies) scattered around the planet. Each of them would > >>> ideally be taking copies of each others' full holdings, as well as > doing > >>> their own crawls of the live web, and scanning in whatever physical > >>> cultural works they are particularly interested in. Anybody know any > >>> Internet billionaires or spy-agency VP's who want to catalyze and endow > >>> a second Internet Archive? The big advantage for spy agencies is > >>> stealth; you can look anywhere you want in your own archive, and nobody > >>> knows where you are looking. > >>> > >>> John > >>> > >>> > >> -- > >> 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 dhc at dcrocker.net Thu Feb 16 15:19:45 2023 From: dhc at dcrocker.net (Dave Crocker) Date: Thu, 16 Feb 2023 15:19:45 -0800 Subject: [ih] Archiving Internet history In-Reply-To: <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> References: <20230216223108.CFE979986324@ary.qy> <7bed2f1f-f6dd-f0b3-e1b5-ff0fd6d89f15@3kitty.org> <13b51c4a-ebc1-b376-ef08-a142c0b621f7@johnlevine.com> <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> Message-ID: On 2/16/2023 3:11 PM, Jack Haverty via Internet-history wrote: > Whoever is in charge of the IETF discussion groups/lists, I assume > they're somehow being archived well, Unless things have changed dramatically in recent years, they are not. The difference between reliable operation, operational backups, and museum quality archiving was not something that resonated with the IETF, when it was discussed back then.? All that was being done then was the first 2. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker at mastodon.social From touch at strayalpha.com Thu Feb 16 15:19:46 2023 From: touch at strayalpha.com (touch at strayalpha.com) Date: Thu, 16 Feb 2023 15:19:46 -0800 Subject: [ih] Archiving Internet history In-Reply-To: <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> References: <20230216223108.CFE979986324@ary.qy> <7bed2f1f-f6dd-f0b3-e1b5-ff0fd6d89f15@3kitty.org> <13b51c4a-ebc1-b376-ef08-a142c0b621f7@johnlevine.com> <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> Message-ID: On Feb 16, 2023, at 3:11 PM, Jack Haverty via Internet-history wrote: > > OK, I probably don't understand the intertwined relationship of ISOC and IETF. > > Whoever is in charge of the IETF discussion groups/lists, I assume they're somehow being archived well, to preserve a historical record. My question was whether that same mechanism, whatever it is, could also be used to preserve the discussion on this ISOC list. I would not make that assumption. I presume things are backed up, but not archival-quality archived. Joe From johnl at iecc.com Thu Feb 16 15:28:50 2023 From: johnl at iecc.com (John R. Levine) Date: 16 Feb 2023 18:28:50 -0500 Subject: [ih] Archiving Internet history In-Reply-To: <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> References: <20230216223108.CFE979986324@ary.qy> <7bed2f1f-f6dd-f0b3-e1b5-ff0fd6d89f15@3kitty.org> <13b51c4a-ebc1-b376-ef08-a142c0b621f7@johnlevine.com> <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> Message-ID: <493c7d5c-685b-9d7b-87c2-934cb66f5df0@iecc.com> > OK, I probably don't understand the intertwined relationship of ISOC and > IETF. > > Whoever is in charge of the IETF discussion groups/lists, I assume they're > somehow being archived well, to preserve a historical record.? My question > was whether that same mechanism, whatever it is, could also be used to > preserve the discussion on this ISOC list. Not really. The IETF has an archive of all of its lists at mailarchive.ietf.org but I don't think they do anything about long term archiving. Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From steffen at sdaoden.eu Thu Feb 16 15:58:40 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 17 Feb 2023 00:58:40 +0100 Subject: [ih] Archiving Internet history In-Reply-To: References: Message-ID: <20230216235840.a49Gq%steffen@sdaoden.eu> Nelson H. F. Beebe wrote in : |>> Nelson Beebe is not here to provide BibTeX references? |>> (He was not heard for certainly a year, anyhow.) | |I'm still around, and still active: That is good to hear! |bibtex=> select count(*) from bibtab where bibtimestamp > '2022.01'; | count |-------- | 121291 | |bibtex=> select count(*) from bibtab where bibtimestamp > '2023'; | count |------- | 970 | |The reduced count of the last 6 weeks is because I'm actively |working on software and a companion book. Incredible numbers! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Thu Feb 16 16:00:33 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 17 Feb 2023 01:00:33 +0100 Subject: [ih] Archiving Internet history In-Reply-To: <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> References: <20230216223108.CFE979986324@ary.qy> <7bed2f1f-f6dd-f0b3-e1b5-ff0fd6d89f15@3kitty.org> <13b51c4a-ebc1-b376-ef08-a142c0b621f7@johnlevine.com> <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> Message-ID: <20230217000033.g6pUa%steffen@sdaoden.eu> Jack Haverty wrote in <9372ec24-5bb7-59cb-94b4-eb5da6255ffa at 3kitty.org>: |OK, I probably don't understand the intertwined relationship of ISOC and |IETF. | |Whoever is in charge of the IETF discussion groups/lists, I assume |they're somehow being archived well, to preserve a historical record.? Only to mention that many IETF lists are mirrored to both marc.info and mail-archive. But i am silent now. |My question was whether that same mechanism, whatever it is, could also |be used to preserve the discussion on this ISOC list. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From jeanjour at comcast.net Thu Feb 16 17:13:18 2023 From: jeanjour at comcast.net (John Day) Date: Thu, 16 Feb 2023 20:13:18 -0500 Subject: [ih] Archiving Internet history In-Reply-To: References: <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C@strayalpha.com> <310f863b-136b-4bb4-8127-d629611319ec@3kitty.org> Message-ID: <1BBEDC14-C06B-4AED-AFF4-00DFC1C12191@comcast.net> ?out of print? often means they are more expensive. ;-) or at least they are in a library for free. It doesn?t mean they don?t exist, right? > On Feb 16, 2023, at 18:13, vinton cerf via Internet-history wrote: > > re: books - you have surely heard "out of print" for economic/demand > reasons... > v > > > On Thu, Feb 16, 2023 at 1:37 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > >> My best thought for proactive archiving is based on a business model, >> involving giving an "archive" some value. My "print everything and >> make a book" suggestion was only partly whimsical. If a book exists, >> someone will sell it (priced low enough so anyone can afford it). The >> bookseller(s) du jour (e.g., Amazon) will treat it as part of their >> SKUs, and presumably preserve it as long as there is interest in it >> (i.e., buyers). Even if a company shifts priorities or goes out of >> business, their "assets" remain, including the books they've been >> selling, and will likely be sold to someone else. This has been >> happening with various kinds of media, e.g., movies, TV shows, >> recordings, etc. When no one cares about the book any more it may >> disappear. But if no one cares... >> >> My second choice is to simply transmit all of the content into deep >> space. It will travel forever at the speed of light, and can preserve >> an enormous amount of content. Future researchers will be able to >> access the archive once they've solved the technical problem of how to >> catch up to it, and capture and decode the contents. Just like today's >> researchers are now able to look at what happened just after the Big >> Bang by looking at the signals that are just getting here using the JWST. >> >> Jack Haverty >> >> >> On 2/16/23 10:08, Joe Touch via Internet-history wrote: >>> FYI, even cemeteries don?t preserve things ?forever?. Plots are leased, >> not sold. Libraries disappear, universities dissolve, and churches are sold >> and rebuilt. >>> >>> I don?t think this group will find a new solution. >>> >>>> On Feb 16, 2023, at 10:03 AM, vinton cerf via Internet-history < >> internet-history at elists.isoc.org> wrote: >>>> >>>> ?John, >>>> thanks for your thoughtful intervention. Your conclusion leads me to >> wonder >>>> about business models that might produce the desired resilience. >>>> Preservation by accident is not a plan and so often that's all that we >>>> achieve. >>>> >>>> v >>>> >>>> >>>>> On Thu, Feb 16, 2023 at 1:08 AM John Gilmore wrote: >>>>> >>>>> vinton cerf via Internet-history >> wrote: >>>>>> wow thanks for this lengthy history. So many familiar names. I sure >> hope >>>>>> this mailing list does get archived properly as it contains a wealth >> of >>>>>> information it would be hard to re-create in the future. >>>>> Besides the internet-history mailing list's archives here: >>>>> >>>>> https://elists.isoc.org/pipermail/internet-history/ >>>>> >>>>> I have also been using an Archive-It account to make periodic copies of >>>>> that web site in the Internet Archive here: >>>>> >>>>> >>>>> >> https://wayback.archive-it.org/15071/20230114211520/https://elists.isoc.org/pipermail/internet-history/ >>>>> >>>>> These are accessible via the Wayback Machine as well as via >>>>> the page for this collection, here: >>>>> >>>>> Internet and Unix History >>>>> https://archive-it.org/collections/15071 >>>>> >>>>> As you can see there, it's set up to periodically scan various other >> URLs; >>>>> please suggest others that are of historic interest, and I can add >> them. >>>>> >>>>> FYI, the Wayback Machine does not necessarily get deep copies of every >>>>> web site. Their focus is on breadth, so if a website has a thousand >> web >>>>> pages, perhaps they will get 50 or 100 of them in each crawl. Also, >>>>> there are enough websites which are designed to "trap" a web crawler >> and >>>>> cause it to waste a lot of its time, storage and bandwidth uselessly, >> so >>>>> the main crawler doesn't keep going. So, if there's a deep collection >>>>> (for example, ALL the source code to reproduce a popular Linux >>>>> distribution) that you think is worth saving for the future, >>>>> Archive-It.org is one way to get it saved for posterity. >>>>> >>>>> Also FYI, the Internet Archive is an example of the philosophy of >>>>> putting all your eggs in one basket and watching that basket intently. >>>>> The (untested) theory is that the collection will be too valuable to >> let >>>>> it fall apart later. A distributed system (like LOCKSS for example) >>>>> would provide higher likelihood of stuff surviving the next hundred, >>>>> thousand or 10,000 years. The Archive is keeping two or three >>>>> replicated copies of each item they have, and copying them forward onto >>>>> newer and fatter drives, but all of them are under the same >>>>> administration and owned by the same nonprofit. Brewster Kahle is the >>>>> sparkplug and the main funding source; control of that nonprofit will >> be >>>>> in the hands of a small number of probably-less-competent-and-virtuous >>>>> people after Brewster is no more. Hell, during the pandemic, ONE GUY >>>>> was responsible for swapping out failed disk drives before the only >>>>> second copy of a failed drive happened to also fail. Bit-rot sets in >>>>> quickly, and five or ten years of merely incompetent system >>>>> administration would make a shambles of this finely tuned machine. Not >>>>> to mention the possibility of malicious intrusion, particularly by >>>>> people or governments who want to destroy the historical evidence of >>>>> whatever bad stuff they've been up to. >>>>> >>>>> It would be better if there were ten Internet Archive nonprofits (or >>>>> government agencies) scattered around the planet. Each of them would >>>>> ideally be taking copies of each others' full holdings, as well as >> doing >>>>> their own crawls of the live web, and scanning in whatever physical >>>>> cultural works they are particularly interested in. Anybody know any >>>>> Internet billionaires or spy-agency VP's who want to catalyze and endow >>>>> a second Internet Archive? The big advantage for spy agencies is >>>>> stealth; you can look anywhere you want in your own archive, and nobody >>>>> knows where you are looking. >>>>> >>>>> John >>>>> >>>>> >>>> -- >>>> 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 From brian.e.carpenter at gmail.com Thu Feb 16 17:52:31 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 17 Feb 2023 14:52:31 +1300 Subject: [ih] Archiving Internet history In-Reply-To: References: <20230216223108.CFE979986324@ary.qy> <7bed2f1f-f6dd-f0b3-e1b5-ff0fd6d89f15@3kitty.org> <13b51c4a-ebc1-b376-ef08-a142c0b621f7@johnlevine.com> <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> Message-ID: On 17-Feb-23 12:19, Dave Crocker via Internet-history wrote: > On 2/16/2023 3:11 PM, Jack Haverty via Internet-history wrote: >> Whoever is in charge of the IETF discussion groups/lists, I assume >> they're somehow being archived well, > > Unless things have changed dramatically in recent years, they are not. > > The difference between reliable operation, operational backups, and > museum quality archiving was not something that resonated with the IETF, > when it was discussed back then.? All that was being done then was the > first 2. In fact, a large number of IETF WG list archives from before the IETF learned to host its own lists at ietf.org are lost. Whether the IETF mail archive (https://mailarchive.ietf.org) is safely archived, I don't know. Brian From jack at 3kitty.org Thu Feb 16 18:27:05 2023 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 16 Feb 2023 18:27:05 -0800 Subject: [ih] Archiving Internet history In-Reply-To: <1BBEDC14-C06B-4AED-AFF4-00DFC1C12191@comcast.net> References: <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C@strayalpha.com> <310f863b-136b-4bb4-8127-d629611319ec@3kitty.org> <1BBEDC14-C06B-4AED-AFF4-00DFC1C12191@comcast.net> Message-ID: Also, it was traditionally expensive to set up a printing run for a book, so economics required a large demand to justify the cost. Saving a book today in digital form takes a few megabytes of storage, orders of magnitude less cost.?? Today's "print-on-demand" means it's a lot more reasonable to keep digitized books available to be printed should anyone want a copy. On 2/16/23 17:13, John Day via Internet-history wrote: > ?out of print? often means they are more expensive. ;-) or at least they are in a library for free. > > It doesn?t mean they don?t exist, right? > >> On Feb 16, 2023, at 18:13, vinton cerf via Internet-history wrote: >> >> re: books - you have surely heard "out of print" for economic/demand >> reasons... >> v >> >> >> On Thu, Feb 16, 2023 at 1:37 PM Jack Haverty via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> My best thought for proactive archiving is based on a business model, >>> involving giving an "archive" some value. My "print everything and >>> make a book" suggestion was only partly whimsical. If a book exists, >>> someone will sell it (priced low enough so anyone can afford it). The >>> bookseller(s) du jour (e.g., Amazon) will treat it as part of their >>> SKUs, and presumably preserve it as long as there is interest in it >>> (i.e., buyers). Even if a company shifts priorities or goes out of >>> business, their "assets" remain, including the books they've been >>> selling, and will likely be sold to someone else. This has been >>> happening with various kinds of media, e.g., movies, TV shows, >>> recordings, etc. When no one cares about the book any more it may >>> disappear. But if no one cares... >>> >>> My second choice is to simply transmit all of the content into deep >>> space. It will travel forever at the speed of light, and can preserve >>> an enormous amount of content. Future researchers will be able to >>> access the archive once they've solved the technical problem of how to >>> catch up to it, and capture and decode the contents. Just like today's >>> researchers are now able to look at what happened just after the Big >>> Bang by looking at the signals that are just getting here using the JWST. >>> >>> Jack Haverty >>> >>> >>> On 2/16/23 10:08, Joe Touch via Internet-history wrote: >>>> FYI, even cemeteries don?t preserve things ?forever?. Plots are leased, >>> not sold. Libraries disappear, universities dissolve, and churches are sold >>> and rebuilt. >>>> I don?t think this group will find a new solution. >>>> >>>>> On Feb 16, 2023, at 10:03 AM, vinton cerf via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>>>> ?John, >>>>> thanks for your thoughtful intervention. Your conclusion leads me to >>> wonder >>>>> about business models that might produce the desired resilience. >>>>> Preservation by accident is not a plan and so often that's all that we >>>>> achieve. >>>>> >>>>> v >>>>> >>>>> >>>>>> On Thu, Feb 16, 2023 at 1:08 AM John Gilmore wrote: >>>>>> >>>>>> vinton cerf via Internet-history >>> wrote: >>>>>>> wow thanks for this lengthy history. So many familiar names. I sure >>> hope >>>>>>> this mailing list does get archived properly as it contains a wealth >>> of >>>>>>> information it would be hard to re-create in the future. >>>>>> Besides the internet-history mailing list's archives here: >>>>>> >>>>>> https://elists.isoc.org/pipermail/internet-history/ >>>>>> >>>>>> I have also been using an Archive-It account to make periodic copies of >>>>>> that web site in the Internet Archive here: >>>>>> >>>>>> >>>>>> >>> https://wayback.archive-it.org/15071/20230114211520/https://elists.isoc.org/pipermail/internet-history/ >>>>>> These are accessible via the Wayback Machine as well as via >>>>>> the page for this collection, here: >>>>>> >>>>>> Internet and Unix History >>>>>> https://archive-it.org/collections/15071 >>>>>> >>>>>> As you can see there, it's set up to periodically scan various other >>> URLs; >>>>>> please suggest others that are of historic interest, and I can add >>> them. >>>>>> FYI, the Wayback Machine does not necessarily get deep copies of every >>>>>> web site. Their focus is on breadth, so if a website has a thousand >>> web >>>>>> pages, perhaps they will get 50 or 100 of them in each crawl. Also, >>>>>> there are enough websites which are designed to "trap" a web crawler >>> and >>>>>> cause it to waste a lot of its time, storage and bandwidth uselessly, >>> so >>>>>> the main crawler doesn't keep going. So, if there's a deep collection >>>>>> (for example, ALL the source code to reproduce a popular Linux >>>>>> distribution) that you think is worth saving for the future, >>>>>> Archive-It.org is one way to get it saved for posterity. >>>>>> >>>>>> Also FYI, the Internet Archive is an example of the philosophy of >>>>>> putting all your eggs in one basket and watching that basket intently. >>>>>> The (untested) theory is that the collection will be too valuable to >>> let >>>>>> it fall apart later. A distributed system (like LOCKSS for example) >>>>>> would provide higher likelihood of stuff surviving the next hundred, >>>>>> thousand or 10,000 years. The Archive is keeping two or three >>>>>> replicated copies of each item they have, and copying them forward onto >>>>>> newer and fatter drives, but all of them are under the same >>>>>> administration and owned by the same nonprofit. Brewster Kahle is the >>>>>> sparkplug and the main funding source; control of that nonprofit will >>> be >>>>>> in the hands of a small number of probably-less-competent-and-virtuous >>>>>> people after Brewster is no more. Hell, during the pandemic, ONE GUY >>>>>> was responsible for swapping out failed disk drives before the only >>>>>> second copy of a failed drive happened to also fail. Bit-rot sets in >>>>>> quickly, and five or ten years of merely incompetent system >>>>>> administration would make a shambles of this finely tuned machine. Not >>>>>> to mention the possibility of malicious intrusion, particularly by >>>>>> people or governments who want to destroy the historical evidence of >>>>>> whatever bad stuff they've been up to. >>>>>> >>>>>> It would be better if there were ten Internet Archive nonprofits (or >>>>>> government agencies) scattered around the planet. Each of them would >>>>>> ideally be taking copies of each others' full holdings, as well as >>> doing >>>>>> their own crawls of the live web, and scanning in whatever physical >>>>>> cultural works they are particularly interested in. Anybody know any >>>>>> Internet billionaires or spy-agency VP's who want to catalyze and endow >>>>>> a second Internet Archive? The big advantage for spy agencies is >>>>>> stealth; you can look anywhere you want in your own archive, and nobody >>>>>> knows where you are looking. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>> -- >>>>> 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 From vint at google.com Thu Feb 16 18:29:51 2023 From: vint at google.com (Vint Cerf) Date: Thu, 16 Feb 2023 21:29:51 -0500 Subject: [ih] Archiving Internet history In-Reply-To: <1BBEDC14-C06B-4AED-AFF4-00DFC1C12191@comcast.net> References: <58D73F87-2EA0-4404-A8BB-DB9DF8CB367C@strayalpha.com> <310f863b-136b-4bb4-8127-d629611319ec@3kitty.org> <1BBEDC14-C06B-4AED-AFF4-00DFC1C12191@comcast.net> Message-ID: yes, but the business model that puts them out of print causes the LOCKSS mechanism to stop propagating v On Thu, Feb 16, 2023 at 8:13 PM John Day via Internet-history < internet-history at elists.isoc.org> wrote: > ?out of print? often means they are more expensive. ;-) or at least they > are in a library for free. > > It doesn?t mean they don?t exist, right? > > > On Feb 16, 2023, at 18:13, vinton cerf via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > re: books - you have surely heard "out of print" for economic/demand > > reasons... > > v > > > > > > On Thu, Feb 16, 2023 at 1:37 PM Jack Haverty via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> My best thought for proactive archiving is based on a business model, > >> involving giving an "archive" some value. My "print everything and > >> make a book" suggestion was only partly whimsical. If a book exists, > >> someone will sell it (priced low enough so anyone can afford it). The > >> bookseller(s) du jour (e.g., Amazon) will treat it as part of their > >> SKUs, and presumably preserve it as long as there is interest in it > >> (i.e., buyers). Even if a company shifts priorities or goes out of > >> business, their "assets" remain, including the books they've been > >> selling, and will likely be sold to someone else. This has been > >> happening with various kinds of media, e.g., movies, TV shows, > >> recordings, etc. When no one cares about the book any more it may > >> disappear. But if no one cares... > >> > >> My second choice is to simply transmit all of the content into deep > >> space. It will travel forever at the speed of light, and can preserve > >> an enormous amount of content. Future researchers will be able to > >> access the archive once they've solved the technical problem of how to > >> catch up to it, and capture and decode the contents. Just like today's > >> researchers are now able to look at what happened just after the Big > >> Bang by looking at the signals that are just getting here using the > JWST. > >> > >> Jack Haverty > >> > >> > >> On 2/16/23 10:08, Joe Touch via Internet-history wrote: > >>> FYI, even cemeteries don?t preserve things ?forever?. Plots are leased, > >> not sold. Libraries disappear, universities dissolve, and churches are > sold > >> and rebuilt. > >>> > >>> I don?t think this group will find a new solution. > >>> > >>>> On Feb 16, 2023, at 10:03 AM, vinton cerf via Internet-history < > >> internet-history at elists.isoc.org> wrote: > >>>> > >>>> ?John, > >>>> thanks for your thoughtful intervention. Your conclusion leads me to > >> wonder > >>>> about business models that might produce the desired resilience. > >>>> Preservation by accident is not a plan and so often that's all that we > >>>> achieve. > >>>> > >>>> v > >>>> > >>>> > >>>>> On Thu, Feb 16, 2023 at 1:08 AM John Gilmore wrote: > >>>>> > >>>>> vinton cerf via Internet-history > >> wrote: > >>>>>> wow thanks for this lengthy history. So many familiar names. I sure > >> hope > >>>>>> this mailing list does get archived properly as it contains a wealth > >> of > >>>>>> information it would be hard to re-create in the future. > >>>>> Besides the internet-history mailing list's archives here: > >>>>> > >>>>> https://elists.isoc.org/pipermail/internet-history/ > >>>>> > >>>>> I have also been using an Archive-It account to make periodic copies > of > >>>>> that web site in the Internet Archive here: > >>>>> > >>>>> > >>>>> > >> > https://wayback.archive-it.org/15071/20230114211520/https://elists.isoc.org/pipermail/internet-history/ > >>>>> > >>>>> These are accessible via the Wayback Machine as well as via > >>>>> the page for this collection, here: > >>>>> > >>>>> Internet and Unix History > >>>>> https://archive-it.org/collections/15071 > >>>>> > >>>>> As you can see there, it's set up to periodically scan various other > >> URLs; > >>>>> please suggest others that are of historic interest, and I can add > >> them. > >>>>> > >>>>> FYI, the Wayback Machine does not necessarily get deep copies of > every > >>>>> web site. Their focus is on breadth, so if a website has a thousand > >> web > >>>>> pages, perhaps they will get 50 or 100 of them in each crawl. Also, > >>>>> there are enough websites which are designed to "trap" a web crawler > >> and > >>>>> cause it to waste a lot of its time, storage and bandwidth uselessly, > >> so > >>>>> the main crawler doesn't keep going. So, if there's a deep > collection > >>>>> (for example, ALL the source code to reproduce a popular Linux > >>>>> distribution) that you think is worth saving for the future, > >>>>> Archive-It.org is one way to get it saved for posterity. > >>>>> > >>>>> Also FYI, the Internet Archive is an example of the philosophy of > >>>>> putting all your eggs in one basket and watching that basket > intently. > >>>>> The (untested) theory is that the collection will be too valuable to > >> let > >>>>> it fall apart later. A distributed system (like LOCKSS for example) > >>>>> would provide higher likelihood of stuff surviving the next hundred, > >>>>> thousand or 10,000 years. The Archive is keeping two or three > >>>>> replicated copies of each item they have, and copying them forward > onto > >>>>> newer and fatter drives, but all of them are under the same > >>>>> administration and owned by the same nonprofit. Brewster Kahle is > the > >>>>> sparkplug and the main funding source; control of that nonprofit will > >> be > >>>>> in the hands of a small number of > probably-less-competent-and-virtuous > >>>>> people after Brewster is no more. Hell, during the pandemic, ONE GUY > >>>>> was responsible for swapping out failed disk drives before the only > >>>>> second copy of a failed drive happened to also fail. Bit-rot sets in > >>>>> quickly, and five or ten years of merely incompetent system > >>>>> administration would make a shambles of this finely tuned machine. > Not > >>>>> to mention the possibility of malicious intrusion, particularly by > >>>>> people or governments who want to destroy the historical evidence of > >>>>> whatever bad stuff they've been up to. > >>>>> > >>>>> It would be better if there were ten Internet Archive nonprofits (or > >>>>> government agencies) scattered around the planet. Each of them would > >>>>> ideally be taking copies of each others' full holdings, as well as > >> doing > >>>>> their own crawls of the live web, and scanning in whatever physical > >>>>> cultural works they are particularly interested in. Anybody know any > >>>>> Internet billionaires or spy-agency VP's who want to catalyze and > endow > >>>>> a second Internet Archive? The big advantage for spy agencies is > >>>>> stealth; you can look anywhere you want in your own archive, and > nobody > >>>>> knows where you are looking. > >>>>> > >>>>> John > >>>>> > >>>>> > >>>> -- > >>>> 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 > > -- > 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 odlyzko at umn.edu Thu Feb 16 18:46:53 2023 From: odlyzko at umn.edu (odlyzko at umn.edu) Date: Thu, 16 Feb 2023 20:46:53 -0600 (CST) Subject: [ih] Archiving Internet history Message-ID: In principle that is true. But there are practical problems, often involving copyrights. How do you make sure that the publisher stays in business, or, if it goes out of business, that the digitized book is taken over by another publisher? That issue has been a bane of many people trying to assemble collected papers of eminent folks, in that copyright owners could not be found. It should not be so much of a problem online, but it still exists. This is, of course, aggravated by the fact that publishers like to keep control of their books, and not have lots of copies floating around. And libraries are also not an infallible fallback position. First of all, libraries did not collect everything. And now, with the lowered demand for hard copies, they are sending their physical volumes to offsite storage sites, or just recycling them. There is a cooperative movement among libraries to ensure that enough physical copies survive to serve the world (this is primarily of concern for items still in copyright). If you look at WorldCat, it lists libraries that have a copy of a book, and often notes how many have committed to keep a copy. Andrew ------------------------------ Message: 4 Date: Thu, 16 Feb 2023 18:27:05 -0800 From: Jack Haverty To: internet-history at elists.isoc.org Subject: Re: [ih] Archiving Internet history Message-ID: Content-Type: text/plain; charset=UTF-8; format=flowed Also, it was traditionally expensive to set up a printing run for a book, so economics required a large demand to justify the cost. Saving a book today in digital form takes a few megabytes of storage, orders of magnitude less cost.?? Today's "print-on-demand" means it's a lot more reasonable to keep digitized books available to be printed should anyone want a copy. On 2/16/23 17:13, John Day via Internet-history wrote: > ?out of print? often means they are more expensive. ;-) or at least they are in a library for free. > > It doesn?t mean they don?t exist, right? > >> On Feb 16, 2023, at 18:13, vinton cerf via Internet-history wrote: >> >> re: books - you have surely heard "out of print" for economic/demand >> reasons... >> v >> >> >> On Thu, Feb 16, 2023 at 1:37 PM Jack Haverty via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> My best thought for proactive archiving is based on a business model, >>> involving giving an "archive" some value. My "print everything and >>> make a book" suggestion was only partly whimsical. If a book exists, >>> someone will sell it (priced low enough so anyone can afford it). The >>> bookseller(s) du jour (e.g., Amazon) will treat it as part of their >>> SKUs, and presumably preserve it as long as there is interest in it >>> (i.e., buyers). Even if a company shifts priorities or goes out of >>> business, their "assets" remain, including the books they've been >>> selling, and will likely be sold to someone else. This has been >>> happening with various kinds of media, e.g., movies, TV shows, >>> recordings, etc. When no one cares about the book any more it may >>> disappear. But if no one cares... >>> >>> My second choice is to simply transmit all of the content into deep >>> space. It will travel forever at the speed of light, and can preserve >>> an enormous amount of content. Future researchers will be able to >>> access the archive once they've solved the technical problem of how to >>> catch up to it, and capture and decode the contents. Just like today's >>> researchers are now able to look at what happened just after the Big >>> Bang by looking at the signals that are just getting here using the JWST. >>> >>> Jack Haverty >>> >>> >>> On 2/16/23 10:08, Joe Touch via Internet-history wrote: >>>> FYI, even cemeteries don?t preserve things ?forever?. Plots are leased, >>> not sold. Libraries disappear, universities dissolve, and churches are sold >>> and rebuilt. >>>> I don?t think this group will find a new solution. >>>> >>>>> On Feb 16, 2023, at 10:03 AM, vinton cerf via Internet-history < >>> internet-history at elists.isoc.org> wrote: >>>>> ?John, >>>>> thanks for your thoughtful intervention. Your conclusion leads me to >>> wonder >>>>> about business models that might produce the desired resilience. >>>>> Preservation by accident is not a plan and so often that's all that we >>>>> achieve. >>>>> >>>>> v >>>>> >>>>> >>>>>> On Thu, Feb 16, 2023 at 1:08 AM John Gilmore wrote: >>>>>> >>>>>> vinton cerf via Internet-history >>> wrote: >>>>>>> wow thanks for this lengthy history. So many familiar names. I sure >>> hope >>>>>>> this mailing list does get archived properly as it contains a wealth >>> of >>>>>>> information it would be hard to re-create in the future. >>>>>> Besides the internet-history mailing list's archives here: >>>>>> >>>>>> https://elists.isoc.org/pipermail/internet-history/ >>>>>> >>>>>> I have also been using an Archive-It account to make periodic copies of >>>>>> that web site in the Internet Archive here: >>>>>> >>>>>> >>>>>> >>> https://wayback.archive-it.org/15071/20230114211520/https://elists.isoc.org/pipermail/internet-history/ >>>>>> These are accessible via the Wayback Machine as well as via >>>>>> the page for this collection, here: >>>>>> >>>>>> Internet and Unix History >>>>>> https://archive-it.org/collections/15071 >>>>>> >>>>>> As you can see there, it's set up to periodically scan various other >>> URLs; >>>>>> please suggest others that are of historic interest, and I can add >>> them. >>>>>> FYI, the Wayback Machine does not necessarily get deep copies of every >>>>>> web site. Their focus is on breadth, so if a website has a thousand >>> web >>>>>> pages, perhaps they will get 50 or 100 of them in each crawl. Also, >>>>>> there are enough websites which are designed to "trap" a web crawler >>> and >>>>>> cause it to waste a lot of its time, storage and bandwidth uselessly, >>> so >>>>>> the main crawler doesn't keep going. So, if there's a deep collection >>>>>> (for example, ALL the source code to reproduce a popular Linux >>>>>> distribution) that you think is worth saving for the future, >>>>>> Archive-It.org is one way to get it saved for posterity. >>>>>> >>>>>> Also FYI, the Internet Archive is an example of the philosophy of >>>>>> putting all your eggs in one basket and watching that basket intently. >>>>>> The (untested) theory is that the collection will be too valuable to >>> let >>>>>> it fall apart later. A distributed system (like LOCKSS for example) >>>>>> would provide higher likelihood of stuff surviving the next hundred, >>>>>> thousand or 10,000 years. The Archive is keeping two or three >>>>>> replicated copies of each item they have, and copying them forward onto >>>>>> newer and fatter drives, but all of them are under the same >>>>>> administration and owned by the same nonprofit. Brewster Kahle is the >>>>>> sparkplug and the main funding source; control of that nonprofit will >>> be >>>>>> in the hands of a small number of probably-less-competent-and-virtuous >>>>>> people after Brewster is no more. Hell, during the pandemic, ONE GUY >>>>>> was responsible for swapping out failed disk drives before the only >>>>>> second copy of a failed drive happened to also fail. Bit-rot sets in >>>>>> quickly, and five or ten years of merely incompetent system >>>>>> administration would make a shambles of this finely tuned machine. Not >>>>>> to mention the possibility of malicious intrusion, particularly by >>>>>> people or governments who want to destroy the historical evidence of >>>>>> whatever bad stuff they've been up to. >>>>>> >>>>>> It would be better if there were ten Internet Archive nonprofits (or >>>>>> government agencies) scattered around the planet. Each of them would >>>>>> ideally be taking copies of each others' full holdings, as well as >>> doing >>>>>> their own crawls of the live web, and scanning in whatever physical >>>>>> cultural works they are particularly interested in. Anybody know any >>>>>> Internet billionaires or spy-agency VP's who want to catalyze and endow >>>>>> a second Internet Archive? The big advantage for spy agencies is >>>>>> stealth; you can look anywhere you want in your own archive, and nobody >>>>>> knows where you are looking. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>> -- >>>>> 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 From gnu at toad.com Thu Feb 16 19:27:23 2023 From: gnu at toad.com (John Gilmore) Date: Thu, 16 Feb 2023 19:27:23 -0800 Subject: [ih] Archiving Internet history In-Reply-To: References: <20230216223108.CFE979986324@ary.qy> <7bed2f1f-f6dd-f0b3-e1b5-ff0fd6d89f15@3kitty.org> <13b51c4a-ebc1-b376-ef08-a142c0b621f7@johnlevine.com> <9372ec24-5bb7-59cb-94b4-eb5da6255ffa@3kitty.org> Message-ID: <27620.1676604443@hop.toad.com> >> Whoever is in charge of the IETF discussion groups/lists, I assume >> they're somehow being archived well, > > Unless things have changed dramatically in recent years, they are not. > The difference between reliable operation, operational backups, and > museum quality archiving was not something that resonated with the > IETF, when it was discussed back then. I am also using the Internet Archive's "Archive-It.org" to make *some* backups of the IETF archives: https://archive-it.org/collections/11034 For example, it's very useful to keep long term copies of Internet-Drafts that have long expired. Documentation of more recent Internet protocols is likely to be sitting in unapproved Internet-Drafts, if it's anywhere at the IETF. John PS: Many of the national and regional archives of the world also contract with the Internet Archive to outsource their web crawls. The results are hosted at the Internet Archive as well as being supplied to the funding archive on disk drives for their own preservation. It is always a big crawl when Australia annually pays IA to crawl every website that's hosted in Australia -- and they aren't the only country to do that. You can see a list of many Archive-It institutional members here: https://archive-it.org/explore ISOC itself is a subscriber: https://archive-it.org/home/internetsociety From feinler at earthlink.net Sat Feb 18 19:24:31 2023 From: feinler at earthlink.net (jake feinler) Date: Sun, 19 Feb 2023 03:24:31 +0000 Subject: [ih] Change of address Message-ID: Change of address feinlerj at gmail.com