From karl at cavebear.com Thu Jun 1 13:25:00 2023 From: karl at cavebear.com (Karl Auerbach) Date: Thu, 1 Jun 2023 13:25:00 -0700 Subject: [ih] =?utf-8?q?Failed_Expectations=3A_A_Deep_Dive_Into_the_Inter?= =?utf-8?q?net=E2=80=99s_40_Years_of_Evolution_=28Geoff_Huston=29?= In-Reply-To: <4DC12E8D-E96F-4FEA-84A1-D8CB70C1D1DC@comcast.net> References: <0095c63c-891f-b844-3a85-5bc88769969e@cavebear.com> <681205d8-806d-f287-fd01-1d5d581eb080@stanford.com.au> <4DC12E8D-E96F-4FEA-84A1-D8CB70C1D1DC@comcast.net> Message-ID: <10db7c4b-afdb-669c-e6ef-62cb2aca4d04@cavebear.com> On 5/31/23 6:47 PM, John Day via Internet-history wrote: > What Karl was referring to, wasn?t really the Session Layer. Actually I was. (The larger intent of my comments was, however, merely to point out how we have that quite human desire to want to protect the good things we did during our lifetimes and that may come with a tendency to discount the ideas of others, a kind of techno-tribalism.) I realized that the OSI session layer, after months of staring at opaque documentation, turns out to be nothing more than a means for the two ends of a network conversation to reliably plant named markers into the conversation.? (Of course the way they did it was more complicated than a Rube Goldberg contraption.) This is useful for network conversations that can break (perhaps due to changes in position, and hence IP address) and be resumed. The named markers become a useful way for an application style that always begins with a "where were we the last time we spoke" handshake.? That allows resumption from the last session-established marker (it does also mean that applications need to remember things that occurred after that last marker - that's a job for the application, not the session protocol.) On the web we tend to use cookies for this.? However, a generalized method that could be packed - much like TLS - into a library between the transport API and our applications could be a useful thing. With regard to the point about OSI names for "the application other end": I do think that the introduction of domain names and URL/URIs as levels added a very useful form of flexible indirection to our network.? But in our modern day I sense that more flexibility is still needed. For example, consider a somewhat persistent application - perhaps a complex banking transaction.? It is possible today that one or both ends of that network conversation will be in motion (thus changing IP addresses and forcing transport re-establishment) or may split or coalesce due to load balancing.? In these case it is useful that application-level state be preservable, or, rather, that if a connection is re-established that it be made to the instance of "the other end" that holds the present state of affairs.? And that could mean that our naming systems need to be able to identify the pieces of applications that result from things like load-balancing cloning of services (or merging of once-separate clones.) Some years back I dashed off a quick note on this topic: On Entity Associations In A Cloud Network https://www.cavebear.com/archive/public/cloud-entities.pdf ??? --karl-- From vint at google.com Thu Jun 1 13:31:13 2023 From: vint at google.com (Vint Cerf) Date: Thu, 1 Jun 2023 16:31:13 -0400 Subject: [ih] =?utf-8?q?Failed_Expectations=3A_A_Deep_Dive_Into_the_Inter?= =?utf-8?q?net=E2=80=99s_40_Years_of_Evolution_=28Geoff_Huston=29?= In-Reply-To: <10db7c4b-afdb-669c-e6ef-62cb2aca4d04@cavebear.com> References: <0095c63c-891f-b844-3a85-5bc88769969e@cavebear.com> <681205d8-806d-f287-fd01-1d5d581eb080@stanford.com.au> <4DC12E8D-E96F-4FEA-84A1-D8CB70C1D1DC@comcast.net> <10db7c4b-afdb-669c-e6ef-62cb2aca4d04@cavebear.com> Message-ID: QUIC has some simplified elements of "shared markers" for rapid recovery of a broken connection up to and including change on one side's IP address v On Thu, Jun 1, 2023 at 4:25?PM Karl Auerbach via Internet-history < internet-history at elists.isoc.org> wrote: > On 5/31/23 6:47 PM, John Day via Internet-history wrote: > > > What Karl was referring to, wasn?t really the Session Layer. > > Actually I was. > > (The larger intent of my comments was, however, merely to point out how > we have that quite human desire to want to protect the good things we > did during our lifetimes and that may come with a tendency to discount > the ideas of others, a kind of techno-tribalism.) > > I realized that the OSI session layer, after months of staring at opaque > documentation, turns out to be nothing more than a means for the two > ends of a network conversation to reliably plant named markers into the > conversation. (Of course the way they did it was more complicated than > a Rube Goldberg contraption.) > > This is useful for network conversations that can break (perhaps due to > changes in position, and hence IP address) and be resumed. > > The named markers become a useful way for an application style that > always begins with a "where were we the last time we spoke" handshake. > That allows resumption from the last session-established marker (it does > also mean that applications need to remember things that occurred after > that last marker - that's a job for the application, not the session > protocol.) > > On the web we tend to use cookies for this. However, a generalized > method that could be packed - much like TLS - into a library between the > transport API and our applications could be a useful thing. > > With regard to the point about OSI names for "the application other > end": I do think that the introduction of domain names and URL/URIs as > levels added a very useful form of flexible indirection to our network. > But in our modern day I sense that more flexibility is still needed. > > For example, consider a somewhat persistent application - perhaps a > complex banking transaction. It is possible today that one or both ends > of that network conversation will be in motion (thus changing IP > addresses and forcing transport re-establishment) or may split or > coalesce due to load balancing. In these case it is useful that > application-level state be preservable, or, rather, that if a connection > is re-established that it be made to the instance of "the other end" > that holds the present state of affairs. And that could mean that our > naming systems need to be able to identify the pieces of applications > that result from things like load-balancing cloning of services (or > merging of once-separate clones.) > > Some years back I dashed off a quick note on this topic: > > On Entity Associations In A Cloud Network > > https://www.cavebear.com/archive/public/cloud-entities.pdf > > --karl-- > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > -- Please send any postal/overnight deliveries to: Vint Cerf Google, LLC 1900 Reston Metro Plaza, 16th Floor Reston, VA 20190 +1 (571) 213 1346 until further notice From brian.e.carpenter at gmail.com Thu Jun 1 13:46:58 2023 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 2 Jun 2023 08:46:58 +1200 Subject: [ih] =?utf-8?q?Failed_Expectations=3A_A_Deep_Dive_Into_the_Inter?= =?utf-8?q?net=E2=80=99s_40_Years_of_Evolution_=28Geoff_Huston=29?= In-Reply-To: References: <0095c63c-891f-b844-3a85-5bc88769969e@cavebear.com> <681205d8-806d-f287-fd01-1d5d581eb080@stanford.com.au> <4DC12E8D-E96F-4FEA-84A1-D8CB70C1D1DC@comcast.net> <10db7c4b-afdb-669c-e6ef-62cb2aca4d04@cavebear.com> Message-ID: <75aae739-a41e-b44d-9cc7-6a25c074b46d@gmail.com> Personally I liked "name-based sockets", but it's still not quite what Karl was getting at: https://datatracker.ietf.org/doc/html/draft-ubillos-name-based-sockets Regards Brian On 02-Jun-23 08:31, Vint Cerf wrote: > QUIC has some simplified elements of "shared markers" for rapid recovery of a broken connection up to and including change on one side's IP address > > v > > > On Thu, Jun 1, 2023 at 4:25?PM Karl Auerbach via Internet-history > wrote: > > On 5/31/23 6:47 PM, John Day via Internet-history wrote: > > > What Karl was referring to, wasn?t really the Session Layer. > > Actually I was. > > (The larger intent of my comments was, however, merely to point out how > we have that quite human desire to want to protect the good things we > did during our lifetimes and that may come with a tendency to discount > the ideas of others, a kind of techno-tribalism.) > > I realized that the OSI session layer, after months of staring at opaque > documentation, turns out to be nothing more than a means for the two > ends of a network conversation to reliably plant named markers into the > conversation.? (Of course the way they did it was more complicated than > a Rube Goldberg contraption.) > > This is useful for network conversations that can break (perhaps due to > changes in position, and hence IP address) and be resumed. > > The named markers become a useful way for an application style that > always begins with a "where were we the last time we spoke" handshake. > That allows resumption from the last session-established marker (it does > also mean that applications need to remember things that occurred after > that last marker - that's a job for the application, not the session > protocol.) > > On the web we tend to use cookies for this.? However, a generalized > method that could be packed - much like TLS - into a library between the > transport API and our applications could be a useful thing. > > With regard to the point about OSI names for "the application other > end": I do think that the introduction of domain names and URL/URIs as > levels added a very useful form of flexible indirection to our network. > But in our modern day I sense that more flexibility is still needed. > > For example, consider a somewhat persistent application - perhaps a > complex banking transaction.? It is possible today that one or both ends > of that network conversation will be in motion (thus changing IP > addresses and forcing transport re-establishment) or may split or > coalesce due to load balancing.? In these case it is useful that > application-level state be preservable, or, rather, that if a connection > is re-established that it be made to the instance of "the other end" > that holds the present state of affairs.? And that could mean that our > naming systems need to be able to identify the pieces of applications > that result from things like load-balancing cloning of services (or > merging of once-separate clones.) > > Some years back I dashed off a quick note on this topic: > > On Entity Associations In A Cloud Network > > https://www.cavebear.com/archive/public/cloud-entities.pdf > > ???? --karl-- > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > > > -- > Please send any postal/overnight deliveries to: > Vint Cerf > Google, LLC > 1900 Reston Metro Plaza, 16th Floor > Reston, VA 20190 > +1 (571) 213 1346 > > > until further notice > > > From cabo at tzi.org Thu Jun 1 16:46:57 2023 From: cabo at tzi.org (Carsten Bormann) Date: Fri, 2 Jun 2023 01:46:57 +0200 Subject: [ih] =?utf-8?q?Failed_Expectations=3A_A_Deep_Dive_Into_the_Inter?= =?utf-8?q?net=E2=80=99s_40_Years_of_Evolution_=28Geoff_Huston=29?= In-Reply-To: <4DC12E8D-E96F-4FEA-84A1-D8CB70C1D1DC@comcast.net> References: <0095c63c-891f-b844-3a85-5bc88769969e@cavebear.com> <681205d8-806d-f287-fd01-1d5d581eb080@stanford.com.au> <4DC12E8D-E96F-4FEA-84A1-D8CB70C1D1DC@comcast.net> Message-ID: <535810CB-7BF7-41CC-A198-9C56BFC92E40@tzi.org> On 1. Jun 2023, at 03:47, John Day via Internet-history wrote: > > opening a connection with different protocols to a specific instance of an application. Which is now widely implemented as a part of TLS: ALPN. One other higher layer (put by OSI on the session layer) thing that TLS grew: close_notify. While TCP does have orderly release (slightly marred by UNIX considering a process crashing as orderly release), it turns out the end-to-end argument applies, and you need orderly release above the security layer. Gr??e, Carsten From lpress at csudh.edu Fri Jun 2 10:38:42 2023 From: lpress at csudh.edu (Larry Press) Date: Fri, 2 Jun 2023 17:38:42 +0000 Subject: [ih] =?utf-8?q?Failed_Expectations=3A_A_Deep_Dive_Into_the_Inter?= =?utf-8?q?net=E2=80=99s_40_Years_of_Evolution_=28Geoff_Huston=29?= In-Reply-To: References: Message-ID: I also saw this and tweeted it with a different excerpt and news of Meta being fined. https://twitter.com/larrypress/status/1663683385838161920 Larry ________________________________ From: Dave Taht Sent: Tuesday, May 30, 2023 4:23 PM To: the keyboard of geoff goodfellow Cc: Internet-history ; Larry Press Subject: Re: [ih] Failed Expectations: A Deep Dive Into the Internet?s 40 Years of Evolution (Geoff Huston) On Tue, May 30, 2023 at 5:17?PM the keyboard of geoff goodfellow via Internet-history wrote: > > EXCERPT: > > In a recent workshop, I attended, reflecting on the evolution of the > Internet over the past 40 years, one of the takeaways for me is how we?ve > managed to surprise ourselves in both the unanticipated successes we?ve > encountered and in the instances of failure when technology has stubbornly > resisted to be deployed despite our confident expectations to the contrary! > What have we learned from these lessons about our inability to predict > technology outcomes? Are the issues related to the aspects of the > technology? Are they embedded in the considerations behind the expectations > about how a technology will be adopted? Or do the primary issues reside at > a deeper level relating to economic and even political contexts? Let?s look > at this question of failed expectations using several specific examples > drawn from the last 40 years of the Internet?s evolution. > > *The Public Debut of the Internet (and the demise of O.S.I.)*... > > [...] > https://urldefense.com/v3/__https://circleid.com/posts/20230524-failed-expectations-a-deep-dive-into-the-internets-40-years-of-evolution__;!!P7nkOOY!p8kV8eCBeeoJ1xRGVW6zbO8yhJ_HGao1hG0-4VmO1GT99yth0bkxi_FGvKiR_Q4QEtfKl4VlMgE_PRmyMQ$ hilariously I was also within seconds of posting this. Larry lurks on my starlink mailing list... adding to cc. > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!P7nkOOY!p8kV8eCBeeoJ1xRGVW6zbO8yhJ_HGao1hG0-4VmO1GT99yth0bkxi_FGvKiR_Q4QEtfKl4VlMgGyy3CwHA$ -- Podcast: https://urldefense.com/v3/__https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/__;!!P7nkOOY!p8kV8eCBeeoJ1xRGVW6zbO8yhJ_HGao1hG0-4VmO1GT99yth0bkxi_FGvKiR_Q4QEtfKl4VlMgHfz29uHw$ Dave T?ht CSO, LibreQos From gregskinner0 at icloud.com Thu Jun 15 21:53:57 2023 From: gregskinner0 at icloud.com (Greg Skinner) Date: Thu, 15 Jun 2023 21:53:57 -0700 Subject: [ih] The linux router project and wifi routers In-Reply-To: <19489474.2624258.1667409611325@mail.yahoo.com> References: <19489474.2624258.1667409611325@mail.yahoo.com> Message-ID: <72E6E587-00F2-49DA-89C6-7E9FADAAE727@icloud.com> Speaking of Len Bosack, he recently gave the keynote at NANOG88. The slides he presented include (what looks like) an early cut at a BGP finite state diagram. https://storage.googleapis.com/site-media-prod/meetings/NANOG88/4846/20230612_Bosack_Keynote_From_Data_v1.pdf? 20230612_Bosack_Keynote_From_Data_v1 PDF Document ? 1.8 MB My apologies again, if you receive duplicates or other confusing messages. I still have trouble sending mail to the list. ?gregbo > On Nov 2, 2022, at 10:20 AM, Bill Nowicki via Internet-history wrote: > > > Oh yes, Tom's page is fairly accurate. The Stanford vs. Cisco story should be well known by now. In the early 1980s I was lucky to be friends with both Bill Yeager and Len Bosack, who each were smart people making contributions, as well as the others mentioned. I wrote some very early software for the original Stanford University Network project (SUN, vs. the company Sun, where I worker later from 1985-1989). > The anecdote I would add might be the following. My wife worked at a now-defunct Stanford spin-off in the late 1980s, which was one of the first customers of both Cisco and Sun, since we knew each other. She showed me that their Cisco box used the prompt "Welcome to SU-Net", the original spelling that Bill Yeager used in his software, not mentioning the company Cisco at all. Cisco had not even bothered to change the prompt in those early days! On Wednesday, November 2, 2022 at 10:05:04 AM PDT, Dave Taht via Internet-history wrote: > > which among other things, spawned busybox, I once wrote up my > intersection with here: > > http://the-edge.blogspot.com/2003/06/wireless-connection.html > > I didn't know the cisco story was similar. How history repeats itself! > I don't remember a whole lot about the linuxrouter project (dave > cinege > had some odd ideas), but it was pretty foundational to the birth of > the embedded linux market as a whole. Similarly, the story of busybox > is not particularly well known, but it combined the most common unix > utilities into one binary that *fit* into the limited amount of flash > and memory available in the 90s and early 2000s in a form that allowed > for extensive scripting for complex functionality, compared to the > all-in-one approach of OSes like windriver's. > > There's also the handhelds.org project, which nobody remembers along > the brief flurry of app stores for linux-running handhelds in the > pocketpc era... > > And also, uclinux. > > On Wed, Nov 2, 2022 at 9:33 AM the keyboard of geoff goodfellow via > Internet-history wrote: >> >> EXCERPT: >> >> The following account of the real origins of Cisco Systems, as opposed to >> the history often recounted in Cisco company literature, was written in >> 1999 by Tom Rindfleisch. Rindfleisch was Director of the SUMEX-AIM project >> (1973-1990), under which the software for a powerful Internet router system >> was developed and widely deployed at Stanford and elsewhere for research >> purposes. That code found its way, without approval from the original >> developers, to form the basis of the Cisco router... >> >> Tom Rindfleisch >> Last updated April 8, 1999 >> >> [...] >> https://www.tcracs.org/tcrwp/1origin-of-cisco/ >> >> -- >> Geoff.Goodfellow at iconia.com >> living as The Truth is True >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history > > > > -- > 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 > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From geoff at iconia.com Sun Jun 18 18:44:06 2023 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 18 Jun 2023 18:44:06 -0700 Subject: [ih] 1994 report on future of the internet Message-ID: ??https://twitter.com/JonErlichman/status/1670580180601954304 -- Geoff.Goodfellow at iconia.com living as The Truth is True From jmamodio at gmail.com Sun Jun 18 22:04:49 2023 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 19 Jun 2023 00:04:49 -0500 Subject: [ih] 1994 report on future of the internet In-Reply-To: References: Message-ID: "Information SuperHighway" ... Makes sense, always under construction and full of traffic :-) Cheers Jorge On Sun, Jun 18, 2023 at 8:44?PM the keyboard of geoff goodfellow via Internet-history wrote: > ??https://twitter.com/JonErlichman/status/1670580180601954304 > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From alejandroacostaalamo at gmail.com Fri Jun 23 06:18:29 2023 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Fri, 23 Jun 2023 09:18:29 -0400 Subject: [ih] BGP - The two or three napkins protocol? Message-ID: <16dfdca0-bde1-0667-27ef-8cf16314c52a@gmail.com> Hello all, ? I wonder if you can clarify this. ? Many people and documentation call BGP as the two Napkin protocol, other call the three Napkin protocol. Why is that? ? I guess the right answer is the three Napkin protocol as Mr Yakov Rekhter mentions in his Google TechTalk (https://www.youtube.com/watch?v=HAOVNYSnL7k) (at 5:37) ? However, for example in this link says "the two napkins protocols": https://computerhistory.org/blog/the-two-napkin-protocol/ Thanks, Alejandro, From awalding at gmail.com Fri Jun 23 07:45:22 2023 From: awalding at gmail.com (Andrew Walding) Date: Fri, 23 Jun 2023 09:45:22 -0500 Subject: [ih] BGP - The two or three napkins protocol? In-Reply-To: <16dfdca0-bde1-0667-27ef-8cf16314c52a@gmail.com> References: <16dfdca0-bde1-0667-27ef-8cf16314c52a@gmail.com> Message-ID: If Yakhov Rehkter calls it a three napkin protocol (Which he does at approx 6 minutes into the video - and he explains why it was called the three napkin protocol) anyone who calls it anything else is simply wrong. On Fri, Jun 23, 2023 at 8:18?AM Alejandro Acosta via Internet-history < internet-history at elists.isoc.org> wrote: > Hello all, > > I wonder if you can clarify this. > > Many people and documentation call BGP as the two Napkin protocol, > other call the three Napkin protocol. Why is that? > > I guess the right answer is the three Napkin protocol as Mr Yakov > Rekhter mentions in his Google TechTalk > (https://www.youtube.com/watch?v=HAOVNYSnL7k) (at 5:37) > > However, for example in this link says "the two napkins protocols": > https://computerhistory.org/blog/the-two-napkin-protocol/ > > > Thanks, > > > Alejandro, > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history >