From bob.hinden at gmail.com Tue Sep 1 11:23:37 2020 From: bob.hinden at gmail.com (Bob Hinden) Date: Tue, 1 Sep 2020 11:23:37 -0700 Subject: [ih] The Sub-atomic Physics of The Internet In-Reply-To: References: Message-ID: <7A46A5FF-AA56-4BE4-9E39-76292721E217@gmail.com> Hi Jack, We always had the idea of multiple applications on the Internet. As you point out TCP/IP, which formed the basic "glue" of The Internet I don?t see an issue with different applications (planets in this article), and in this model one gets to be on as many planets as one wants at the same time. Seems to me some of the separation driven by different languages, I am unlikely to use an app that is focused on content in a language I don?t understand. The two big things I worry about are that many of the large application platforms are owned by the same company (that is, Facebook owns Facebook, Instagram, Messenger, WhatsApp), and that the TCP/IP Internet is getting more divided as countries block content at their borders. Bob > On Aug 29, 2020, at 10:34 AM, Jack Haverty via Internet-history wrote: > > My apologies - yes, I should have looked to Astronomy rather than > Physics on seeing that graphic. > > The deja vu experience I was trying to relate was from two historical > seminal events. > > One was in the late 60s, when many sites, usually universities, had > computer facilities, and one could "choose" which to use, usually by > choosing an institution to join. The movers and shakers at ARPA had > multiple terminals, one for each institution they were sponsoring, and > it was tedious to constantly shift back and forth to interact with their > remote colleagues. To address that issue, ARPA created the ARPANET. > > Through the 70s and 80s, other network technologies appeared, and one > could choose which to use, and interact with others on that network. > But some projects required interactions between different networks. So > ARPA created TCP/IP, which formed the basic "glue" of The Internet. > > Now, in 2020, dozens of large social media "platforms" have evolved, > built on The Internet, yet it is very tedious to interact across their > boundaries (as Dave Crocker illustrated). AFAIK, no one has yet > created the "SocialNet" to glue them all together. > > I agree choice is a good thing. It allows one to pick a mechanism most > suited to your own needs. It fosters competition and survival of the > fittest. > > But one particular "choice" has been very popular - the choice of using > a mechanism that integrates the various "planets" into a cohesive > community. In the 70s, the ARPANET grew explosively because it provided > that cohesion among diverse computers. In the 90s, the Internet > similarly exploded across the world, integrating all sorts of physical > networks. > > Now we have a lot of "planets" again. There are even more > "planetesimals" if you consider all the forums and discussion groups, > media publications with hyperactive "comments" areas, and other such > closed communities. Personally, I find it virtually impossible to keep > track of it all, and not miss things that I really should see. I don't > seem to have the choice of using a cohesive interface to multiple > planets. At least I haven't found it. > > My deja vu sense tells me that it's a similar situation to that at the > time of the ARPANET and Internet emergence. ARPA seems to have gone on > to other things, so I just wonder who will continue the pattern of > Internet History. And if. > > /Jack Haverty > > -- > 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 jack at 3kitty.org Tue Sep 1 13:00:38 2020 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 1 Sep 2020 13:00:38 -0700 Subject: [ih] The Sub-atomic Physics of The Internet In-Reply-To: <7A46A5FF-AA56-4BE4-9E39-76292721E217@gmail.com> References: <7A46A5FF-AA56-4BE4-9E39-76292721E217@gmail.com> Message-ID: <2c240ea5-fa69-c13d-f55a-3c629e835ddb@3kitty.org> Hi Bob, The key is what you said - "one gets to be on as many planets as one wants at the same time".?? That's analogous to the situation that existed before ARPANET.? The folks at ARPA could work at a terminal connected to one of their "planets" (computer somewhere), and they could have as many terminals as they could fit in the office.? But it was very tedious to work that way, e.g., to send some message to several of their "planets", they had to type it in to every terminal. The ARPANET, and email, fixed that problem.? For a while, pretty much everyone you interacted with was "on the net" and easy to interact with. Today, that's no longer true.? Some people use email, some use Facebook, or Instagram, etc.? Some do multiple "connections" at the same time.?? But there's again no reasonable way (that I've found) to interact simultaneously with several people on different planets.? It's a little easier now, doing cut-and-paste rather than retyping on a different terminal, but not all that different from the pre-ARPANET era. That's why I coined the term "SocialNet" - an "internet" providing connectivity at the social level. /Jack On 9/1/20 11:23 AM, Bob Hinden wrote: > Hi Jack, > > We always had the idea of multiple applications on the Internet. As you point out > > TCP/IP, which formed the basic "glue" of The Internet > > I don?t see an issue with different applications (planets in this article), and in this model one gets to be on as many planets as one wants at the same time. Seems to me some of the separation driven by different languages, I am unlikely to use an app that is focused on content in a language I don?t understand. > > The two big things I worry about are that many of the large application platforms are owned by the same company (that is, Facebook owns Facebook, Instagram, Messenger, WhatsApp), and that the TCP/IP Internet is getting more divided as countries block content at their borders. > > Bob > > > > >> On Aug 29, 2020, at 10:34 AM, Jack Haverty via Internet-history wrote: >> >> My apologies - yes, I should have looked to Astronomy rather than >> Physics on seeing that graphic. >> >> The deja vu experience I was trying to relate was from two historical >> seminal events. >> >> One was in the late 60s, when many sites, usually universities, had >> computer facilities, and one could "choose" which to use, usually by >> choosing an institution to join. The movers and shakers at ARPA had >> multiple terminals, one for each institution they were sponsoring, and >> it was tedious to constantly shift back and forth to interact with their >> remote colleagues. To address that issue, ARPA created the ARPANET. >> >> Through the 70s and 80s, other network technologies appeared, and one >> could choose which to use, and interact with others on that network. >> But some projects required interactions between different networks. So >> ARPA created TCP/IP, which formed the basic "glue" of The Internet. >> >> Now, in 2020, dozens of large social media "platforms" have evolved, >> built on The Internet, yet it is very tedious to interact across their >> boundaries (as Dave Crocker illustrated). AFAIK, no one has yet >> created the "SocialNet" to glue them all together. >> >> I agree choice is a good thing. It allows one to pick a mechanism most >> suited to your own needs. It fosters competition and survival of the >> fittest. >> >> But one particular "choice" has been very popular - the choice of using >> a mechanism that integrates the various "planets" into a cohesive >> community. In the 70s, the ARPANET grew explosively because it provided >> that cohesion among diverse computers. In the 90s, the Internet >> similarly exploded across the world, integrating all sorts of physical >> networks. >> >> Now we have a lot of "planets" again. There are even more >> "planetesimals" if you consider all the forums and discussion groups, >> media publications with hyperactive "comments" areas, and other such >> closed communities. Personally, I find it virtually impossible to keep >> track of it all, and not miss things that I really should see. I don't >> seem to have the choice of using a cohesive interface to multiple >> planets. At least I haven't found it. >> >> My deja vu sense tells me that it's a similar situation to that at the >> time of the ARPANET and Internet emergence. ARPA seems to have gone on >> to other things, so I just wonder who will continue the pattern of >> Internet History. And if. >> >> /Jack Haverty >> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history From gtaylor at tnetconsulting.net Tue Sep 1 20:24:11 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 1 Sep 2020 21:24:11 -0600 Subject: [ih] Exterior Gateway Protocol Message-ID: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> Hi, Does anyone know of any surviving implementations of Exterior Gateway Protocol, BGP's predecessor. I know that NetWare 4.x has an implementation of EGP. But I'm not aware of anything else that did support it. I assume that Cisco IOS of the time did. Did any other network operating system vendor or 3rd party vendor have EGP implementations? -- Grant. . . . unix || die From reed at reedmedia.net Tue Sep 1 20:49:13 2020 From: reed at reedmedia.net (Jeremy C. Reed) Date: Tue, 1 Sep 2020 22:49:13 -0500 (CDT) Subject: [ih] Exterior Gateway Protocol In-Reply-To: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> Message-ID: > Does anyone know of any surviving implementations of Exterior Gateway > Protocol, BGP's predecessor. (I don't know about it, but ...) See net1 tarball at https://www.tuhs.org/Archive/Distributions/UCB/ egp/ directory has code and notes for 4.2BSD and 4.3BSD including: /* "egpup" is a user process that implements the Exterior Gateway Protocol * under Unix 4.2 BSD according to the spec. in RFC 888 and 904. ... (Be sure to see egp-notes for history, examples and more.) From tony.li at tony.li Tue Sep 1 21:16:11 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Tue, 1 Sep 2020 21:16:11 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> Message-ID: > I assume that Cisco IOS of the time did. Did any other network operating system vendor or 3rd party vendor have EGP implementations? Yes Cisco IOS (now Classic) did. I was the maintainer for awhile. I can corroborate that there was EGP on BSD, as already mentioned. I was a sysadmin for oberon.usc.edu , running EGP against the mailbridges. Losing your mailbridge slot and having to wait until the next site crashed and a slot opened up was No Fun. Tony From gtaylor at tnetconsulting.net Tue Sep 1 21:54:35 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 1 Sep 2020 22:54:35 -0600 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> Message-ID: <3fc22e07-779d-ed8f-99ae-ef7236038014@tnetconsulting.net> On 9/1/20 10:16 PM, Tony Li via Internet-history wrote: > Yes Cisco IOS (now Classic) did. I was the maintainer for awhile. I saw a "router egp #" reference after sending the message to the IH mailing list. I may have to see if I can get it to work. > I can corroborate that there was EGP on BSD, as already mentioned. I > was a sysadmin for oberon.usc.edu, running EGP against the mailbridges. *nod*nod*nod* > Losing your mailbridge slot and having to wait until the next site > crashed and a slot opened up was No Fun. ???"mailbridge"???"slot"??? That sounds like some history that I'm completely ignorant of. Do you have a TL;DR or a quick pointer so that I can learn? -- Grant. . . . unix || die From york at isoc.org Wed Sep 2 06:55:05 2020 From: york at isoc.org (Dan York) Date: Wed, 2 Sep 2020 13:55:05 +0000 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> Message-ID: <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> Grant, On Sep 1, 2020, at 11:24 PM, Grant Taylor via Internet-history > wrote: Does anyone know of any surviving implementations of Exterior Gateway Protocol, BGP's predecessor. I know that NetWare 4.x has an implementation of EGP. But I'm not aware of anything else that did support it. I assume that Cisco IOS of the time did. Did any other network operating system vendor or 3rd party vendor have EGP implementations? I have no knowledge of EGP implementations ? but related to EGP, one of my personal late night hobbies/distractions during the pandemic has been diving more deeply into Wikipedia editing, and I noticed that the page for EGP needs some citations / references: https://en.wikipedia.org/wiki/Exterior_Gateway_Protocol It also needs more explanation that EGP was replaced by BGP. (The current sentence there says ?essentially replaced? and is a bit vague with no references.) If any of you all here know of any RFCs that explicitly indicate EGP was replaced/obsoleted, or if you know of any journal articles, academic papers, historical documents, etc., that could be useful, I would be glad to update the article a bit. Or if you can point me to any info about the creation of EGP (there?s a line that needs a source). Or any other info you think would be useful in this Wikipedia article, that would be great. (Note that for info to appear in the English version of Wikipedia, it needs to be backed up by a ?reliable source? - https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which includes journal articles, academic papers, news articles, RFCs, etc.) Dan P.S. Please do note that this Wikipedia updating is something I do on my own personal time and is not part of any of my responsibilities and work at the Internet Society. This is just me wanting to update info in Wikipedia to be more accurate. :-) From agmalis at gmail.com Wed Sep 2 07:29:00 2020 From: agmalis at gmail.com (Andrew G. Malis) Date: Wed, 2 Sep 2020 10:29:00 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> Message-ID: Dan, RFC 1772 describes how to do EGP to BGP migration (see section 8.1 in particular). RFC 1773 discusses BGP operational experience in the Internet. But neither definitively says "BGP has replaced EGP in the Internet". Perhaps NANOG might have something useful? Or an IEEE Communications article? Cheers, Andy On Wed, Sep 2, 2020 at 9:55 AM Dan York via Internet-history < internet-history at elists.isoc.org> wrote: > Grant, > > On Sep 1, 2020, at 11:24 PM, Grant Taylor via Internet-history < > internet-history at elists.isoc.org> > wrote: > > Does anyone know of any surviving implementations of Exterior Gateway > Protocol, BGP's predecessor. > > I know that NetWare 4.x has an implementation of EGP. But I'm not aware > of anything else that did support it. I assume that Cisco IOS of the time > did. Did any other network operating system vendor or 3rd party vendor > have EGP implementations? > > I have no knowledge of EGP implementations ? but related to EGP, one of my > personal late night hobbies/distractions during the pandemic has been > diving more deeply into Wikipedia editing, and I noticed that the page for > EGP needs some citations / references: > > https://en.wikipedia.org/wiki/Exterior_Gateway_Protocol > > It also needs more explanation that EGP was replaced by BGP. (The current > sentence there says ?essentially replaced? and is a bit vague with no > references.) > > If any of you all here know of any RFCs that explicitly indicate EGP was > replaced/obsoleted, or if you know of any journal articles, academic > papers, historical documents, etc., that could be useful, I would be glad > to update the article a bit. Or if you can point me to any info about the > creation of EGP (there?s a line that needs a source). Or any other info you > think would be useful in this Wikipedia article, that would be great. > > (Note that for info to appear in the English version of Wikipedia, it > needs to be backed up by a ?reliable source? - > https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which includes > journal articles, academic papers, news articles, RFCs, etc.) > > Dan > > P.S. Please do note that this Wikipedia updating is something I do on my > own personal time and is not part of any of my responsibilities and work at > the Internet Society. This is just me wanting to update info in Wikipedia > to be more accurate. :-) > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From gtaylor at tnetconsulting.net Wed Sep 2 07:39:40 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 2 Sep 2020 08:39:40 -0600 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> Message-ID: <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> On 9/2/20 7:55 AM, Dan York via Internet-history wrote: > Grant, Hi, > It also needs more explanation that EGP was replaced by BGP. (The > current sentence there says ?essentially replaced? and is a bit > vague with no references.) Hum. > If any of you all here know of any RFCs that explicitly indicate > EGP was replaced/obsoleted, or if you know of any journal articles, > academic papers, historical documents, etc., that could be useful, > I would be glad to update the article a bit. Or if you can point me > to any info about the creation of EGP (there?s a line that needs a > source). Or any other info you think would be useful in this Wikipedia > article, that would be great. I found a some information about EGP in and around the gated routing daemon. I wonder if there might be some more information that could help you. > (Note that for info to appear in the English version of > Wikipedia, it needs to be backed up by a ?reliable source? - > https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which > includes journal articles, academic papers, news articles, RFCs, etc.) I wonder if you can find any graphs on the number of Internet connections using BGP. If similar ever existed for EGP, you can probably compare / contrast the two. I also think that the lack of contemporary EGP implementations is evidence of BGP's replacement of EGP. As is the fact that BGP supports things that EGP does not. Things which are used all over the Internet, e.g. multipath. -- Grant. . . . unix || die From vgcerf at gmail.com Wed Sep 2 07:51:01 2020 From: vgcerf at gmail.com (vinton cerf) Date: Wed, 2 Sep 2020 10:51:01 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> Message-ID: NSFNET'S rapid growth induced the need for something more flexible than EGP. As I recall, Hans-Werner Braun (among others) spearheaded the effort. vint On Wed, Sep 2, 2020 at 10:39 AM Grant Taylor via Internet-history < internet-history at elists.isoc.org> wrote: > On 9/2/20 7:55 AM, Dan York via Internet-history wrote: > > Grant, > > Hi, > > > It also needs more explanation that EGP was replaced by BGP. (The > > current sentence there says ?essentially replaced? and is a bit > > vague with no references.) > > Hum. > > > If any of you all here know of any RFCs that explicitly indicate > > EGP was replaced/obsoleted, or if you know of any journal articles, > > academic papers, historical documents, etc., that could be useful, > > I would be glad to update the article a bit. Or if you can point me > > to any info about the creation of EGP (there?s a line that needs a > > source). Or any other info you think would be useful in this Wikipedia > > article, that would be great. > > I found a some information about EGP in and around the gated routing > daemon. I wonder if there might be some more information that could > help you. > > > (Note that for info to appear in the English version of > > Wikipedia, it needs to be backed up by a ?reliable source? - > > https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which > > includes journal articles, academic papers, news articles, RFCs, etc.) > > I wonder if you can find any graphs on the number of Internet > connections using BGP. If similar ever existed for EGP, you can > probably compare / contrast the two. > > I also think that the lack of contemporary EGP implementations is > evidence of BGP's replacement of EGP. As is the fact that BGP supports > things that EGP does not. Things which are used all over the Internet, > e.g. multipath. > > > > -- > Grant. . . . > unix || die > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From sob at sobco.com Wed Sep 2 08:07:15 2020 From: sob at sobco.com (Scott O. Bradner) Date: Wed, 2 Sep 2020 11:07:15 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> Message-ID: <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> my recollection was that EGP could not be twisted enough to be able to deal with the actual topology that was evolving on the Internet Scott ps - I tried to open an old powerpoint presentation (from the late 1990s) where I discussed EGP & BGP but it seem like the oldest version of PowerPoint I have had evolved enough that it will no longer open that version - I mention that because there is yet again a discussion on the IETF list about RFC formats and some people have argued, as people have argued for at least 20 years, that moving to MS Word would be a good thing > On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history wrote: > > On 9/2/20 7:55 AM, Dan York via Internet-history wrote: >> Grant, > > Hi, > >> It also needs more explanation that EGP was replaced by BGP. (The current sentence there says ?essentially replaced? and is a bit vague with no references.) > > Hum. > >> If any of you all here know of any RFCs that explicitly indicate EGP was replaced/obsoleted, or if you know of any journal articles, academic papers, historical documents, etc., that could be useful, I would be glad to update the article a bit. Or if you can point me to any info about the creation of EGP (there?s a line that needs a source). Or any other info you think would be useful in this Wikipedia article, that would be great. > > I found a some information about EGP in and around the gated routing daemon. I wonder if there might be some more information that could help you. > >> (Note that for info to appear in the English version of Wikipedia, it needs to be backed up by a ?reliable source? - https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which includes journal articles, academic papers, news articles, RFCs, etc.) > > I wonder if you can find any graphs on the number of Internet connections using BGP. If similar ever existed for EGP, you can probably compare / contrast the two. > > I also think that the lack of contemporary EGP implementations is evidence of BGP's replacement of EGP. As is the fact that BGP supports things that EGP does not. Things which are used all over the Internet, e.g. multipath. > > > > -- > Grant. . . . > unix || die > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From jack at 3kitty.org Wed Sep 2 09:38:57 2020 From: jack at 3kitty.org (Jack Haverty) Date: Wed, 2 Sep 2020 09:38:57 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> Message-ID: Hi Dan, Re: the creation of EGP:?? Five or ten years ago, I summarized the events around the creation of EGP on this list (actually the list when it was hosted at ISI).? You may be able to find it in old internet-history message archives.? Here's what I wrote. The "Bob" is Bob Kahn, who was one of the ARPA Program Managers at the time.? These events occurred just prior to RFC 827, sometime in 1981/2: > I was at one of innumerable meetings.? Sorry, I can't remember where or when.? > It was probably in DC, where I spent a lot of time, but my gut feeling tells me > it was the European Internet meeting, maybe in Munich.? Anyway,... Bob and I > were hanging on the same subway strap, with the usual group of a dozen or two > people heading out to find dinner.? Bob wanted to talk about the Internet > architecture, and in particular the core gateways.? He managed over the > squealing of the car's wheels to overcome my skepticism and make it clear that > it would be a good idea to figure out how to make it possible for gateways not > built by BBN to be full participants in the system of gateways.? I don't know > whether this was motivated by political pressures to enable CSNET/NSFNET, or > some technical considerations, or by the ARPA charter to focus on new technology > and new ideas, rather than replicating the old ones.? But he convinced me, and I > went away with a new direction, and a harder task to make something work using > an unproven approach. > > Back at BBN, the challenge was not only to figure out how to make a stable > heterogeneous Internet, but also how to convince the people on the project that > it was a good idea to let other people build gateways and hook them up to "our" > system.?? Fortunately the meetings of the TCP and IP working groups were great > training for this kind of work.?? I recruited one of the best thinkers from the > ARPANet crowd - Dr. Eric Rosen.? He and I sat down for several multi-hour > brainstorming sessions, and came up with the notion of "autonomous systems", > which were sets of routers owned/managed by a single organization, and > interconnected with other such systems to form the overall Internet.? EGP (which > I think evolved into BGP) and the concept of IGP (which basically means whatever > mechanisms are used among the routers inside their own closed system)? made it > possible to use different approaches within different ASes.?? This led to RFC > 827 and a bunch of others in the early 80s. > IMHO, it's important to note that we defined EGP *not* as a general purpose routing protocol, but rather as a "firewall" mechanism, which would permit different internal mechanisms (IGPs) to be introduced into the Internet, each isolated in its own "autonomous system". ? This is described in RFC 827. ? If a particular AS wanted to protect itself, it could design its own IGP to be "skeptical" of routing information it received from other ASes through the EGP interactions.?? EGP was not intended to "solve the problem".? It's purpose was to create an experimental testbed in which various ideas could be tried to find good answers. So, the purpose of EGP was to make it possible for diverse groups to try out their ideas in the operational Internet, in their own AS, and retaining the possibility of isolation between different ASes so that flaws in one could be prevented from causing outages elsewhere.?? That of course depended on exactly what mechanisms each group implemented in their own internal IGP mechanisms to provide such isolation.?? For example, an AS might choose to ignore routing information from another AS claiming a "better" route to some network that the AS itself has a route to reach totally within that AS. In particular, Eric continued that work and wrote a series of internal BBN documents about ideas for the IGP to be used in the "core gateways" AS, which BBN was tasked to operate as a reliable 24x7 core Internet service.? I don't know if that BBN IGP ever got implemented in the core gateways.?? Other groups doing gateways (Dave Mills' et al, the MIT group, Cisco, etc.) presumably did their own IGPs, but I never heard much about anyone's IGP design or implementation. /Jack Haverty On 9/2/20 6:55 AM, Dan York via Internet-history wrote: > Grant, > > On Sep 1, 2020, at 11:24 PM, Grant Taylor via Internet-history > wrote: > > Does anyone know of any surviving implementations of Exterior Gateway Protocol, BGP's predecessor. > > I know that NetWare 4.x has an implementation of EGP. But I'm not aware of anything else that did support it. I assume that Cisco IOS of the time did. Did any other network operating system vendor or 3rd party vendor have EGP implementations? > > I have no knowledge of EGP implementations ? but related to EGP, one of my personal late night hobbies/distractions during the pandemic has been diving more deeply into Wikipedia editing, and I noticed that the page for EGP needs some citations / references: > > https://en.wikipedia.org/wiki/Exterior_Gateway_Protocol > > It also needs more explanation that EGP was replaced by BGP. (The current sentence there says ?essentially replaced? and is a bit vague with no references.) > > If any of you all here know of any RFCs that explicitly indicate EGP was replaced/obsoleted, or if you know of any journal articles, academic papers, historical documents, etc., that could be useful, I would be glad to update the article a bit. Or if you can point me to any info about the creation of EGP (there?s a line that needs a source). Or any other info you think would be useful in this Wikipedia article, that would be great. > > (Note that for info to appear in the English version of Wikipedia, it needs to be backed up by a ?reliable source? - https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which includes journal articles, academic papers, news articles, RFCs, etc.) > > Dan > > P.S. Please do note that this Wikipedia updating is something I do on my own personal time and is not part of any of my responsibilities and work at the Internet Society. This is just me wanting to update info in Wikipedia to be more accurate. :-) > From craig at tereschau.net Wed Sep 2 09:59:06 2020 From: craig at tereschau.net (Craig Partridge) Date: Wed, 2 Sep 2020 10:59:06 -0600 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> Message-ID: EGP preceded NSFnet by about 5 years (RFC 827 was released in October 1982). CSNET was nascent and IP service on CSNET was still a year or so in the future. Could Bob have been thinking about splitting off DoD IP networks to another provider (e.g. the logical step after inserting the mailbridges) and using EGP for that purpose? Craig On Wed, Sep 2, 2020 at 10:39 AM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > Hi Dan, > > Re: the creation of EGP: Five or ten years ago, I summarized the > events around the creation of EGP on this list (actually the list when > it was hosted at ISI). You may be able to find it in old > internet-history message archives. > > Here's what I wrote. The "Bob" is Bob Kahn, who was one of the ARPA > Program Managers at the time. These events occurred just prior to RFC > 827, sometime in 1981/2: > > > I was at one of innumerable meetings. Sorry, I can't remember where > or when. > > It was probably in DC, where I spent a lot of time, but my gut feeling > tells me > > it was the European Internet meeting, maybe in Munich. Anyway,... Bob > and I > > were hanging on the same subway strap, with the usual group of a dozen > or two > > people heading out to find dinner. Bob wanted to talk about the Internet > > architecture, and in particular the core gateways. He managed over the > > squealing of the car's wheels to overcome my skepticism and make it > clear that > > it would be a good idea to figure out how to make it possible for > gateways not > > built by BBN to be full participants in the system of gateways. I > don't know > > whether this was motivated by political pressures to enable > CSNET/NSFNET, or > > some technical considerations, or by the ARPA charter to focus on new > technology > > and new ideas, rather than replicating the old ones. But he convinced > me, and I > > went away with a new direction, and a harder task to make something > work using > > an unproven approach. > > > > Back at BBN, the challenge was not only to figure out how to make a > stable > > heterogeneous Internet, but also how to convince the people on the > project that > > it was a good idea to let other people build gateways and hook them up > to "our" > > system. Fortunately the meetings of the TCP and IP working groups > were great > > training for this kind of work. I recruited one of the best thinkers > from the > > ARPANet crowd - Dr. Eric Rosen. He and I sat down for several multi-hour > > brainstorming sessions, and came up with the notion of "autonomous > systems", > > which were sets of routers owned/managed by a single organization, and > > interconnected with other such systems to form the overall Internet. > EGP (which > > I think evolved into BGP) and the concept of IGP (which basically > means whatever > > mechanisms are used among the routers inside their own closed system) > made it > > possible to use different approaches within different ASes. This led > to RFC > > 827 and a bunch of others in the early 80s. > > > > IMHO, it's important to note that we defined EGP *not* as a general > purpose routing protocol, but rather as a "firewall" mechanism, which > would permit different internal mechanisms (IGPs) to be introduced into > the Internet, each isolated in its own "autonomous system". This is > described in RFC 827. If a particular AS wanted to protect itself, it > could design its own IGP to be "skeptical" of routing information it > received from other ASes through the EGP interactions. EGP was not > intended to "solve the problem". It's purpose was to create an > experimental testbed in which various ideas could be tried to find good > answers. > > So, the purpose of EGP was to make it possible for diverse groups to try > out their ideas in the operational Internet, in their own AS, and > retaining the possibility of isolation between different ASes so that > flaws in one could be prevented from causing outages elsewhere. That > of course depended on exactly what mechanisms each group implemented in > their own internal IGP mechanisms to provide such isolation. For > example, an AS might choose to ignore routing information from another > AS claiming a "better" route to some network that the AS itself has a > route to reach totally within that AS. > > In particular, Eric continued that work and wrote a series of internal > BBN documents about ideas for the IGP to be used in the "core gateways" > AS, which BBN was tasked to operate as a reliable 24x7 core Internet > service. > > I don't know if that BBN IGP ever got implemented in the core > gateways. Other groups doing gateways (Dave Mills' et al, the MIT > group, Cisco, etc.) presumably did their own IGPs, but I never heard > much about anyone's IGP design or implementation. > > /Jack Haverty > > > On 9/2/20 6:55 AM, Dan York via Internet-history wrote: > > Grant, > > > > On Sep 1, 2020, at 11:24 PM, Grant Taylor via Internet-history < > internet-history at elists.isoc.org> > wrote: > > > > Does anyone know of any surviving implementations of Exterior Gateway > Protocol, BGP's predecessor. > > > > I know that NetWare 4.x has an implementation of EGP. But I'm not aware > of anything else that did support it. I assume that Cisco IOS of the time > did. Did any other network operating system vendor or 3rd party vendor > have EGP implementations? > > > > I have no knowledge of EGP implementations ? but related to EGP, one of > my personal late night hobbies/distractions during the pandemic has been > diving more deeply into Wikipedia editing, and I noticed that the page for > EGP needs some citations / references: > > > > https://en.wikipedia.org/wiki/Exterior_Gateway_Protocol > > > > It also needs more explanation that EGP was replaced by BGP. (The > current sentence there says ?essentially replaced? and is a bit vague with > no references.) > > > > If any of you all here know of any RFCs that explicitly indicate EGP was > replaced/obsoleted, or if you know of any journal articles, academic > papers, historical documents, etc., that could be useful, I would be glad > to update the article a bit. Or if you can point me to any info about the > creation of EGP (there?s a line that needs a source). Or any other info you > think would be useful in this Wikipedia article, that would be great. > > > > (Note that for info to appear in the English version of Wikipedia, it > needs to be backed up by a ?reliable source? - > https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which includes > journal articles, academic papers, news articles, RFCs, etc.) > > > > Dan > > > > P.S. Please do note that this Wikipedia updating is something I do on my > own personal time and is not part of any of my responsibilities and work at > the Internet Society. This is just me wanting to update info in Wikipedia > to be more accurate. :-) > > > > -- > 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 jnc at mercury.lcs.mit.edu Wed Sep 2 10:01:56 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 2 Sep 2020 13:01:56 -0400 (EDT) Subject: [ih] Exterior Gateway Protocol Message-ID: <20200902170156.D296E18C093@mercury.lcs.mit.edu> > From: Grant Taylor > Does anyone know of any surviving implementations of Exterior Gateway > Protocol, BGP's predecessor. ... Did any other network operating system > vendor or 3rd party vendor have EGP implementations? Liza Martin did one for the MIT so-called "C Gateway". That was distributed to a number of people, along with the rest of the CGW code. All that code is all still around (on the dump of the MIT-CSR machine which was recently retrieved), and easily available. I later re-wrote that one somewhat, to improve it, for the Proteon router products. The one big change I recall which I made was to the code which generated the lists of routes in the updates. To pack as many entriess as possible into a single packet (IIRC, EGP routing table updates were only single packets; no provision for overflow into sets of 2 or more), it used a somewhat arcane organization, which a naive implementation would be slow to generate. So I wrote code to walk the routing' table, and generate an intermediate tree structure which was a good match to the layout in the EGP updates; the code to generate the output packets could then walk that swiftly. (Or, at least, that's my best memory; it's been ~40 years since I last looked at it.) I think I have all that code on a magtape somewhere, so it's retrievable, but qith some effort. If you just want to see it, I can scan the listings I have of it. The other implementatinos I know of were for the BBN PDP-11 router (in Macro-11, I would assume), and I assume there was one for the Fuzzball (ditto). If anyone's super-interested in EGP, Liza had a mailbox of mail with other people outside MIT about work on EGP (Dave Mills led an effort to modify EGPa from the original 'EGP1' to, among other things, hold more routes, which is where that 'packed' format came from). That is in that dump; if anyone is interested in it, I can go through it and make sure there's no personal content, and make it available (afer checking with Liza, if I can work out how to contact her, do make sure it'e OK to let it out). Noel From gtaylor at tnetconsulting.net Wed Sep 2 10:14:48 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 2 Sep 2020 11:14:48 -0600 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <20200902170156.D296E18C093@mercury.lcs.mit.edu> References: <20200902170156.D296E18C093@mercury.lcs.mit.edu> Message-ID: <149306e7-32ef-1478-d4a0-b14b9c67e4a7@tnetconsulting.net> On 9/2/20 11:01 AM, Noel Chiappa via Internet-history wrote: > Liza Martin did one for the MIT so-called "C Gateway". That was > distributed to a number of people, along with the rest of the CGW > code. All that code is all still around (on the dump of the MIT-CSR > machine which was recently retrieved), and easily available. Intriguing. I found that gated implemented EGP, along with many other protocols, and some source archives from the late '90s. I may take a swing at building them in a VM running Linux from the early 2000s. - I know that contemporary GCC was ... unhappy with the code. Which is not surprising to me. > I later re-wrote that one somewhat, to improve it, for the Proteon > router products. The one big change I recall which I made was to the > code which generated the lists of routes in the updates. To pack as > many entriess as possible into a single packet (IIRC, EGP routing table > updates were only single packets; no provision for overflow into sets > of 2 or more), it used a somewhat arcane organization, which a naive > implementation would be slow to generate. So I wrote code to walk the > routing' table, and generate an intermediate tree structure which was > a good match to the layout in the EGP updates; the code to generate > the output packets could then walk that swiftly. (Or, at least, > that's my best memory; it's been ~40 years since I last looked at it.) Impressive work. > I think I have all that code on a magtape somewhere, so it's > retrievable, but qith some effort. If you just want to see it, I can > scan the listings I have of it. > > The other implementatinos I know of were for the BBN PDP-11 router > (in Macro-11, I would assume), and I assume there was one for the > Fuzzball (ditto). > > If anyone's super-interested in EGP, Liza had a mailbox of mail with > other people outside MIT about work on EGP (Dave Mills led an effort > to modify EGPa from the original 'EGP1' to, among other things, hold > more routes, which is where that 'packed' format came from). That > is in that dump; if anyone is interested in it, I can go through it > and make sure there's no personal content, and make it available > (afer checking with Liza, if I can work out how to contact her, > do make sure it'e OK to let it out). I'm retizent to ask someone to do work that I can't do myself. But that being said, I wonder if it might be worth while to get some of the contents of some of these caches archived away somewhere for others to find them. Internet Archive, TUHS, BitSavers, and the likes come to mind. -- Grant. . . . unix || die From jack at 3kitty.org Wed Sep 2 10:46:14 2020 From: jack at 3kitty.org (Jack Haverty) Date: Wed, 2 Sep 2020 10:46:14 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> Message-ID: <1a432f6b-3dd0-7585-23bb-4cfc63ac21c4@3kitty.org> Bob never mentioned why he wanted to have gateways from different sources, so I'm not sure if the DoD evolution was the driver. At the time, there were a lot of people/groups fascinated by the problems inherent in routing protocols, and each wanted to try out their ideas.? I think this interest was heightened by the experience in the ARPANET, where othes' ideas could not be put into code except by BBN, whose focus was on running a reliable decade-old ARPANET, rather than a research testbed for new unproven ideas from the community. So there was a motivation to "open up" the relatively new gateway environment in order to promote research and experimentation.??? That was the task that Eric and I tackled - with the solution we settled on being to create a "firewall" mechanism for the gateways so that such experimentation could happen while maintaining reliability in the "core" service. I've always wondered why there was such fascination in the network community with routing, yet very little interest in other areas, e.g., congestion control or operational issues such as problem isolation, introduction of new releases, etc.?? Lots of ideas about how to do routing better. IIRC, one of the hot topics at the time was how to deal with operational problems caused by research activities.?? There was a real desire to start getting the Internet to stabilize as a reliable communications service (probably motivated by DoD needs).? It had to be as reliable as the ARPANET had become by then. Also, IIRC at the time DoD preferred multiple-source solutions, and "COTS" (Commercial Off The Shelf) was a popular buzzword.?? So for TCP to fit well into the DoD world, a single-source gateway was probably not enough.? Sole-source justifications were becoming increasingly difficult. So, research collided with operations.? Dave Mills, for example, was famous for trying things out on the Internet that should have worked, but didn't, and brought down some aspect of the core service.? His (research) attitude was "Let's see what happens if I do this", where our BBN (operational) attitude was "Don't do that!".?? My assumption was that Bob was searching for a way to enable research and operational activities to coexist peacefully in The Internet.? Like all good managers, he delegated that problem, while hanging on that subway strap. /Jack On 9/2/20 9:59 AM, Craig Partridge wrote: > EGP preceded?NSFnet by about 5 years (RFC 827 was released?in October > 1982).? CSNET was nascent and IP service on CSNET was still a year or > so in the future. > > Could Bob have been thinking about splitting off DoD IP networks to > another provider (e.g. the logical step after inserting the > mailbridges) and using EGP for that purpose? > > Craig > > On Wed, Sep 2, 2020 at 10:39 AM Jack Haverty via Internet-history > > wrote: > > Hi Dan, > > Re: the creation of EGP:?? Five or ten years ago, I summarized the > events around the creation of EGP on this list (actually the list when > it was hosted at ISI).? You may be able to find it in old > internet-history message archives.? > > Here's what I wrote. The "Bob" is Bob Kahn, who was one of the ARPA > Program Managers at the time.? These events occurred just prior to RFC > 827, sometime in 1981/2: > > > I was at one of innumerable meetings.? Sorry, I can't remember where > or when.? > > It was probably in DC, where I spent a lot of time, but my gut > feeling > tells me > > it was the European Internet meeting, maybe in Munich.? > Anyway,... Bob > and I > > were hanging on the same subway strap, with the usual group of a > dozen > or two > > people heading out to find dinner.? Bob wanted to talk about the > Internet > > architecture, and in particular the core gateways.? He managed > over the > > squealing of the car's wheels to overcome my skepticism and make it > clear that > > it would be a good idea to figure out how to make it possible for > gateways not > > built by BBN to be full participants in the system of gateways.? I > don't know > > whether this was motivated by political pressures to enable > CSNET/NSFNET, or > > some technical considerations, or by the ARPA charter to focus > on new > technology > > and new ideas, rather than replicating the old ones.? But he > convinced > me, and I > > went away with a new direction, and a harder task to make something > work using > > an unproven approach. > > > > Back at BBN, the challenge was not only to figure out how to make a > stable > > heterogeneous Internet, but also how to convince the people on the > project that > > it was a good idea to let other people build gateways and hook > them up > to "our" > > system.?? Fortunately the meetings of the TCP and IP working groups > were great > > training for this kind of work.?? I recruited one of the best > thinkers > from the > > ARPANet crowd - Dr. Eric Rosen.? He and I sat down for several > multi-hour > > brainstorming sessions, and came up with the notion of "autonomous > systems", > > which were sets of routers owned/managed by a single > organization, and > > interconnected with other such systems to form the overall > Internet.? > EGP (which > > I think evolved into BGP) and the concept of IGP (which basically > means whatever > > mechanisms are used among the routers inside their own closed > system)? > made it > > possible to use different approaches within different ASes.?? > This led > to RFC > > 827 and a bunch of others in the early 80s. > > > > IMHO, it's important to note that we defined EGP *not* as a general > purpose routing protocol, but rather as a "firewall" mechanism, which > would permit different internal mechanisms (IGPs) to be introduced > into > the Internet, each isolated in its own "autonomous system". ? This is > described in RFC 827. ? If a particular AS wanted to protect > itself, it > could design its own IGP to be "skeptical" of routing information it > received from other ASes through the EGP interactions.?? EGP was not > intended to "solve the problem".? It's purpose was to create an > experimental testbed in which various ideas could be tried to find > good > answers. > > So, the purpose of EGP was to make it possible for diverse groups > to try > out their ideas in the operational Internet, in their own AS, and > retaining the possibility of isolation between different ASes so that > flaws in one could be prevented from causing outages elsewhere.?? That > of course depended on exactly what mechanisms each group > implemented in > their own internal IGP mechanisms to provide such isolation.?? For > example, an AS might choose to ignore routing information from another > AS claiming a "better" route to some network that the AS itself has a > route to reach totally within that AS. > > In particular, Eric continued that work and wrote a series of internal > BBN documents about ideas for the IGP to be used in the "core > gateways" > AS, which BBN was tasked to operate as a reliable 24x7 core Internet > service.? > > I don't know if that BBN IGP ever got implemented in the core > gateways.?? Other groups doing gateways (Dave Mills' et al, the MIT > group, Cisco, etc.) presumably did their own IGPs, but I never heard > much about anyone's IGP design or implementation. > > /Jack Haverty > > > On 9/2/20 6:55 AM, Dan York via Internet-history wrote: > > Grant, > > > > On Sep 1, 2020, at 11:24 PM, Grant Taylor via Internet-history > >> wrote: > > > > Does anyone know of any surviving implementations of Exterior > Gateway Protocol, BGP's predecessor. > > > > I know that NetWare 4.x has an implementation of EGP.? But I'm > not aware of anything else that did support it.? I assume that > Cisco IOS of the time did.? Did any other network operating system > vendor or 3rd party vendor have EGP implementations? > > > > I have no knowledge of EGP implementations ? but related to EGP, > one of my personal late night hobbies/distractions during the > pandemic has been diving more deeply into Wikipedia editing, and I > noticed that the page for EGP needs some citations / references: > > > > https://en.wikipedia.org/wiki/Exterior_Gateway_Protocol > > > > It also needs more explanation that EGP was replaced by BGP. > (The current sentence there says ?essentially replaced? and is a > bit vague with no references.) > > > > If any of you all here know of any RFCs that explicitly indicate > EGP was replaced/obsoleted, or if you know of any journal > articles, academic papers, historical documents, etc., that could > be useful, I would be glad to update the article a bit. Or if you > can point me to any info about the creation of EGP (there?s a line > that needs a source). Or any other info you think would be useful > in this Wikipedia article, that would be great. > > > > (Note that for info to appear in the English version of > Wikipedia, it needs to be backed up by a ?reliable source? - > https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which > includes journal articles, academic papers, news articles, RFCs, etc.) > > > > Dan > > > > P.S. Please do note that this Wikipedia updating is something I > do on my own personal time and is not part of any of my > responsibilities and work at the Internet Society. This is just me > wanting to update info in Wikipedia to be more accurate. :-) > > > > -- > 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 tony.li at tony.li Wed Sep 2 11:11:34 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Wed, 2 Sep 2020 11:11:34 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <1a432f6b-3dd0-7585-23bb-4cfc63ac21c4@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <1a432f6b-3dd0-7585-23bb-4cfc63ac21c4@3kitty.org> Message-ID: > I've always wondered why there was such fascination in the network > community with routing, yet very little interest in other areas, e.g., > congestion control or operational issues such as problem isolation, > introduction of new releases, etc. Lots of ideas about how to do > routing better. That?s easy: when routing broke, everything stopped and the pager buzzed. Tony From b_a_denny at yahoo.com Wed Sep 2 12:45:47 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Wed, 2 Sep 2020 19:45:47 +0000 (UTC) Subject: [ih] Exterior Gateway Protocol In-Reply-To: <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> Message-ID: <2120484892.2319134.1599075947873@mail.yahoo.com> That is my recollection too. EGP had topology constraints.? barbara? On Wednesday, September 2, 2020, 08:07:37 AM PDT, Scott O. Bradner via Internet-history wrote: my recollection was that EGP could not be twisted enough to be able to deal with the actual topology that was evolving on the Internet Scott ps - I tried to open an old powerpoint presentation (from the late 1990s) where I discussed EGP & BGP but it seem like the oldest version of PowerPoint I have had evolved enough that it will no longer open that version? - I mention that because there is yet again a discussion on the IETF list about RFC formats and some people have argued, as people have argued for at least 20 years, that moving to MS Word would be a good thing > On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history wrote: > > On 9/2/20 7:55 AM, Dan York via Internet-history wrote: >> Grant, > > Hi, > >> It also needs more explanation that EGP was replaced by BGP. (The current sentence there says ?essentially replaced? and is a bit vague with no references.) > > Hum. > >> If any of you all here know of any RFCs that explicitly indicate EGP was replaced/obsoleted, or if you know of any journal articles, academic papers, historical documents, etc., that could be useful, I would be glad to update the article a bit. Or if you can point me to any info about the creation of EGP (there?s a line that needs a source). Or any other info you think would be useful in this Wikipedia article, that would be great. > > I found a some information about EGP in and around the gated routing daemon.? I wonder if there might be some more information that could help you. > >> (Note that for info to appear in the English version of Wikipedia, it needs to be backed up by a ?reliable source? - https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which includes journal articles, academic papers, news articles, RFCs, etc.) > > I wonder if you can find any graphs on the number of Internet connections using BGP.? If similar ever existed for EGP, you can probably compare / contrast the two. > > I also think that the lack of contemporary EGP implementations is evidence of BGP's replacement of EGP.? As is the fact that BGP supports things that EGP does not.? Things which are used all over the Internet, e.g. multipath. > > > > -- > Grant. . . . > unix || die > > -- > 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 Wed Sep 2 12:52:18 2020 From: sob at sobco.com (Scott O. Bradner) Date: Wed, 2 Sep 2020 15:52:18 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <2120484892.2319134.1599075947873@mail.yahoo.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> Message-ID: <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> I found a printout of my late 1990s notes which said that EGP was "limited to a tree structured Internet" although I recall that people were hacking it to expand its usefulness but the result was not pretty Scott > On Sep 2, 2020, at 3:45 PM, Barbara Denny wrote: > > That is my recollection too. EGP had topology constraints. > > barbara > > On Wednesday, September 2, 2020, 08:07:37 AM PDT, Scott O. Bradner via Internet-history wrote: > > > my recollection was that EGP could not be twisted enough to be able to deal with the actual > topology that was evolving on the Internet > > Scott > > ps - I tried to open an old powerpoint presentation (from the late 1990s) where I discussed EGP & BGP > but it seem like the oldest version of PowerPoint I have had evolved enough that it will no longer open > that version - I mention that because there is yet again a discussion on the IETF list about RFC formats > and some people have argued, as people have argued for at least 20 years, that moving to MS Word > would be a good thing > > > > > On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history wrote: > > > > On 9/2/20 7:55 AM, Dan York via Internet-history wrote: > >> Grant, > > > > Hi, > > > >> It also needs more explanation that EGP was replaced by BGP. (The current sentence there says ?essentially replaced? and is a bit vague with no references.) > > > > Hum. > > > >> If any of you all here know of any RFCs that explicitly indicate EGP was replaced/obsoleted, or if you know of any journal articles, academic papers, historical documents, etc., that could be useful, I would be glad to update the article a bit. Or if you can point me to any info about the creation of EGP (there?s a line that needs a source). Or any other info you think would be useful in this Wikipedia article, that would be great. > > > > I found a some information about EGP in and around the gated routing daemon. I wonder if there might be some more information that could help you. > > > >> (Note that for info to appear in the English version of Wikipedia, it needs to be backed up by a ?reliable source? - https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which includes journal articles, academic papers, news articles, RFCs, etc.) > > > > I wonder if you can find any graphs on the number of Internet connections using BGP. If similar ever existed for EGP, you can probably compare / contrast the two. > > > > I also think that the lack of contemporary EGP implementations is evidence of BGP's replacement of EGP. As is the fact that BGP supports things that EGP does not. Things which are used all over the Internet, e.g. multipath. > > > > > > > > -- > > Grant. . . . > > unix || die > > > > -- > > 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 craig at tereschau.net Wed Sep 2 12:57:29 2020 From: craig at tereschau.net (Craig Partridge) Date: Wed, 2 Sep 2020 13:57:29 -0600 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> Message-ID: There was a SIGCOMM '87 paper by Mills and Hans-Werner Braun that discussed what happened when you tried to break the tree topology. Craig On Wed, Sep 2, 2020 at 1:52 PM Scott O. Bradner via Internet-history < internet-history at elists.isoc.org> wrote: > I found a printout of my late 1990s notes which said that EGP was "limited > to a tree structured Internet" > although I recall that people were hacking it to expand its usefulness but > the result was not pretty > > Scott > > > > On Sep 2, 2020, at 3:45 PM, Barbara Denny wrote: > > > > That is my recollection too. EGP had topology constraints. > > > > barbara > > > > On Wednesday, September 2, 2020, 08:07:37 AM PDT, Scott O. Bradner via > Internet-history wrote: > > > > > > my recollection was that EGP could not be twisted enough to be able to > deal with the actual > > topology that was evolving on the Internet > > > > Scott > > > > ps - I tried to open an old powerpoint presentation (from the late > 1990s) where I discussed EGP & BGP > > but it seem like the oldest version of PowerPoint I have had evolved > enough that it will no longer open > > that version - I mention that because there is yet again a discussion > on the IETF list about RFC formats > > and some people have argued, as people have argued for at least 20 > years, that moving to MS Word > > would be a good thing > > > > > > > > > On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > > > On 9/2/20 7:55 AM, Dan York via Internet-history wrote: > > >> Grant, > > > > > > Hi, > > > > > >> It also needs more explanation that EGP was replaced by BGP. (The > current sentence there says ?essentially replaced? and is a bit vague with > no references.) > > > > > > Hum. > > > > > >> If any of you all here know of any RFCs that explicitly indicate EGP > was replaced/obsoleted, or if you know of any journal articles, academic > papers, historical documents, etc., that could be useful, I would be glad > to update the article a bit. Or if you can point me to any info about the > creation of EGP (there?s a line that needs a source). Or any other info you > think would be useful in this Wikipedia article, that would be great. > > > > > > I found a some information about EGP in and around the gated routing > daemon. I wonder if there might be some more information that could help > you. > > > > > >> (Note that for info to appear in the English version of Wikipedia, it > needs to be backed up by a ?reliable source? - > https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources - which includes > journal articles, academic papers, news articles, RFCs, etc.) > > > > > > I wonder if you can find any graphs on the number of Internet > connections using BGP. If similar ever existed for EGP, you can probably > compare / contrast the two. > > > > > > I also think that the lack of contemporary EGP implementations is > evidence of BGP's replacement of EGP. As is the fact that BGP supports > things that EGP does not. Things which are used all over the Internet, > e.g. multipath. > > > > > > > > > > > > -- > > > Grant. . . . > > > unix || die > > > > > > -- > > > 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 > -- ***** Craig Partridge's email account for professional society activities and mailing lists. From casner at acm.org Wed Sep 2 14:10:20 2020 From: casner at acm.org (Stephen Casner) Date: Wed, 2 Sep 2020 14:10:20 -0700 (PDT) Subject: [ih] Exterior Gateway Protocol In-Reply-To: <1a432f6b-3dd0-7585-23bb-4cfc63ac21c4@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <1a432f6b-3dd0-7585-23bb-4cfc63ac21c4@3kitty.org> Message-ID: On Wed, 2 Sep 2020, Jack Haverty via Internet-history wrote: > So, research collided with operations. Dave Mills, for example, was > famous for trying things out on the Internet that should have worked, > but didn't, and brought down some aspect of the core service. His > (research) attitude was "Let's see what happens if I do this", where our > BBN (operational) attitude was "Don't do that!". Same with opening up subtype 3 uncontrolled packets on the ARPANET for our packet voice work earlier -- also Bob's push. -- Steve From galmes at tamu.edu Wed Sep 2 14:10:39 2020 From: galmes at tamu.edu (Guy Almes) Date: Wed, 2 Sep 2020 17:10:39 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> Message-ID: <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Craig et al., 1987 was an interesting year. The NSFnet-related regional networks were connecting new sites and had to solve interesting routing problems. EGP would tell you that a given network was reachable via a given gateway router / AS. But that network might be reachable via two different gateways. During that era, our "Sesquinet" regional network in Texas was connected to two different valuable "backbone" type networks: the Fuzzball-based proto-NSFnet via Boulder and the ARPAnet via Austin. Both were useful. Both had 56kb/s circuits. Both were congested. At that time, there were a few hundred networks, and I recall going through the whole list, one by one, figuring out whether, if they were reachable via both the ARPAnet and the proto-NSFnet, which should be preferred. I considered it worth doing, but it was of course Quixotic, given the rapidly growing number of connected networks. Phill Gross asked me to lead an "Interconnectivity Working Group" within the IETF and work to solve some of these problems. It was a great group, with members from the ARPAnet, NSFnet, NASA, ESnet, and other communities. Understanding the various "backbones", their differing technical and policy natures, and the limitations of EGP all made for fascinating discussions, which did allow us to make progress. One of our explicit marching orders was *not* to invent a new protocol. But we did discuss the problem of how to choose which of two exterior routes to use when both advertised a given network. One line of thought was to consider that the Internet, while not having a "tree topology", did have a notion of levels of hierarchy, e.g., campus, then regional, then national backbone, then international links. I am grateful that we fairly quickly realized that relying on that notion of hierarchy would be building on sand. But what kind of "metric" could be used to help make routing decisions? One idea, based on Cicso's IGRP protocol was to characterize each transit network with a bandwidth and a delay metric. Then minimum of bandwidth along a path and sum of delay along a path could be used. That did not get traction. I'd been teaching a computer scientist where an idea called the "zero, one, infinity rule" was discussed. As applied here, if a single scalar number would not suffice as a metric, then allow a metric of variable length. For example, a whole AS-path could be an interesting kind of metric could be used. But, particularly during that era, variable-length fields in protocols were not in favor, and we did not pursue this idea. Except that, at our next working group meeting (at the January 1989 IETF meeting at UT-Austin), Kirk Lougheed (Cisco) and Yakov Rekhter (IBM) invented BGP in one of the Internet's most famous napkins. The complete AS-path, variable though it was, was a key idea. BGP solved several problems with EGP. I should emphasize that the AS-path was never exactly regarded as a "metric", but it provided valuable information. I'll avoid going further with the evolution of BGP, but it was so much better than its predecessor and came along at a very fortunate time. -- Guy On 9/2/20 3:57 PM, Craig Partridge via Internet-history wrote: > There was a SIGCOMM '87 paper by Mills and Hans-Werner Braun that discussed > what happened when you tried to break the tree topology. > > Craig > > On Wed, Sep 2, 2020 at 1:52 PM Scott O. Bradner via Internet-history < > internet-history at elists.isoc.org> wrote: > >> I found a printout of my late 1990s notes which said that EGP was "limited >> to a tree structured Internet" >> although I recall that people were hacking it to expand its usefulness but >> the result was not pretty >> >> Scott >> >> >>> On Sep 2, 2020, at 3:45 PM, Barbara Denny wrote: >>> >>> That is my recollection too. EGP had topology constraints. >>> >>> barbara >>> >>> On Wednesday, September 2, 2020, 08:07:37 AM PDT, Scott O. Bradner via >> Internet-history wrote: >>> >>> >>> my recollection was that EGP could not be twisted enough to be able to >> deal with the actual >>> topology that was evolving on the Internet >>> >>> Scott >>> >>> ps - I tried to open an old powerpoint presentation (from the late >> 1990s) where I discussed EGP & BGP >>> but it seem like the oldest version of PowerPoint I have had evolved >> enough that it will no longer open >>> that version - I mention that because there is yet again a discussion >> on the IETF list about RFC formats >>> and some people have argued, as people have argued for at least 20 >> years, that moving to MS Word >>> would be a good thing >>> >>> >>> >>>> On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history < >> internet-history at elists.isoc.org> wrote: >>>> >>>> On 9/2/20 7:55 AM, Dan York via Internet-history wrote: >>>>> Grant, >>>> >>>> Hi, >>>> >>>>> It also needs more explanation that EGP was replaced by BGP. (The >> current sentence there says ?essentially replaced? and is a bit vague with >> no references.) >>>> >>>> Hum. >>>> >>>>> If any of you all here know of any RFCs that explicitly indicate EGP >> was replaced/obsoleted, or if you know of any journal articles, academic >> papers, historical documents, etc., that could be useful, I would be glad >> to update the article a bit. Or if you can point me to any info about the >> creation of EGP (there?s a line that needs a source). Or any other info you >> think would be useful in this Wikipedia article, that would be great. >>>> >>>> I found a some information about EGP in and around the gated routing >> daemon. I wonder if there might be some more information that could help >> you. >>>> >>>>> (Note that for info to appear in the English version of Wikipedia, it >> needs to be backed up by a ?reliable source? - >> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6ld3QEI5A$ - which includes >> journal articles, academic papers, news articles, RFCs, etc.) >>>> >>>> I wonder if you can find any graphs on the number of Internet >> connections using BGP. If similar ever existed for EGP, you can probably >> compare / contrast the two. >>>> >>>> I also think that the lack of contemporary EGP implementations is >> evidence of BGP's replacement of EGP. As is the fact that BGP supports >> things that EGP does not. Things which are used all over the Internet, >> e.g. multipath. >>>> >>>> >>>> >>>> -- >>>> Grant. . . . >>>> unix || die >>>> >>>> -- >>>> Internet-history mailing list >>>> Internet-history at elists.isoc.org >>>> https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ >>> >>> >>> -- >>> Internet-history mailing list >>> Internet-history at elists.isoc.org >>> https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ >> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ >> > > From scott.brim at gmail.com Wed Sep 2 14:23:02 2020 From: scott.brim at gmail.com (Scott Brim) Date: Wed, 2 Sep 2020 17:23:02 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: Yes. My first IETF was #3 and a major topic was "FGP", the Follow-On Gateway Protocol, figuring out a follow-on to EGP (several people on this list will remember that time). It didn't get far, but we tossed good ideas around, in particular iirc Mike St. Johns wanted to eliminate using numbers to prioritize routes in any way. When the IETF developed working groups, I had a short-lived one named something like "Topology Engineering" that fed into Guy's WG. The zero-one-infinity mantra, and the conceptualization of what was eventually called path vector, were great developments. Unfortunately I got sick just before the Austin IETF so I missed the moment of birth of BGP but Jeff Honig was there, and we piled in with the Gatedaemon. Dennis Ferguson (again, that's as I recall) had an implementation for gated in ~3 weeks. After that, when I was doing multicast, attempts at source-asserted path vectors for interdomain multicast came right out of those early BGP concepts. On Wed, Sep 2, 2020 at 5:10 PM Guy Almes via Internet-history < internet-history at elists.isoc.org> wrote: > Craig et al., > 1987 was an interesting year. The NSFnet-related regional networks > were connecting new sites and had to solve interesting routing problems. > EGP would tell you that a given network was reachable via a given > gateway router / AS. But that network might be reachable via two > different gateways. > During that era, our "Sesquinet" regional network in Texas was > connected to two different valuable "backbone" type networks: the > Fuzzball-based proto-NSFnet via Boulder and the ARPAnet via Austin. > Both were useful. Both had 56kb/s circuits. Both were congested. > At that time, there were a few hundred networks, and I recall going > through the whole list, one by one, figuring out whether, if they were > reachable via both the ARPAnet and the proto-NSFnet, which should be > preferred. I considered it worth doing, but it was of course Quixotic, > given the rapidly growing number of connected networks. > > Phill Gross asked me to lead an "Interconnectivity Working Group" > within the IETF and work to solve some of these problems. It was a > great group, with members from the ARPAnet, NSFnet, NASA, ESnet, and > other communities. Understanding the various "backbones", their > differing technical and policy natures, and the limitations of EGP all > made for fascinating discussions, which did allow us to make progress. > One of our explicit marching orders was *not* to invent a new protocol. > But we did discuss the problem of how to choose which of two exterior > routes to use when both advertised a given network. > One line of thought was to consider that the Internet, while not > having a "tree topology", did have a notion of levels of hierarchy, > e.g., campus, then regional, then national backbone, then international > links. I am grateful that we fairly quickly realized that relying on > that notion of hierarchy would be building on sand. > But what kind of "metric" could be used to help make routing decisions? > One idea, based on Cicso's IGRP protocol was to characterize each > transit network with a bandwidth and a delay metric. Then minimum of > bandwidth along a path and sum of delay along a path could be used. > That did not get traction. > I'd been teaching a computer scientist where an idea called the > "zero, one, infinity rule" was discussed. As applied here, if a single > scalar number would not suffice as a metric, then allow a metric of > variable length. For example, a whole AS-path could be an interesting > kind of metric could be used. But, particularly during that era, > variable-length fields in protocols were not in favor, and we did not > pursue this idea. > Except that, at our next working group meeting (at the January 1989 > IETF meeting at UT-Austin), Kirk Lougheed (Cisco) and Yakov Rekhter > (IBM) invented BGP in one of the Internet's most famous napkins. The > complete AS-path, variable though it was, was a key idea. > BGP solved several problems with EGP. > I should emphasize that the AS-path was never exactly regarded as a > "metric", but it provided valuable information. I'll avoid going > further with the evolution of BGP, but it was so much better than its > predecessor and came along at a very fortunate time. > > -- Guy > > On 9/2/20 3:57 PM, Craig Partridge via Internet-history wrote: > > There was a SIGCOMM '87 paper by Mills and Hans-Werner Braun that > discussed > > what happened when you tried to break the tree topology. > > > > Craig > > > > On Wed, Sep 2, 2020 at 1:52 PM Scott O. Bradner via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> I found a printout of my late 1990s notes which said that EGP was > "limited > >> to a tree structured Internet" > >> although I recall that people were hacking it to expand its usefulness > but > >> the result was not pretty > >> > >> Scott > >> > >> > >>> On Sep 2, 2020, at 3:45 PM, Barbara Denny wrote: > >>> > >>> That is my recollection too. EGP had topology constraints. > >>> > >>> barbara > >>> > >>> On Wednesday, September 2, 2020, 08:07:37 AM PDT, Scott O. Bradner via > >> Internet-history wrote: > >>> > >>> > >>> my recollection was that EGP could not be twisted enough to be able to > >> deal with the actual > >>> topology that was evolving on the Internet > >>> > >>> Scott > >>> > >>> ps - I tried to open an old powerpoint presentation (from the late > >> 1990s) where I discussed EGP & BGP > >>> but it seem like the oldest version of PowerPoint I have had evolved > >> enough that it will no longer open > >>> that version - I mention that because there is yet again a discussion > >> on the IETF list about RFC formats > >>> and some people have argued, as people have argued for at least 20 > >> years, that moving to MS Word > >>> would be a good thing > >>> > >>> > >>> > >>>> On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history < > >> internet-history at elists.isoc.org> wrote: > >>>> > >>>> On 9/2/20 7:55 AM, Dan York via Internet-history wrote: > >>>>> Grant, > >>>> > >>>> Hi, > >>>> > >>>>> It also needs more explanation that EGP was replaced by BGP. (The > >> current sentence there says ?essentially replaced? and is a bit vague > with > >> no references.) > >>>> > >>>> Hum. > >>>> > >>>>> If any of you all here know of any RFCs that explicitly indicate EGP > >> was replaced/obsoleted, or if you know of any journal articles, academic > >> papers, historical documents, etc., that could be useful, I would be > glad > >> to update the article a bit. Or if you can point me to any info about > the > >> creation of EGP (there?s a line that needs a source). Or any other info > you > >> think would be useful in this Wikipedia article, that would be great. > >>>> > >>>> I found a some information about EGP in and around the gated routing > >> daemon. I wonder if there might be some more information that could > help > >> you. > >>>> > >>>>> (Note that for info to appear in the English version of Wikipedia, it > >> needs to be backed up by a ?reliable source? - > >> > https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6ld3QEI5A$ > - which includes > >> journal articles, academic papers, news articles, RFCs, etc.) > >>>> > >>>> I wonder if you can find any graphs on the number of Internet > >> connections using BGP. If similar ever existed for EGP, you can > probably > >> compare / contrast the two. > >>>> > >>>> I also think that the lack of contemporary EGP implementations is > >> evidence of BGP's replacement of EGP. As is the fact that BGP supports > >> things that EGP does not. Things which are used all over the Internet, > >> e.g. multipath. > >>>> > >>>> > >>>> > >>>> -- > >>>> Grant. . . . > >>>> unix || die > >>>> > >>>> -- > >>>> Internet-history mailing list > >>>> Internet-history at elists.isoc.org > >>>> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >>> > >>> > >>> -- > >>> Internet-history mailing list > >>> Internet-history at elists.isoc.org > >>> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >> > >> -- > >> Internet-history mailing list > >> Internet-history at elists.isoc.org > >> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >> > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From galmes at tamu.edu Wed Sep 2 14:33:15 2020 From: galmes at tamu.edu (Guy Almes) Date: Wed, 2 Sep 2020 17:33:15 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: Scott, Exactly. As Vint just reminded me, not only was the variable length AS path an unusual characteristic, but BGP's use of TCP was quite controversial. But, in addition to other advantages, the use of TCP made possible several early implementations. -- Guy On 9/2/20 5:23 PM, Scott Brim wrote: > Yes. My first IETF was #3 and a major topic was "FGP", the Follow-On > Gateway Protocol, figuring out a follow-on to EGP (several people on > this list will remember that time). It didn't get far, but we tossed > good ideas around, in particular iirc Mike St. Johns wanted to eliminate > using numbers to prioritize routes in any way. When the IETF developed > working groups, I had a short-lived one named something like "Topology > Engineering" that fed into Guy's WG. The zero-one-infinity mantra, and > the conceptualization of what was eventually called path vector, were > great developments. Unfortunately I got sick just before the Austin IETF > so I missed the moment of birth of BGP but Jeff Honig was there, and we > piled in with the Gatedaemon. Dennis Ferguson (again, that's as I > recall) had an implementation for gated in ~3 weeks.? After that, when I > was doing multicast, attempts at source-asserted?path vectors for > interdomain multicast came right out of those early BGP concepts. > > On Wed, Sep 2, 2020 at 5:10 PM Guy Almes via Internet-history > > wrote: > > Craig et al., > ? ?1987 was an interesting year.? The NSFnet-related regional networks > were connecting new sites and had to solve interesting routing problems. > ? ?EGP would tell you that a given network was reachable via a given > gateway router / AS.? But that network might be reachable via two > different gateways. > ? ?During that era, our "Sesquinet" regional network in Texas was > connected to two different valuable "backbone" type networks: the > Fuzzball-based proto-NSFnet via Boulder and the ARPAnet via Austin. > Both were useful.? Both had 56kb/s circuits.? Both were congested. > ? ?At that time, there were a few hundred networks, and I recall going > through the whole list, one by one, figuring out whether, if they were > reachable via both the ARPAnet and the proto-NSFnet, which should be > preferred.? I considered it worth doing, but it was of course Quixotic, > given the rapidly growing number of connected networks. > > ? ?Phill Gross asked me to lead an "Interconnectivity Working Group" > within the IETF and work to solve some of these problems.? It was a > great group, with members from the ARPAnet, NSFnet, NASA, ESnet, and > other communities.? Understanding the various "backbones", their > differing technical and policy natures, and the limitations of EGP all > made for fascinating discussions, which did allow us to make progress. > ? ?One of our explicit marching orders was *not* to invent a new > protocol. > ? ?But we did discuss the problem of how to choose which of two > exterior > routes to use when both advertised a given network. > ? ?One line of thought was to consider that the Internet, while not > having a "tree topology", did have a notion of levels of hierarchy, > e.g., campus, then regional, then national backbone, then international > links.? I am grateful that we fairly quickly realized that relying on > that notion of hierarchy would be building on sand. > ? ?But what kind of "metric" could be used to help make routing > decisions? > ? ?One idea, based on Cicso's IGRP protocol was to characterize each > transit network with a bandwidth and a delay metric.? Then minimum of > bandwidth along a path and sum of delay along a path could be used. > That did not get traction. > ? ?I'd been teaching a computer scientist where an idea called the > "zero, one, infinity rule" was discussed.? As applied here, if a single > scalar number would not suffice as a metric, then allow a metric of > variable length.? For example, a whole AS-path could be an interesting > kind of metric could be used.? But, particularly during that era, > variable-length fields in protocols were not in favor, and we did not > pursue this idea. > ? ?Except that, at our next working group meeting (at the January 1989 > IETF meeting at UT-Austin), Kirk Lougheed (Cisco) and Yakov Rekhter > (IBM) invented BGP in one of the Internet's most famous napkins.? The > complete AS-path, variable though it was, was a key idea. > ? ?BGP solved several problems with EGP. > ? ?I should emphasize that the AS-path was never exactly regarded as a > "metric", but it provided valuable information.? I'll avoid going > further with the evolution of BGP, but it was so much better than its > predecessor and came along at a very fortunate time. > > ? ? ? ? -- Guy > > On 9/2/20 3:57 PM, Craig Partridge via Internet-history wrote: > > There was a SIGCOMM '87 paper by Mills and Hans-Werner Braun that > discussed > > what happened when you tried to break the tree topology. > > > > Craig > > > > On Wed, Sep 2, 2020 at 1:52 PM Scott O. Bradner via > Internet-history < > > internet-history at elists.isoc.org > > wrote: > > > >> I found a printout of my late 1990s notes which said that EGP > was "limited > >> to a tree structured Internet" > >> although I recall that people were hacking it to expand its > usefulness but > >> the result was not pretty > >> > >> Scott > >> > >> > >>> On Sep 2, 2020, at 3:45 PM, Barbara Denny > wrote: > >>> > >>> That is my recollection too. EGP had topology constraints. > >>> > >>> barbara > >>> > >>> On Wednesday, September 2, 2020, 08:07:37 AM PDT, Scott O. > Bradner via > >> Internet-history > wrote: > >>> > >>> > >>> my recollection was that EGP could not be twisted enough to be > able to > >> deal with the actual > >>> topology that was evolving on the Internet > >>> > >>> Scott > >>> > >>> ps - I tried to open an old powerpoint presentation (from the late > >> 1990s) where I discussed EGP & BGP > >>> but it seem like the oldest version of PowerPoint I have had > evolved > >> enough that it will no longer open > >>> that version? - I mention that because there is yet again a > discussion > >> on the IETF list about RFC formats > >>> and some people have argued, as people have argued for at least 20 > >> years, that moving to MS Word > >>> would be a good thing > >>> > >>> > >>> > >>>> On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history < > >> internet-history at elists.isoc.org > > wrote: > >>>> > >>>> On 9/2/20 7:55 AM, Dan York via Internet-history wrote: > >>>>> Grant, > >>>> > >>>> Hi, > >>>> > >>>>> It also needs more explanation that EGP was replaced by BGP. (The > >> current sentence there says ?essentially replaced? and is a bit > vague with > >> no references.) > >>>> > >>>> Hum. > >>>> > >>>>> If any of you all here know of any RFCs that explicitly > indicate EGP > >> was replaced/obsoleted, or if you know of any journal articles, > academic > >> papers, historical documents, etc., that could be useful, I > would be glad > >> to update the article a bit. Or if you can point me to any info > about the > >> creation of EGP (there?s a line that needs a source). Or any > other info you > >> think would be useful in this Wikipedia article, that would be > great. > >>>> > >>>> I found a some information about EGP in and around the gated > routing > >> daemon.? I wonder if there might be some more information that > could help > >> you. > >>>> > >>>>> (Note that for info to appear in the English version of > Wikipedia, it > >> needs to be backed up by a ?reliable source? - > >> > https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6ld3QEI5A$ > - which includes > >> journal articles, academic papers, news articles, RFCs, etc.) > >>>> > >>>> I wonder if you can find any graphs on the number of Internet > >> connections using BGP.? If similar ever existed for EGP, you can > probably > >> compare / contrast the two. > >>>> > >>>> I also think that the lack of contemporary EGP implementations is > >> evidence of BGP's replacement of EGP.? As is the fact that BGP > supports > >> things that EGP does not.? Things which are used all over the > Internet, > >> e.g. multipath. > >>>> > >>>> > >>>> > >>>> -- > >>>> Grant. . . . > >>>> unix || die > >>>> > >>>> -- > >>>> Internet-history mailing list > >>>> Internet-history at elists.isoc.org > > >>>> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >>> > >>> > >>> -- > >>> Internet-history mailing list > >>> Internet-history at elists.isoc.org > > >>> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >> > >> -- > >> Internet-history mailing list > >> Internet-history at elists.isoc.org > > >> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >> > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > From geoff at iconia.com Wed Sep 2 15:08:36 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Wed, 2 Sep 2020 12:08:36 -1000 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: gents, in the midst of this EGP/IGP/BGP recollectioning: where did/does SFP fit in with gateway protocol historying? geoff On Wed, Sep 2, 2020 at 11:10 AM Guy Almes via Internet-history < internet-history at elists.isoc.org> wrote: > Craig et al., > 1987 was an interesting year. The NSFnet-related regional networks > were connecting new sites and had to solve interesting routing problems. > EGP would tell you that a given network was reachable via a given > gateway router / AS. But that network might be reachable via two > different gateways. > During that era, our "Sesquinet" regional network in Texas was > connected to two different valuable "backbone" type networks: the > Fuzzball-based proto-NSFnet via Boulder and the ARPAnet via Austin. > Both were useful. Both had 56kb/s circuits. Both were congested. > At that time, there were a few hundred networks, and I recall going > through the whole list, one by one, figuring out whether, if they were > reachable via both the ARPAnet and the proto-NSFnet, which should be > preferred. I considered it worth doing, but it was of course Quixotic, > given the rapidly growing number of connected networks. > > Phill Gross asked me to lead an "Interconnectivity Working Group" > within the IETF and work to solve some of these problems. It was a > great group, with members from the ARPAnet, NSFnet, NASA, ESnet, and > other communities. Understanding the various "backbones", their > differing technical and policy natures, and the limitations of EGP all > made for fascinating discussions, which did allow us to make progress. > One of our explicit marching orders was *not* to invent a new protocol. > But we did discuss the problem of how to choose which of two exterior > routes to use when both advertised a given network. > One line of thought was to consider that the Internet, while not > having a "tree topology", did have a notion of levels of hierarchy, > e.g., campus, then regional, then national backbone, then international > links. I am grateful that we fairly quickly realized that relying on > that notion of hierarchy would be building on sand. > But what kind of "metric" could be used to help make routing decisions? > One idea, based on Cicso's IGRP protocol was to characterize each > transit network with a bandwidth and a delay metric. Then minimum of > bandwidth along a path and sum of delay along a path could be used. > That did not get traction. > I'd been teaching a computer scientist where an idea called the > "zero, one, infinity rule" was discussed. As applied here, if a single > scalar number would not suffice as a metric, then allow a metric of > variable length. For example, a whole AS-path could be an interesting > kind of metric could be used. But, particularly during that era, > variable-length fields in protocols were not in favor, and we did not > pursue this idea. > Except that, at our next working group meeting (at the January 1989 > IETF meeting at UT-Austin), Kirk Lougheed (Cisco) and Yakov Rekhter > (IBM) invented BGP in one of the Internet's most famous napkins. The > complete AS-path, variable though it was, was a key idea. > BGP solved several problems with EGP. > I should emphasize that the AS-path was never exactly regarded as a > "metric", but it provided valuable information. I'll avoid going > further with the evolution of BGP, but it was so much better than its > predecessor and came along at a very fortunate time. > > -- Guy > > On 9/2/20 3:57 PM, Craig Partridge via Internet-history wrote: > > There was a SIGCOMM '87 paper by Mills and Hans-Werner Braun that > discussed > > what happened when you tried to break the tree topology. > > > > Craig > > > > On Wed, Sep 2, 2020 at 1:52 PM Scott O. Bradner via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> I found a printout of my late 1990s notes which said that EGP was > "limited > >> to a tree structured Internet" > >> although I recall that people were hacking it to expand its usefulness > but > >> the result was not pretty > >> > >> Scott > >> > >> > >>> On Sep 2, 2020, at 3:45 PM, Barbara Denny wrote: > >>> > >>> That is my recollection too. EGP had topology constraints. > >>> > >>> barbara > >>> > >>> On Wednesday, September 2, 2020, 08:07:37 AM PDT, Scott O. Bradner via > >> Internet-history wrote: > >>> > >>> > >>> my recollection was that EGP could not be twisted enough to be able to > >> deal with the actual > >>> topology that was evolving on the Internet > >>> > >>> Scott > >>> > >>> ps - I tried to open an old powerpoint presentation (from the late > >> 1990s) where I discussed EGP & BGP > >>> but it seem like the oldest version of PowerPoint I have had evolved > >> enough that it will no longer open > >>> that version - I mention that because there is yet again a discussion > >> on the IETF list about RFC formats > >>> and some people have argued, as people have argued for at least 20 > >> years, that moving to MS Word > >>> would be a good thing > >>> > >>> > >>> > >>>> On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history < > >> internet-history at elists.isoc.org> wrote: > >>>> > >>>> On 9/2/20 7:55 AM, Dan York via Internet-history wrote: > >>>>> Grant, > >>>> > >>>> Hi, > >>>> > >>>>> It also needs more explanation that EGP was replaced by BGP. (The > >> current sentence there says ?essentially replaced? and is a bit vague > with > >> no references.) > >>>> > >>>> Hum. > >>>> > >>>>> If any of you all here know of any RFCs that explicitly indicate EGP > >> was replaced/obsoleted, or if you know of any journal articles, academic > >> papers, historical documents, etc., that could be useful, I would be > glad > >> to update the article a bit. Or if you can point me to any info about > the > >> creation of EGP (there?s a line that needs a source). Or any other info > you > >> think would be useful in this Wikipedia article, that would be great. > >>>> > >>>> I found a some information about EGP in and around the gated routing > >> daemon. I wonder if there might be some more information that could > help > >> you. > >>>> > >>>>> (Note that for info to appear in the English version of Wikipedia, it > >> needs to be backed up by a ?reliable source? - > >> > https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6ld3QEI5A$ > - which includes > >> journal articles, academic papers, news articles, RFCs, etc.) > >>>> > >>>> I wonder if you can find any graphs on the number of Internet > >> connections using BGP. If similar ever existed for EGP, you can > probably > >> compare / contrast the two. > >>>> > >>>> I also think that the lack of contemporary EGP implementations is > >> evidence of BGP's replacement of EGP. As is the fact that BGP supports > >> things that EGP does not. Things which are used all over the Internet, > >> e.g. multipath. > >>>> > >>>> > >>>> > >>>> -- > >>>> Grant. . . . > >>>> unix || die > >>>> > >>>> -- > >>>> Internet-history mailing list > >>>> Internet-history at elists.isoc.org > >>>> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >>> > >>> > >>> -- > >>> Internet-history mailing list > >>> Internet-history at elists.isoc.org > >>> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >> > >> -- > >> Internet-history mailing list > >> Internet-history at elists.isoc.org > >> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >> > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From galmes at tamu.edu Wed Sep 2 17:24:38 2020 From: galmes at tamu.edu (Guy Almes) Date: Wed, 2 Sep 2020 20:24:38 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: Hi Geoff, You ask about how SPF (shortest path first) fits in. I'll try to answer, keeping in mind that this is a history list (and not a deep routing-technical list). At the outset, the basic concept of an Autonomous System (AS) is so important. I appreciate Jack Haverty's message describing how he and Eric Rosen came up with it at BBN. An AS is a set of routers (fine point: not a set of networks) under a single technical/administrative unit. This naturally led to the distinction between routing protocols for use within an AS (an Interior Gateway Protocol) and for use between pairs of ASes (an Exterior Gateway Protocol). While not strictly necessary, this has led to a variety of IGPs (since each AS can make its own decision about this) vs uniformity of an EGP (since all the ASes need to agree on them). Thus, there is usually only one 'EGP' (EGPv2 during the period 1986 to 1990, BGP since about 1990, and an awkward period during the transition). Within the world of IGPs of that era, most were distance-vector. With history going back to the original ARPAnet routing protocol, these included (in the 1986-1990 era): <> RIP, using hop count as its metric, <> Hello, from Dave Mills including in his Fuzzball routers, using delay as its metric (sometimes measured delay, but more often configured delay), and <> IGRP, from Cisco, with an interesting combination of min-bandwidth and sum-of-delay metrics. These were relatively simple to implement and could exhibit nasty "counting to infinity" problems. And there were shortest-path-first (alias link-state) protocols. With history going back to the second ARPAnet routing protocol, these included: <> ISIS, from the DECnet effort, and <> OSPF, for Open Shortest Path First, from the IETF. These were more sophisticated both in theory and practice, but converged quickly and had other nice technical properties. A key challenge is that the SPF algorithm is executed on all the routers within the AS in a consistent way; if done correctly, this can result in nicely optimized routes and rapid convergence times. It's worth noting that BGP can be viewed as a distance-vector protocol, with the entire AS-path as its metric. Note that BGP does *not* dictate which of several possible routes a given AS will prefer (and propagate). And, sure enough, it can exhibit a really nasty version of the "counting to infinity" problem. While I'm not aware of anyone actually doing this, it is interesting to contemplate what an SPF-based *EGP*. This could have advantages (e.g., more optimal inter-AS routing and rapid convergence times), but having any Global agreement on which inter-AS routes will be preferred would be very unlikely. So, in practice, SPF technology is only used in IGPs. Again, I focus on the late 1980s for historical focus. And also, since, once a pretty good system, especially with BGP in the generic EGP/inter-AS context, evolves, it's hard to make big changes. Comments? -- Guy On 9/2/20 6:08 PM, the keyboard of geoff goodfellow wrote: > gents, in the midst of this EGP/IGP/BGP recollectioning: > where?did/does SFP fit in with gateway protocol historying? > geoff > > On Wed, Sep 2, 2020 at 11:10 AM Guy Almes via Internet-history > > wrote: > > Craig et al., > ? ?1987 was an interesting year.? The NSFnet-related regional networks > were connecting new sites and had to solve interesting routing problems. > ? ?EGP would tell you that a given network was reachable via a given > gateway router / AS.? But that network might be reachable via two > different gateways. > ? ?During that era, our "Sesquinet" regional network in Texas was > connected to two different valuable "backbone" type networks: the > Fuzzball-based proto-NSFnet via Boulder and the ARPAnet via Austin. > Both were useful.? Both had 56kb/s circuits.? Both were congested. > ? ?At that time, there were a few hundred networks, and I recall going > through the whole list, one by one, figuring out whether, if they were > reachable via both the ARPAnet and the proto-NSFnet, which should be > preferred.? I considered it worth doing, but it was of course Quixotic, > given the rapidly growing number of connected networks. > > ? ?Phill Gross asked me to lead an "Interconnectivity Working Group" > within the IETF and work to solve some of these problems.? It was a > great group, with members from the ARPAnet, NSFnet, NASA, ESnet, and > other communities.? Understanding the various "backbones", their > differing technical and policy natures, and the limitations of EGP all > made for fascinating discussions, which did allow us to make progress. > ? ?One of our explicit marching orders was *not* to invent a new > protocol. > ? ?But we did discuss the problem of how to choose which of two > exterior > routes to use when both advertised a given network. > ? ?One line of thought was to consider that the Internet, while not > having a "tree topology", did have a notion of levels of hierarchy, > e.g., campus, then regional, then national backbone, then international > links.? I am grateful that we fairly quickly realized that relying on > that notion of hierarchy would be building on sand. > ? ?But what kind of "metric" could be used to help make routing > decisions? > ? ?One idea, based on Cicso's IGRP protocol was to characterize each > transit network with a bandwidth and a delay metric.? Then minimum of > bandwidth along a path and sum of delay along a path could be used. > That did not get traction. > ? ?I'd been teaching a computer scientist where an idea called the > "zero, one, infinity rule" was discussed.? As applied here, if a single > scalar number would not suffice as a metric, then allow a metric of > variable length.? For example, a whole AS-path could be an interesting > kind of metric could be used.? But, particularly during that era, > variable-length fields in protocols were not in favor, and we did not > pursue this idea. > ? ?Except that, at our next working group meeting (at the January 1989 > IETF meeting at UT-Austin), Kirk Lougheed (Cisco) and Yakov Rekhter > (IBM) invented BGP in one of the Internet's most famous napkins.? The > complete AS-path, variable though it was, was a key idea. > ? ?BGP solved several problems with EGP. > ? ?I should emphasize that the AS-path was never exactly regarded as a > "metric", but it provided valuable information.? I'll avoid going > further with the evolution of BGP, but it was so much better than its > predecessor and came along at a very fortunate time. > > ? ? ? ? -- Guy > > On 9/2/20 3:57 PM, Craig Partridge via Internet-history wrote: > > There was a SIGCOMM '87 paper by Mills and Hans-Werner Braun that > discussed > > what happened when you tried to break the tree topology. > > > > Craig > > > > On Wed, Sep 2, 2020 at 1:52 PM Scott O. Bradner via > Internet-history < > > internet-history at elists.isoc.org > > wrote: > > > >> I found a printout of my late 1990s notes which said that EGP > was "limited > >> to a tree structured Internet" > >> although I recall that people were hacking it to expand its > usefulness but > >> the result was not pretty > >> > >> Scott > >> > >> > >>> On Sep 2, 2020, at 3:45 PM, Barbara Denny > wrote: > >>> > >>> That is my recollection too. EGP had topology constraints. > >>> > >>> barbara > >>> > >>> On Wednesday, September 2, 2020, 08:07:37 AM PDT, Scott O. > Bradner via > >> Internet-history > wrote: > >>> > >>> > >>> my recollection was that EGP could not be twisted enough to be > able to > >> deal with the actual > >>> topology that was evolving on the Internet > >>> > >>> Scott > >>> > >>> ps - I tried to open an old powerpoint presentation (from the late > >> 1990s) where I discussed EGP & BGP > >>> but it seem like the oldest version of PowerPoint I have had > evolved > >> enough that it will no longer open > >>> that version? - I mention that because there is yet again a > discussion > >> on the IETF list about RFC formats > >>> and some people have argued, as people have argued for at least 20 > >> years, that moving to MS Word > >>> would be a good thing > >>> > >>> > >>> > >>>> On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history < > >> internet-history at elists.isoc.org > > wrote: > >>>> > >>>> On 9/2/20 7:55 AM, Dan York via Internet-history wrote: > >>>>> Grant, > >>>> > >>>> Hi, > >>>> > >>>>> It also needs more explanation that EGP was replaced by BGP. (The > >> current sentence there says ?essentially replaced? and is a bit > vague with > >> no references.) > >>>> > >>>> Hum. > >>>> > >>>>> If any of you all here know of any RFCs that explicitly > indicate EGP > >> was replaced/obsoleted, or if you know of any journal articles, > academic > >> papers, historical documents, etc., that could be useful, I > would be glad > >> to update the article a bit. Or if you can point me to any info > about the > >> creation of EGP (there?s a line that needs a source). Or any > other info you > >> think would be useful in this Wikipedia article, that would be > great. > >>>> > >>>> I found a some information about EGP in and around the gated > routing > >> daemon.? I wonder if there might be some more information that > could help > >> you. > >>>> > >>>>> (Note that for info to appear in the English version of > Wikipedia, it > >> needs to be backed up by a ?reliable source? - > >> > https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6ld3QEI5A$ > - which includes > >> journal articles, academic papers, news articles, RFCs, etc.) > >>>> > >>>> I wonder if you can find any graphs on the number of Internet > >> connections using BGP.? If similar ever existed for EGP, you can > probably > >> compare / contrast the two. > >>>> > >>>> I also think that the lack of contemporary EGP implementations is > >> evidence of BGP's replacement of EGP.? As is the fact that BGP > supports > >> things that EGP does not.? Things which are used all over the > Internet, > >> e.g. multipath. > >>>> > >>>> > >>>> > >>>> -- > >>>> Grant. . . . > >>>> unix || die > >>>> > >>>> -- > >>>> Internet-history mailing list > >>>> Internet-history at elists.isoc.org > > >>>> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >>> > >>> > >>> -- > >>> Internet-history mailing list > >>> Internet-history at elists.isoc.org > > >>> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >> > >> -- > >> Internet-history mailing list > >> Internet-history at elists.isoc.org > > >> > https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ > >> > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > From tony.li at tony.li Wed Sep 2 17:47:41 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Wed, 2 Sep 2020 17:47:41 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: <0AD082CA-03BB-439C-A6BF-8B3F79064F00@tony.li> To add a bit of color: > And there were shortest-path-first (alias link-state) protocols. With history going back to the second ARPAnet routing protocol, these included: > <> ISIS, from the DECnet effort, and > <> OSPF, for Open Shortest Path First, from the IETF. > These were more sophisticated both in theory and practice, but converged quickly and had other nice technical properties. A key challenge is that the SPF algorithm is executed on all the routers within the AS in a consistent way; if done correctly, this can result in nicely optimized routes and rapid convergence times. Both of these are supposedly evolved from BBN?s Spread protocol, which I think is what was documented here: https://www.cs.yale.edu/homes/lans/readings/routing/mcquillan-darpa_routing-1980.pdf While link state has many good properties, scaling it turns out to be challenging, both in state volume and in messaging in dense topologies. Hierarchy was introduced to help with the amount of state, but flooding has not been addressed until very recently. In the interim, many sites have turned to using BGP as their IGP to avoid this issue. > It's worth noting that BGP can be viewed as a distance-vector protocol, with the entire AS-path as its metric. Note that BGP does *not* dictate which of several possible routes a given AS will prefer (and propagate). And, sure enough, it can exhibit a really nasty version of the "counting to infinity" problem. Namely, it explores every possible loop-free recovery path until all possible paths are known to have failed. Yes, this can be painful, but what can you do short of an oracle? > While I'm not aware of anyone actually doing this, it is interesting to contemplate what an SPF-based *EGP*. This could have advantages (e.g., more optimal inter-AS routing and rapid convergence times), but having any Global agreement on which inter-AS routes will be preferred would be very unlikely. This was explored as part of a BBN research project in the late ?80s called Inter-Domain Policy Routing (lead: Martha Steenstrup) (IDPR ? not to be confused with IDRP). As noted, getting routing policy out of commercial players was discussed and violently discarded. Routing policies are encodings of corporate relationships and to be able to see inequalities in treatment would have caused extreme reactions in the industry. Noel also applied link-state to his NIMROD proposal. > Again, I focus on the late 1980s for historical focus. And also, since, once a pretty good system, especially with BGP in the generic EGP/inter-AS context, evolves, it's hard to make big changes. > Comments? We await better ideas. :-) Deployment is possible through an overlay, as we initially did with BGP. Regards, Tony From scott.brim at gmail.com Wed Sep 2 18:13:56 2020 From: scott.brim at gmail.com (Scott Brim) Date: Wed, 2 Sep 2020 21:13:56 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: and GGP ( :-) ) From jnc at mercury.lcs.mit.edu Wed Sep 2 19:12:21 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 2 Sep 2020 22:12:21 -0400 (EDT) Subject: [ih] Exterior Gateway Protocol Message-ID: <20200903021221.9622718C09D@mercury.lcs.mit.edu> > From: Craig Partridge > Could Bob have been thinking about splitting off DoD IP networks to > another provider ... and using EGP for that purpose? I was involved with an early incident that _may_ have been part of the impetus for EGP; I was out of the loop that started EGP, so I can't say for sure. Well, let me tell the story, FWIW. MIT got a router (gateway as we called them then) between its collection of LAN's (mostly CHAOS speaking at that early stage) and the ARPANET somewhat early on; later than would have been optimal, but there were no spare IMP ports at MIT, and we had to wait for the installation of IMP 77 (one of the first C/30 IMPs, I think) to get connected to the Internet. (Jerry Saltzer worked out when that was, by looking in hardcopies of CSR progress reports that he had in his garage; I can look it up if it's important. My very vague memory is that it was roughly around 1980.) The first ARPANET gateway at MIT was bodged 'Port Expander' code (I found a version of it in that CSR dump, if anyone cares; I'm not sure it's the version that was in service, all that stuff is pretty disorganized). To exchange packets with the rest of the Internet, we needed to let the BBN gateways (pretty much all there were at the time) know that MIT-GW was the route to net 18. We decided to do that by hacking up a small MOS process to run in the same box, which would send a small, short GGP routing update that just said 'net 18. this way' every so often. So I coded it up, installed it in MIT-GW, and apparently as soon as I started it, the BBN gateways started falling over. IIRC, I got a phone call from someone at BBN, asking what I was doing that was causing their gateways to crash. This was news to me, I had no idea I was doing that. Anyway, after some investigation, we figured out what had happened: BBN had changed the format of GGP routing update, but hadn't documented the change. So when I dutifully took the routing update format from the GGP spec online, it was malformed in a way that killed the BBN code. I have this memory that when this tale was told to Vint at the next Internet WG meeting, he took out a little notebook and made some notes, and shortly thereafter we found out that the Internet router work at BBN had moved between Div 4 and Div 6 - we were under the impression at the time that that change was a result of those router issues. I don't know if the start of EGP was also connected, but those events certainly showed the downside of having new routers trying to talk GGP to the BBN routers. Noel From brian.e.carpenter at gmail.com Wed Sep 2 19:16:13 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 3 Sep 2020 14:16:13 +1200 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <0AD082CA-03BB-439C-A6BF-8B3F79064F00@tony.li> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <0AD082CA-03BB-439C-A6BF-8B3F79064F00@tony.li> Message-ID: On 03-Sep-20 12:47, Tony Li via Internet-history wrote: ... > Namely, it explores every possible loop-free recovery path until all possible paths are known to have failed. Yes, this can be painful, but what can you do short of an oracle? Was an oracle ever seriously contemplated for the Internet? SNA sysgen amounted to an oracle, but was of course notorious because the whole network had to be restarted to install a new set of tables. Brian From tony.li at tony.li Wed Sep 2 19:23:02 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Wed, 2 Sep 2020 19:23:02 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <0AD082CA-03BB-439C-A6BF-8B3F79064F00@tony.li> Message-ID: >> Namely, it explores every possible loop-free recovery path until all possible paths are known to have failed. Yes, this can be painful, but what can you do short of an oracle? > > Was an oracle ever seriously contemplated for the Internet? Only in the minds of computational complexity theorists, mythologists, and Larry Ellison. T From galmes at tamu.edu Wed Sep 2 19:28:14 2020 From: galmes at tamu.edu (Guy Almes) Date: Wed, 2 Sep 2020 22:28:14 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <0AD082CA-03BB-439C-A6BF-8B3F79064F00@tony.li> Message-ID: <3e8621ca-808f-56aa-4d7e-692bf2b50973@tamu.edu> Brian, I have literally not thought of this since about 1990, but ... Designing such an oracle would not so much be technically difficult, but it would surely fail for non-technical reasons. For example, with total inter-AS link-state knowledge, and with a definition of what "good" is, you could probably quickly compute a good set of routes. But I suspect that different competing ISPs would have a different definition of what "good" means. This was very evident even in 1990. -- Guy On 9/2/20 10:16 PM, Brian E Carpenter wrote: > On 03-Sep-20 12:47, Tony Li via Internet-history wrote: > ... >> Namely, it explores every possible loop-free recovery path until all possible paths are known to have failed. Yes, this can be painful, but what can you do short of an oracle? > > Was an oracle ever seriously contemplated for the Internet? > > SNA sysgen amounted to an oracle, but was of course notorious because the whole network had to be restarted to install a new set of tables. > > Brian > From b_a_denny at yahoo.com Wed Sep 2 22:05:51 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Thu, 3 Sep 2020 05:05:51 +0000 (UTC) Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: <801548670.2555059.1599109551064@mail.yahoo.com> I don't remember being part of this discussion but Packet Radio had ongoing DARPA projects through the 1980s. I would have questioned whether BGP's use of TCP at that point in time would result in stable BGP peers across Packet Radio networks.? I don't know whether any testing was done.? This is not to say we never tried anything that involved an EGP.? In September 1989 I participated a large military exercise using SINCGARS (a packet radio network with SINCGARS radios). However, we were just a stub network across a satellite link at Fort Gordon so no real test.? Unfortunately I don't remember right now if that exercise used BGP or EGP.? Allison Mankin might remember since she needed to take some measurements at the time. She called me to see if we could help her out since our SINCGARs demo network was one of the few sites up when she needed to do her work. Someone from BBN might know too because I think they were the ones who allocated the AS numbers used in the exercise.? I remember when we did this because Hurricane Hugo hit while I was on site so lots of activity to shut down early and weather the storm.? barbara? On Wednesday, September 2, 2020, 02:33:31 PM PDT, Guy Almes via Internet-history wrote: Scott, ? Exactly. ? As Vint just reminded me, not only was the variable length AS path an unusual characteristic, but BGP's use of TCP was quite controversial. But, in addition to other advantages, the use of TCP made possible several early implementations. ??? -- Guy On 9/2/20 5:23 PM, Scott Brim wrote: > Yes. My first IETF was #3 and a major topic was "FGP", the Follow-On > Gateway Protocol, figuring out a follow-on to EGP (several people on > this list will remember that time). It didn't get far, but we tossed > good ideas around, in particular iirc Mike St. Johns wanted to eliminate > using numbers to prioritize routes in any way. When the IETF developed > working groups, I had a short-lived one named something like "Topology > Engineering" that fed into Guy's WG. The zero-one-infinity mantra, and > the conceptualization of what was eventually called path vector, were > great developments. Unfortunately I got sick just before the Austin IETF > so I missed the moment of birth of BGP but Jeff Honig was there, and we > piled in with the Gatedaemon. Dennis Ferguson (again, that's as I > recall) had an implementation for gated in ~3 weeks.? After that, when I > was doing multicast, attempts at source-asserted?path vectors for > interdomain multicast came right out of those early BGP concepts. > > On Wed, Sep 2, 2020 at 5:10 PM Guy Almes via Internet-history > > wrote: > >? ? Craig et al., >? ? ? ? ?1987 was an interesting year.? The NSFnet-related regional networks >? ? were connecting new sites and had to solve interesting routing problems. >? ? ? ? ?EGP would tell you that a given network was reachable via a given >? ? gateway router / AS.? But that network might be reachable via two >? ? different gateways. >? ? ? ? ?During that era, our "Sesquinet" regional network in Texas was >? ? connected to two different valuable "backbone" type networks: the >? ? Fuzzball-based proto-NSFnet via Boulder and the ARPAnet via Austin. >? ? Both were useful.? Both had 56kb/s circuits.? Both were congested. >? ? ? ? ?At that time, there were a few hundred networks, and I recall going >? ? through the whole list, one by one, figuring out whether, if they were >? ? reachable via both the ARPAnet and the proto-NSFnet, which should be >? ? preferred.? I considered it worth doing, but it was of course Quixotic, >? ? given the rapidly growing number of connected networks. > >? ? ? ? ?Phill Gross asked me to lead an "Interconnectivity Working Group" >? ? within the IETF and work to solve some of these problems.? It was a >? ? great group, with members from the ARPAnet, NSFnet, NASA, ESnet, and >? ? other communities.? Understanding the various "backbones", their >? ? differing technical and policy natures, and the limitations of EGP all >? ? made for fascinating discussions, which did allow us to make progress. >? ? ? ? ?One of our explicit marching orders was *not* to invent a new >? ? protocol. >? ? ? ? ?But we did discuss the problem of how to choose which of two >? ? exterior >? ? routes to use when both advertised a given network. >? ? ? ? ?One line of thought was to consider that the Internet, while not >? ? having a "tree topology", did have a notion of levels of hierarchy, >? ? e.g., campus, then regional, then national backbone, then international >? ? links.? I am grateful that we fairly quickly realized that relying on >? ? that notion of hierarchy would be building on sand. >? ? ? ? ?But what kind of "metric" could be used to help make routing >? ? decisions? >? ? ? ? ?One idea, based on Cicso's IGRP protocol was to characterize each >? ? transit network with a bandwidth and a delay metric.? Then minimum of >? ? bandwidth along a path and sum of delay along a path could be used. >? ? That did not get traction. >? ? ? ? ?I'd been teaching a computer scientist where an idea called the >? ? "zero, one, infinity rule" was discussed.? As applied here, if a single >? ? scalar number would not suffice as a metric, then allow a metric of >? ? variable length.? For example, a whole AS-path could be an interesting >? ? kind of metric could be used.? But, particularly during that era, >? ? variable-length fields in protocols were not in favor, and we did not >? ? pursue this idea. >? ? ? ? ?Except that, at our next working group meeting (at the January 1989 >? ? IETF meeting at UT-Austin), Kirk Lougheed (Cisco) and Yakov Rekhter >? ? (IBM) invented BGP in one of the Internet's most famous napkins.? The >? ? complete AS-path, variable though it was, was a key idea. >? ? ? ? ?BGP solved several problems with EGP. >? ? ? ? ?I should emphasize that the AS-path was never exactly regarded as a >? ? "metric", but it provided valuable information.? I'll avoid going >? ? further with the evolution of BGP, but it was so much better than its >? ? predecessor and came along at a very fortunate time. > >? ? ? ? ? ? ? -- Guy > >? ? On 9/2/20 3:57 PM, Craig Partridge via Internet-history wrote: >? ? ? > There was a SIGCOMM '87 paper by Mills and Hans-Werner Braun that >? ? discussed >? ? ? > what happened when you tried to break the tree topology. >? ? ? > >? ? ? > Craig >? ? ? > >? ? ? > On Wed, Sep 2, 2020 at 1:52 PM Scott O. Bradner via >? ? Internet-history < >? ? ? > internet-history at elists.isoc.org >? ? > wrote: >? ? ? > >? ? ? >> I found a printout of my late 1990s notes which said that EGP >? ? was "limited >? ? ? >> to a tree structured Internet" >? ? ? >> although I recall that people were hacking it to expand its >? ? usefulness but >? ? ? >> the result was not pretty >? ? ? >> >? ? ? >> Scott >? ? ? >> >? ? ? >> >? ? ? >>> On Sep 2, 2020, at 3:45 PM, Barbara Denny ? ? > wrote: >? ? ? >>> >? ? ? >>> That is my recollection too. EGP had topology constraints. >? ? ? >>> >? ? ? >>> barbara >? ? ? >>> >? ? ? >>> On Wednesday, September 2, 2020, 08:07:37 AM PDT, Scott O. >? ? Bradner via >? ? ? >> Internet-history ? ? > wrote: >? ? ? >>> >? ? ? >>> >? ? ? >>> my recollection was that EGP could not be twisted enough to be >? ? able to >? ? ? >> deal with the actual >? ? ? >>> topology that was evolving on the Internet >? ? ? >>> >? ? ? >>> Scott >? ? ? >>> >? ? ? >>> ps - I tried to open an old powerpoint presentation (from the late >? ? ? >> 1990s) where I discussed EGP & BGP >? ? ? >>> but it seem like the oldest version of PowerPoint I have had >? ? evolved >? ? ? >> enough that it will no longer open >? ? ? >>> that version? - I mention that because there is yet again a >? ? discussion >? ? ? >> on the IETF list about RFC formats >? ? ? >>> and some people have argued, as people have argued for at least 20 >? ? ? >> years, that moving to MS Word >? ? ? >>> would be a good thing >? ? ? >>> >? ? ? >>> >? ? ? >>> >? ? ? >>>> On Sep 2, 2020, at 10:39 AM, Grant Taylor via Internet-history < >? ? ? >> internet-history at elists.isoc.org >? ? > wrote: >? ? ? >>>> >? ? ? >>>> On 9/2/20 7:55 AM, Dan York via Internet-history wrote: >? ? ? >>>>> Grant, >? ? ? >>>> >? ? ? >>>> Hi, >? ? ? >>>> >? ? ? >>>>> It also needs more explanation that EGP was replaced by BGP. (The >? ? ? >> current sentence there says ?essentially replaced? and is a bit >? ? vague with >? ? ? >> no references.) >? ? ? >>>> >? ? ? >>>> Hum. >? ? ? >>>> >? ? ? >>>>> If any of you all here know of any RFCs that explicitly >? ? indicate EGP >? ? ? >> was replaced/obsoleted, or if you know of any journal articles, >? ? academic >? ? ? >> papers, historical documents, etc., that could be useful, I >? ? would be glad >? ? ? >> to update the article a bit. Or if you can point me to any info >? ? about the >? ? ? >> creation of EGP (there?s a line that needs a source). Or any >? ? other info you >? ? ? >> think would be useful in this Wikipedia article, that would be >? ? great. >? ? ? >>>> >? ? ? >>>> I found a some information about EGP in and around the gated >? ? routing >? ? ? >> daemon.? I wonder if there might be some more information that >? ? could help >? ? ? >> you. >? ? ? >>>> >? ? ? >>>>> (Note that for info to appear in the English version of >? ? Wikipedia, it >? ? ? >> needs to be backed up by a ?reliable source? - >? ? ? >> >? ? https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6ld3QEI5A$ >? ? - which includes >? ? ? >> journal articles, academic papers, news articles, RFCs, etc.) >? ? ? >>>> >? ? ? >>>> I wonder if you can find any graphs on the number of Internet >? ? ? >> connections using BGP.? If similar ever existed for EGP, you can >? ? probably >? ? ? >> compare / contrast the two. >? ? ? >>>> >? ? ? >>>> I also think that the lack of contemporary EGP implementations is >? ? ? >> evidence of BGP's replacement of EGP.? As is the fact that BGP >? ? supports >? ? ? >> things that EGP does not.? Things which are used all over the >? ? Internet, >? ? ? >> e.g. multipath. >? ? ? >>>> >? ? ? >>>> >? ? ? >>>> >? ? ? >>>> -- >? ? ? >>>> Grant. . . . >? ? ? >>>> unix || die >? ? ? >>>> >? ? ? >>>> -- >? ? ? >>>> Internet-history mailing list >? ? ? >>>> Internet-history at elists.isoc.org >? ? >? ? ? >>>> >? ? https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ >? ? ? >>> >? ? ? >>> >? ? ? >>> -- >? ? ? >>> Internet-history mailing list >? ? ? >>> Internet-history at elists.isoc.org >? ? >? ? ? >>> >? ? https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ >? ? ? >> >? ? ? >> -- >? ? ? >> Internet-history mailing list >? ? ? >> Internet-history at elists.isoc.org >? ? >? ? ? >> >? ? https://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!VGbu8UR1ds9tLcdTmqj_BlSaJwdAR7VMX3YliVLEE7V0gQyXuH0Pp6mWiH895w$ >? ? ? >> >? ? ? > >? ? ? > >? ? -- >? ? 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 craig at tereschau.net Thu Sep 3 08:52:37 2020 From: craig at tereschau.net (Craig Partridge) Date: Thu, 3 Sep 2020 09:52:37 -0600 Subject: [ih] EGP reference Message-ID: I got requests for references for the Mills and HWB paper. @inproceedings{10.1145/55482.55502, author = {Mills, D. L. and Braun, H.}, title = {The NSFNET Backbone Network}, year = {1987}, isbn = {0897912454}, publisher = {Association for Computing Machinery}, address = {New York, NY, USA}, url = {https://doi-org.ezproxy2.library.colostate.edu/10.1145/55482.55502}, doi = {10.1145/55482.55502}, abstract = {The NSFNET Backbone Network interconnects six supercomputer sites, several regional networks and ARPANET. It supports the DARPA Internet protocol suite and DCN subnet protocols, which provide delay-based routing and very accurate time-synchronization services. This paper describes the design and implementation of this network, with special emphasis on robustness issues and congestion-control mechanisms.}, booktitle = {Proceedings of the ACM Workshop on Frontiers in Computer Communications Technology}, pages = {191?196}, numpages = {6}, location = {Stowe, Vermont, USA}, series = {SIGCOMM '87} } @article{10.1145/55483.55502, author = {Mills, D. L. and Braun, H.}, title = {The NSFNET Backbone Network}, year = {1987}, issue_date = {Oct./Nov. 1987}, publisher = {Association for Computing Machinery}, address = {New York, NY, USA}, volume = {17}, number = {5}, issn = {0146-4833}, url = {https://doi-org.ezproxy2.library.colostate.edu/10.1145/55483.55502}, doi = {10.1145/55483.55502}, abstract = {The NSFNET Backbone Network interconnects six supercomputer sites, several regional networks and ARPANET. It supports the DARPA Internet protocol suite and DCN subnet protocols, which provide delay-based routing and very accurate time-synchronization services. This paper describes the design and implementation of this network, with special emphasis on robustness issues and congestion-control mechanisms.}, journal = {SIGCOMM Comput. Commun. Rev.}, month = aug, pages = {191?196}, numpages = {6} } Craig -- ***** Craig Partridge's email account for professional society activities and mailing lists. From scott.brim at gmail.com Thu Sep 3 10:03:38 2020 From: scott.brim at gmail.com (Scott Brim) Date: Thu, 3 Sep 2020 13:03:38 -0400 Subject: [ih] EGP reference In-Reply-To: References: Message-ID: The ACM version is open: https://dl.acm.org/doi/10.1145/55482.55502 There's also an enjoyable/illuminating reminiscence by Hans-Werner that spans 1985-1991, appropriate for this list, at http://hpwren.ucsd.edu/~hwb/NSFNET/NSFNET-200711Summary/ Scott On Thu, Sep 3, 2020 at 11:53 AM Craig Partridge via Internet-history < internet-history at elists.isoc.org> wrote: > I got requests for references for the Mills and HWB paper. > > @inproceedings{10.1145/55482.55502, author = {Mills, D. L. and Braun, > H.}, title = {The NSFNET Backbone Network}, year = {1987}, isbn = > {0897912454}, publisher = {Association for Computing Machinery}, > address = {New York, NY, USA}, url = > {https://doi-org.ezproxy2.library.colostate.edu/10.1145/55482.55502}, > doi = {10.1145/55482.55502}, abstract = {The NSFNET Backbone Network > interconnects six supercomputer sites, several regional networks and > ARPANET. It supports the DARPA Internet protocol suite and DCN subnet > protocols, which provide delay-based routing and very accurate > time-synchronization services. This paper describes the design and > implementation of this network, with special emphasis on robustness > issues and congestion-control mechanisms.}, booktitle = {Proceedings > of the ACM Workshop on Frontiers in Computer Communications > Technology}, pages = {191?196}, numpages = {6}, location = {Stowe, > Vermont, USA}, series = {SIGCOMM '87} } > @article{10.1145/55483.55502, author = {Mills, D. L. and Braun, H.}, > title = {The NSFNET Backbone Network}, year = {1987}, issue_date = > {Oct./Nov. 1987}, publisher = {Association for Computing Machinery}, > address = {New York, NY, USA}, volume = {17}, number = {5}, issn = > {0146-4833}, url = > {https://doi-org.ezproxy2.library.colostate.edu/10.1145/55483.55502}, > doi = {10.1145/55483.55502}, abstract = {The NSFNET Backbone Network > interconnects six supercomputer sites, several regional networks and > ARPANET. It supports the DARPA Internet protocol suite and DCN subnet > protocols, which provide delay-based routing and very accurate > time-synchronization services. This paper describes the design and > implementation of this network, with special emphasis on robustness > issues and congestion-control mechanisms.}, journal = {SIGCOMM Comput. > Commun. Rev.}, month = aug, pages = {191?196}, numpages = {6} } > > 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 jnc at mercury.lcs.mit.edu Thu Sep 3 15:14:42 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 3 Sep 2020 18:14:42 -0400 (EDT) Subject: [ih] Exterior Gateway Protocol Message-ID: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> > From: Guy Almes > While I'm not aware of anyone actually doing this, it is interesting to > contemplate what an SPF-based *EGP*. This could have advantages (e.g., more > optimal inter-AS routing and rapid convergence times), but having any > Global agreement on which inter-AS routes will be preferred would be > very unlikely. > So, in practice, SPF technology is only used in IGPs. > ... > Comments? Tony already said something about this, but a few more notes. First, SPF is not the best term to use. To me, the fundamental division in routing architectures is between what I call 'Map Distribution' designs (named after the fundamental data passed around in them - map elements), and 'Destination Vector' (which pass around routing tables - arrays of destinations). SPF applies to a subset of MD, ones in which every node runs the same path-selection algorithm, in parallel, and each only makes a decision on the next hop from it (to any particular destination). (The algorithm outputs, from a given map input, have to be identical, as well as the maps, otherwise routing loops can result. So in theory one could have different algorithms, but in practise the algorithm is part of the protocol spec.) An orthogonal subset of MD uses what we called Explicit Routing' (a name due to Yakov Rekhter, with thanks), where _individual_ nodes (perhaps recursively) select the entire path (or sections thereof, in the recursive case). This has several advatanges; in addition to being less fragile, and far less suscpetible to loops, it _allows_ (but does _not_ mandate) individal nodes to make their own decisions about paths - aka policy routing. With that in hand, a couple of 'SPF' (actualy, mostly all MD) EGP designs. I started an early effort for an SPF (I think; I'd have to look) replacement for EGP, called 'FGP', just after John Moy joined Proteon; my concept was he could do the detailed design. Alas, John wasn't sure he had the technical chops for it (to which I just rolled my eyes, he clearly could handle it), but unfortunately Dave Clark (then a director at Proteon) also agreed that it wasn't a good move. Instead, Proteon started what turned into OSPF; originally a Proteon thing, we rapidly turned it over to the IETF. I have this vague memory that Scott Brim may have been at an FGP kick-off meeting - or is my memory playing false? Then there was the IDPR design, which was an MD EGP capable of supporting policy routing. It was the output of a long-running IETF WG, whose name now escapes me, which had been charged with coming up for a replacment for EGP. (This was before BGP - which initally was supposed to be a quick hack 'interim' EGP replacemt, when IDPR was late.) I recall we wrote a draft requirements document, which a late joiner took over to 'edit', and he he entirely re-wrote it - the original version was left in as an appendix. Martha Steenstrup later came up with an actual design. Around then, I'd split off to work on Nimrod (the name is neither an acronym nor a backronym, but a private joke between me and John Lekashman, from whom I had hoped to get funding). The primary difference between IDPR and Nimrod was that I wanted to get rid of the EGP/IGP split - to me it was a blunt tool of limited capabilities. My idea was that Nimrod regions (which could nest) would have similar 'firewalls' to protect them, not just the single blunt IGP/EGP split. But the real reason was that I saw a unified routing architecture, from top to bottom, as more flexible and powerful. (And it would have been; some years later I remember discussing an optical network which could handle qbit traffic; Nimrod, off the shelf, could have handled the routing for it.) There was also IDRP (the name, I am convinced, was deliberately chosen to be confusing), from Yakov and someone else (Deborah Estrin?), which was a mashup of IDPR (to handle policy-routed traffic) and a BGP-ish DV system (to handle ordinary traffic). The ATM people used Nimrod ideas as the basis for the initial versions of PNNI, which was intended to be the routing system for a large, multi-vendor ATM network. (I gather the name was later applied to a simplified protocol, based on OSPF.) > once a pretty good system, especially with BGP in the generic > EGP/inter-AS context, evolves, it's hard to make big changes. As Tony mentioned, you can do it. We'd put a fair amont of work into thinking about the deployment path for Nimrod, you haqd to have an interoperation phase, duing which the part running the 'new' design would grow in size - very vaguely similar to how BGP was first deployed. Nimrd's flexibility and power was intended to make such a transition in the future unnecessaet (forever). Whether it could have net the business goalsTony alluded to - maybe (via the vietualization and information hiding mechanisms). Noel From vint at google.com Thu Sep 3 15:20:31 2020 From: vint at google.com (Vint Cerf) Date: Thu, 3 Sep 2020 18:20:31 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> References: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> Message-ID: I seem to recall that we ran into a number of problem with the ARPANET routing algorithms and John McQuillan was tasked to deal with them. Didn't he come up with SPF as a solution? https://www.cs.yale.edu/homes/lans/readings/routing/mcquillan-darpa_routing-1980.pdf v On Thu, Sep 3, 2020 at 6:14 PM Noel Chiappa via Internet-history < internet-history at elists.isoc.org> wrote: > > From: Guy Almes > > > While I'm not aware of anyone actually doing this, it is interesting > to > > contemplate what an SPF-based *EGP*. This could have advantages > (e.g., more > > optimal inter-AS routing and rapid convergence times), but having any > > Global agreement on which inter-AS routes will be preferred would be > > very unlikely. > > So, in practice, SPF technology is only used in IGPs. > > ... > > Comments? > > Tony already said something about this, but a few more notes. > > > First, SPF is not the best term to use. To me, the fundamental division in > routing architectures is between what I call 'Map Distribution' designs > (named > after the fundamental data passed around in them - map elements), and > 'Destination Vector' (which pass around routing tables - arrays of > destinations). > > SPF applies to a subset of MD, ones in which every node runs the same > path-selection algorithm, in parallel, and each only makes a decision on > the > next hop from it (to any particular destination). (The algorithm outputs, > from > a given map input, have to be identical, as well as the maps, otherwise > routing loops can result. So in theory one could have different algorithms, > but in practise the algorithm is part of the protocol spec.) > > An orthogonal subset of MD uses what we called Explicit Routing' (a name > due > to Yakov Rekhter, with thanks), where _individual_ nodes (perhaps > recursively) > select the entire path (or sections thereof, in the recursive case). This > has > several advatanges; in addition to being less fragile, and far less > suscpetible to loops, it _allows_ (but does _not_ mandate) individal nodes > to make their own decisions about paths - aka policy routing. > > With that in hand, a couple of 'SPF' (actualy, mostly all MD) EGP designs. > > > I started an early effort for an SPF (I think; I'd have to look) > replacement > for EGP, called 'FGP', just after John Moy joined Proteon; my concept was > he > could do the detailed design. Alas, John wasn't sure he had the technical > chops for it (to which I just rolled my eyes, he clearly could handle it), > but > unfortunately Dave Clark (then a director at Proteon) also agreed that it > wasn't a good move. Instead, Proteon started what turned into OSPF; > originally > a Proteon thing, we rapidly turned it over to the IETF. I have this vague > memory that Scott Brim may have been at an FGP kick-off meeting - or is my > memory playing false? > > Then there was the IDPR design, which was an MD EGP capable of supporting > policy routing. It was the output of a long-running IETF WG, whose name now > escapes me, which had been charged with coming up for a replacment for > EGP. (This was before BGP - which initally was supposed to be a quick hack > 'interim' EGP replacemt, when IDPR was late.) I recall we wrote a draft > requirements document, which a late joiner took over to 'edit', and he he > entirely re-wrote it - the original version was left in as an appendix. > Martha > Steenstrup later came up with an actual design. > > Around then, I'd split off to work on Nimrod (the name is neither an > acronym > nor a backronym, but a private joke between me and John Lekashman, from > whom I > had hoped to get funding). The primary difference between IDPR and Nimrod > was > that I wanted to get rid of the EGP/IGP split - to me it was a blunt tool > of > limited capabilities. My idea was that Nimrod regions (which could nest) > would > have similar 'firewalls' to protect them, not just the single blunt IGP/EGP > split. But the real reason was that I saw a unified routing architecture, > from > top to bottom, as more flexible and powerful. (And it would have been; some > years later I remember discussing an optical network which could handle > qbit > traffic; Nimrod, off the shelf, could have handled the routing for it.) > > There was also IDRP (the name, I am convinced, was deliberately chosen to > be > confusing), from Yakov and someone else (Deborah Estrin?), which was a > mashup > of IDPR (to handle policy-routed traffic) and a BGP-ish DV system (to > handle > ordinary traffic). > > The ATM people used Nimrod ideas as the basis for the initial versions of > PNNI, which was intended to be the routing system for a large, multi-vendor > ATM network. (I gather the name was later applied to a simplified protocol, > based on OSPF.) > > > > once a pretty good system, especially with BGP in the generic > > EGP/inter-AS context, evolves, it's hard to make big changes. > > As Tony mentioned, you can do it. We'd put a fair amont of work into > thinking > about the deployment path for Nimrod, you haqd to have an interoperation > phase, > duing which the part running the 'new' design would grow in size - very > vaguely > similar to how BGP was first deployed. > > Nimrd's flexibility and power was intended to make such a transition > in the future unnecessaet (forever). Whether it could have net the business > goalsTony alluded to - maybe (via the vietualization and information hiding > mechanisms). > > Noel > -- > 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 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From brian.e.carpenter at gmail.com Thu Sep 3 15:45:55 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 4 Sep 2020 10:45:55 +1200 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> Message-ID: On 04-Sep-20 10:20, Vint Cerf via Internet-history wrote: > I seem to recall that we ran into a number of problem with the ARPANET > routing algorithms and John McQuillan was tasked to deal with them. Didn't > he come up with SPF as a solution? > > > https://www.cs.yale.edu/homes/lans/readings/routing/mcquillan-darpa_routing-1980.pdf Interesting paper. It cites this paper as its immediate source: D. B. Johnson. "Efficient algorithms for shortest paths in sparse networks", J. Ass. Comput. Mach. vol. 24. pp. 1-13. Jan. 1977. DOI: 10.1145/321992.321993 which of course cites both Dijkstra and Bellman & Ford as original sources. Brian > > > v > > > On Thu, Sep 3, 2020 at 6:14 PM Noel Chiappa via Internet-history < > internet-history at elists.isoc.org> wrote: > >> > From: Guy Almes >> >> > While I'm not aware of anyone actually doing this, it is interesting >> to >> > contemplate what an SPF-based *EGP*. This could have advantages >> (e.g., more >> > optimal inter-AS routing and rapid convergence times), but having any >> > Global agreement on which inter-AS routes will be preferred would be >> > very unlikely. >> > So, in practice, SPF technology is only used in IGPs. >> > ... >> > Comments? >> >> Tony already said something about this, but a few more notes. >> >> >> First, SPF is not the best term to use. To me, the fundamental division in >> routing architectures is between what I call 'Map Distribution' designs >> (named >> after the fundamental data passed around in them - map elements), and >> 'Destination Vector' (which pass around routing tables - arrays of >> destinations). >> >> SPF applies to a subset of MD, ones in which every node runs the same >> path-selection algorithm, in parallel, and each only makes a decision on >> the >> next hop from it (to any particular destination). (The algorithm outputs, >> from >> a given map input, have to be identical, as well as the maps, otherwise >> routing loops can result. So in theory one could have different algorithms, >> but in practise the algorithm is part of the protocol spec.) >> >> An orthogonal subset of MD uses what we called Explicit Routing' (a name >> due >> to Yakov Rekhter, with thanks), where _individual_ nodes (perhaps >> recursively) >> select the entire path (or sections thereof, in the recursive case). This >> has >> several advatanges; in addition to being less fragile, and far less >> suscpetible to loops, it _allows_ (but does _not_ mandate) individal nodes >> to make their own decisions about paths - aka policy routing. >> >> With that in hand, a couple of 'SPF' (actualy, mostly all MD) EGP designs. >> >> >> I started an early effort for an SPF (I think; I'd have to look) >> replacement >> for EGP, called 'FGP', just after John Moy joined Proteon; my concept was >> he >> could do the detailed design. Alas, John wasn't sure he had the technical >> chops for it (to which I just rolled my eyes, he clearly could handle it), >> but >> unfortunately Dave Clark (then a director at Proteon) also agreed that it >> wasn't a good move. Instead, Proteon started what turned into OSPF; >> originally >> a Proteon thing, we rapidly turned it over to the IETF. I have this vague >> memory that Scott Brim may have been at an FGP kick-off meeting - or is my >> memory playing false? >> >> Then there was the IDPR design, which was an MD EGP capable of supporting >> policy routing. It was the output of a long-running IETF WG, whose name now >> escapes me, which had been charged with coming up for a replacment for >> EGP. (This was before BGP - which initally was supposed to be a quick hack >> 'interim' EGP replacemt, when IDPR was late.) I recall we wrote a draft >> requirements document, which a late joiner took over to 'edit', and he he >> entirely re-wrote it - the original version was left in as an appendix. >> Martha >> Steenstrup later came up with an actual design. >> >> Around then, I'd split off to work on Nimrod (the name is neither an >> acronym >> nor a backronym, but a private joke between me and John Lekashman, from >> whom I >> had hoped to get funding). The primary difference between IDPR and Nimrod >> was >> that I wanted to get rid of the EGP/IGP split - to me it was a blunt tool >> of >> limited capabilities. My idea was that Nimrod regions (which could nest) >> would >> have similar 'firewalls' to protect them, not just the single blunt IGP/EGP >> split. But the real reason was that I saw a unified routing architecture, >> from >> top to bottom, as more flexible and powerful. (And it would have been; some >> years later I remember discussing an optical network which could handle >> qbit >> traffic; Nimrod, off the shelf, could have handled the routing for it.) >> >> There was also IDRP (the name, I am convinced, was deliberately chosen to >> be >> confusing), from Yakov and someone else (Deborah Estrin?), which was a >> mashup >> of IDPR (to handle policy-routed traffic) and a BGP-ish DV system (to >> handle >> ordinary traffic). >> >> The ATM people used Nimrod ideas as the basis for the initial versions of >> PNNI, which was intended to be the routing system for a large, multi-vendor >> ATM network. (I gather the name was later applied to a simplified protocol, >> based on OSPF.) >> >> >> > once a pretty good system, especially with BGP in the generic >> > EGP/inter-AS context, evolves, it's hard to make big changes. >> >> As Tony mentioned, you can do it. We'd put a fair amont of work into >> thinking >> about the deployment path for Nimrod, you haqd to have an interoperation >> phase, >> duing which the part running the 'new' design would grow in size - very >> vaguely >> similar to how BGP was first deployed. >> >> Nimrd's flexibility and power was intended to make such a transition >> in the future unnecessaet (forever). Whether it could have net the business >> goalsTony alluded to - maybe (via the vietualization and information hiding >> mechanisms). >> >> Noel >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> > > > From jack at 3kitty.org Thu Sep 3 15:49:00 2020 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 3 Sep 2020 15:49:00 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <20200903021221.9622718C09D@mercury.lcs.mit.edu> References: <20200903021221.9622718C09D@mercury.lcs.mit.edu> Message-ID: Hi Noel, Yes, I can confirm that MIT was one of the culprits motivating the creation of EGP.?? I don't remember the details of the particular incident, but I do remember that MIT and Dave's Fuzzballs were notorious sources of disruption. At the time, there were two conflicting goals, running a stable core Internet as a service, and providing a "real" environment in which to try out new ideas for our list of problems-to-be-solved.? EGP was intended as a way to have your cake and eat it too. The motivation for a stable service was obvious - to prove that TCP/IP worked and could be deployed as a DoD standard.?? But there was also a strong desire to continue research aggressively, because of various scenarios that would be poorly handled by the initial routing mechanism. I probably don't remember them all, but there were a bunch of such "routing problems" beyond the basic desire for efficiency and stability.? At the ICCB meetings, we used to keep a list of "things to be worked on", many of which were associated with routing.? A few I remember: - Type-Of-Service Routing: how to route packets differently for different needs, in particular low-latency for voice/video, versus high-throughput for file transfers.? That's why we put the TOS field in the IP header.? Another example would be handling ICMP packets with priority over others. - Expressway Routing: how to route packets through a separate network, even if both ends were attached to a common network.? The example was how to route traffic between two ARPANET hosts through gateways to the WideBandNet, rather than just sending packets directly through the ARPANET. - Policy Routing: how to route packets depending on who "owned" them.?? The example here involved the two paths between the US and Europe at the time.? The X.25 path cost money to use, and ARPA wanted only ARPA-sponsored packets to use the satellite (SATNET) path which ARPA was paying for. - Multipath Routing: how to route packets along more than the one "best" path, if two (or more) independent paths led from source to destination.?? This was coupled with another problem - how to take advantage of Multi-homed Hosts that had connections to multiple networks.?? The goal was to achieve higher host-host throughputs by simultaneously using all viable paths. - Capacity Routing: how to route packets depending on the sustainable bandwidth of possible paths, rather than hops or delay.? This would allow things like file transfers to finish sooner, even though the individual packets might not get there in the fastest way. These usage scenarios were in addition to the common goals of using delay-based metrics instead of hops, which were well understood to be a poor metric.? At the time, the gateways simply had too little memory and CPU to implement anything fancy, and IIRC the core gateways didn't have appropriate clocks either.? So it was tough to see how to measure things like gateway queueing or network transmission delays.?? Dave Mills was especially interested in dealing with and measuring delays, which I think motivated him to drive the creation of NTP.?? EGP was intended to keep the "operational" part of the Internet running smoothly, while enabling the research community to solve those problems.? I've always been curious about how, and if, those "routing problems" ever were addressed in any subsequent IGP, or whether they just disappeared into the fog of history. /Jack Haverty On 9/2/20 7:12 PM, Noel Chiappa via Internet-history wrote: > > From: Craig Partridge > > > Could Bob have been thinking about splitting off DoD IP networks to > > another provider ... and using EGP for that purpose? > > I was involved with an early incident that _may_ have been part of the > impetus for EGP; I was out of the loop that started EGP, so I can't say for > sure. Well, let me tell the story, FWIW. > > MIT got a router (gateway as we called them then) between its collection of > LAN's (mostly CHAOS speaking at that early stage) and the ARPANET somewhat > early on; later than would have been optimal, but there were no spare IMP > ports at MIT, and we had to wait for the installation of IMP 77 (one of the > first C/30 IMPs, I think) to get connected to the Internet. (Jerry Saltzer > worked out when that was, by looking in hardcopies of CSR progress reports > that he had in his garage; I can look it up if it's important. My very vague > memory is that it was roughly around 1980.) > > The first ARPANET gateway at MIT was bodged 'Port Expander' code (I found a > version of it in that CSR dump, if anyone cares; I'm not sure it's the > version that was in service, all that stuff is pretty disorganized). To > exchange packets with the rest of the Internet, we needed to let the BBN > gateways (pretty much all there were at the time) know that MIT-GW was the > route to net 18. We decided to do that by hacking up a small MOS process to > run in the same box, which would send a small, short GGP routing update that > just said 'net 18. this way' every so often. > > So I coded it up, installed it in MIT-GW, and apparently as soon as I started > it, the BBN gateways started falling over. IIRC, I got a phone call from > someone at BBN, asking what I was doing that was causing their gateways to > crash. This was news to me, I had no idea I was doing that. Anyway, after some > investigation, we figured out what had happened: BBN had changed the format of > GGP routing update, but hadn't documented the change. So when I dutifully took > the routing update format from the GGP spec online, it was malformed in a way > that killed the BBN code. > > I have this memory that when this tale was told to Vint at the next Internet > WG meeting, he took out a little notebook and made some notes, and shortly > thereafter we found out that the Internet router work at BBN had moved > between Div 4 and Div 6 - we were under the impression at the time that that > change was a result of those router issues. > > I don't know if the start of EGP was also connected, but those events > certainly showed the downside of having new routers trying to talk GGP to the > BBN routers. > > Noel From galmes at tamu.edu Thu Sep 3 15:52:13 2020 From: galmes at tamu.edu (Guy Almes) Date: Thu, 3 Sep 2020 18:52:13 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> References: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> Message-ID: <89a39ac4-3ef1-939b-0cf4-42f2ad57dfb8@tamu.edu> Hi Noel, Your memories / comments are very interesting. Once again with a history (as opposed to technical) focus, I was particularly struck by two comments ... On 9/3/20 6:14 PM, Noel Chiappa via Internet-history wrote: > > From: Guy Almes > > > While I'm not aware of anyone actually doing this, it is interesting to > > contemplate what an SPF-based *EGP*. This could have advantages (e.g., more > > optimal inter-AS routing and rapid convergence times), but having any > > Global agreement on which inter-AS routes will be preferred would be > > very unlikely. > > So, in practice, SPF technology is only used in IGPs. > > ... > > Comments? > > Tony already said something about this, but a few more notes. > > > ... > > An orthogonal subset of MD uses what we called Explicit Routing' (a name due > to Yakov Rekhter, with thanks), where _individual_ nodes (perhaps recursively) > select the entire path (or sections thereof, in the recursive case). This has > several advatanges; in addition to being less fragile, and far less > suscpetible to loops, it _allows_ (but does _not_ mandate) individal nodes > to make their own decisions about paths - aka policy routing. Back in the 1980s, the Loose Source Routing and Strict Source Routing were typically observed by routers, so we had a sandbox with which to play with these ideas. It seemed a reasonable and practical idea to make use of Loose Source Routing in applications where Policy Routing was demanded. Within a decade, of course, most any form of source routing was regarded with horror. > > ... > > Around then, I'd split off to work on Nimrod (the name is neither an acronym > nor a backronym, but a private joke between me and John Lekashman, from whom I > had hoped to get funding). The primary difference between IDPR and Nimrod was > that I wanted to get rid of the EGP/IGP split - to me it was a blunt tool of > limited capabilities. ... I take the EGP/IGP split to be, in essence, the basic Autonomous System (AS) concept. During the late-80s and early-90s period, the basic AS idea was amazingly powerful. It allowed the wonderful variety of technical approaches to be taken by an explosively growing (by which I mean dozens or hundreds) number of campus, regional, international, etc. networks, while preserving a relatively simple inter-AS world where we had to cooperate. That allowed the Internet to grow into something amazing and unstoppable, if flawed. But you were right then and now in pointing out the weaknesses of this binary intra-AS / inter-AS split. I became particularly aware of that weakness when the IETF moved to expand the size of the AS field in BGP from 16 to 32 bits. In 1987, I would not have anticipated 64,000 ASes. Oh well. And then, again, when working with routers that had to usable in backbone networks and thus have a "full" routing table in expensive fast packet-forwarding cards. If memory serves, an example was the need for 10s of thousands of inter-AS routes in the forwarding card of the IBM routers used in the T3 version of the NSFnet backbone. Again, focusing on history, sometimes a technical idea (here, the binary intra-AS / inter-AS split, can allow an infrastructure to grow to become unstoppable and yet not be adequate for the additional growth it will need after becoming unstoppable. Cheers, -- Guy > > ... > > Noel > From tony.li at tony.li Thu Sep 3 16:05:59 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Thu, 3 Sep 2020 16:05:59 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <89a39ac4-3ef1-939b-0cf4-42f2ad57dfb8@tamu.edu> References: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> <89a39ac4-3ef1-939b-0cf4-42f2ad57dfb8@tamu.edu> Message-ID: <45D5284F-FE6B-4B5A-9734-1B1FF4E175C8@tony.li> > Back in the 1980s, the Loose Source Routing and Strict Source Routing were typically observed by routers, so we had a sandbox with which to play with these ideas. It seemed a reasonable and practical idea to make use of Loose Source Routing in applications where Policy Routing was demanded. > Within a decade, of course, most any form of source routing was regarded with horror. Worry not, it?s back. This time in the guise of SRv6. > Again, focusing on history, sometimes a technical idea (here, the binary intra-AS / inter-AS split, can allow an infrastructure to grow to become unstoppable and yet not be adequate for the additional growth it will need after becoming unstoppable. As noted, it didn?t work out to be binary. There are many ISPs out there using multiple ASes to segregate different regions/fiefdoms. Other people using BGP as an IGP in their enterprise, and many using BGP to route their leaf-spine data centers, with one AS number per router. All permutations will be explored? Tony From jack at 3kitty.org Thu Sep 3 16:09:39 2020 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 3 Sep 2020 16:09:39 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <89a39ac4-3ef1-939b-0cf4-42f2ad57dfb8@tamu.edu> References: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> <89a39ac4-3ef1-939b-0cf4-42f2ad57dfb8@tamu.edu> Message-ID: <33b59c08-af35-1cb4-76e8-f4cf227f42ed@3kitty.org> On 9/3/20 3:52 PM, Guy Almes via Internet-history wrote: > But you were right then and now in pointing out the weaknesses of this > binary intra-AS / inter-AS split. > ? I became particularly aware of that weakness when the IETF moved to > expand the size of the AS field in BGP from 16 to 32 bits.? In 1987, I > would not have anticipated 64,000 ASes.? Oh well. > .... > ? Again, focusing on history, sometimes a technical idea (here, the > binary intra-AS / inter-AS split, can allow an infrastructure to grow > to become unstoppable and yet not be adequate for the additional > growth it will need after becoming unstoppable. Yikes!? When we created EGP circa 1982, IIRC we expected maybe a dozen or so ASes would be sufficient to support experimentation with all the research ideas.?? 64,000 ASes?? No way. Also, the "plan" back then in the ICCB thinking. was that the research efforts would hone in on solutions to at least a few of those problems I listed, and the best solutions would be incorporated into the next round of gateway-gateway protocols, and folded into the DoD standards (which lacked any spec for gateways).? Having served its purpose, EGP would be retired.?? That would occur in parallel with the evolution from IPV4 to the next generation IP, since a new routing mechanism would probably impact the IP definition as well. I didn't realize EGP would be so explosive.?? Somehow things got out of hand.....something for historians to ponder I guess. /Jack From jnc at mercury.lcs.mit.edu Thu Sep 3 16:39:58 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 3 Sep 2020 19:39:58 -0400 (EDT) Subject: [ih] Exterior Gateway Protocol Message-ID: <20200903233958.1427C18C0A5@mercury.lcs.mit.edu> > From: Vint Cerf > I seem to recall that we ran into a number of problem with the ARPANET > routing algorithms and John McQuillan was tasked to deal with > them. Didn't he come up with SPF as a solution? Yes, SPF is the design he came up with to replace the original 'old' ARPANET routing architecture (which was a DV system). In the descriptive system I laid out, it is exactly an SPF system (everyone runs the identical algorithm over a map, and only computes the next hop from them). A term often/usually used as a synonym for SPF is 'Link State'; the New ARPANET SPF, OSPF, and IS-IS are all LS protocols. His PhD thesis, done at the time (or perhaps slightly before) explores the entire field of routing. Anyone who's really interested in routing should get a copy; mine came from NTIS, but I imagine University Microfilms International would also be a source. Oh, one note: in the ARPANET, 'routing' (both old and new systems) was not _just_ path selection, but also 'congestion avoidance'; i.e. it tried to divert traffic around congested areas. This made the 'routing' problem much harder (in terms of getting paths to stabilize); the constant changes in delays with load were equivalent to constant connectivity changes in a network like today's. IIRC, one problem they saw was 'load chasing' oscillations: a part of the network is loaded, so everyone starts avoiding it, and heads for an unloaded part. Repeat! :-) IIRC they sorta 'cured' that with damping. I think in a really large network, doing congestion avoidance in one subsystem, long with path selection, is not workable. I think it should be done separately (easy to pull them apart with an ER/MD system, _another_ advantage of that architectural approach). Noel From louie at transsys.com Thu Sep 3 22:05:07 2020 From: louie at transsys.com (Louis Mamakos) Date: Fri, 04 Sep 2020 01:05:07 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <20200902170156.D296E18C093@mercury.lcs.mit.edu> References: <20200902170156.D296E18C093@mercury.lcs.mit.edu> Message-ID: On 2 Sep 2020, at 13:01, Noel Chiappa via Internet-history wrote: > > From: Grant Taylor > > > Does anyone know of any surviving implementations of Exterior > Gateway > > Protocol, BGP's predecessor. ... Did any other network operating > system > > vendor or 3rd party vendor have EGP implementations? > > Liza Martin did one for the MIT so-called "C Gateway". That was > distributed to > a number of people, along with the rest of the CGW code. All that code > is all > still around (on the dump of the MIT-CSR machine which was recently > retrieved), and easily available. > > I later re-wrote that one somewhat, to improve it, for the Proteon > router > products. The one big change I recall which I made was to the code > which > generated the lists of routes in the updates. To pack as many entriess > as > possible into a single packet (IIRC, EGP routing table updates were > only > single packets; no provision for overflow into sets of 2 or more), it > used a > somewhat arcane organization, which a naive implementation would be > slow to > generate. So I wrote code to walk the routing' table, and generate an > intermediate tree structure which was a good match to the layout in > the EGP > updates; the code to generate the output packets could then walk that > swiftly. (Or, at least, that's my best memory; it's been ~40 years > since I > last looked at it.) As a practical operational matter, there was also concern about the ever growing size of the EGP datagrams, which would get fragmented. And now you're trying to reassemble fragments, with ever decreasing probably of success in the ever-congested Internet of the day. And you have to wonder just how large a (fragmented) IP datagram you could reasonably expect would be reassembled. Of course, this was happening in the pre-CIDR times. louie From touch at strayalpha.com Thu Sep 3 22:16:53 2020 From: touch at strayalpha.com (Joseph Touch) Date: Thu, 3 Sep 2020 22:16:53 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> Message-ID: > On Sep 2, 2020, at 9:38 AM, Jack Haverty via Internet-history wrote: > > Re: the creation of EGP: Five or ten years ago, I summarized the > events around the creation of EGP on this list (actually the list when > it was hosted at ISI). You may be able to find it in old > internet-history message archives. FYI - we moved the archives here. Joe (as list admin) From touch at strayalpha.com Thu Sep 3 22:29:14 2020 From: touch at strayalpha.com (Joseph Touch) Date: Thu, 3 Sep 2020 22:29:14 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> > On Sep 2, 2020, at 2:33 PM, Guy Almes via Internet-history wrote: > ... > As Vint just reminded me, not only was the variable length AS path an unusual characteristic, but BGP's use of TCP was quite controversial. But, in addition to other advantages, the use of TCP made possible several early implementations. Can you tell us more about what part of BGP?s use of TCP was controversial at the time? I.e., other than the error of linking ?this path is up? inside BGP to ?TCP is stable over that path?, a decision that required multiple fixes to address (MD5, TCP-AO, RST rejection, and route dampening). Joe From scott.brim at gmail.com Fri Sep 4 04:30:54 2020 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 4 Sep 2020 07:30:54 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> References: <20200903221442.60F8518C0A5@mercury.lcs.mit.edu> Message-ID: On Thu, Sep 3, 2020, 18:14 Noel Chiappa via Internet-history < internet-history at elists.isoc.org> wrote: > I have this vague > memory that Scott Brim may have been at an FGP kick-off meeting - or is my > memory playing false? > Either the first or the second. It was the third IETF. > There was also IDRP (the name, I am convinced, was deliberately chosen to be > confusing), from Yakov and someone else (Deborah Estrin?), which was a > mashup > of IDPR (to handle policy-routed traffic) and a BGP-ish DV system (to > handle > ordinary traffic). > IMHO that evolved out of the Autonomous Networks Task Force - 1987-88 or so, chaired by Deborah. The goal was policy-based interdomain routing, and as I recall we spent a lot of time on credentials (who gets to use which gateway) and confidentiality (do you get to search through all my credentials when I want to traverse you?). From scott.brim at gmail.com Fri Sep 4 04:35:39 2020 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 4 Sep 2020 07:35:39 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> Message-ID: On Fri, Sep 4, 2020 at 1:29 AM Joseph Touch wrote: > On Sep 2, 2020, at 2:33 PM, Guy Almes via Internet-history < > internet-history at elists.isoc.org> wrote: > ... > As Vint just reminded me, not only was the variable length AS path an > unusual characteristic, but BGP's use of TCP was quite controversial. But, > in addition to other advantages, the use of TCP made possible several early > implementations. > > > Can you tell us more about what part of BGP?s use of TCP was controversial > at the time? > > I.e., other than the error of linking ?this path is up? inside BGP to ?TCP > is stable over that path?, a decision that required multiple fixes to > address (MD5, TCP-AO, RST rejection, and route dampening). > Layering. You're setting up a connection to a node in a different AS, so you needed AS-level routing to tell you the path, so you need BGP so etc. From vgcerf at gmail.com Fri Sep 4 04:51:22 2020 From: vgcerf at gmail.com (vinton cerf) Date: Fri, 4 Sep 2020 07:51:22 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> Message-ID: It felt like a layer violation to run BGP over TCP but in fact it proved to be very useful. v On Fri, Sep 4, 2020 at 7:36 AM Scott Brim via Internet-history < internet-history at elists.isoc.org> wrote: > On Fri, Sep 4, 2020 at 1:29 AM Joseph Touch wrote: > > > On Sep 2, 2020, at 2:33 PM, Guy Almes via Internet-history < > > internet-history at elists.isoc.org> wrote: > > ... > > As Vint just reminded me, not only was the variable length AS path an > > unusual characteristic, but BGP's use of TCP was quite controversial. > But, > > in addition to other advantages, the use of TCP made possible several > early > > implementations. > > > > > > Can you tell us more about what part of BGP?s use of TCP was > controversial > > at the time? > > > > I.e., other than the error of linking ?this path is up? inside BGP to > ?TCP > > is stable over that path?, a decision that required multiple fixes to > > address (MD5, TCP-AO, RST rejection, and route dampening). > > > > Layering. You're setting up a connection to a node in a different AS, so > you needed AS-level routing to tell you the path, so you need BGP so etc. > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From galmes at tamu.edu Fri Sep 4 05:38:20 2020 From: galmes at tamu.edu (Guy Almes) Date: Fri, 4 Sep 2020 08:38:20 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> Message-ID: Vint, Scott, et al., You have both correctly remembered the uneasiness as being a vague sense of layer violation. Picking up on Scott's specific reason for the objection, recall that an Autonomous System was defined as a set of routers rather than (as in DECnet, for example) a set of network numbers. And so, even if the two "Border Gateways" engaging in BGP were in different Autonomous Systems, they typically shared a network number. For example, they might have two different interfaces on the same Ethernet or be at two different ends of the same serial line. So (if I recall correctly), it was not a layer violation, but the reason why was a little subtle. This all relates to the original thinking about Border Gateways. Later, people did start doing BGP other than between Border Gateways sharing a network number / prefix. There was, of course, "Interior BGP" between Border Routers of the same AS. And there was the later application of BGP to connect to route servers. Does anyone know whether any of those later applications did depend on inter-AS routing already working? If so, how was the layer violation handled (or problems arising from it not being handled)? -- Guy On 9/4/20 7:51 AM, vinton cerf wrote: > It felt like a layer violation to run BGP over TCP but in fact it proved > to be very useful. > > v > > > On Fri, Sep 4, 2020 at 7:36 AM Scott Brim via Internet-history > > wrote: > > On Fri, Sep 4, 2020 at 1:29 AM Joseph Touch > wrote: > > > On Sep 2, 2020, at 2:33 PM, Guy Almes via Internet-history < > > internet-history at elists.isoc.org > > wrote: > > ... > >? As Vint just reminded me, not only was the variable length AS > path an > > unusual characteristic, but BGP's use of TCP was quite > controversial. But, > > in addition to other advantages, the use of TCP made possible > several early > > implementations. > > > > > > Can you tell us more about what part of BGP?s use of TCP was > controversial > > at the time? > > > > I.e., other than the error of linking ?this path is up? inside > BGP to ?TCP > > is stable over that path?, a decision that required multiple fixes to > > address (MD5, TCP-AO, RST rejection, and route dampening). > > > > Layering. You're setting up a connection to a node in a different AS, so > you needed AS-level routing to tell you the path, so you need BGP so > etc. > -- > Internet-history mailing list > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > From tony.li at tony.li Fri Sep 4 06:51:58 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Fri, 4 Sep 2020 06:51:58 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> Message-ID: <5FB7397E-01B5-463E-BFE1-BBD361A109FA@tony.li> > This all relates to the original thinking about Border Gateways. Later, people did start doing BGP other than between Border Gateways sharing a network number / prefix. There was, of course, "Interior BGP" between Border Routers of the same AS. And there was the later application of BGP to connect to route servers. > Does anyone know whether any of those later applications did depend on inter-AS routing already working? If so, how was the layer violation handled (or problems arising from it not being handled)? Yes, IBGP is used, pretty much ubiquitously and has a dependency on the IGP. Because the IGPs cannot support the route scale of the Internet, interior routers are forced to run IBGP. Thus, we?re forced into a situation where each router is running both BGP and IGP. Some people have experimented with pushing their IGP routing into BGP as well, but that largely hasn?t worked well because convergence can only proceed one hop at a time. Tony From touch at strayalpha.com Fri Sep 4 08:16:48 2020 From: touch at strayalpha.com (Joseph Touch) Date: Fri, 4 Sep 2020 08:16:48 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <745426D9-D99E-458E-948F-FF67DF51ABC3@gmail.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <745426D9-D99E-458E-948F-FF67DF51ABC3@gmail.com> Message-ID: <4CEAF4FE-6C07-471A-B990-51A49F389F28@strayalpha.com> > On Sep 3, 2020, at 11:03 PM, Tony Li wrote: > .. >> Can you tell us more about what part of BGP?s use of TCP was controversial at the time? > > The words ?layering violation? were bandied about. Hmm. I see that, but only as below. >> I.e., other than the error of linking ?this path is up? inside BGP to ?TCP is stable over that path?, a decision that required multiple fixes to address (MD5, TCP-AO, RST rejection, and route dampening). > > You seem to be confused. A BGP path does not imply TCP stabiility. Only reachability. BGP paths don?t imply TCP stability, but then TCP stability should never affect whether a BGP path is viable. > Most of the symptoms that you cite are all a result of the lack of a workable security architecture. A problem that pervades the entire stack, even to this day. Were it not for the TCP-to-BGPpath correlation, BGP security could be completely supported elsewhere, e.g., by signing the individual routes. Even if there were a deployable solution to those signatures, TCP connection vulnerability still requires MD5, AO, or IPsec ? or an override in the config to NOT correlate TCP sustainability with path viability. Joe From tony.li at tony.li Fri Sep 4 08:29:58 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Fri, 4 Sep 2020 08:29:58 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <4CEAF4FE-6C07-471A-B990-51A49F389F28@strayalpha.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <745426D9-D99E-458E-948F-FF67DF51ABC3@gmail.com> <4CEAF4FE-6C07-471A-B990-51A49F389F28@strayalpha.com> Message-ID: >> Most of the symptoms that you cite are all a result of the lack of a workable security architecture. A problem that pervades the entire stack, even to this day. > > Were it not for the TCP-to-BGPpath correlation, BGP security could be completely supported elsewhere, e.g., by signing the individual routes. Even if there were a deployable solution to those signatures, TCP connection vulnerability still requires MD5, AO, or IPsec ? or an override in the config to NOT correlate TCP sustainability with path viability. Sorry, but that?s provably incorrect. As we?ve seen with other protocols the transport mechanism must be secured as well, not just the contents. We have authentication in OSPF hellos and IS-IS IIHs for this reason. Tony From galmes at tamu.edu Fri Sep 4 08:46:54 2020 From: galmes at tamu.edu (Guy Almes) Date: Fri, 4 Sep 2020 11:46:54 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <745426D9-D99E-458E-948F-FF67DF51ABC3@gmail.com> <4CEAF4FE-6C07-471A-B990-51A49F389F28@strayalpha.com> Message-ID: <0dba1ece-906c-0ec3-a2de-62f3ed8c90dd@tamu.edu> Tony, Joe, et al., In addition, and again trying to keep a historical emphasis, the original BGP design was for Border Routers that were typically one hop from each other. But note that the use of TCP, while viewed as mildly heretical at the time, brought many advantages. For example, experience with EGPv2 made clear that BGP would need to support incremental updates, and TCP sessions helped with that. Again, as the number of network numbers / prefixes grew rapidly, TCP supported very large (especially) initial route messages. Again, there were contemporary (e.g., Van Jacobson's early work) and ongoing improvements to the performance, stability, and security of TCP, and those strengthened BGP without the need for BGP-specific efforts. So I think, especially in hindsight, a very good move, -- Guy On 9/4/20 11:29 AM, tony.li at tony.li wrote: >>> Most of the symptoms that you cite are all a result of the lack of a workable security architecture. A problem that pervades the entire stack, even to this day. >> >> Were it not for the TCP-to-BGPpath correlation, BGP security could be completely supported elsewhere, e.g., by signing the individual routes. Even if there were a deployable solution to those signatures, TCP connection vulnerability still requires MD5, AO, or IPsec ? or an override in the config to NOT correlate TCP sustainability with path viability. > > > Sorry, but that?s provably incorrect. As we?ve seen with other protocols the transport mechanism must be secured as well, not just the contents. We have authentication in OSPF hellos and IS-IS IIHs for this reason. > > Tony > From gtaylor at tnetconsulting.net Fri Sep 4 09:19:46 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 4 Sep 2020 10:19:46 -0600 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: On 9/2/20 3:33 PM, Guy Almes via Internet-history wrote: > BGP's use of TCP was quite controversial. This floors me. It also shows just how little I know about some of the history. What communications mechanism did other routing protocols, e.g. EGP, use? -- Grant. . . . unix || die From tony.li at tony.li Fri Sep 4 09:40:13 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Fri, 4 Sep 2020 09:40:13 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: > What communications mechanism did other routing protocols, e.g. EGP, use? EGP is IP protocol number 8. IGRP is IP protocol number 9. OSPF is IP protocol number 89. RIP runs on UDP, port 520. IS-IS has its own link layer, basically it looks like CLNP. Tony From gtaylor at tnetconsulting.net Fri Sep 4 09:49:34 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 4 Sep 2020 10:49:34 -0600 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> Message-ID: <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> On 9/4/20 5:35 AM, Scott Brim via Internet-history wrote: > Layering. You're setting up a connection to a node in a different AS, > so you needed AS-level routing to tell you the path, so you need BGP > so etc. Were people trying to do things that I think would now be similar to BGP-multi-hop? I don't see how AS-level routing is needed between neighbors on opposite ends of link-networks. What am I missing? -- Grant. . . . unix || die From tony.li at tony.li Fri Sep 4 10:11:32 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Fri, 4 Sep 2020 10:11:32 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> Message-ID: <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> > Were people trying to do things that I think would now be similar to BGP-multi-hop? IBGP is necessarily multi-hop, so that?s been a requirement since day 1. Multi-hop EBGP has been a hack that?s also been around since day 1, but was never officially sanctioned. Yes, people use it and depend on it. > I don't see how AS-level routing is needed between neighbors on opposite ends of link-networks. > > What am I missing? Topology. Strictly speaking, AS-level routing is not necessary. You can do everything with other protocols and leaking/redistribution except that: - No protocol other than BGP can support Internet (or service provider) route scale. - Leaking/redistribution has no loop prevention mechanism. Tony From touch at strayalpha.com Fri Sep 4 11:06:04 2020 From: touch at strayalpha.com (Joseph Touch) Date: Fri, 4 Sep 2020 11:06:04 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <745426D9-D99E-458E-948F-FF67DF51ABC3@gmail.com> <4CEAF4FE-6C07-471A-B990-51A49F389F28@strayalpha.com> Message-ID: <079A73F5-F2FE-4F7A-ACD7-E3D3D736E479@strayalpha.com> > On Sep 4, 2020, at 8:29 AM, tony.li at tony.li wrote: > >>> Most of the symptoms that you cite are all a result of the lack of a workable security architecture. A problem that pervades the entire stack, even to this day. >> >> Were it not for the TCP-to-BGPpath correlation, BGP security could be completely supported elsewhere, e.g., by signing the individual routes. Even if there were a deployable solution to those signatures, TCP connection vulnerability still requires MD5, AO, or IPsec ? or an override in the config to NOT correlate TCP sustainability with path viability. > > Sorry, but that?s provably incorrect. As we?ve seen with other protocols the transport mechanism must be secured as well, not just the contents. We have authentication in OSPF hellos and IS-IS IIHs for this reason. The only reason the transport needs securing is if BGP infers anything from its headers or the fact that it is up. The endpoints of the information inside the connection need not correlate to the TCP addresses or ports, so that?s not needed, If BGP didn?t tear down a route when TCP went down, it wouldn?t matter per se how many times TCP connections were dropped or why as long as SOME of the route info came through. Joe From gtaylor at tnetconsulting.net Fri Sep 4 12:30:55 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 4 Sep 2020 13:30:55 -0600 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> Message-ID: On 9/4/20 11:11 AM, Tony Li via Internet-history wrote: > IBGP is necessarily multi-hop, so that?s been a requirement since > day 1. Minor nitpick. There is nothing that prevents me from using iBGP between two peers on the same link. iBGP between loopbacks does need to be multi-hop. But iBGP between directly connected interfaces does not need to be multi-hop. -- Grant. . . . unix || die From jack at 3kitty.org Fri Sep 4 13:03:45 2020 From: jack at 3kitty.org (Jack Haverty) Date: Fri, 4 Sep 2020 13:03:45 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: On 9/4/20 9:19 AM, Grant Taylor via Internet-history wrote: > On 9/2/20 3:33 PM, Guy Almes via Internet-history wrote: >> BGP's use of TCP was quite controversial. > > This floors me.? It also shows just how little I know about some of > the history. > > What communications mechanism did other routing protocols, e.g. EGP, use? > FYI, I can relate some of the earliest history of such communications mechanisms. There was a great discussion of the choices for implementing internal control mechanisms in the Internet, at the time we were rearranging the Internet architecture to split IP apart from TCP to become V4.? With such a dramatic change on the table, all sorts of issues were considered.? One of those was how to provide the internal control mechanisms of the new Internet, i.e., mechanisms such as the routing algorithm and protocols used to pass information around among the routers, i.e., the GGP and its successors. There had been more than 10 years of experience by then with the ARPANET, and lots of sometimes unplanned experiments, especially with routing.??? Many people don't know much about the internal mechanisms of the ARPANET.?? For example, although from the user (host) perspective it was a "datagram/packet" network, internally there were a lot of mechanisms to provide a "virtual circuit" behavior.?? Packets were reordered, retransmitted, error-checked, and flow-controlled as needed to make the users' see a virtual circuit, and to keep the network stable and functional.? In a sense, there was a "TCP connection" acting between each pair of IMPs that had any active traffic flow. The ARPANET routing protocol also used internal mechanisms to pass information between IMPS.? In particular, the routing traffic was not handled by the same mechanisms that handled user traffic.?? It was kept separate, so that it would not necessarily be affected by any problems that were impacting users' traffic.? That design was termed "out-of-band-signalling", where control mechanisms utilize communications outside of those used for standard user traffic.?? The alternative was "in-band signalling", where all traffic is handled in the same way. There was a great debate about which approach to use in creating V4 of the Internet protocols.? This impacted both the design of the routing mechanism in the gateways, and the design of the ICMP protocol for communicating "control information" between hosts and gateways, and to some extent TCP as well (the design of the "Urgent" mechanism). There were many reasons to prefer out-of-band signalling, both from the ARPANET experience and other communications systems such as the traditional telephone network.? However, such an approach is necessarily more complex. At the end of the debate, in-band signalling was selected.? Partly this was because it was much simpler.? But another important reason was that the Internet was officially an Experiment. So, in-band-signalling became an Experiment.? After some operational experience, we could always change it in the next version of TCP/IP (how naive we were..). Subsequent evolution to do things like run routing over TCP seem to have increased the in-band nature, by making the internal mechanism (routing) depend even more strongly on the mechanisms it supported.?? E.g., if TCP stopped working for whatever reason, routing that used TCP would also fail. GGP was defined as an in-band protocol, using IP datagrams to communicate, while also being part of the mechanism to transport those datagrams.?? An alternative, out-of-band, mechanism might have been to define such messages separately purely using the facilities of each kind of network that provided the paths between pairs of gateways, so that GGP messages could be exchanged even if the IP mechanisms were failing (e.g., due to a routing problem). ARPA's charter was to perform Advanced Research, so trying the unproven was part of its mission.? Effectively, the Internet made a major design decision to abandon the "out-of-band" mechanisms proven in the ARPANET, and ask the question "Is it possible to create a large-scale network that uses in-band internal communications?"?? The design was selected not because we knew it would work, but because we didn't know it wouldn't work. I haven't followed all of the subsequent routing ideas and implementations, but I assume they continue to use "in-band" designs.? So if you can read this message, the answer to that experimental question is apparently "Yes, it works!" /Jack From tony.li at tony.li Fri Sep 4 14:43:30 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Fri, 4 Sep 2020 14:43:30 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> Message-ID: >> IBGP is necessarily multi-hop, so that?s been a requirement since day 1. > > Minor nitpick. There is nothing that prevents me from using iBGP between two peers on the same link. > > iBGP between loopbacks does need to be multi-hop. But iBGP between directly connected interfaces does not need to be multi-hop. True, but no one would run it that way. That makes both of those interfaces into single points of failure. If you run it between loopbacks, then any path suffices. This was also effectively the early driver for multi-hop EBGP: pre-LAG link groups. Tony From tony.li at tony.li Fri Sep 4 15:13:34 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Fri, 4 Sep 2020 15:13:34 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> Message-ID: <60173786-95A9-4B6F-9AB3-7AA6ECFF4FD3@tony.li> Jack, > I haven't followed all of the subsequent routing ideas and > implementations, but I assume they continue to use "in-band" designs. > So if you can read this message, the answer to that experimental > question is apparently "Yes, it works!? Yes, it works. Sorta. In-band signaling was fine when we had a cooperative community. Once the Internet hit the mainstream, it has been seriously problematic. DoS attacks to all control protocols are the daily norm. Forgery of control traffic is trivial and easy. We?ve had to put hardware in place to help alleviate some of these symptoms. ICMP is frequently used for DoS attacks, so most folks block it. This renders PMTUD ineffective. Net net: the decision to go to in-band signaling needed to be coupled with a decision to secure signaling, either by crypto or by piggybacking it on the transport protocol itself (with crypto there too). And again, an overall security architecture is sorely missing. Regards, Tony From brian.e.carpenter at gmail.com Fri Sep 4 16:05:32 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 5 Sep 2020 11:05:32 +1200 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> Message-ID: <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> So, here's another history question: On 05-Sep-20 05:11, Tony Li via Internet-history wrote: ... > Topology. > > Strictly speaking, AS-level routing is not necessary. You can do everything with other protocols and leaking/redistribution except that: > > - No protocol other than BGP can support Internet (or service provider) route scale. > > - Leaking/redistribution has no loop prevention mechanism. I was taught many years ago that the TTL field (renamed Hop Limit in IPv6) was intended only as a last resort method of loop prevention. a) Is that accurate? b) Has it ever saved the Internet? (It does have one slightly bizarre use today: check that it's still 255 to detect forwarded link-local packets, and there's also RFC5082.) Brian From vint at google.com Fri Sep 4 16:12:16 2020 From: vint at google.com (Vint Cerf) Date: Fri, 4 Sep 2020 19:12:16 -0400 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> Message-ID: others closer to ops may have better opinions but I think hop count has helped to detect loops. v On Fri, Sep 4, 2020 at 7:05 PM Brian E Carpenter via Internet-history < internet-history at elists.isoc.org> wrote: > So, here's another history question: > > On 05-Sep-20 05:11, Tony Li via Internet-history wrote: > ... > > Topology. > > > > Strictly speaking, AS-level routing is not necessary. You can do > everything with other protocols and leaking/redistribution except that: > > > > - No protocol other than BGP can support Internet (or service provider) > route scale. > > > > - Leaking/redistribution has no loop prevention mechanism. > > I was taught many years ago that the TTL field (renamed Hop Limit in IPv6) > was intended only as a last resort method of loop prevention. > > a) Is that accurate? > b) Has it ever saved the Internet? > > (It does have one slightly bizarre use today: check that it's still 255 to > detect forwarded link-local packets, and there's also RFC5082.) > > Brian > -- > 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 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From tony.li at tony.li Fri Sep 4 16:16:43 2020 From: tony.li at tony.li (tony.li at tony.li) Date: Fri, 4 Sep 2020 16:16:43 -0700 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> Message-ID: <038DD7EC-A592-4E23-AC9B-B8F408370413@tony.li> Hi Brian, > I was taught many years ago that the TTL field (renamed Hop Limit in IPv6) was intended only as a last resort method of loop prevention. > > a) Is that accurate? > b) Has it ever saved the Internet? Well I can?t speak to original intent. Has it saved the Internet? No. Has it saved some links (and thereby some networks and some jobs)? Absolutely. Routing loops happen every day. Yes, most of them are micro-loop transients that happen while our IGPs converge. However, some of them are far more serious: we allow people to create static routes. If you create a loop with those and there?s no TTL you?re in for a Bad Day. Was it worthwhile? Totally. Tony From galmes at tamu.edu Fri Sep 4 16:19:10 2020 From: galmes at tamu.edu (Guy Almes) Date: Fri, 4 Sep 2020 19:19:10 -0400 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> Message-ID: Brian, It did give us traceroute. Not quite saving the Internet, but it was wonderful, -- Guy On 9/4/20 7:05 PM, Brian E Carpenter via Internet-history wrote: > So, here's another history question: > > On 05-Sep-20 05:11, Tony Li via Internet-history wrote: > ... >> Topology. >> >> Strictly speaking, AS-level routing is not necessary. You can do everything with other protocols and leaking/redistribution except that: >> >> - No protocol other than BGP can support Internet (or service provider) route scale. >> >> - Leaking/redistribution has no loop prevention mechanism. > > I was taught many years ago that the TTL field (renamed Hop Limit in IPv6) was intended only as a last resort method of loop prevention. > > a) Is that accurate? > b) Has it ever saved the Internet? > > (It does have one slightly bizarre use today: check that it's still 255 to detect forwarded link-local packets, and there's also RFC5082.) > > Brian > From louie at transsys.com Fri Sep 4 16:20:10 2020 From: louie at transsys.com (Louis Mamakos) Date: Fri, 04 Sep 2020 19:20:10 -0400 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> Message-ID: <958FD15D-A2E1-4778-950E-4482735F7AB3@transsys.com> One could argue that traceroute saves the Internet pretty much every day. On 4 Sep 2020, at 19:19, Guy Almes via Internet-history wrote: > Brian, > It did give us traceroute. Not quite saving the Internet, but it > was wonderful, > -- Guy > > On 9/4/20 7:05 PM, Brian E Carpenter via Internet-history wrote: >> So, here's another history question: >> >> On 05-Sep-20 05:11, Tony Li via Internet-history wrote: >> ... >>> Topology. >>> >>> Strictly speaking, AS-level routing is not necessary. You can do >>> everything with other protocols and leaking/redistribution except >>> that: >>> >>> - No protocol other than BGP can support Internet (or service >>> provider) route scale. >>> >>> - Leaking/redistribution has no loop prevention mechanism. >> >> I was taught many years ago that the TTL field (renamed Hop Limit in >> IPv6) was intended only as a last resort method of loop prevention. >> >> a) Is that accurate? >> b) Has it ever saved the Internet? >> >> (It does have one slightly bizarre use today: check that it's still >> 255 to detect forwarded link-local packets, and there's also >> RFC5082.) >> >> Brian >> > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From scott.brim at gmail.com Fri Sep 4 17:31:31 2020 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 4 Sep 2020 20:31:31 -0400 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> Message-ID: On Fri, Sep 4, 2020 at 7:06 PM Brian E Carpenter via Internet-history < internet-history at elists.isoc.org> wrote: > b) Has it ever saved the Internet? When we blackholed traffic to HP (net 16) we didn't know there was a problem for hours, thanks to TTL. And I remember one morning talking to Hans-Werner Braun on the phone as we watched packets loop through net 35 and die. They had been all night. So it has definitely saved parts of it. Purists have said that network mechanisms that obscure problems should be avoided -- let the problems have full effect so they are fixed immediately and don't linger as ticking bombs. From jack at 3kitty.org Fri Sep 4 18:04:37 2020 From: jack at 3kitty.org (Jack Haverty) Date: Fri, 4 Sep 2020 18:04:37 -0700 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <60173786-95A9-4B6F-9AB3-7AA6ECFF4FD3@tony.li> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <60173786-95A9-4B6F-9AB3-7AA6ECFF4FD3@tony.li> Message-ID: Tony, Thanks for the update.? From my end-user's perspective, the net seems to work amazingly well.? Especially now, with half the planet seeming to be Zooming all the time, I'm astonished that it still works at all.? But of course we users don't see the army of people inside the net, frantically playing whack-a-mole to keep it running with all the things that go on. Back circa 1980, the potential problem of attacks was well known, and there were research projects working on it in various government activities.? Little of that appeared in the public Internet, but there are traces from projects like TACACS and the Military Message Experiment.?? I think there were two reasons for that: it wasn't considered a problem for an experimental collegial network, and appropriate hardware wasn't available either.?? Most of those efforts were focused on the traditional usage model of a human at a terminal using the network to access a remote computer.?? That could be addressed by access control (TACACS) implemented with appropriate crypto mechanisms.?? "End-to-end" was the buzzword of the day. There was a larger problem identified, which I used to call the "end-middle" problem.? Basically this recognizes that even in carrying a single TCP connection, there are many other important traffic flows in the net which also need protection in order for that TCP connection to function. The way to analyze this was to look at every field, of every header, of every protocol, that had to work properly to assure that the users' TCP connection involved would also work.? Each piece of information in each such field had a source that generated it, and one or more "consumers" that received and acted upon it.? Unless those communications were also appropriately secured (one or more of authenticated, secret, authorized, etc.), the viability of the users' TCP traffic was at risk. So, for example, ICMP messages that originated at a gateway, and were sent to a host, or vice-versa, should be appropriately secured.? They are one example of an end-middle information flow.?? Same with GGP messages, although perhaps they'd be called "middle-middle".? Fields in the IP header had similar characteristics, e.g., the addresses, TOS, TTL, et al that were intended to convey "commands" to the gateways along the path.? They are also an end-middle flow. So, with in-band signalling there was recognition of the need to secure the signalling as well as the user traffic.? But implementation could wait for the next release.?? Sigh. Much of the discussions at the time never made it into RFCs.? Most work was much more informal, carried out in email, or innumerable meetings, or even at the hotel bar or chinese restaurant late into the evening.?? Sadly that's a now a real problem for historians.?? Of course, I can only recall the particular discussions where I was involved, so a complete history would need to get many more perspectives. /Jack On 9/4/20 3:13 PM, tony.li at tony.li wrote: > > Jack, > > >> I haven't followed all of the subsequent routing ideas and >> implementations, but I assume they continue to use "in-band" designs.? >> So if you can read this message, the answer to that experimental >> question is apparently "Yes, it works!? > > > Yes, it works. Sorta. > > In-band signaling was fine when we had a cooperative community. ?Once > the Internet hit the mainstream, > it has been seriously problematic. DoS attacks to all control > protocols are the daily norm. Forgery of control traffic is > trivial and easy. We?ve had to put hardware in place to help alleviate > some of these symptoms. > > ICMP is frequently used for DoS attacks, so most folks block it. This > renders PMTUD ineffective. > > Net net: the decision to go to in-band signaling needed to be coupled > with a decision to secure signaling, > either by crypto or by piggybacking it on the transport protocol > itself (with crypto there too).? > And again, an overall security architecture is sorely missing. > > Regards, > Tony > From jtk at depaul.edu Fri Sep 4 18:11:35 2020 From: jtk at depaul.edu (John Kristoff) Date: Fri, 4 Sep 2020 20:11:35 -0500 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> Message-ID: <20200904201135.4f58dd1c@p50.localdomain> On Sat, 5 Sep 2020 00:31:31 +0000 Scott Brim via Internet-history wrote: > Purists have said that network mechanisms that obscure problems should be > avoided -- let the problems have full effect so they are fixed immediately > and don't linger as ticking bombs. Anyone who has experienced their share of bridge loops would welcome a means by which frames could eventually die after a few times around. To the original poster, a TTL/hop-limit field for a internetwork protocol is a relatively easy and effective means for an internetwork protocol to avoid more complex means to solve a topology challenge. Has it saved the Internet, we could only guess, but mine would be yes it has. John From jack at 3kitty.org Fri Sep 4 18:15:32 2020 From: jack at 3kitty.org (Jack Haverty) Date: Fri, 4 Sep 2020 18:15:32 -0700 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> Message-ID: On 9/4/20 4:05 PM, Brian E Carpenter via Internet-history wrote: > So, here's another history question: > > > I was taught many years ago that the TTL field (renamed Hop Limit in IPv6) was intended only as a last resort method of loop prevention. > > a) Is that accurate? > My recollection, from the discussions when the IP4 header was being defined, was that TTL was included for two reasons: 1/ we couldn't be sure that packets would never loop, so TTL was a last resort that would get rid of old packets.? The name "Time To Live" captured the desire to actually limit packet lifetime, e.g., in milliseconds, but hops were the best metric that could actually be implemented.? So TTL was a placeholder for some future when it was possible to measure time.?? TTL did not prevent loops, but it did make them less likely to cause problems. 2/ TCP connections could be "confused" if an old packet arrived that looked like it belonged to a current connection, with unpredictable behavior.? The TTL maximum at least set some limits on how long such a window of vulnerability could be open.?? Computers had an annoying tendency to crash a lot in those days, but took rather long times to reboot.? So the TTL made it less likely that an old packet would cause problems.?? (Note that this did not address the scenario when a gateway crashed, was subsequently restarted possibly hours later, and sent out all the packets it still had in its queues.) /Jack From gtaylor at tnetconsulting.net Fri Sep 4 21:45:20 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 4 Sep 2020 22:45:20 -0600 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> Message-ID: <04fe1431-00c8-06d9-13b2-486cbed37c60@spamtrap.tnetconsulting.net> On 9/4/20 3:43 PM, Tony Li via Internet-history wrote: > True, but no one would run it that way. You might not think it, but I know for a fact that multiple people do run iBGP between two adjacent routers on the link-net IPs. (Think serial interfaces between two offices that are part of a larger single AS.) > That makes both of those interfaces into single points of failure. Agreed. > If you run it between loopbacks, then any path suffices. But if the WAN link is also the SPOF that can't be avoided, then using loopback IPs just means additional complexity. > This was also effectively the early driver for multi-hop EBGP: > pre-LAG link groups. *nod* -- Grant. . . . unix || die From jnc at mercury.lcs.mit.edu Sat Sep 5 07:58:36 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 5 Sep 2020 10:58:36 -0400 (EDT) Subject: [ih] List archives (Was: Exterior Gateway Protocol) Message-ID: <20200905145836.5A15918C09A@mercury.lcs.mit.edu> > From: Joseph Touch > FYI - we moved the archives here. I've just noticed that the archives are now only accessible to list members? Surely we wish to make them open to all, so that people who are doing Web searches on historical topics can find/see all the irreplaceable personal recollections that are stored here? Noel From touch at strayalpha.com Sat Sep 5 08:05:42 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 5 Sep 2020 08:05:42 -0700 Subject: [ih] List archives (Was: Exterior Gateway Protocol) In-Reply-To: <20200905145836.5A15918C09A@mercury.lcs.mit.edu> References: <20200905145836.5A15918C09A@mercury.lcs.mit.edu> Message-ID: <74D55C16-5AAE-4803-96D0-4847DB73F240@strayalpha.com> HI, all, > On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: > >> From: Joseph Touch > >> FYI - we moved the archives here. > > I've just noticed that the archives are now only accessible to list members? They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. Please let me know if you continue to find otherwise. Joe (as list admin) From jack at 3kitty.org Sat Sep 5 10:56:31 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sat, 5 Sep 2020 10:56:31 -0700 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> Message-ID: <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> I just realized that I should have also said: 3/ Although TTL did not prevent loops, it was a mechanism that *detected* loops.? When a packet TTL dropped to zero, an ICMP message (something like "TTL Time Exceeded") was supposed to be generated to tell the source of the failure to deliver.? Gateways could also report such events to some monitoring/control center by use of SNMP, where a human operator could be alerted. 4/ TTL was also intended for use with different TOS values, by the systems sending voice over the Internet (Steve Casner may remember more).? The idea was that a packet containing voice data was useless if it didn't get to its destination in time, so TTL with a "fastest delivery" TOS enabled the sender to say "if you can't deliver this in 200 milliseconds, just throw it away and don't waste any more bandwidth".?? That of course wouldn't work with "time" measured in hops, but we hoped to upgrade soon to time-based measurements.?? Dave Mills was working hard on that, developing techniques for synchronizing clocks across a set of gateways (NTP was intended for more than just setting your PC's clock). I've noticed that researchers, especially if they're not involved in actually operating a network, often don't think about the need for tools to be used when things are not going well - both to detect problems and to take actions to fix the problem. Without that operational perspective, some of the protocol functions and header fields may not seem to be necessary for the basic operation of carrying user traffic.?? TTL is one such mechanism.? Source route was another, in that it might provide a way to get control messages delivered to a misbehaving host/router/whatever that was causing routing failure.? This involved using source routing as a somewhat "out of band" signal mechanism that might not be affected by whatever was going on at the time. All of this was considered part of the "Internet Experiment", providing instrumentation to monitor the experiment to see what worked and what didn't, and evolve into tools for use in dealing with problems in operational networks. At one point I remember writing, sometime in the mid 80s,? a rather large document called something like "Managing Large Network Systems" for some government contract, where these kinds of tools were described.?? But I haven't been able to find it.?? Probably in a dusty warehouse somewhere.... /Jack On 9/4/20 6:15 PM, Jack Haverty via Internet-history wrote: > > On 9/4/20 4:05 PM, Brian E Carpenter via Internet-history wrote: >> So, here's another history question: >> >> >> I was taught many years ago that the TTL field (renamed Hop Limit in IPv6) was intended only as a last resort method of loop prevention. >> >> a) Is that accurate? >> > My recollection, from the discussions when the IP4 header was being > defined, was that TTL was included for two reasons: > > 1/ we couldn't be sure that packets would never loop, so TTL was a last > resort that would get rid of old packets.? The name "Time To Live" > captured the desire to actually limit packet lifetime, e.g., in > milliseconds, but hops were the best metric that could actually be > implemented.? So TTL was a placeholder for some future when it was > possible to measure time.?? TTL did not prevent loops, but it did make > them less likely to cause problems. > > 2/ TCP connections could be "confused" if an old packet arrived that > looked like it belonged to a current connection, with unpredictable > behavior.? The TTL maximum at least set some limits on how long such a > window of vulnerability could be open.?? Computers had an annoying > tendency to crash a lot in those days, but took rather long times to > reboot.? So the TTL made it less likely that an old packet would cause > problems.?? (Note that this did not address the scenario when a gateway > crashed, was subsequently restarted possibly hours later, and sent out > all the packets it still had in its queues.) > > /Jack > From dan at lynch.com Sat Sep 5 12:10:37 2020 From: dan at lynch.com (Dan Lynch) Date: Sat, 5 Sep 2020 12:10:37 -0700 Subject: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) References: Message-ID: <05D1F815-A946-412B-AF3F-E6780C91786E@lynch.com> Forgot to copy the fantastic list! Dan Cell 650-776-7313 Begin forwarded message: > From: Dan Lynch > Date: September 5, 2020 at 11:42:36 AM PDT > To: Joseph Touch > Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) > > ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. > > Dan > > Cell 650-776-7313 > >> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >> >> ?HI, all, >> >>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>> >>>>> From: Joseph Touch >>> >>>> FYI - we moved the archives here. >>> >>> I've just noticed that the archives are now only accessible to list members? >> >> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >> >> Please let me know if you continue to find otherwise. >> >> Joe (as list admin) >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history From jack at 3kitty.org Sat Sep 5 13:28:04 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sat, 5 Sep 2020 13:28:04 -0700 Subject: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) In-Reply-To: <05D1F815-A946-412B-AF3F-E6780C91786E@lynch.com> References: <05D1F815-A946-412B-AF3F-E6780C91786E@lynch.com> Message-ID: <7c403414-efea-6aea-6d23-831d9534f79a@3kitty.org> Thanks Dan! There's so much of the history that didn't get recorded in RFCs and such, and mail list archives from that era are rare.? We weren't very good about documenting things, especially the "why" of how decisions were made. There's plenty of room for more participation!?? Perhaps you can provide the story behind this artifact of the early Internet? ACE Coaster That coaster has been sitting on my desk for close to 40 years.? The lettering is fading, after too many attacks by marauding coffee mugs over the decades, and a few trips to the floor courtesy of a roaming cat.? The story of ACE, and Interop which followed, is an important part of Internet history.? There tends to be a focus on protocols and algorithms, but innovations like Interop were, IMHO, equally important to the success of the Internet by making it accessible to the masses and emphasizing the importance of working systems.? Perhaps more important.?? Tell us the story. /Jack On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: > Forgot to copy the fantastic list! > > Dan > > Cell 650-776-7313 > > Begin forwarded message: > >> From: Dan Lynch >> Date: September 5, 2020 at 11:42:36 AM PDT >> To: Joseph Touch >> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) >> >> ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >> >> Dan >> >> Cell 650-776-7313 >> >>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >>> >>> ?HI, all, >>> >>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>>> >>>>>> From: Joseph Touch >>>>> FYI - we moved the archives here. >>>> I've just noticed that the archives are now only accessible to list members? >>> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >>> >>> Please let me know if you continue to find otherwise. >>> >>> Joe (as list admin) >>> -- >>> Internet-history mailing list >>> Internet-history at elists.isoc.org >>> https://elists.isoc.org/mailman/listinfo/internet-history From jack at 3kitty.org Sat Sep 5 13:32:59 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sat, 5 Sep 2020 13:32:59 -0700 Subject: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) In-Reply-To: <7c403414-efea-6aea-6d23-831d9534f79a@3kitty.org> References: <05D1F815-A946-412B-AF3F-E6780C91786E@lynch.com> <7c403414-efea-6aea-6d23-831d9534f79a@3kitty.org> Message-ID: Grrmmpphh.? Apparently this mailing list doesn't believe in images.? Here's the picture that was supposed to be there: https://photos.app.goo.gl/gaeGeNjZTE3UPaXC9 /Jack On 9/5/20 1:28 PM, Jack Haverty via Internet-history wrote: > Thanks Dan! > > There's so much of the history that didn't get recorded in RFCs and > such, and mail list archives from that era are rare.? We weren't very > good about documenting things, especially the "why" of how decisions > were made. > > There's plenty of room for more participation!?? Perhaps you can provide > the story behind this artifact of the early Internet? > > ACE Coaster > > That coaster has been sitting on my desk for close to 40 years.? The > lettering is fading, after too many attacks by marauding coffee mugs > over the decades, and a few trips to the floor courtesy of a roaming cat.? > > The story of ACE, and Interop which followed, is an important part of > Internet history.? There tends to be a focus on protocols and > algorithms, but innovations like Interop were, IMHO, equally important > to the success of the Internet by making it accessible to the masses and > emphasizing the importance of working systems.? > > Perhaps more important.?? Tell us the story. > > /Jack > > > On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >> Forgot to copy the fantastic list! >> >> Dan >> >> Cell 650-776-7313 >> >> Begin forwarded message: >> >>> From: Dan Lynch >>> Date: September 5, 2020 at 11:42:36 AM PDT >>> To: Joseph Touch >>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) >>> >>> ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >>> >>> Dan >>> >>> Cell 650-776-7313 >>> >>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >>>> >>>> ?HI, all, >>>> >>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>>>> >>>>>>> From: Joseph Touch >>>>>> FYI - we moved the archives here. >>>>> I've just noticed that the archives are now only accessible to list members? >>>> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >>>> >>>> Please let me know if you continue to find otherwise. >>>> >>>> Joe (as list admin) >>>> -- >>>> Internet-history mailing list >>>> Internet-history at elists.isoc.org >>>> https://elists.isoc.org/mailman/listinfo/internet-history From casner at acm.org Sat Sep 5 14:00:54 2020 From: casner at acm.org (Stephen Casner) Date: Sat, 5 Sep 2020 14:00:54 -0700 (PDT) Subject: [ih] Delivery disturbance? Message-ID: I received Dan's message below after he forwarded it to the list, but I did not receive Joe's message responding to Noel. Joe's message went at least to Dan. Did it miss anyone else? Since Joe's message was about adjusting settings on the mail server, maybe the missed email was a side effect. -- Steve ---------- Forwarded message ---------- Date: Sat, 5 Sep 2020 12:10:37 -0700 From: Dan Lynch via Internet-history Reply-To: Dan Lynch To: Internet-history Subject: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) Forgot to copy the fantastic list! Dan Cell 650-776-7313 Begin forwarded message: > From: Dan Lynch > Date: September 5, 2020 at 11:42:36 AM PDT > To: Joseph Touch > Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) > > ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I've forgotten just now. > > Dan > > Cell 650-776-7313 > >> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >> >> ?HI, all, >> >>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>> >>>>> From: Joseph Touch >>> >>>> FYI - we moved the archives here. >>> >>> I've just noticed that the archives are now only accessible to list members? >> >> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >> >> Please let me know if you continue to find otherwise. >> >> Joe (as list admin) >> -- >> 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 casner at acm.org Sat Sep 5 14:06:25 2020 From: casner at acm.org (Stephen Casner) Date: Sat, 5 Sep 2020 14:06:25 -0700 (PDT) Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> Message-ID: On Sat, 5 Sep 2020, Jack Haverty via Internet-history wrote: > 4/ TTL was also intended for use with different TOS values, by the > systems sending voice over the Internet (Steve Casner may remember > more). The idea was that a packet containing voice data was useless if > it didn't get to its destination in time, so TTL with a "fastest > delivery" TOS enabled the sender to say "if you can't deliver this in > 200 milliseconds, just throw it away and don't waste any more > bandwidth". That of course wouldn't work with "time" measured in hops, > but we hoped to upgrade soon to time-based measurements. I don't recall any discussion of that idea while we were developing RTP. As you say, the units being in hops rather than time would make this mechanism imprecise, and the variability in the diameter of the network would make it hard to use. Multicast complicates that even further. -- Steve From vgcerf at gmail.com Sat Sep 5 14:06:21 2020 From: vgcerf at gmail.com (vinton cerf) Date: Sat, 5 Sep 2020 17:06:21 -0400 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <7BE92727-EB6E-4BFA-BA1C-2AB097A2B85F@isoc.org> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> Message-ID: i agree with Casner on this one. v On Sat, Sep 5, 2020 at 5:04 PM Stephen Casner via Internet-history < internet-history at elists.isoc.org> wrote: > On Sat, 5 Sep 2020, Jack Haverty via Internet-history wrote: > > > 4/ TTL was also intended for use with different TOS values, by the > > systems sending voice over the Internet (Steve Casner may remember > > more). The idea was that a packet containing voice data was useless if > > it didn't get to its destination in time, so TTL with a "fastest > > delivery" TOS enabled the sender to say "if you can't deliver this in > > 200 milliseconds, just throw it away and don't waste any more > > bandwidth". That of course wouldn't work with "time" measured in hops, > > but we hoped to upgrade soon to time-based measurements. > > I don't recall any discussion of that idea while we were developing > RTP. As you say, the units being in hops rather than time would make > this mechanism imprecise, and the variability in the diameter of the > network would make it hard to use. Multicast complicates that even > further. > > -- Steve > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From jack at 3kitty.org Sat Sep 5 14:34:01 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sat, 5 Sep 2020 14:34:01 -0700 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> Message-ID: Unfortunately I can't remember where or when that discussion happened.?? It might have been in some meeting not involved in RTP, but perhaps thinking about how to make the underlying gateway system more efficient by discarding useless datagrams as soon as possible.? The "meeting" I remember might even have been in a hotel bar or some restaurant.? I remember that TCP was split apart to create TCP/IP, in order to permit the creation of UDP, which was done to provide application access to a more basic datagram service in addition to TCP's virtual circuit service, for scenarios such as packet voice.?? That split motivated subsequent thinking about how to deal in the gateways with the different traffic requirements, using the information provided by IP fields such as TOS and TTL.?? E.g., if a gateway received a packet with a TTL that it knew, from its routing tables, could not be delivered to the ultimate destination "in time", then it was advantageous to throw it away right then, even though the TTL was still non-zero.?? That kind of discussion may not have overlapped much with the RTP community. I wonder if today's routers behave that way...? /Jack On 9/5/20 2:06 PM, Stephen Casner wrote: > On Sat, 5 Sep 2020, Jack Haverty via Internet-history wrote: > >> 4/ TTL was also intended for use with different TOS values, by the >> systems sending voice over the Internet (Steve Casner may remember >> more). The idea was that a packet containing voice data was useless if >> it didn't get to its destination in time, so TTL with a "fastest >> delivery" TOS enabled the sender to say "if you can't deliver this in >> 200 milliseconds, just throw it away and don't waste any more >> bandwidth". That of course wouldn't work with "time" measured in hops, >> but we hoped to upgrade soon to time-based measurements. > I don't recall any discussion of that idea while we were developing > RTP. As you say, the units being in hops rather than time would make > this mechanism imprecise, and the variability in the diameter of the > network would make it hard to use. Multicast complicates that even > further. > > -- Steve From vgcerf at gmail.com Sat Sep 5 14:37:27 2020 From: vgcerf at gmail.com (vinton cerf) Date: Sat, 5 Sep 2020 17:37:27 -0400 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <8098f5db-1b0d-57a5-2526-2eb929adb563@tnetconsulting.net> <1DB8A833-8965-4416-8CF1-AEF4844D644C@sobco.com> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> Message-ID: i don't think traffic is discarded except for hop count or lack for forwarding path unless RTP does something with timers? v On Sat, Sep 5, 2020 at 5:34 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > Unfortunately I can't remember where or when that discussion happened. > It might have been in some meeting not involved in RTP, but perhaps > thinking about how to make the underlying gateway system more efficient > by discarding useless datagrams as soon as possible. The "meeting" I > remember might even have been in a hotel bar or some restaurant. > > I remember that TCP was split apart to create TCP/IP, in order to permit > the creation of UDP, which was done to provide application access to a > more basic datagram service in addition to TCP's virtual circuit > service, for scenarios such as packet voice. That split motivated > subsequent thinking about how to deal in the gateways with the different > traffic requirements, using the information provided by IP fields such > as TOS and TTL. > > E.g., if a gateway received a packet with a TTL that it knew, from its > routing tables, could not be delivered to the ultimate destination "in > time", then it was advantageous to throw it away right then, even though > the TTL was still non-zero. That kind of discussion may not have > overlapped much with the RTP community. > > I wonder if today's routers behave that way...? > > /Jack > > On 9/5/20 2:06 PM, Stephen Casner wrote: > > On Sat, 5 Sep 2020, Jack Haverty via Internet-history wrote: > > > >> 4/ TTL was also intended for use with different TOS values, by the > >> systems sending voice over the Internet (Steve Casner may remember > >> more). The idea was that a packet containing voice data was useless if > >> it didn't get to its destination in time, so TTL with a "fastest > >> delivery" TOS enabled the sender to say "if you can't deliver this in > >> 200 milliseconds, just throw it away and don't waste any more > >> bandwidth". That of course wouldn't work with "time" measured in hops, > >> but we hoped to upgrade soon to time-based measurements. > > I don't recall any discussion of that idea while we were developing > > RTP. As you say, the units being in hops rather than time would make > > this mechanism imprecise, and the variability in the diameter of the > > network would make it hard to use. Multicast complicates that even > > further. > > > > -- Steve > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From casner at acm.org Sat Sep 5 14:47:48 2020 From: casner at acm.org (Stephen Casner) Date: Sat, 5 Sep 2020 14:47:48 -0700 (PDT) Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> Message-ID: On Sat, 5 Sep 2020, vinton cerf via Internet-history wrote: > i don't think traffic is discarded except for hop count or lack for > forwarding path unless RTP does something with timers? Routers don't know about RTP other than those that implement some form of IP/UDP/RTP header compression, ant that does not involve decisions about timestamps in particular because that compression is most efficient when all the packets are preserved. An application-level gateway could make decisions based on RTP timestamps. -- Steve From jack at 3kitty.org Sat Sep 5 14:58:04 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sat, 5 Sep 2020 14:58:04 -0700 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> Message-ID: I don't know much about RTP, but isn't it a host-host protocol communicating using IP datagrams??? So the IP routers don't really participate in it (except likely for multicast, which I never worked with). What I was describing was behavior within the router mesh, where a router is permitted to discard a datagram whenever it deems it appropriate to do so.? The EGP/IGP structure gave wide leeway for designing and configuring the internal mechanisms within any particular AS.?? The discussion I recall was about how to handle datagrams within a particular AS to get the most useful work out of the underlying comm lines.?? It was better to discard a datagram as soon as you figured out that it wasn't going to be useful.?? Making that decision based on TTL and information from the routing table state was one possibility.? Another I remember was eliminating duplicates, by examing the queues in the router to see if the incoming datagram was already there, still waiting to be sent out.?? That was an expected (and observed) scenario in situations such as a router interconnecting a fast LAN to a much slower long-haul net which provided back-pressure, e.g., Ethernet to ARPANET.?? Queues built up, sometimes containing multiple copies of the same datagram. /Jack On 9/5/20 2:37 PM, vinton cerf wrote: > i don't think traffic is discarded except for hop count or lack for > forwarding path unless RTP does something with timers? > > v > > > On Sat, Sep 5, 2020 at 5:34 PM Jack Haverty via Internet-history > > wrote: > > Unfortunately I can't remember where or when that discussion > happened.?? > It might have been in some meeting not involved in RTP, but perhaps > thinking about how to make the underlying gateway system more > efficient > by discarding useless datagrams as soon as possible.? The "meeting" I > remember might even have been in a hotel bar or some restaurant.? > > I remember that TCP was split apart to create TCP/IP, in order to > permit > the creation of UDP, which was done to provide application access to a > more basic datagram service in addition to TCP's virtual circuit > service, for scenarios such as packet voice.?? That split motivated > subsequent thinking about how to deal in the gateways with the > different > traffic requirements, using the information provided by IP fields such > as TOS and TTL.?? > > E.g., if a gateway received a packet with a TTL that it knew, from its > routing tables, could not be delivered to the ultimate destination "in > time", then it was advantageous to throw it away right then, even > though > the TTL was still non-zero.?? That kind of discussion may not have > overlapped much with the RTP community. > > I wonder if today's routers behave that way...? > > /Jack > > On 9/5/20 2:06 PM, Stephen Casner wrote: > > On Sat, 5 Sep 2020, Jack Haverty via Internet-history wrote: > > > >> 4/ TTL was also intended for use with different TOS values, by the > >> systems sending voice over the Internet (Steve Casner may remember > >> more).? The idea was that a packet containing voice data was > useless if > >> it didn't get to its destination in time, so TTL with a "fastest > >> delivery" TOS enabled the sender to say "if you can't deliver > this in > >> 200 milliseconds, just throw it away and don't waste any more > >> bandwidth".? ?That of course wouldn't work with "time" measured > in hops, > >> but we hoped to upgrade soon to time-based measurements. > > I don't recall any discussion of that idea while we were developing > > RTP.? As you say, the units being in hops rather than time would > make > > this mechanism imprecise, and the variability in the diameter of the > > network would make it hard to use.? Multicast complicates that even > > further. > > > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-- Steve > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > From vgcerf at gmail.com Sat Sep 5 15:06:45 2020 From: vgcerf at gmail.com (vinton cerf) Date: Sat, 5 Sep 2020 18:06:45 -0400 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> Message-ID: no disagreement about discard - just that TTL wasn't interpreted as time but hop count in the implementations with which I am familiar; I am sure we discussed the possibility of making TTL a real "time to live" but clock sync and accuracy across the Internet seemed out of reach short of relying on NTP. When GPS came along that created a possibility of trying to sync many clocks but I am not aware of any implementations of TTL that used such a method. v On Sat, Sep 5, 2020 at 5:58 PM Jack Haverty wrote: > I don't know much about RTP, but isn't it a host-host protocol > communicating using IP datagrams? So the IP routers don't really > participate in it (except likely for multicast, which I never worked with). > > What I was describing was behavior within the router mesh, where a router > is permitted to discard a datagram whenever it deems it appropriate to do > so. The EGP/IGP structure gave wide leeway for designing and configuring > the internal mechanisms within any particular AS. The discussion I recall > was about how to handle datagrams within a particular AS to get the most > useful work out of the underlying comm lines. > > It was better to discard a datagram as soon as you figured out that it > wasn't going to be useful. Making that decision based on TTL and > information from the routing table state was one possibility. Another I > remember was eliminating duplicates, by examing the queues in the router to > see if the incoming datagram was already there, still waiting to be sent > out. > > That was an expected (and observed) scenario in situations such as a > router interconnecting a fast LAN to a much slower long-haul net which > provided back-pressure, e.g., Ethernet to ARPANET. Queues built up, > sometimes containing multiple copies of the same datagram. > > /Jack > > On 9/5/20 2:37 PM, vinton cerf wrote: > > i don't think traffic is discarded except for hop count or lack for > forwarding path unless RTP does something with timers? > > v > > > On Sat, Sep 5, 2020 at 5:34 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > >> Unfortunately I can't remember where or when that discussion happened. >> It might have been in some meeting not involved in RTP, but perhaps >> thinking about how to make the underlying gateway system more efficient >> by discarding useless datagrams as soon as possible. The "meeting" I >> remember might even have been in a hotel bar or some restaurant. >> >> I remember that TCP was split apart to create TCP/IP, in order to permit >> the creation of UDP, which was done to provide application access to a >> more basic datagram service in addition to TCP's virtual circuit >> service, for scenarios such as packet voice. That split motivated >> subsequent thinking about how to deal in the gateways with the different >> traffic requirements, using the information provided by IP fields such >> as TOS and TTL. >> >> E.g., if a gateway received a packet with a TTL that it knew, from its >> routing tables, could not be delivered to the ultimate destination "in >> time", then it was advantageous to throw it away right then, even though >> the TTL was still non-zero. That kind of discussion may not have >> overlapped much with the RTP community. >> >> I wonder if today's routers behave that way...? >> >> /Jack >> >> On 9/5/20 2:06 PM, Stephen Casner wrote: >> > On Sat, 5 Sep 2020, Jack Haverty via Internet-history wrote: >> > >> >> 4/ TTL was also intended for use with different TOS values, by the >> >> systems sending voice over the Internet (Steve Casner may remember >> >> more). The idea was that a packet containing voice data was useless if >> >> it didn't get to its destination in time, so TTL with a "fastest >> >> delivery" TOS enabled the sender to say "if you can't deliver this in >> >> 200 milliseconds, just throw it away and don't waste any more >> >> bandwidth". That of course wouldn't work with "time" measured in >> hops, >> >> but we hoped to upgrade soon to time-based measurements. >> > I don't recall any discussion of that idea while we were developing >> > RTP. As you say, the units being in hops rather than time would make >> > this mechanism imprecise, and the variability in the diameter of the >> > network would make it hard to use. Multicast complicates that even >> > further. >> > >> > -- Steve >> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> > > From touch at strayalpha.com Sat Sep 5 15:21:04 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 5 Sep 2020 15:21:04 -0700 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <2120484892.2319134.1599075947873@mail.yahoo.com> <2A92424C-C957-42BA-A588-4AABD8B50489@sobco.com> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> Message-ID: > On Sep 5, 2020, at 3:06 PM, vinton cerf via Internet-history wrote: > > no disagreement about discard - just that TTL wasn't interpreted as time > but hop count in the implementations with which I am familiar; That?s the spec requirement since RFC 1009 (1987), i.e., decrement by as many seconds as the packet is held, but never less than 1. For most routers, that effectively means TTL equates to hop count (few queues build up by seconds, except in more recent bufferbloat examples - because, AFAICT, before bufferbloat the cost of memory made such long queues rare relative to link speeds). IPv6 made that change complete, calling the field ?hopcount? anyway. Joe From jack at 3kitty.org Sat Sep 5 15:59:10 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sat, 5 Sep 2020 15:59:10 -0700 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> Message-ID: <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> IMHO, it's unfortunate that TTL has officially become just a hop count.??? That was just the best we could do then. At the time, circa 1982/3, Dave Mills had been showing some pretty impressive (to me at least) results, being able to achieve millisecond-level synchronization among his Fuzzballs, using only inexpensive on-board clocks with some complicated algorithms to interact with an atomic clock somewhere.?? NTP still does that today, and all the computers in my house know what time it is thanks to that work.?? Yours too probably. The plan was to incorporate such inexpensive clocks into gateways, use Dave's NTP magic to achieve an appropriate precision of sync, and make TTL and routing actually based on time rather than hops.? Among other things, that would have enabled a true "fastest possible delivery" datagram service, selected by a setting in the TOS and TTL fields for traffic flows that needed it.? Seemed pretty straightforward at the time, but I guess it didn't happen.?? I don't see how "hops" are very useful now; does anything in the net ever use that information for purposes other than to blow datagrams out of stable orbits? Today, as I watch all the talking heads and interviewees on TV pixelating in garish color schemes with hauntingly garbled audio, I wonder if it has something to do with the TTL/TOS part of Internet History.?? I keep looking behind the TV to see if the bit-bucket has overflowed. /Jack On 9/5/20 3:21 PM, Joseph Touch wrote: > > >> On Sep 5, 2020, at 3:06 PM, vinton cerf via Internet-history >> > > wrote: >> >> no disagreement about discard - just that TTL wasn't interpreted as time >> but hop count in the implementations with which I am familiar; > > That?s the spec requirement since RFC 1009 (1987), i.e., decrement by > as many seconds as the packet is held, but never less than 1. For most > routers, that effectively means TTL equates to hop count (few queues > build up by seconds, except in more recent bufferbloat examples - > because, AFAICT, before bufferbloat the cost of memory made such long > queues rare relative to link speeds). > > IPv6 made that change complete, calling the field ?hopcount? anyway. > > Joe > > > From lukasz at bromirski.net Sat Sep 5 19:38:40 2020 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Sun, 6 Sep 2020 04:38:40 +0200 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <0e6d197b-fb64-6b5e-0bd1-80d78f65bcdb@tamu.edu> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> Message-ID: Jack, I was reading a lot of old BBN PDFs thanks to all good souls on this list that post nice URLs from time to time. I remember reading in at least one of them, that apparently first TCP/IP implementations were indeed using TTL as literally ?time?, not hop count. I believe there somewhere there between PDP docs and ARPANET docs I?ve read something to the effect ?and from this time we changed from measuring time to simply count routing hops?. Of course, right now google-fu is failing me. Quoting RFC 1009 that was already brought up, there?s quite direct ?definition? of the field: "4.8. Time-To-Live The Time-to-Live (TTL) field of the IP header is defined to be a timer limiting the lifetime of a datagram in the Internet. It is an 8-bit field and the units are seconds. This would imply that for a maximum TTL of 255 a datagram would time-out after about 4 and a quarter minutes. Another aspect of the definition requires each gateway (or other module) that handles a datagram to decrement the TTL by at least one, even if the elapsed time was much less than a second. Since this is very often the case, the TTL effectively becomes a hop count limit on how far a datagram can propagate through the Internet." Were there any implementations that survived somewhere and actually did exactly that - counted actual time/processing delay, not hops? And if it took 2s to process packet, did they really decrement TTL by two? Thanks for any pointers, -- ?ukasz Bromirski From brian.e.carpenter at gmail.com Sat Sep 5 20:28:47 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 6 Sep 2020 15:28:47 +1200 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> Message-ID: On 06-Sep-20 14:38, ?ukasz Bromirski via Internet-history wrote: > Jack, > > I was reading a lot of old BBN PDFs thanks to all good souls on > this list that post nice URLs from time to time. > > I remember reading in at least one of them, that apparently first > TCP/IP implementations were indeed using TTL as literally ?time?, > not hop count. I believe there somewhere there between PDP docs > and ARPANET docs I?ve read something to the effect ?and from this > time we changed from measuring time to simply count routing hops?. > Of course, right now google-fu is failing me. > > Quoting RFC 1009 that was already brought up, there?s quite > direct ?definition? of the field: "1009 Requirements for Internet gateways. R.T. Braden, J. Postel. June 1987. (Format: TXT, HTML) (Obsoletes RFC0985) (Obsoleted by RFC1812) (Status: HISTORIC) (DOI: 10.17487/RFC1009)" It might be interesting to ask Fred Baker, editor of RFC1812, whether there was any evidence of deployed code for this in the early 90's when he was struggling mightily to get an agreed draft. The text is subtly different than RFC1009: "5.3.1 Time to Live (TTL) The Time-to-Live (TTL) field of the IP header is defined to be a timer limiting the lifetime of a datagram. It is an 8-bit field and the units are seconds. Each router (or other module) that handles a packet MUST decrement the TTL by at least one, even if the elapsed time was much less than a second. Since this is very often the case, the TTL is effectively a hop count limit on how far a datagram can propagate through the Internet. When a router forwards a packet, it MUST reduce the TTL by at least one. If it holds a packet for more than one second, it MAY decrement the TTL by one for each second." That "MAY" effectively means "nah, don't bother". Process wonk comment: By modern standards that means that RFC1812 should be marked as Updates: 791, since it changes the definition of TTL on page 14 of RFC791. Brian > > "4.8. Time-To-Live > > The Time-to-Live (TTL) field of the IP header is defined to be a > timer limiting the lifetime of a datagram in the Internet. It is > an 8-bit field and the units are seconds. This would imply that > for a maximum TTL of 255 a datagram would time-out after about 4 > and a quarter minutes. Another aspect of the definition requires > each gateway (or other module) that handles a datagram to > decrement the TTL by at least one, even if the elapsed time was > much less than a second. Since this is very often the case, the > TTL effectively becomes a hop count limit on how far a datagram > can propagate through the Internet." > > Were there any implementations that survived somewhere and actually > did exactly that - counted actual time/processing delay, not hops? > And if it took 2s to process packet, did they really decrement TTL > by two? > > Thanks for any pointers, > From jack at 3kitty.org Sat Sep 5 23:40:07 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sat, 5 Sep 2020 23:40:07 -0700 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> Message-ID: <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> Lukasz, I think that the earliest implementations of TTL called it "Time", but I'm not aware that anyone actually used time per se in gateways, at least in the early days (1977-1982 or so).? TCP implementations didn't do anything with TTL other than set it on outgoing datagrams, and at least in my implementation (TCP for Unix), it was just set to some arbitrary value.? Until we had some data from experimentation it was hard to evaluate ideas about what routers, hosts, et al should actually do.?? The early TCPs did use time in handling retransmission timers, and there was work a bit later to incorporate time more powerfully into TCP behavior, e.g., Van Jacobson's work. The early gateways, IIRC, used the terminology "time", but in practice used just hop counts, since time measurements were difficult to implement.?? The exception to that may be Dave Mills' Fuzzballs, since Dave was the implementor most interested in time and making precise measurements of network behavior.?? I *think* Dave may have used time values and delay-based routing amongst his "fuzzies". The BBN doc you're seeking might have been one of many that discussed the ARPANET internal mechanisms, e.g., ones with titles like "Routing Algorithm Improvements".? The ARPANET internal mechanisms did use time.? It was fairly simple in the IMPs, since the delay introduced by the synchronous communications lines could be easily predicted, and the other major component of delay was the time spent in queues, which could be measured fairly easily.?? I even found one BBN ARPANET Project QTR from circa 1975 that discussed the merits of the new-fangled TCP proposal that some professor had published -- and seemed to conclude it couldn't possibly work. My involvement in implementations of TCPs and gateways lasted through about mid-1983, so I don't know much of the detail of subsequent implementations.? For the various BBN gateway/router equipment, Bob Hinden would probably be a good source.? The other major early player was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will remember.?? There's also at least one paper on the Fuzzballs which may have some details. One thing I'd advise being careful of is the various "specifications" in RFCs.? Much of the wording in those was intentionally non-prescriptive (use of "should" or "may" instead of "must"), to provide as much latitude as possible for experimentation with new ideas, especially within an AS.?? The Internet was an Experiment. Also, there was no consistent enforcement mechanism to assure that implementations actually even conformed to the "must" elements.?? So Reality could be very different from Specification. I don't know of any gateway implementations that have survived.?? There *is* ARPANET IMP software which was recently restored and a small ARPANET was run using simulated IMP hardware.?? I still have a ~1979 listing of the TCP I wrote for Unix, but haven't scanned it into digital form yet. Jack On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > Jack, > > I was reading a lot of old BBN PDFs thanks to all good souls on > this list that post nice URLs from time to time. > > I remember reading in at least one of them, that apparently first > TCP/IP implementations were indeed using TTL as literally ?time?, > not hop count. I believe there somewhere there between PDP docs > and ARPANET docs I?ve read something to the effect ?and from this > time we changed from measuring time to simply count routing hops?. > Of course, right now google-fu is failing me. > > Quoting RFC 1009 that was already brought up, there?s quite > direct ?definition? of the field: > > "4.8. Time-To-Live > > The Time-to-Live (TTL) field of the IP header is defined to be a > timer limiting the lifetime of a datagram in the Internet. It is > an 8-bit field and the units are seconds. This would imply that > for a maximum TTL of 255 a datagram would time-out after about 4 > and a quarter minutes. Another aspect of the definition requires > each gateway (or other module) that handles a datagram to > decrement the TTL by at least one, even if the elapsed time was > much less than a second. Since this is very often the case, the > TTL effectively becomes a hop count limit on how far a datagram > can propagate through the Internet." > > Were there any implementations that survived somewhere and actually > did exactly that - counted actual time/processing delay, not hops? > And if it took 2s to process packet, did they really decrement TTL > by two? > > Thanks for any pointers, From geoff at iconia.com Sun Sep 6 00:34:12 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sat, 5 Sep 2020 21:34:12 -1000 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> Message-ID: jack, you've raised my curiosity with respect to: ... There *is* ARPANET IMP software which was recently restored and a small ARPANET was run using simulated IMP hardware. Who/What/When/Where/Why? geoff On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > Lukasz, > > I think that the earliest implementations of TTL called it "Time", but > I'm not aware that anyone actually used time per se in gateways, at > least in the early days (1977-1982 or so). > > TCP implementations didn't do anything with TTL other than set it on > outgoing datagrams, and at least in my implementation (TCP for Unix), it > was just set to some arbitrary value. Until we had some data from > experimentation it was hard to evaluate ideas about what routers, hosts, > et al should actually do. The early TCPs did use time in handling > retransmission timers, and there was work a bit later to incorporate > time more powerfully into TCP behavior, e.g., Van Jacobson's work. > > The early gateways, IIRC, used the terminology "time", but in practice > used just hop counts, since time measurements were difficult to > implement. The exception to that may be Dave Mills' Fuzzballs, since > Dave was the implementor most interested in time and making precise > measurements of network behavior. I *think* Dave may have used time > values and delay-based routing amongst his "fuzzies". > > The BBN doc you're seeking might have been one of many that discussed > the ARPANET internal mechanisms, e.g., ones with titles like "Routing > Algorithm Improvements". The ARPANET internal mechanisms did use time. > It was fairly simple in the IMPs, since the delay introduced by the > synchronous communications lines could be easily predicted, and the > other major component of delay was the time spent in queues, which could > be measured fairly easily. > > I even found one BBN ARPANET Project QTR from circa 1975 that discussed > the merits of the new-fangled TCP proposal that some professor had > published -- and seemed to conclude it couldn't possibly work. > > My involvement in implementations of TCPs and gateways lasted through > about mid-1983, so I don't know much of the detail of subsequent > implementations. For the various BBN gateway/router equipment, Bob > Hinden would probably be a good source. The other major early player > was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will > remember. There's also at least one paper on the Fuzzballs which may > have some details. > > One thing I'd advise being careful of is the various "specifications" in > RFCs. Much of the wording in those was intentionally non-prescriptive > (use of "should" or "may" instead of "must"), to provide as much > latitude as possible for experimentation with new ideas, especially > within an AS. The Internet was an Experiment. > > Also, there was no consistent enforcement mechanism to assure that > implementations actually even conformed to the "must" elements. So > Reality could be very different from Specification. > > I don't know of any gateway implementations that have survived. There > *is* ARPANET IMP software which was recently restored and a small > ARPANET was run using simulated IMP hardware. I still have a ~1979 > listing of the TCP I wrote for Unix, but haven't scanned it into digital > form yet. > > Jack > > On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > > Jack, > > > > I was reading a lot of old BBN PDFs thanks to all good souls on > > this list that post nice URLs from time to time. > > > > I remember reading in at least one of them, that apparently first > > TCP/IP implementations were indeed using TTL as literally ?time?, > > not hop count. I believe there somewhere there between PDP docs > > and ARPANET docs I?ve read something to the effect ?and from this > > time we changed from measuring time to simply count routing hops?. > > Of course, right now google-fu is failing me. > > > > Quoting RFC 1009 that was already brought up, there?s quite > > direct ?definition? of the field: > > > > "4.8. Time-To-Live > > > > The Time-to-Live (TTL) field of the IP header is defined to be a > > timer limiting the lifetime of a datagram in the Internet. It is > > an 8-bit field and the units are seconds. This would imply that > > for a maximum TTL of 255 a datagram would time-out after about 4 > > and a quarter minutes. Another aspect of the definition requires > > each gateway (or other module) that handles a datagram to > > decrement the TTL by at least one, even if the elapsed time was > > much less than a second. Since this is very often the case, the > > TTL effectively becomes a hop count limit on how far a datagram > > can propagate through the Internet." > > > > Were there any implementations that survived somewhere and actually > > did exactly that - counted actual time/processing delay, not hops? > > And if it took 2s to process packet, did they really decrement TTL > > by two? > > > > Thanks for any pointers, > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From lars at nocrew.org Sun Sep 6 00:44:28 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 06 Sep 2020 07:44:28 +0000 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. In-Reply-To: (the keyboard of geoff goodfellow via Internet-history's message of "Sat, 5 Sep 2020 21:34:12 -1000") References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> Message-ID: <7w8sdnjqn7.fsf@junk.nocrew.org> Geoff Goodfellow wrote: > jack, you've raised my curiosity with respect to: > > ... There > *is* ARPANET IMP software which was recently restored and a small > ARPANET was run using simulated IMP hardware. > > Who/What/When/Where/Why? I believe this is the software: https://www.walden-family.com/impcode/ And here's information about the simulation: https://github.com/simh/simh/blob/master/H316/tests/00readme.txt From dave.walden.family at gmail.com Sun Sep 6 03:31:43 2020 From: dave.walden.family at gmail.com (David Walden) Date: Sun, 06 Sep 2020 06:31:43 -0400 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. Message-ID: Not so recent -- 2013. >I believe this is the software: >https://www.walden-family.com/impcode/ >And here's information about the simulation: >https://github.com/simh/simh/blob/master/H316/tests/00readme.txt From jack at 3kitty.org Sun Sep 6 11:24:18 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sun, 6 Sep 2020 11:24:18 -0700 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> Message-ID: Geoff, Dave's IEEE paper does an excellent job of the Who/What/When/Where.? He's right that it was about 7 years ago.?? Time flies... but I guess it's still "recent" when viewed as part of Internet History. For the curious, I can add a bit more about the Why. Sometime in 2013, I got an email out of the blue from Charlie Neuhauser, someone I didn't recognize or remember at all, asking if I was the "Jack Haverty" who authored IEN 158 - documenting the XNET protocol in 1980.?? Figuring that the statute of limitations must have expired after 30+ years, I cautiously said yes.? Over the next few days, he hooked me up with the lawyers who were involved in a patent dispute - one that had been going on for several decades by then.? In fact, the patent involved had been issued, ran its 17 year lifetime, and expired, but there was still litigation in process about whether or not the patent was valid, and 17 years of violations were alleged cause for compensation in the many millions. ? For the next few years I was involved in the battles, working with the lawyers scattered all over the country.? I never met any of them.? All our work was done by email and telephone.?? No Zoom then or we probably would have used it. The core issue in the patent battle concerned "downloading instructions", mechanisms such as would be involved in patching or issuing new software releases to remote equipment.?? XNET seemed to them to possibly have something to do with that, hence the interest.? The goal was to find hard evidence that such procedures were being done by 1980, which would prove that prior art existed.? Hard evidence literally means "hard" - opinions help, but physical equipment and running code is much more impressive in a courtroom. They hadn't found any XNET artifacts, and I couldn't point them to any surviving implementations.?? But I pointed out that my XNET document simply captured the technology that we "stole" from the ARPANET IMP experience, and that the IMPs routinely "downloaded code" from their neighbors and the NOC all during the life of the ARPANET. Since the IMPs had existed since the early 70s, that really sparked their interest, and a search (worldwide) ensued to find old IMPs, in the hope that just maybe one of them still had the IMP software in its magnetic-core memory.? A few IMPs were located, but none were functional.? The one in the museum at UCLA seemed promising, but the owners were reluctant to even hook it up to power after sitting idle for so many years, expecting it might go up in smoke. Then I learned from the BBN alumni mailing list that an ancient IMP listing had been found in a basement.?? The story from that point is pretty well described in Dave's paper. Personally, it was an interesting experience.? I worked extensively with one lawyer in San Diego.? I taught him how computers and networks actually work; he taught me a lot about the legal system regarding patents.?? IMHO, they are equally convoluted and complex when viewed from the other's perspective. I also learned a lot about the IMP code, which I had never even looked at while I was at BBN.? One task I took on was to exhaustively analyze the parts of the IMP code that implemented the "download new instructions" functionality, writing up an instruction-by-instruction description of how the code accomplished that by interacting with a neighboring IMP.?? It was a very clever design, and extremely tight code, even including self-modifying instructions.?? Not easy to figure out (or explain in language amenable to a non-technical judge or jury).? So there was great interest in being able to demonstrate the code in action using real software from the 70s and hardware simulators.?? Tangible evidence is much better than even expert opinions. The whole legal project came to a sudden end just a few months prior to the first court date.??? I was looking forward to going to Delaware (legal action was filed in Federal court in Delaware), and finally meeting some of the people.?? But the parties settled suddenly, the case was dropped, and AFAIK the patent question was never resolved.?? So, that's a bit about the "Why", for history to ponder.??? The experience got me wondering about the "patent history" of The Internet.?? Clearly there was a lot of innovation in those days.?? My recollection is that very little was patented, even if only to make sure no one else could.?? Maybe someone will document the patent-related aspects of Internet History someday. /Jack Haverty On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > jack, you've raised my curiosity with respect to: > > ... There > *is* ARPANET IMP software which was recently restored and a small > ARPANET was run using simulated IMP hardware. > > Who/What/When/Where/Why? > > geoff > > On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history > > wrote: > > Lukasz, > > I think that the earliest implementations of TTL called it "Time", but > I'm not aware that anyone actually used time per se in gateways, at > least in the early days (1977-1982 or so).? > > TCP implementations didn't do anything with TTL other than set it on > outgoing datagrams, and at least in my implementation (TCP for > Unix), it > was just set to some arbitrary value.? Until we had some data from > experimentation it was hard to evaluate ideas about what routers, > hosts, > et al should actually do.?? The early TCPs did use time in handling > retransmission timers, and there was work a bit later to incorporate > time more powerfully into TCP behavior, e.g., Van Jacobson's work. > > The early gateways, IIRC, used the terminology "time", but in practice > used just hop counts, since time measurements were difficult to > implement.?? The exception to that may be Dave Mills' Fuzzballs, since > Dave was the implementor most interested in time and making precise > measurements of network behavior.?? I *think* Dave may have used time > values and delay-based routing amongst his "fuzzies". > > The BBN doc you're seeking might have been one of many that discussed > the ARPANET internal mechanisms, e.g., ones with titles like "Routing > Algorithm Improvements".? The ARPANET internal mechanisms did use > time.? > It was fairly simple in the IMPs, since the delay introduced by the > synchronous communications lines could be easily predicted, and the > other major component of delay was the time spent in queues, which > could > be measured fairly easily.?? > > I even found one BBN ARPANET Project QTR from circa 1975 that > discussed > the merits of the new-fangled TCP proposal that some professor had > published -- and seemed to conclude it couldn't possibly work. > > My involvement in implementations of TCPs and gateways lasted through > about mid-1983, so I don't know much of the detail of subsequent > implementations.? For the various BBN gateway/router equipment, Bob > Hinden would probably be a good source.? The other major early player > was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will > remember.?? There's also at least one paper on the Fuzzballs which may > have some details. > > One thing I'd advise being careful of is the various > "specifications" in > RFCs.? Much of the wording in those was intentionally non-prescriptive > (use of "should" or "may" instead of "must"), to provide as much > latitude as possible for experimentation with new ideas, especially > within an AS.?? The Internet was an Experiment. > > Also, there was no consistent enforcement mechanism to assure that > implementations actually even conformed to the "must" elements.?? So > Reality could be very different from Specification. > > I don't know of any gateway implementations that have survived.?? > There > *is* ARPANET IMP software which was recently restored and a small > ARPANET was run using simulated IMP hardware.?? I still have a ~1979 > listing of the TCP I wrote for Unix, but haven't scanned it into > digital > form yet. > > Jack > > On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > > Jack, > > > > I was reading a lot of old BBN PDFs thanks to all good souls on > > this list that post nice URLs from time to time. > > > > I remember reading in at least one of them, that apparently first > > TCP/IP implementations were indeed using TTL as literally ?time?, > > not hop count. I believe there somewhere there between PDP docs > > and ARPANET docs I?ve read something to the effect ?and from this > > time we changed from measuring time to simply count routing hops?. > > Of course, right now google-fu is failing me. > > > > Quoting RFC 1009 that was already brought up, there?s quite > > direct ?definition? of the field: > > > > "4.8.? Time-To-Live > > > >? The Time-to-Live (TTL) field of the IP header is defined to be a > >? timer limiting the lifetime of a datagram in the Internet.? It is > >? an 8-bit field and the units are seconds.? This would imply that > >? for a maximum TTL of 255 a datagram would time-out after about 4 > >? and a quarter minutes.? Another aspect of the definition requires > >? each gateway (or other module) that handles a datagram to > >? decrement the TTL by at least one, even if the elapsed time was > >? much less than a second.? Since this is very often the case, the > >? TTL effectively becomes a hop count limit on how far a datagram > >? can propagate through the Internet." > > > > Were there any implementations that survived somewhere and actually > > did exactly that - counted actual time/processing delay, not hops? > > And if it took 2s to process packet, did they really decrement TTL > > by two? > > > > Thanks for any pointers, > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > From geoff at iconia.com Sun Sep 6 11:58:24 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 6 Sep 2020 08:58:24 -1000 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> Message-ID: Jack, you're a Most Eloquent purveyor of history and that WHY explain is exactly what yours truly was hoping for... Thank You for the elucidation! :D along the lines vis-a-vis: So, that's a bit about the "Why", for history to ponder. The experience got me wondering about the "patent history" of The Internet. Clearly there was a lot of innovation in those days. My recollection is that very little was patented, even if only to make sure no one else could. Maybe someone will document the patent-related aspects of Internet History someday. please excuse/pardon this immodesty: yours truly had a kinda similar "lawyered" experience with respect to WHO was the purported "inventor"/originator of wireless email in a patent litigation case and the "challenge" of finding/presenting any extant legally submissive "artifactual proof" to that effect -- for which John Markoff at the New York Times wrote about in this 2006 article: In Silicon Valley, a Man Without a Patent https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html for which some links of "proof" exist -- for some stuff mentioned in the above NYT article -- on my website https://iconia.com/ under "wireless email" (in case any historians are duly interested)... geoff On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty wrote: > Geoff, > > Dave's IEEE paper does an excellent job of the Who/What/When/Where. He's > right that it was about 7 years ago. Time flies... but I guess it's still > "recent" when viewed as part of Internet History. > > For the curious, I can add a bit more about the Why. > > Sometime in 2013, I got an email out of the blue from Charlie Neuhauser, > someone I didn't recognize or remember at all, asking if I was the "Jack > Haverty" who authored IEN 158 - documenting the XNET protocol in 1980. > Figuring that the statute of limitations must have expired after 30+ years, > I cautiously said yes. Over the next few days, he hooked me up with the > lawyers who were involved in a patent dispute - one that had been going on > for several decades by then. In fact, the patent involved had been issued, > ran its 17 year lifetime, and expired, but there was still litigation in > process about whether or not the patent was valid, and 17 years of > violations were alleged cause for compensation in the many millions. For > the next few years I was involved in the battles, working with the lawyers > scattered all over the country. I never met any of them. All our work was > done by email and telephone. No Zoom then or we probably would have used > it. > > The core issue in the patent battle concerned "downloading instructions", > mechanisms such as would be involved in patching or issuing new software > releases to remote equipment. XNET seemed to them to possibly have > something to do with that, hence the interest. The goal was to find hard > evidence that such procedures were being done by 1980, which would prove > that prior art existed. Hard evidence literally means "hard" - opinions > help, but physical equipment and running code is much more impressive in a > courtroom. > > They hadn't found any XNET artifacts, and I couldn't point them to any > surviving implementations. But I pointed out that my XNET document simply > captured the technology that we "stole" from the ARPANET IMP experience, > and that the IMPs routinely "downloaded code" from their neighbors and the > NOC all during the life of the ARPANET. > > Since the IMPs had existed since the early 70s, that really sparked their > interest, and a search (worldwide) ensued to find old IMPs, in the hope > that just maybe one of them still had the IMP software in its magnetic-core > memory. A few IMPs were located, but none were functional. The one in the > museum at UCLA seemed promising, but the owners were reluctant to even hook > it up to power after sitting idle for so many years, expecting it might go > up in smoke. > > Then I learned from the BBN alumni mailing list that an ancient IMP > listing had been found in a basement. The story from that point is pretty > well described in Dave's paper. > > Personally, it was an interesting experience. I worked extensively with > one lawyer in San Diego. I taught him how computers and networks actually > work; he taught me a lot about the legal system regarding patents. IMHO, > they are equally convoluted and complex when viewed from the other's > perspective. > > I also learned a lot about the IMP code, which I had never even looked at > while I was at BBN. One task I took on was to exhaustively analyze the > parts of the IMP code that implemented the "download new instructions" > functionality, writing up an instruction-by-instruction description of how > the code accomplished that by interacting with a neighboring IMP. It was > a very clever design, and extremely tight code, even including > self-modifying instructions. Not easy to figure out (or explain in > language amenable to a non-technical judge or jury). So there was great > interest in being able to demonstrate the code in action using real > software from the 70s and hardware simulators. Tangible evidence is much > better than even expert opinions. > > The whole legal project came to a sudden end just a few months prior to > the first court date. I was looking forward to going to Delaware (legal > action was filed in Federal court in Delaware), and finally meeting some of > the people. But the parties settled suddenly, the case was dropped, and > AFAIK the patent question was never resolved. > > So, that's a bit about the "Why", for history to ponder. The experience > got me wondering about the "patent history" of The Internet. Clearly > there was a lot of innovation in those days. My recollection is that very > little was patented, even if only to make sure no one else could. Maybe > someone will document the patent-related aspects of Internet History > someday. > > /Jack Haverty > > > > On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > > jack, you've raised my curiosity with respect to: > > ... There > *is* ARPANET IMP software which was recently restored and a small > ARPANET was run using simulated IMP hardware. > > Who/What/When/Where/Why? > > geoff > > On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > >> Lukasz, >> >> I think that the earliest implementations of TTL called it "Time", but >> I'm not aware that anyone actually used time per se in gateways, at >> least in the early days (1977-1982 or so). >> >> TCP implementations didn't do anything with TTL other than set it on >> outgoing datagrams, and at least in my implementation (TCP for Unix), it >> was just set to some arbitrary value. Until we had some data from >> experimentation it was hard to evaluate ideas about what routers, hosts, >> et al should actually do. The early TCPs did use time in handling >> retransmission timers, and there was work a bit later to incorporate >> time more powerfully into TCP behavior, e.g., Van Jacobson's work. >> >> The early gateways, IIRC, used the terminology "time", but in practice >> used just hop counts, since time measurements were difficult to >> implement. The exception to that may be Dave Mills' Fuzzballs, since >> Dave was the implementor most interested in time and making precise >> measurements of network behavior. I *think* Dave may have used time >> values and delay-based routing amongst his "fuzzies". >> >> The BBN doc you're seeking might have been one of many that discussed >> the ARPANET internal mechanisms, e.g., ones with titles like "Routing >> Algorithm Improvements". The ARPANET internal mechanisms did use time. >> It was fairly simple in the IMPs, since the delay introduced by the >> synchronous communications lines could be easily predicted, and the >> other major component of delay was the time spent in queues, which could >> be measured fairly easily. >> >> I even found one BBN ARPANET Project QTR from circa 1975 that discussed >> the merits of the new-fangled TCP proposal that some professor had >> published -- and seemed to conclude it couldn't possibly work. >> >> My involvement in implementations of TCPs and gateways lasted through >> about mid-1983, so I don't know much of the detail of subsequent >> implementations. For the various BBN gateway/router equipment, Bob >> Hinden would probably be a good source. The other major early player >> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will >> remember. There's also at least one paper on the Fuzzballs which may >> have some details. >> >> One thing I'd advise being careful of is the various "specifications" in >> RFCs. Much of the wording in those was intentionally non-prescriptive >> (use of "should" or "may" instead of "must"), to provide as much >> latitude as possible for experimentation with new ideas, especially >> within an AS. The Internet was an Experiment. >> >> Also, there was no consistent enforcement mechanism to assure that >> implementations actually even conformed to the "must" elements. So >> Reality could be very different from Specification. >> >> I don't know of any gateway implementations that have survived. There >> *is* ARPANET IMP software which was recently restored and a small >> ARPANET was run using simulated IMP hardware. I still have a ~1979 >> listing of the TCP I wrote for Unix, but haven't scanned it into digital >> form yet. >> >> Jack >> >> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: >> > Jack, >> > >> > I was reading a lot of old BBN PDFs thanks to all good souls on >> > this list that post nice URLs from time to time. >> > >> > I remember reading in at least one of them, that apparently first >> > TCP/IP implementations were indeed using TTL as literally ?time?, >> > not hop count. I believe there somewhere there between PDP docs >> > and ARPANET docs I?ve read something to the effect ?and from this >> > time we changed from measuring time to simply count routing hops?. >> > Of course, right now google-fu is failing me. >> > >> > Quoting RFC 1009 that was already brought up, there?s quite >> > direct ?definition? of the field: >> > >> > "4.8. Time-To-Live >> > >> > The Time-to-Live (TTL) field of the IP header is defined to be a >> > timer limiting the lifetime of a datagram in the Internet. It is >> > an 8-bit field and the units are seconds. This would imply that >> > for a maximum TTL of 255 a datagram would time-out after about 4 >> > and a quarter minutes. Another aspect of the definition requires >> > each gateway (or other module) that handles a datagram to >> > decrement the TTL by at least one, even if the elapsed time was >> > much less than a second. Since this is very often the case, the >> > TTL effectively becomes a hop count limit on how far a datagram >> > can propagate through the Internet." >> > >> > Were there any implementations that survived somewhere and actually >> > did exactly that - counted actual time/processing delay, not hops? >> > And if it took 2s to process packet, did they really decrement TTL >> > by two? >> > >> > Thanks for any pointers, >> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> >> > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From touch at strayalpha.com Sun Sep 6 12:34:56 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sun, 6 Sep 2020 12:34:56 -0700 Subject: [ih] List archives (Was: Exterior Gateway Protocol) In-Reply-To: <74D55C16-5AAE-4803-96D0-4847DB73F240@strayalpha.com> References: <20200905145836.5A15918C09A@mercury.lcs.mit.edu> <74D55C16-5AAE-4803-96D0-4847DB73F240@strayalpha.com> Message-ID: <7EEA9E47-847C-4758-B0C7-A3A8ACE6E7D2@strayalpha.com> Hi, all, Unfortunately there is a bug in the Mailman at ISOC. When I set the list archives to be open to the public, they become inaccessible to everyone now (404 link error). I?ve set the archive back to ?list members only? and will ask the ISOC support staff to look into the issue. Until it is fixed, it will remain as currently set. I?ve also heard from some of you that you might not be receiving posts. Please check your filters and try a few short tests; I have received all posts to the list without gaps, so I?m not clear that this issue is on the server side yet. Joe (as list admin) > On Sep 5, 2020, at 8:05 AM, Joseph Touch wrote: > > HI, all, > >> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >> >>> From: Joseph Touch >> >>> FYI - we moved the archives here. >> >> I've just noticed that the archives are now only accessible to list members? > > They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. > > Please let me know if you continue to find otherwise. > > Joe (as list admin) From jack at 3kitty.org Sun Sep 6 12:39:09 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sun, 6 Sep 2020 12:39:09 -0700 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> Message-ID: <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3kitty.org> Hi Geoff - thanks for that bit of history and kudos!? I think there's an Internet connection in your experience.? I'm not sure what, legally, "wireless email" means.? But I suspect that email was being sent and received, wirelessly, well before even 1982, if only to and from the SRI Packet Radio van that could occasionally be seen then roaming around the Bay Area. Of course, technically, that probably involved a Telnet connection, wirelessly, to some PDP-10 running an email program.?? But, legally, it might meet the court accepted definition of "wireless email". ? I learned from the lawyers that much of litigation involves arguing about the meaning of words and phrases. So, perhaps someone could have looked for mouldering Packet Radio (aka PR) hardware and software, and demonstrated wireless email circa 1978 over one or more PRNETs. Sadly, although I was pretty sure that interesting "prior art" would be found in the PR environment, we had little success 7 years ago while trying to find anything that might show exactly how PR equipment "downloaded instructions".?? There's remarkably little readily discoverable material about lots of the computer and network systems of the 70s/80s, especially internal details of operation, tools, procedures, etc.?? Plenty of stuff on Routing, but little on other mechanisms, or other types of networks of that era, at least that the lawyers and I could find.?? IMHO, that's a huge gap even in Internet History, since the Internet did not evolve in a vacuum, was itself composed of more than the ARPANET, and was surrounded by competitors (remember multiprotocol routers). /Jack On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > Jack, you're a Most Eloquent purveyor of history and that WHY explain > is exactly what yours truly was hoping for... Thank You for the > elucidation! :D > > along the lines vis-a-vis: > > So, that's a bit about the "Why", for history to ponder.? The > experience got me wondering about the "patent history" of The > Internet.? Clearly there was a lot of innovation in those days.? > My recollection is that very little was patented, even if only to > make sure no one else could.? Maybe someone will document the > patent-related aspects of Internet History someday. > > please excuse/pardon this immodesty: yours truly had a kinda similar > "lawyered" experience with respect to WHO was the purported > "inventor"/originator of wireless email in a patent litigation case > and the "challenge" of finding/presenting any extant legally > submissive "artifactual?proof" to that effect -- for which John > Markoff at the New York Times wrote about in this 2006 article: > > In Silicon Valley, a Man Without a Patent > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > > for which some links of "proof" exist -- for some stuff mentioned in > the above NYT article -- on my website?https://iconia.com/?under > "wireless email" (in case any historians are duly interested)...? > > geoff > > On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > wrote: > > Geoff, > > Dave's IEEE paper does an excellent job of the > Who/What/When/Where.? He's right that it was about 7 years ago.?? > Time flies... but I guess it's still "recent" when viewed as part > of Internet History. > > For the curious, I can add a bit more about the Why. > > Sometime in 2013, I got an email out of the blue from Charlie > Neuhauser, someone I didn't recognize or remember at all, asking > if I was the "Jack Haverty" who authored IEN 158 - documenting the > XNET protocol in 1980.?? Figuring that the statute of limitations > must have expired after 30+ years, I cautiously said yes.? Over > the next few days, he hooked me up with the lawyers who were > involved in a patent dispute - one that had been going on for > several decades by then.? In fact, the patent involved had been > issued, ran its 17 year lifetime, and expired, but there was still > litigation in process about whether or not the patent was valid, > and 17 years of violations were alleged cause for compensation in > the many millions. ? For the next few years I was involved in the > battles, working with the lawyers scattered all over the country.? > I never met any of them.? All our work was done by email and > telephone.?? No Zoom then or we probably would have used it. > > The core issue in the patent battle concerned "downloading > instructions", mechanisms such as would be involved in patching or > issuing new software releases to remote equipment.?? XNET seemed > to them to possibly have something to do with that, hence the > interest.? The goal was to find hard evidence that such procedures > were being done by 1980, which would prove that prior art > existed.? Hard evidence literally means "hard" - opinions help, > but physical equipment and running code is much more impressive in > a courtroom. > > They hadn't found any XNET artifacts, and I couldn't point them to > any surviving implementations.?? But I pointed out that my XNET > document simply captured the technology that we "stole" from the > ARPANET IMP experience, and that the IMPs routinely "downloaded > code" from their neighbors and the NOC all during the life of the > ARPANET. > > Since the IMPs had existed since the early 70s, that really > sparked their interest, and a search (worldwide) ensued to find > old IMPs, in the hope that just maybe one of them still had the > IMP software in its magnetic-core memory.? A few IMPs were > located, but none were functional.? The one in the museum at UCLA > seemed promising, but the owners were reluctant to even hook it up > to power after sitting idle for so many years, expecting it might > go up in smoke. > > Then I learned from the BBN alumni mailing list that an ancient > IMP listing had been found in a basement.?? The story from that > point is pretty well described in Dave's paper. > > Personally, it was an interesting experience.? I worked > extensively with one lawyer in San Diego.? I taught him how > computers and networks actually work; he taught me a lot about the > legal system regarding patents.?? IMHO, they are equally > convoluted and complex when viewed from the other's perspective. > > I also learned a lot about the IMP code, which I had never even > looked at while I was at BBN.? One task I took on was to > exhaustively analyze the parts of the IMP code that implemented > the "download new instructions" functionality, writing up an > instruction-by-instruction description of how the code > accomplished that by interacting with a neighboring IMP.?? It was > a very clever design, and extremely tight code, even including > self-modifying instructions.?? Not easy to figure out (or explain > in language amenable to a non-technical judge or jury).? So there > was great interest in being able to demonstrate the code in action > using real software from the 70s and hardware simulators.?? > Tangible evidence is much better than even expert opinions. > > The whole legal project came to a sudden end just a few months > prior to the first court date.??? I was looking forward to going > to Delaware (legal action was filed in Federal court in Delaware), > and finally meeting some of the people.?? But the parties settled > suddenly, the case was dropped, and AFAIK the patent question was > never resolved.?? > > So, that's a bit about the "Why", for history to ponder.??? The > experience got me wondering about the "patent history" of The > Internet.?? Clearly there was a lot of innovation in those days.?? > My recollection is that very little was patented, even if only to > make sure no one else could.?? Maybe someone will document the > patent-related aspects of Internet History someday. > > /Jack Haverty > > > > On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: >> jack, you've raised my curiosity with respect to: >> >> ... There >> *is* ARPANET IMP software which was recently restored and a small >> ARPANET was run using simulated IMP hardware. >> >> Who/What/When/Where/Why? >> >> geoff >> >> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history >> > > wrote: >> >> Lukasz, >> >> I think that the earliest implementations of TTL called it >> "Time", but >> I'm not aware that anyone actually used time per se in >> gateways, at >> least in the early days (1977-1982 or so).? >> >> TCP implementations didn't do anything with TTL other than >> set it on >> outgoing datagrams, and at least in my implementation (TCP >> for Unix), it >> was just set to some arbitrary value.? Until we had some data >> from >> experimentation it was hard to evaluate ideas about what >> routers, hosts, >> et al should actually do.?? The early TCPs did use time in >> handling >> retransmission timers, and there was work a bit later to >> incorporate >> time more powerfully into TCP behavior, e.g., Van Jacobson's >> work. >> >> The early gateways, IIRC, used the terminology "time", but in >> practice >> used just hop counts, since time measurements were difficult to >> implement.?? The exception to that may be Dave Mills' >> Fuzzballs, since >> Dave was the implementor most interested in time and making >> precise >> measurements of network behavior.?? I *think* Dave may have >> used time >> values and delay-based routing amongst his "fuzzies". >> >> The BBN doc you're seeking might have been one of many that >> discussed >> the ARPANET internal mechanisms, e.g., ones with titles like >> "Routing >> Algorithm Improvements".? The ARPANET internal mechanisms did >> use time.? >> It was fairly simple in the IMPs, since the delay introduced >> by the >> synchronous communications lines could be easily predicted, >> and the >> other major component of delay was the time spent in queues, >> which could >> be measured fairly easily.?? >> >> I even found one BBN ARPANET Project QTR from circa 1975 that >> discussed >> the merits of the new-fangled TCP proposal that some >> professor had >> published -- and seemed to conclude it couldn't possibly work. >> >> My involvement in implementations of TCPs and gateways lasted >> through >> about mid-1983, so I don't know much of the detail of subsequent >> implementations.? For the various BBN gateway/router >> equipment, Bob >> Hinden would probably be a good source.? The other major >> early player >> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will >> remember.?? There's also at least one paper on the Fuzzballs >> which may >> have some details. >> >> One thing I'd advise being careful of is the various >> "specifications" in >> RFCs.? Much of the wording in those was intentionally >> non-prescriptive >> (use of "should" or "may" instead of "must"), to provide as much >> latitude as possible for experimentation with new ideas, >> especially >> within an AS.?? The Internet was an Experiment. >> >> Also, there was no consistent enforcement mechanism to assure >> that >> implementations actually even conformed to the "must" >> elements.?? So >> Reality could be very different from Specification. >> >> I don't know of any gateway implementations that have >> survived.?? There >> *is* ARPANET IMP software which was recently restored and a small >> ARPANET was run using simulated IMP hardware.?? I still have >> a ~1979 >> listing of the TCP I wrote for Unix, but haven't scanned it >> into digital >> form yet. >> >> Jack >> >> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: >> > Jack, >> > >> > I was reading a lot of old BBN PDFs thanks to all good souls on >> > this list that post nice URLs from time to time. >> > >> > I remember reading in at least one of them, that apparently >> first >> > TCP/IP implementations were indeed using TTL as literally >> ?time?, >> > not hop count. I believe there somewhere there between PDP docs >> > and ARPANET docs I?ve read something to the effect ?and >> from this >> > time we changed from measuring time to simply count routing >> hops?. >> > Of course, right now google-fu is failing me. >> > >> > Quoting RFC 1009 that was already brought up, there?s quite >> > direct ?definition? of the field: >> > >> > "4.8.? Time-To-Live >> > >> >? The Time-to-Live (TTL) field of the IP header is defined >> to be a >> >? timer limiting the lifetime of a datagram in the >> Internet.? It is >> >? an 8-bit field and the units are seconds.? This would >> imply that >> >? for a maximum TTL of 255 a datagram would time-out after >> about 4 >> >? and a quarter minutes.? Another aspect of the definition >> requires >> >? each gateway (or other module) that handles a datagram to >> >? decrement the TTL by at least one, even if the elapsed >> time was >> >? much less than a second.? Since this is very often the >> case, the >> >? TTL effectively becomes a hop count limit on how far a >> datagram >> >? can propagate through the Internet." >> > >> > Were there any implementations that survived somewhere and >> actually >> > did exactly that - counted actual time/processing delay, >> not hops? >> > And if it took 2s to process packet, did they really >> decrement TTL >> > by two? >> > >> > Thanks for any pointers, >> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> >> https://elists.isoc.org/mailman/listinfo/internet-history >> >> >> >> -- >> Geoff.Goodfellow at iconia.com >> living as The Truth is True >> >> >> > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > From geoff at iconia.com Sun Sep 6 13:03:58 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 6 Sep 2020 10:03:58 -1000 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3kitty.org> Message-ID: jack, vis-a-vis packet radio (PR) wireless email vs. the NTP/RIM litigation yours truly consulted on: For Sure there was an Internet connection in yours truly's experience: the first thing yours truly brought up was Norm Abramson's ALOHANET in the early 70's with respect to wireless email (over the ARPANET) -- for which yours truly had first hand/personal experience during multiple "vacations" to Hawaii with telneting from/via the menehune application level gateway at UH Manoa to SRI-AI. :D BUT, in the NTP/RIM litigation case: the ALOHANET "experience" (or "prior art" if you will) didn't "count" against vis-a-vis the various NTP patents "legitimacy" -- for which there were multiple -- for each NTP patient had many claims in them and were constructed around "machine-to-machine" protocol "interaction" via/with an X.25 network, MTA's and a (one-way) paging wireless network vs. our collective ARPANET(NCP)/Internet(TCP/IP) Packet Radio net telnet/terminal "experiences" we all had in the 70's and 80's. geoff On Sun, Sep 6, 2020 at 9:39 AM Jack Haverty wrote: > Hi Geoff - thanks for that bit of history and kudos! > > I think there's an Internet connection in your experience. I'm not sure > what, legally, "wireless email" means. But I suspect that email was being > sent and received, wirelessly, well before even 1982, if only to and from > the SRI Packet Radio van that could occasionally be seen then roaming > around the Bay Area. > > Of course, technically, that probably involved a Telnet connection, > wirelessly, to some PDP-10 running an email program. But, legally, it > might meet the court accepted definition of "wireless email". I learned > from the lawyers that much of litigation involves arguing about the meaning > of words and phrases. > > So, perhaps someone could have looked for mouldering Packet Radio (aka PR) > hardware and software, and demonstrated wireless email circa 1978 over one > or more PRNETs. > > Sadly, although I was pretty sure that interesting "prior art" would be > found in the PR environment, we had little success 7 years ago while trying > to find anything that might show exactly how PR equipment "downloaded > instructions". > > There's remarkably little readily discoverable material about lots of the > computer and network systems of the 70s/80s, especially internal details of > operation, tools, procedures, etc. Plenty of stuff on Routing, but little > on other mechanisms, or other types of networks of that era, at least that > the lawyers and I could find. IMHO, that's a huge gap even in Internet > History, since the Internet did not evolve in a vacuum, was itself composed > of more than the ARPANET, and was surrounded by competitors (remember > multiprotocol routers). > > /Jack > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > > Jack, you're a Most Eloquent purveyor of history and that WHY explain is > exactly what yours truly was hoping for... Thank You for the elucidation! :D > > along the lines vis-a-vis: > > So, that's a bit about the "Why", for history to ponder. The experience > got me wondering about the "patent history" of The Internet. Clearly there > was a lot of innovation in those days. My recollection is that very little > was patented, even if only to make sure no one else could. Maybe someone > will document the patent-related aspects of Internet History someday. > > please excuse/pardon this immodesty: yours truly had a kinda similar > "lawyered" experience with respect to WHO was the purported > "inventor"/originator of wireless email in a patent litigation case and the > "challenge" of finding/presenting any extant legally submissive > "artifactual proof" to that effect -- for which John Markoff at the New > York Times wrote about in this 2006 article: > > In Silicon Valley, a Man Without a Patent > > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > > for which some links of "proof" exist -- for some stuff mentioned in the > above NYT article -- on my website https://iconia.com/ under "wireless > email" (in case any historians are duly interested)... > > geoff > > On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty wrote: > >> Geoff, >> >> Dave's IEEE paper does an excellent job of the Who/What/When/Where. He's >> right that it was about 7 years ago. Time flies... but I guess it's still >> "recent" when viewed as part of Internet History. >> >> For the curious, I can add a bit more about the Why. >> >> Sometime in 2013, I got an email out of the blue from Charlie Neuhauser, >> someone I didn't recognize or remember at all, asking if I was the "Jack >> Haverty" who authored IEN 158 - documenting the XNET protocol in 1980. >> Figuring that the statute of limitations must have expired after 30+ years, >> I cautiously said yes. Over the next few days, he hooked me up with the >> lawyers who were involved in a patent dispute - one that had been going on >> for several decades by then. In fact, the patent involved had been issued, >> ran its 17 year lifetime, and expired, but there was still litigation in >> process about whether or not the patent was valid, and 17 years of >> violations were alleged cause for compensation in the many millions. For >> the next few years I was involved in the battles, working with the lawyers >> scattered all over the country. I never met any of them. All our work was >> done by email and telephone. No Zoom then or we probably would have used >> it. >> >> The core issue in the patent battle concerned "downloading instructions", >> mechanisms such as would be involved in patching or issuing new software >> releases to remote equipment. XNET seemed to them to possibly have >> something to do with that, hence the interest. The goal was to find hard >> evidence that such procedures were being done by 1980, which would prove >> that prior art existed. Hard evidence literally means "hard" - opinions >> help, but physical equipment and running code is much more impressive in a >> courtroom. >> >> They hadn't found any XNET artifacts, and I couldn't point them to any >> surviving implementations. But I pointed out that my XNET document simply >> captured the technology that we "stole" from the ARPANET IMP experience, >> and that the IMPs routinely "downloaded code" from their neighbors and the >> NOC all during the life of the ARPANET. >> >> Since the IMPs had existed since the early 70s, that really sparked their >> interest, and a search (worldwide) ensued to find old IMPs, in the hope >> that just maybe one of them still had the IMP software in its magnetic-core >> memory. A few IMPs were located, but none were functional. The one in the >> museum at UCLA seemed promising, but the owners were reluctant to even hook >> it up to power after sitting idle for so many years, expecting it might go >> up in smoke. >> >> Then I learned from the BBN alumni mailing list that an ancient IMP >> listing had been found in a basement. The story from that point is pretty >> well described in Dave's paper. >> >> Personally, it was an interesting experience. I worked extensively with >> one lawyer in San Diego. I taught him how computers and networks actually >> work; he taught me a lot about the legal system regarding patents. IMHO, >> they are equally convoluted and complex when viewed from the other's >> perspective. >> >> I also learned a lot about the IMP code, which I had never even looked at >> while I was at BBN. One task I took on was to exhaustively analyze the >> parts of the IMP code that implemented the "download new instructions" >> functionality, writing up an instruction-by-instruction description of how >> the code accomplished that by interacting with a neighboring IMP. It was >> a very clever design, and extremely tight code, even including >> self-modifying instructions. Not easy to figure out (or explain in >> language amenable to a non-technical judge or jury). So there was great >> interest in being able to demonstrate the code in action using real >> software from the 70s and hardware simulators. Tangible evidence is much >> better than even expert opinions. >> >> The whole legal project came to a sudden end just a few months prior to >> the first court date. I was looking forward to going to Delaware (legal >> action was filed in Federal court in Delaware), and finally meeting some of >> the people. But the parties settled suddenly, the case was dropped, and >> AFAIK the patent question was never resolved. >> >> So, that's a bit about the "Why", for history to ponder. The >> experience got me wondering about the "patent history" of The Internet. >> Clearly there was a lot of innovation in those days. My recollection is >> that very little was patented, even if only to make sure no one else >> could. Maybe someone will document the patent-related aspects of Internet >> History someday. >> >> /Jack Haverty >> >> >> >> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: >> >> jack, you've raised my curiosity with respect to: >> >> ... There >> *is* ARPANET IMP software which was recently restored and a small >> ARPANET was run using simulated IMP hardware. >> >> Who/What/When/Where/Why? >> >> geoff >> >> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >>> Lukasz, >>> >>> I think that the earliest implementations of TTL called it "Time", but >>> I'm not aware that anyone actually used time per se in gateways, at >>> least in the early days (1977-1982 or so). >>> >>> TCP implementations didn't do anything with TTL other than set it on >>> outgoing datagrams, and at least in my implementation (TCP for Unix), it >>> was just set to some arbitrary value. Until we had some data from >>> experimentation it was hard to evaluate ideas about what routers, hosts, >>> et al should actually do. The early TCPs did use time in handling >>> retransmission timers, and there was work a bit later to incorporate >>> time more powerfully into TCP behavior, e.g., Van Jacobson's work. >>> >>> The early gateways, IIRC, used the terminology "time", but in practice >>> used just hop counts, since time measurements were difficult to >>> implement. The exception to that may be Dave Mills' Fuzzballs, since >>> Dave was the implementor most interested in time and making precise >>> measurements of network behavior. I *think* Dave may have used time >>> values and delay-based routing amongst his "fuzzies". >>> >>> The BBN doc you're seeking might have been one of many that discussed >>> the ARPANET internal mechanisms, e.g., ones with titles like "Routing >>> Algorithm Improvements". The ARPANET internal mechanisms did use time. >>> It was fairly simple in the IMPs, since the delay introduced by the >>> synchronous communications lines could be easily predicted, and the >>> other major component of delay was the time spent in queues, which could >>> be measured fairly easily. >>> >>> I even found one BBN ARPANET Project QTR from circa 1975 that discussed >>> the merits of the new-fangled TCP proposal that some professor had >>> published -- and seemed to conclude it couldn't possibly work. >>> >>> My involvement in implementations of TCPs and gateways lasted through >>> about mid-1983, so I don't know much of the detail of subsequent >>> implementations. For the various BBN gateway/router equipment, Bob >>> Hinden would probably be a good source. The other major early player >>> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will >>> remember. There's also at least one paper on the Fuzzballs which may >>> have some details. >>> >>> One thing I'd advise being careful of is the various "specifications" in >>> RFCs. Much of the wording in those was intentionally non-prescriptive >>> (use of "should" or "may" instead of "must"), to provide as much >>> latitude as possible for experimentation with new ideas, especially >>> within an AS. The Internet was an Experiment. >>> >>> Also, there was no consistent enforcement mechanism to assure that >>> implementations actually even conformed to the "must" elements. So >>> Reality could be very different from Specification. >>> >>> I don't know of any gateway implementations that have survived. There >>> *is* ARPANET IMP software which was recently restored and a small >>> ARPANET was run using simulated IMP hardware. I still have a ~1979 >>> listing of the TCP I wrote for Unix, but haven't scanned it into digital >>> form yet. >>> >>> Jack >>> >>> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: >>> > Jack, >>> > >>> > I was reading a lot of old BBN PDFs thanks to all good souls on >>> > this list that post nice URLs from time to time. >>> > >>> > I remember reading in at least one of them, that apparently first >>> > TCP/IP implementations were indeed using TTL as literally ?time?, >>> > not hop count. I believe there somewhere there between PDP docs >>> > and ARPANET docs I?ve read something to the effect ?and from this >>> > time we changed from measuring time to simply count routing hops?. >>> > Of course, right now google-fu is failing me. >>> > >>> > Quoting RFC 1009 that was already brought up, there?s quite >>> > direct ?definition? of the field: >>> > >>> > "4.8. Time-To-Live >>> > >>> > The Time-to-Live (TTL) field of the IP header is defined to be a >>> > timer limiting the lifetime of a datagram in the Internet. It is >>> > an 8-bit field and the units are seconds. This would imply that >>> > for a maximum TTL of 255 a datagram would time-out after about 4 >>> > and a quarter minutes. Another aspect of the definition requires >>> > each gateway (or other module) that handles a datagram to >>> > decrement the TTL by at least one, even if the elapsed time was >>> > much less than a second. Since this is very often the case, the >>> > TTL effectively becomes a hop count limit on how far a datagram >>> > can propagate through the Internet." >>> > >>> > Were there any implementations that survived somewhere and actually >>> > did exactly that - counted actual time/processing delay, not hops? >>> > And if it took 2s to process packet, did they really decrement TTL >>> > by two? >>> > >>> > Thanks for any pointers, >>> >>> -- >>> Internet-history mailing list >>> Internet-history at elists.isoc.org >>> https://elists.isoc.org/mailman/listinfo/internet-history >>> >>> >> >> -- >> Geoff.Goodfellow at iconia.com >> living as The Truth is True >> >> >> >> >> > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From jack at 3kitty.org Sun Sep 6 13:49:16 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sun, 6 Sep 2020 13:49:16 -0700 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3kitty.org> Message-ID: <04437cb8-8c53-0033-6ce2-c5ecceef2669@3kitty.org> Makes sense.? That's why I said I didn't know the legal definition of "wireless email".??? It's all about the words, and I remember in the claims I dealt with, every word was subject to years-long debate and argument, until possibly a Judge decided what it meant.? /Jack On 9/6/20 1:03 PM, the keyboard of geoff goodfellow wrote: > jack, vis-a-vis packet radio (PR) wireless email vs. the NTP/RIM > litigation yours truly consulted on: > > For Sure there was an Internet connection in yours truly's experience: > > the first thing yours truly brought up was Norm Abramson's ALOHANET in > the early 70's with respect to wireless email (over the ARPANET) -- > for which yours truly had first hand/personal experience during > multiple "vacations" to Hawaii with?telneting from/via the menehune > application level gateway at UH Manoa to SRI-AI. :D > > BUT, in the NTP/RIM litigation case: the ALOHANET "experience" (or > "prior art" if you will) didn't "count" against vis-a-vis the various > NTP patents "legitimacy" -- for which there were multiple -- for each > NTP patient had many claims in them and were constructed around > "machine-to-machine" protocol "interaction" via/with an X.25 network, > MTA's and a (one-way) paging wireless network vs. our?collective > ARPANET(NCP)/Internet(TCP/IP) Packet Radio net telnet/terminal > "experiences" we all had in the 70's and 80's. > > geoff > > > On Sun, Sep 6, 2020 at 9:39 AM Jack Haverty > wrote: > > Hi Geoff - thanks for that bit of history and kudos!? > > I think there's an Internet connection in your experience.? I'm > not sure what, legally, "wireless email" means.? But I suspect > that email was being sent and received, wirelessly, well before > even 1982, if only to and from the SRI Packet Radio van that could > occasionally be seen then roaming around the Bay Area. > > Of course, technically, that probably involved a Telnet > connection, wirelessly, to some PDP-10 running an email program.?? > But, legally, it might meet the court accepted definition of > "wireless email". ? I learned from the lawyers that much of > litigation involves arguing about the meaning of words and phrases. > > So, perhaps someone could have looked for mouldering Packet Radio > (aka PR) hardware and software, and demonstrated wireless email > circa 1978 over one or more PRNETs. > > Sadly, although I was pretty sure that interesting "prior art" > would be found in the PR environment, we had little success 7 > years ago while trying to find anything that might show exactly > how PR equipment "downloaded instructions".?? > > There's remarkably little readily discoverable material about lots > of the computer and network systems of the 70s/80s, especially > internal details of operation, tools, procedures, etc.?? Plenty of > stuff on Routing, but little on other mechanisms, or other types > of networks of that era, at least that the lawyers and I could > find.?? IMHO, that's a huge gap even in Internet History, since > the Internet did not evolve in a vacuum, was itself composed of > more than the ARPANET, and was surrounded by competitors (remember > multiprotocol routers). > > /Jack > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: >> Jack, you're a Most Eloquent purveyor of history and that WHY >> explain is exactly what yours truly was hoping for... Thank You >> for the elucidation! :D >> >> along the lines vis-a-vis: >> >> So, that's a bit about the "Why", for history to ponder.? The >> experience got me wondering about the "patent history" of The >> Internet.? Clearly there was a lot of innovation in those >> days.? My recollection is that very little was patented, even >> if only to make sure no one else could.? Maybe someone will >> document the patent-related aspects of Internet History someday. >> >> please excuse/pardon this immodesty: yours truly had a kinda >> similar "lawyered" experience with respect to WHO was the >> purported "inventor"/originator of wireless email in a patent >> litigation case and the "challenge" of finding/presenting any >> extant legally submissive "artifactual?proof" to that effect -- >> for which John Markoff at the New York Times wrote about in this >> 2006 article: >> >> In Silicon Valley, a Man Without a Patent >> https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html >> >> for which some links of "proof" exist -- for some stuff mentioned >> in the above NYT article -- on my >> website?https://iconia.com/?under "wireless email" (in case any >> historians are duly interested)...? >> >> geoff >> >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > > wrote: >> >> Geoff, >> >> Dave's IEEE paper does an excellent job of the >> Who/What/When/Where.? He's right that it was about 7 years >> ago.?? Time flies... but I guess it's still "recent" when >> viewed as part of Internet History. >> >> For the curious, I can add a bit more about the Why. >> >> Sometime in 2013, I got an email out of the blue from Charlie >> Neuhauser, someone I didn't recognize or remember at all, >> asking if I was the "Jack Haverty" who authored IEN 158 - >> documenting the XNET protocol in 1980.?? Figuring that the >> statute of limitations must have expired after 30+ years, I >> cautiously said yes.? Over the next few days, he hooked me up >> with the lawyers who were involved in a patent dispute - one >> that had been going on for several decades by then.? In fact, >> the patent involved had been issued, ran its 17 year >> lifetime, and expired, but there was still litigation in >> process about whether or not the patent was valid, and 17 >> years of violations were alleged cause for compensation in >> the many millions. ? For the next few years I was involved in >> the battles, working with the lawyers scattered all over the >> country.? I never met any of them.? All our work was done by >> email and telephone.?? No Zoom then or we probably would have >> used it. >> >> The core issue in the patent battle concerned "downloading >> instructions", mechanisms such as would be involved in >> patching or issuing new software releases to remote >> equipment.?? XNET seemed to them to possibly have something >> to do with that, hence the interest.? The goal was to find >> hard evidence that such procedures were being done by 1980, >> which would prove that prior art existed.? Hard evidence >> literally means "hard" - opinions help, but physical >> equipment and running code is much more impressive in a >> courtroom. >> >> They hadn't found any XNET artifacts, and I couldn't point >> them to any surviving implementations.?? But I pointed out >> that my XNET document simply captured the technology that we >> "stole" from the ARPANET IMP experience, and that the IMPs >> routinely "downloaded code" from their neighbors and the NOC >> all during the life of the ARPANET. >> >> Since the IMPs had existed since the early 70s, that really >> sparked their interest, and a search (worldwide) ensued to >> find old IMPs, in the hope that just maybe one of them still >> had the IMP software in its magnetic-core memory.? A few IMPs >> were located, but none were functional.? The one in the >> museum at UCLA seemed promising, but the owners were >> reluctant to even hook it up to power after sitting idle for >> so many years, expecting it might go up in smoke. >> >> Then I learned from the BBN alumni mailing list that an >> ancient IMP listing had been found in a basement.?? The story >> from that point is pretty well described in Dave's paper. >> >> Personally, it was an interesting experience.? I worked >> extensively with one lawyer in San Diego.? I taught him how >> computers and networks actually work; he taught me a lot >> about the legal system regarding patents.?? IMHO, they are >> equally convoluted and complex when viewed from the other's >> perspective. >> >> I also learned a lot about the IMP code, which I had never >> even looked at while I was at BBN.? One task I took on was to >> exhaustively analyze the parts of the IMP code that >> implemented the "download new instructions" functionality, >> writing up an instruction-by-instruction description of how >> the code accomplished that by interacting with a neighboring >> IMP.?? It was a very clever design, and extremely tight code, >> even including self-modifying instructions.?? Not easy to >> figure out (or explain in language amenable to a >> non-technical judge or jury).? So there was great interest in >> being able to demonstrate the code in action using real >> software from the 70s and hardware simulators.?? Tangible >> evidence is much better than even expert opinions. >> >> The whole legal project came to a sudden end just a few >> months prior to the first court date.??? I was looking >> forward to going to Delaware (legal action was filed in >> Federal court in Delaware), and finally meeting some of the >> people.?? But the parties settled suddenly, the case was >> dropped, and AFAIK the patent question was never resolved.?? >> >> So, that's a bit about the "Why", for history to ponder.??? >> The experience got me wondering about the "patent history" of >> The Internet.?? Clearly there was a lot of innovation in >> those days.?? My recollection is that very little was >> patented, even if only to make sure no one else could.?? >> Maybe someone will document the patent-related aspects of >> Internet History someday. >> >> /Jack Haverty >> >> >> >> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: >>> jack, you've raised my curiosity with respect to: >>> >>> ... There >>> *is* ARPANET IMP software which was recently restored >>> and a small >>> ARPANET was run using simulated IMP hardware. >>> >>> Who/What/When/Where/Why? >>> >>> geoff >>> >>> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via >>> Internet-history >> > wrote: >>> >>> Lukasz, >>> >>> I think that the earliest implementations of TTL called >>> it "Time", but >>> I'm not aware that anyone actually used time per se in >>> gateways, at >>> least in the early days (1977-1982 or so).? >>> >>> TCP implementations didn't do anything with TTL other >>> than set it on >>> outgoing datagrams, and at least in my implementation >>> (TCP for Unix), it >>> was just set to some arbitrary value.? Until we had some >>> data from >>> experimentation it was hard to evaluate ideas about what >>> routers, hosts, >>> et al should actually do.?? The early TCPs did use time >>> in handling >>> retransmission timers, and there was work a bit later to >>> incorporate >>> time more powerfully into TCP behavior, e.g., Van >>> Jacobson's work. >>> >>> The early gateways, IIRC, used the terminology "time", >>> but in practice >>> used just hop counts, since time measurements were >>> difficult to >>> implement.?? The exception to that may be Dave Mills' >>> Fuzzballs, since >>> Dave was the implementor most interested in time and >>> making precise >>> measurements of network behavior.?? I *think* Dave may >>> have used time >>> values and delay-based routing amongst his "fuzzies". >>> >>> The BBN doc you're seeking might have been one of many >>> that discussed >>> the ARPANET internal mechanisms, e.g., ones with titles >>> like "Routing >>> Algorithm Improvements".? The ARPANET internal >>> mechanisms did use time.? >>> It was fairly simple in the IMPs, since the delay >>> introduced by the >>> synchronous communications lines could be easily >>> predicted, and the >>> other major component of delay was the time spent in >>> queues, which could >>> be measured fairly easily.?? >>> >>> I even found one BBN ARPANET Project QTR from circa 1975 >>> that discussed >>> the merits of the new-fangled TCP proposal that some >>> professor had >>> published -- and seemed to conclude it couldn't possibly >>> work. >>> >>> My involvement in implementations of TCPs and gateways >>> lasted through >>> about mid-1983, so I don't know much of the detail of >>> subsequent >>> implementations.? For the various BBN gateway/router >>> equipment, Bob >>> Hinden would probably be a good source.? The other major >>> early player >>> was MIT and spinoffs (Proteon), which perhaps Noel >>> Chiappa will >>> remember.?? There's also at least one paper on the >>> Fuzzballs which may >>> have some details. >>> >>> One thing I'd advise being careful of is the various >>> "specifications" in >>> RFCs.? Much of the wording in those was intentionally >>> non-prescriptive >>> (use of "should" or "may" instead of "must"), to provide >>> as much >>> latitude as possible for experimentation with new ideas, >>> especially >>> within an AS.?? The Internet was an Experiment. >>> >>> Also, there was no consistent enforcement mechanism to >>> assure that >>> implementations actually even conformed to the "must" >>> elements.?? So >>> Reality could be very different from Specification. >>> >>> I don't know of any gateway implementations that have >>> survived.?? There >>> *is* ARPANET IMP software which was recently restored >>> and a small >>> ARPANET was run using simulated IMP hardware.?? I still >>> have a ~1979 >>> listing of the TCP I wrote for Unix, but haven't scanned >>> it into digital >>> form yet. >>> >>> Jack >>> >>> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: >>> > Jack, >>> > >>> > I was reading a lot of old BBN PDFs thanks to all good >>> souls on >>> > this list that post nice URLs from time to time. >>> > >>> > I remember reading in at least one of them, that >>> apparently first >>> > TCP/IP implementations were indeed using TTL as >>> literally ?time?, >>> > not hop count. I believe there somewhere there between >>> PDP docs >>> > and ARPANET docs I?ve read something to the effect >>> ?and from this >>> > time we changed from measuring time to simply count >>> routing hops?. >>> > Of course, right now google-fu is failing me. >>> > >>> > Quoting RFC 1009 that was already brought up, there?s >>> quite >>> > direct ?definition? of the field: >>> > >>> > "4.8.? Time-To-Live >>> > >>> >? The Time-to-Live (TTL) field of the IP header is >>> defined to be a >>> >? timer limiting the lifetime of a datagram in the >>> Internet.? It is >>> >? an 8-bit field and the units are seconds.? This would >>> imply that >>> >? for a maximum TTL of 255 a datagram would time-out >>> after about 4 >>> >? and a quarter minutes.? Another aspect of the >>> definition requires >>> >? each gateway (or other module) that handles a datagram to >>> >? decrement the TTL by at least one, even if the >>> elapsed time was >>> >? much less than a second.? Since this is very often >>> the case, the >>> >? TTL effectively becomes a hop count limit on how far >>> a datagram >>> >? can propagate through the Internet." >>> > >>> > Were there any implementations that survived somewhere >>> and actually >>> > did exactly that - counted actual time/processing >>> delay, not hops? >>> > And if it took 2s to process packet, did they really >>> decrement TTL >>> > by two? >>> > >>> > Thanks for any pointers, >>> >>> -- >>> Internet-history mailing list >>> Internet-history at elists.isoc.org >>> >>> https://elists.isoc.org/mailman/listinfo/internet-history >>> >>> >>> >>> -- >>> Geoff.Goodfellow at iconia.com >>> living as The Truth is True >>> >>> >>> >> >> >> >> -- >> Geoff.Goodfellow at iconia.com >> living as The Truth is True >> >> >> > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > From jack at 3kitty.org Sun Sep 6 13:57:58 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sun, 6 Sep 2020 13:57:58 -0700 Subject: [ih] List archives (Was: Exterior Gateway Protocol) In-Reply-To: <7EEA9E47-847C-4758-B0C7-A3A8ACE6E7D2@strayalpha.com> References: <20200905145836.5A15918C09A@mercury.lcs.mit.edu> <74D55C16-5AAE-4803-96D0-4847DB73F240@strayalpha.com> <7EEA9E47-847C-4758-B0C7-A3A8ACE6E7D2@strayalpha.com> Message-ID: On 9/6/20 12:34 PM, Joseph Touch via Internet-history wrote: > I?ve also heard from some of you that you might not be receiving posts. Please check your filters and try a few short tests; I have received all posts to the list without gaps, so I?m not clear that this issue is on the server side yet. Joe, FYI, one of the "replies" I made yesterday to the ISOC list also was sent directly to a few people.? My ISP's mailer returned one of those messages this morning: ----- Transcript of session follows ----- ... Deferred: Connection timed out with r2d2.bromirski.net. Message could not be delivered for 6 hours Message will be deleted from queue ? Apparently the "TTL" for email, at least with my ISP, is 6 hours. Perhaps something similar is occurring with the ISOC mailer and the messages are being discarded by the server. /Jack From louie at transsys.com Sun Sep 6 16:28:02 2020 From: louie at transsys.com (Louis Mamakos) Date: Sun, 06 Sep 2020 19:28:02 -0400 Subject: [ih] TTL [was Exterior Gateway Protocol] In-Reply-To: <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <64E61382-98B3-4466-B6E5-448C5DC58FE7@strayalpha.com> <74e53c1a-6270-0298-1065-034b4dbe64c8@spamtrap.tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> Message-ID: On 6 Sep 2020, at 2:40, Jack Haverty via Internet-history wrote: > The early gateways, IIRC, used the terminology "time", but in practice > used just hop counts, since time measurements were difficult to > implement. The exception to that may be Dave Mills' Fuzzballs, since > Dave was the implementor most interested in time and making precise > measurements of network behavior. I *think* Dave may have used time > values and delay-based routing amongst his "fuzzies". The Fuzzballs used a delay based metric in their HELLO routing protocol. These delays were computed by way of the exchange of the routing protocols messages, using some timestamps and as was also used to sync the clock on the Fuzzball's. A very similar mechanism was used in NTP later on, with some of the earlier work in HELLO carried forward. Separate from the time sync protocols (but closed related) was the virtual clock model in the Fuzzball code that the clock synchronization acted on. The HELLO protocol was a distance-vector protocol; I forget now what "infinity" was; perhaps 30 seconds? It's been too many years since I looked at that code. I don't believe that the forwarding code in the Fuzzball did anything clever with the TTL during a forwarding operation, other than the usual decrement by one. louie From bernie at fantasyfarm.com Sun Sep 6 16:30:12 2020 From: bernie at fantasyfarm.com (Bernie Cosell) Date: Sun, 06 Sep 2020 19:30:12 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net>, , Message-ID: <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> Let me add a little bit to Jack's explorations. There are two things of interest we put in the IMP code that relates to this. The first was the DDT/TTY machinery and other was the "reload from your neighbor" machinery. I remember that first quite well, since I mostly designed it [we did EVERYTHING as a team so we co?perated and sorted stuff out together] and I implemented it [so I was really responsible for the complicated machinery that made this aspect of the IMP work]: Early on as we were coding the IMP stuff the question arose as to what to do about the TTY [and how the hell were we to debug the damn thing]. We did several things in this regard. First I wrote a simple DDT [about as powerful as the test-word switches on our PDP-1 :o)] but it allowed us to poke around in the dead hulk of the code of a stopped system to see what went wrong and also put patches in. I believe it was originally a stand alone - the imp would crash or hit a diagnostic trap and they we could run the DDT and look at buffers and counters and pointers and such and generally try to figure out what happened. When the IMP was running solidly enough [which actually happened pretty early on in its development], I can't remember the genesis of the underlying idea, but we thought we could route the DDT *over* the net to other IMPs and poke at *then*. I came up with a scheme that Will [I think] thought was way too complicated: 1) connect the DDT to the IMP as a "fake host", &2) connect the TTY to the IMP as another "fake host" With those now residing *in* the IMP, instead of apart from it we got a bunch of benefits: 1) we could run the DDT *while* the IMP was up doing its thing, and 2) we could interrogate a *different* IMPs DDT [simply by pointing the TTY to the appropriate fake host on the other IMP. 3) We could "IM" between machines [simply by pointing the TTY to the *TTY* on the other machine. [on (3) that ability was very handy as Ben and Marty were bringing up IMPs 1&2. They knew, for example, long before any of the host interface and machinery was working, that the IMP was doing just fine, since they could exchange messages and *knew* it used the same code that the hosts would be using. It also replaced lots of long-distance calls to co?rdinate what was happening at SRI and UCLA] WE also had the IMPs send "health reports" [via a background process] and they were hard wired to send to the IMP 5 TTY and so virtually from the outset we could monitor [and with the DDT tweak] the whole network. Until the PDP-1 was online it chewed up a fair bit of paper :o) It was all using the basic IMP packet-handling machinery, so that two IMPs could be poking the DDT on a particular IMP and not interfere with one another. When the PDP-1 came online as the first proto-NCC, the DDT was as happy to talk to a real host as one of its fake brethrens and ditto for the "health reports" that just changed which host they were going to and it all worked. So everything was fitting together very nicely and very usefully [despite the complicated code] A conceptually neat part about all this is that the *internals* of the IMP were host-agnostic. They didn't care if they were fake or real, they just sent the packets where there were supposed to go. and so we could implement "satellite" activities that used the underlying IMP code to do other useful things beyond just host-to-host. Expanding this principle a few years later, we had a H316 that had *two* 16k banks. [and I think I've mentioned this before on this list]. We decided to implement the TIP as, what else?? :o), a host. But in this case it was a pseudo-real-host [as I've mentioned before] this was done so that the TIP code could live in the upper memory bank and its "host interface" transferred data and control across the boundary. The IMP didn't need to know or care that the TIP was there. Phew. now to the second mechanism: reloading from a neighbor. Maybe dave remembers this better than I do but I think that one of the things we did as the IMP got more solid was removed its "loader" [which could boot the machine from paper tape] and replaced with with something that could live in 20 words [which was where the paper tape loader lived: in shadow memory behind the registers] I think that that code was *just* enough of a bootstrap to send message to a neighboring IMP and the first thing that IMP sent over a smarter loader that than received a whole memory-full of IMP code from the neighbor and then started the neighbor up. I believe we could trigger this remotely via DDT and so if the IMP was up but just in need of an updated version it could suck it in from its neighbor. My opinion is that hacking in this kind of stuff [and piggybacking "services" on top of the IMP's 'day job' of handing real host data] helped a lot in the ARPAnet being virtually "operational" [and manageable] from the start. /Bernie\ Bernie Cosell bernie at fantasyfarm.com -- Too many people; too few sheep -- From dave.walden.family at gmail.com Sun Sep 6 17:49:46 2020 From: dave.walden.family at gmail.com (dave walden) Date: Sun, 6 Sep 2020 20:49:46 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> Message-ID: I can describe the genesis.? The IMP code was originally for one host computer and several inter-IMP modems (that was what our contract specified), and I coded the IMP/Host and Host/IMP code for that in parallel with Bernie coding the DDT, etc. Then some host site wanted a second host on its IMP -- I think maybe UCLA for its IBM 360.? ARPA called us and asked if the IMP could handle more than one Host.? Our hardware guys said the Honeywell computer could support (if I remember correctly) up to seven interfaces which could be up to four Host interfaces or up to four inter-IMP modem interfaces.? We looked at the IMP/Host and Host/IMP code and it seemed fairly easy to make it reentrant, so we told ARPANET "yes".? Once the IMP would know how to handle multiple Hosts and given there was a bit in the header words between IMPs and Host to say "real" Host or "fake" Host, the possibilities were fairly clear.? I implemented the reentrant IMP-host and host-IMP code, and Bernie changed the routines he had written or was writing: - TTY in/out - DDT in/out - parameter change packets into the IMP and trace packets out of the IMP - into the IMP to be discarded and statistics packets out of the IMP For the regular reports from IMPs to the Network Monitoring Center, a bit of code in the IMP could send packets to a real host; I don't remember which of the fake Hosts they looked like they were coming from -- stats maybe. On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > Early on as we were coding the IMP stuff the question arose as to what to do > about the TTY [and how the hell were we to debug the damn thing]. We did > several things in this regard. First I wrote a simple DDT [about as powerful as > the test-word switches on our PDP-1 :o)] but it allowed us to poke around in the > dead hulk of the code of a stopped system to see what went wrong and also put > patches in. I believe it was originally a stand alone - the imp would crash or hit a > diagnostic trap and they we could run the DDT and look at buffers and counters > and pointers and such and generally try to figure out what happened. When the > IMP was running solidly enough [which actually happened pretty early on in its > development], I can't remember the genesis of the underlying idea, but we > thought we could route the DDT *over* the net to other IMPs and poke at *then*. > I came up with a scheme that Will [I think] thought was way too complicated: > > From geoff at iconia.com Sun Sep 6 17:57:52 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 6 Sep 2020 14:57:52 -1000 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> Message-ID: Bernie, one thing yours truly has always been curious of is when the ARPANET was initially being rolled out, viz.: http://som.csudh.edu/fac/lpress/history/arpamaps/press.jpg : How were the first four IMPs (UCLA, SRI, UCSB & UTAH) managed/controlled until the cross country link to IMP #5 to y'all at BBN was installed? and What was the length of time the initial 4 ARPANET IMPs "ran" without the cross country link to IMP #5 in Boston? geoff On Sun, Sep 6, 2020 at 1:30 PM Bernie Cosell via Internet-history < internet-history at elists.isoc.org> wrote: > Let me add a little bit to Jack's explorations. There are two things of > interest we > put in the IMP code that relates to this. The first was the DDT/TTY > machinery > and other was the "reload from your neighbor" machinery. > > I remember that first quite well, since I mostly designed it [we did > EVERYTHING as a team so we co?perated and sorted stuff out together] and I > implemented it [so I was really responsible for the complicated machinery > that > made this aspect of the IMP work]: > > Early on as we were coding the IMP stuff the question arose as to what to > do > about the TTY [and how the hell were we to debug the damn thing]. We did > several things in this regard. First I wrote a simple DDT [about as > powerful as > the test-word switches on our PDP-1 :o)] but it allowed us to poke around > in the > dead hulk of the code of a stopped system to see what went wrong and also > put > patches in. I believe it was originally a stand alone - the imp would > crash or hit a > diagnostic trap and they we could run the DDT and look at buffers and > counters > and pointers and such and generally try to figure out what happened. When > the > IMP was running solidly enough [which actually happened pretty early on in > its > development], I can't remember the genesis of the underlying idea, but > we > thought we could route the DDT *over* the net to other IMPs and poke at > *then*. > I came up with a scheme that Will [I think] thought was way too > complicated: > > 1) connect the DDT to the IMP as a "fake host", > &2) connect the TTY to the IMP as another "fake host" > > With those now residing *in* the IMP, instead of apart from it we got a > bunch of > benefits: > 1) we could run the DDT *while* the IMP was up doing its thing, and > 2) we could interrogate a *different* IMPs DDT [simply by pointing the > TTY to > the appropriate fake host on the other IMP. > 3) We could "IM" between machines [simply by pointing the TTY to the > *TTY* > on the other machine. > > [on (3) that ability was very handy as Ben and Marty were bringing up IMPs > 1&2. > They knew, for example, long before any of the host interface and > machinery was > working, that the IMP was doing just fine, since they could exchange > messages > and *knew* it used the same code that the hosts would be using. It also > replaced > lots of long-distance calls to co?rdinate what was happening at SRI and > UCLA] > > WE also had the IMPs send "health reports" [via a background process] and > they > were hard wired to send to the IMP 5 TTY and so virtually from the outset > we > could monitor [and with the DDT tweak] the whole network. Until the > PDP-1 > was online it chewed up a fair bit of paper :o) > > It was all using the basic IMP packet-handling machinery, so that two IMPs > could be poking the DDT on a particular IMP and not interfere with one > another. > When the PDP-1 came online as the first proto-NCC, the DDT was as happy to > talk to a real host as one of its fake brethrens and ditto for the "health > reports" > that just changed which host they were going to and it all worked. So > everything > was fitting together very nicely and very usefully [despite the > complicated code] > > A conceptually neat part about all this is that the *internals* of the IMP > were > host-agnostic. They didn't care if they were fake or real, they just > sent the > packets where there were supposed to go. and so we could implement > "satellite" > activities that used the underlying IMP code to do other useful things > beyond > just host-to-host. > > Expanding this principle a few years later, we had a H316 that had *two* > 16k > banks. [and I think I've mentioned this before on this list]. We decided > to > implement the TIP as, what else?? :o), a host. But in this case it was a > pseudo-real-host [as I've mentioned before] this was done so that the TIP > code > could live in the upper memory bank and its "host interface" transferred > data and > control across the boundary. The IMP didn't need to know or care that the > TIP > was there. > > Phew. now to the second mechanism: reloading from a neighbor. Maybe > dave > remembers this better than I do but I think that one of the things we did > as the > IMP got more solid was removed its "loader" [which could boot the machine > from paper tape] and replaced with with something that could live in 20 > words > [which was where the paper tape loader lived: in shadow memory behind the > registers] I think that that code was *just* enough of a bootstrap to > send > message to a neighboring IMP and the first thing that IMP sent over a > smarter > loader that than received a whole memory-full of IMP code from the > neighbor > and then started the neighbor up. I believe we could trigger this > remotely via > DDT and so if the IMP was up but just in need of an updated version it > could > suck it in from its neighbor. > > My opinion is that hacking in this kind of stuff [and piggybacking > "services" on > top of the IMP's 'day job' of handing real host data] helped a lot in the > ARPAnet > being virtually "operational" [and manageable] from the start. > > /Bernie\ > Bernie Cosell > bernie at fantasyfarm.com > -- Too many people; too few sheep -- > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From geoff at iconia.com Sun Sep 6 18:04:38 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 6 Sep 2020 15:04:38 -1000 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> Message-ID: Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs (the TIPs that had a magnetic tape unit attached to them)? yours truly kinda recalls there were perhaps two of them... one being at GWC? why were they created and to whom did they send their data? geoff On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < internet-history at elists.isoc.org> wrote: > I can describe the genesis. The IMP code was originally for one host > computer and several inter-IMP modems (that was what our contract > specified), and I coded the IMP/Host and Host/IMP code for that in > parallel with Bernie coding the DDT, etc. Then some host site wanted a > second host on its IMP -- I think maybe UCLA for its IBM 360. ARPA > called us and asked if the IMP could handle more than one Host. Our > hardware guys said the Honeywell computer could support (if I remember > correctly) up to seven interfaces which could be up to four Host > interfaces or up to four inter-IMP modem interfaces. We looked at the > IMP/Host and Host/IMP code and it seemed fairly easy to make it > reentrant, so we told ARPANET "yes". Once the IMP would know how to > handle multiple Hosts and given there was a bit in the header words > between IMPs and Host to say "real" Host or "fake" Host, the > possibilities were fairly clear. I implemented the reentrant IMP-host > and host-IMP code, and Bernie changed the routines he had written or was > writing: > - TTY in/out > - DDT in/out > - parameter change packets into the IMP and trace packets out of the IMP > - into the IMP to be discarded and statistics packets out of the IMP > For the regular reports from IMPs to the Network Monitoring Center, a > bit of code in the IMP could send packets to a real host; I don't > remember which of the fake Hosts they looked like they were coming from > -- stats maybe. > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > Early on as we were coding the IMP stuff the question arose as to what > to do > > about the TTY [and how the hell were we to debug the damn thing]. We did > > several things in this regard. First I wrote a simple DDT [about as > powerful as > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > around in the > > dead hulk of the code of a stopped system to see what went wrong and > also put > > patches in. I believe it was originally a stand alone - the imp would > crash or hit a > > diagnostic trap and they we could run the DDT and look at buffers and > counters > > and pointers and such and generally try to figure out what happened. > When the > > IMP was running solidly enough [which actually happened pretty early on > in its > > development], I can't remember the genesis of the underlying idea, > but we > > thought we could route the DDT *over* the net to other IMPs and poke at > *then*. > > I came up with a scheme that Will [I think] thought was way too > complicated: > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From dave.walden.family at gmail.com Sun Sep 6 18:15:16 2020 From: dave.walden.family at gmail.com (dave walden) Date: Sun, 6 Sep 2020 21:15:16 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> Message-ID: <5e3546b4-b1f9-b397-ceb8-40e478cb9b7f@gmail.com> See *** below. On 9/6/2020 8:57 PM, the keyboard of geoff goodfellow via Internet-history wrote > How were the first four IMPs (UCLA, SRI, UCSB & UTAH) managed/controlled > until the cross country link to IMP #5 to y'all at BBN was installed? ***phone calls between the host sites and BBN, paper tapes of software updates mailed or hand carried to site, etc > and > What was the length of time the initial 4 ARPANET IMPs "ran" without the > cross country link to IMP #5 in Boston? ***Not long I think.? The original contract ended at the end of 1969 with the installation of the four IMPs done.? It was extended (without a break) for 1970 and maybe beyond -- I remember (maybe) in order to expand the net to 19 IMPs total.? The gating item was likely ARPA ordering the cross-country circuit which the phone company could probably deliver pretty fast.? We already had an IMP at BBN -- maybe the prototype or maybe a development machine -- I don't remember which. > > From bernie at fantasyfarm.com Sun Sep 6 18:21:08 2020 From: bernie at fantasyfarm.com (Bernie Cosell) Date: Sun, 06 Sep 2020 21:21:08 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net>, <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com>, Message-ID: <5F558B04.16472.8410E90@bernie.fantasyfarm.com> On 6 Sep 2020 at 14:57, the keyboard of geoff goodfellow wrote: > How were the first four IMPs (UCLA, SRI, UCSB & UTAH) managed/controlled > until the cross country link > to IMP #5 to y'all at BBN was installed?? > and? > What was the length of time the initial 4 ARPANET IMPs "ran" without the > cross country link to IMP #5 in > Boston? i honestly don't remember -- dave or alex will know when IMP 5 was installed. I remember scanning the 'health reports" pouring out on the TTY. If I had to guess, I'd say we weren't able to do much other than talk on the phone and have someone at the site reload the IMP from the supplied paper tape. /Bernie\ Bernie Cosell bernie at fantasyfarm.com -- Too many people; too few sheep -- From vgcerf at gmail.com Sun Sep 6 20:06:01 2020 From: vgcerf at gmail.com (vinton cerf) Date: Sun, 6 Sep 2020 23:06:01 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> Message-ID: local back up paper tape and phone calls to people to flip switches - eventually a BBN node came up and the boot-from-neighbor code was written. v On Sun, Sep 6, 2020 at 8:58 PM the keyboard of geoff goodfellow via Internet-history wrote: > Bernie, one thing yours truly has always been curious of is when the > ARPANET was initially being rolled out, viz.: > http://som.csudh.edu/fac/lpress/history/arpamaps/press.jpg : > > How were the first four IMPs (UCLA, SRI, UCSB & UTAH) managed/controlled > until the cross country link to IMP #5 to y'all at BBN was installed? > and > What was the length of time the initial 4 ARPANET IMPs "ran" without the > cross country link to IMP #5 in Boston? > > geoff > > On Sun, Sep 6, 2020 at 1:30 PM Bernie Cosell via Internet-history < > internet-history at elists.isoc.org> wrote: > > > Let me add a little bit to Jack's explorations. There are two things of > > interest we > > put in the IMP code that relates to this. The first was the DDT/TTY > > machinery > > and other was the "reload from your neighbor" machinery. > > > > I remember that first quite well, since I mostly designed it [we did > > EVERYTHING as a team so we co?perated and sorted stuff out together] and > I > > implemented it [so I was really responsible for the complicated machinery > > that > > made this aspect of the IMP work]: > > > > Early on as we were coding the IMP stuff the question arose as to what to > > do > > about the TTY [and how the hell were we to debug the damn thing]. We did > > several things in this regard. First I wrote a simple DDT [about as > > powerful as > > the test-word switches on our PDP-1 :o)] but it allowed us to poke around > > in the > > dead hulk of the code of a stopped system to see what went wrong and also > > put > > patches in. I believe it was originally a stand alone - the imp would > > crash or hit a > > diagnostic trap and they we could run the DDT and look at buffers and > > counters > > and pointers and such and generally try to figure out what happened. > When > > the > > IMP was running solidly enough [which actually happened pretty early on > in > > its > > development], I can't remember the genesis of the underlying idea, but > > we > > thought we could route the DDT *over* the net to other IMPs and poke at > > *then*. > > I came up with a scheme that Will [I think] thought was way too > > complicated: > > > > 1) connect the DDT to the IMP as a "fake host", > > &2) connect the TTY to the IMP as another "fake host" > > > > With those now residing *in* the IMP, instead of apart from it we got a > > bunch of > > benefits: > > 1) we could run the DDT *while* the IMP was up doing its thing, and > > 2) we could interrogate a *different* IMPs DDT [simply by pointing the > > TTY to > > the appropriate fake host on the other IMP. > > 3) We could "IM" between machines [simply by pointing the TTY to the > > *TTY* > > on the other machine. > > > > [on (3) that ability was very handy as Ben and Marty were bringing up > IMPs > > 1&2. > > They knew, for example, long before any of the host interface and > > machinery was > > working, that the IMP was doing just fine, since they could exchange > > messages > > and *knew* it used the same code that the hosts would be using. It also > > replaced > > lots of long-distance calls to co?rdinate what was happening at SRI and > > UCLA] > > > > WE also had the IMPs send "health reports" [via a background process] and > > they > > were hard wired to send to the IMP 5 TTY and so virtually from the outset > > we > > could monitor [and with the DDT tweak] the whole network. Until the > > PDP-1 > > was online it chewed up a fair bit of paper :o) > > > > It was all using the basic IMP packet-handling machinery, so that two > IMPs > > could be poking the DDT on a particular IMP and not interfere with one > > another. > > When the PDP-1 came online as the first proto-NCC, the DDT was as happy > to > > talk to a real host as one of its fake brethrens and ditto for the > "health > > reports" > > that just changed which host they were going to and it all worked. So > > everything > > was fitting together very nicely and very usefully [despite the > > complicated code] > > > > A conceptually neat part about all this is that the *internals* of the > IMP > > were > > host-agnostic. They didn't care if they were fake or real, they just > > sent the > > packets where there were supposed to go. and so we could implement > > "satellite" > > activities that used the underlying IMP code to do other useful things > > beyond > > just host-to-host. > > > > Expanding this principle a few years later, we had a H316 that had *two* > > 16k > > banks. [and I think I've mentioned this before on this list]. We > decided > > to > > implement the TIP as, what else?? :o), a host. But in this case it was a > > pseudo-real-host [as I've mentioned before] this was done so that the > TIP > > code > > could live in the upper memory bank and its "host interface" transferred > > data and > > control across the boundary. The IMP didn't need to know or care that > the > > TIP > > was there. > > > > Phew. now to the second mechanism: reloading from a neighbor. Maybe > > dave > > remembers this better than I do but I think that one of the things we did > > as the > > IMP got more solid was removed its "loader" [which could boot the machine > > from paper tape] and replaced with with something that could live in 20 > > words > > [which was where the paper tape loader lived: in shadow memory behind the > > registers] I think that that code was *just* enough of a bootstrap to > > send > > message to a neighboring IMP and the first thing that IMP sent over a > > smarter > > loader that than received a whole memory-full of IMP code from the > > neighbor > > and then started the neighbor up. I believe we could trigger this > > remotely via > > DDT and so if the IMP was up but just in need of an updated version it > > could > > suck it in from its neighbor. > > > > My opinion is that hacking in this kind of stuff [and piggybacking > > "services" on > > top of the IMP's 'day job' of handing real host data] helped a lot in the > > ARPAnet > > being virtually "operational" [and manageable] from the start. > > > > /Bernie\ > > Bernie Cosell > > bernie at fantasyfarm.com > > -- Too many people; too few sheep -- > > > > > > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From b_a_denny at yahoo.com Sun Sep 6 23:44:38 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Mon, 7 Sep 2020 06:44:38 +0000 (UTC) Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3 kitty.org> Message-ID: <1779558001.912243.1599461078378@mail.yahoo.com> Because of BBN's involvement, I am thinking Packet Radio might have reused many of? the same ideas as the IMPs for loading new software from another node. Do you know this was not the case?? I never needed to look at that part of the code.? I remember using XNET for examination of the Packet Radio station. Given your recent email it sounds like you looked for old Packet Radio station software and couldn't find it. Is this correct?? I don't think Rockwell released their Packet Radio software in the late 70s/early 80s. I would have to contact Rockwell if I thought bugs required a change to a packet radio, versus the Packet Radio station, when I worked at BBN. I know several years later SRI did get some of their code? because I implemented one of the new routing algorithms ( I am pretty sure it was called threshold distance vector routing if anyone is interested). BTW, I think the software may have only been tested in a simulator due to delays in the delivery of the LPR (Low Cost Packet Radio). This was during the SURAN program.? The first demo of Packet Radio and ARPANET in 1976 involved submitting the status report.? Don Nielson would probably remember if that was done through anything like email. Below is a link to an article that discusses this event. The text from the article mentions email but more importantly it has a link to a podcast with Don. I didn't know this podcast existed so I still need to listen to it.? I can see why you might think the report submission may have been done by using a telnet connection to a SRI host that had email.? https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ barbara? On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via Internet-history wrote: Hi Geoff - thanks for that bit of history and kudos!? I think there's an Internet connection in your experience.? I'm not sure what, legally, "wireless email" means.? But I suspect that email was being sent and received, wirelessly, well before even 1982, if only to and from the SRI Packet Radio van that could occasionally be seen then roaming around the Bay Area. Of course, technically, that probably involved a Telnet connection, wirelessly, to some PDP-10 running an email program.?? But, legally, it might meet the court accepted definition of "wireless email". ? I learned from the lawyers that much of litigation involves arguing about the meaning of words and phrases. So, perhaps someone could have looked for mouldering Packet Radio (aka PR) hardware and software, and demonstrated wireless email circa 1978 over one or more PRNETs. Sadly, although I was pretty sure that interesting "prior art" would be found in the PR environment, we had little success 7 years ago while trying to find anything that might show exactly how PR equipment "downloaded instructions".?? There's remarkably little readily discoverable material about lots of the computer and network systems of the 70s/80s, especially internal details of operation, tools, procedures, etc.?? Plenty of stuff on Routing, but little on other mechanisms, or other types of networks of that era, at least that the lawyers and I could find.?? IMHO, that's a huge gap even in Internet History, since the Internet did not evolve in a vacuum, was itself composed of more than the ARPANET, and was surrounded by competitors (remember multiprotocol routers). /Jack On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > Jack, you're a Most Eloquent purveyor of history and that WHY explain > is exactly what yours truly was hoping for... Thank You for the > elucidation! :D > > along the lines vis-a-vis: > >? ? So, that's a bit about the "Why", for history to ponder.? The >? ? experience got me wondering about the "patent history" of The >? ? Internet.? Clearly there was a lot of innovation in those days.? >? ? My recollection is that very little was patented, even if only to >? ? make sure no one else could.? Maybe someone will document the >? ? patent-related aspects of Internet History someday. > > please excuse/pardon this immodesty: yours truly had a kinda similar > "lawyered" experience with respect to WHO was the purported > "inventor"/originator of wireless email in a patent litigation case > and the "challenge" of finding/presenting any extant legally > submissive "artifactual?proof" to that effect -- for which John > Markoff at the New York Times wrote about in this 2006 article: > > In Silicon Valley, a Man Without a Patent > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > > for which some links of "proof" exist -- for some stuff mentioned in > the above NYT article -- on my website?https://iconia.com/?under > "wireless email" (in case any historians are duly interested)...? > > geoff > > On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > wrote: > >? ? Geoff, > >? ? Dave's IEEE paper does an excellent job of the >? ? Who/What/When/Where.? He's right that it was about 7 years ago.?? >? ? Time flies... but I guess it's still "recent" when viewed as part >? ? of Internet History. > >? ? For the curious, I can add a bit more about the Why. > >? ? Sometime in 2013, I got an email out of the blue from Charlie >? ? Neuhauser, someone I didn't recognize or remember at all, asking >? ? if I was the "Jack Haverty" who authored IEN 158 - documenting the >? ? XNET protocol in 1980.?? Figuring that the statute of limitations >? ? must have expired after 30+ years, I cautiously said yes.? Over >? ? the next few days, he hooked me up with the lawyers who were >? ? involved in a patent dispute - one that had been going on for >? ? several decades by then.? In fact, the patent involved had been >? ? issued, ran its 17 year lifetime, and expired, but there was still >? ? litigation in process about whether or not the patent was valid, >? ? and 17 years of violations were alleged cause for compensation in >? ? the many millions. ? For the next few years I was involved in the >? ? battles, working with the lawyers scattered all over the country.? >? ? I never met any of them.? All our work was done by email and >? ? telephone.?? No Zoom then or we probably would have used it. > >? ? The core issue in the patent battle concerned "downloading >? ? instructions", mechanisms such as would be involved in patching or >? ? issuing new software releases to remote equipment.?? XNET seemed >? ? to them to possibly have something to do with that, hence the >? ? interest.? The goal was to find hard evidence that such procedures >? ? were being done by 1980, which would prove that prior art >? ? existed.? Hard evidence literally means "hard" - opinions help, >? ? but physical equipment and running code is much more impressive in >? ? a courtroom. > >? ? They hadn't found any XNET artifacts, and I couldn't point them to >? ? any surviving implementations.?? But I pointed out that my XNET >? ? document simply captured the technology that we "stole" from the >? ? ARPANET IMP experience, and that the IMPs routinely "downloaded >? ? code" from their neighbors and the NOC all during the life of the >? ? ARPANET. > >? ? Since the IMPs had existed since the early 70s, that really >? ? sparked their interest, and a search (worldwide) ensued to find >? ? old IMPs, in the hope that just maybe one of them still had the >? ? IMP software in its magnetic-core memory.? A few IMPs were >? ? located, but none were functional.? The one in the museum at UCLA >? ? seemed promising, but the owners were reluctant to even hook it up >? ? to power after sitting idle for so many years, expecting it might >? ? go up in smoke. > >? ? Then I learned from the BBN alumni mailing list that an ancient >? ? IMP listing had been found in a basement.?? The story from that >? ? point is pretty well described in Dave's paper. > >? ? Personally, it was an interesting experience.? I worked >? ? extensively with one lawyer in San Diego.? I taught him how >? ? computers and networks actually work; he taught me a lot about the >? ? legal system regarding patents.?? IMHO, they are equally >? ? convoluted and complex when viewed from the other's perspective. > >? ? I also learned a lot about the IMP code, which I had never even >? ? looked at while I was at BBN.? One task I took on was to >? ? exhaustively analyze the parts of the IMP code that implemented >? ? the "download new instructions" functionality, writing up an >? ? instruction-by-instruction description of how the code >? ? accomplished that by interacting with a neighboring IMP.?? It was >? ? a very clever design, and extremely tight code, even including >? ? self-modifying instructions.?? Not easy to figure out (or explain >? ? in language amenable to a non-technical judge or jury).? So there >? ? was great interest in being able to demonstrate the code in action >? ? using real software from the 70s and hardware simulators.?? >? ? Tangible evidence is much better than even expert opinions. > >? ? The whole legal project came to a sudden end just a few months >? ? prior to the first court date.??? I was looking forward to going >? ? to Delaware (legal action was filed in Federal court in Delaware), >? ? and finally meeting some of the people.?? But the parties settled >? ? suddenly, the case was dropped, and AFAIK the patent question was >? ? never resolved.?? > >? ? So, that's a bit about the "Why", for history to ponder.??? The >? ? experience got me wondering about the "patent history" of The >? ? Internet.?? Clearly there was a lot of innovation in those days.?? >? ? My recollection is that very little was patented, even if only to >? ? make sure no one else could.?? Maybe someone will document the >? ? patent-related aspects of Internet History someday. > >? ? /Jack Haverty > > > >? ? On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: >>? ? jack, you've raised my curiosity with respect to: >> >>? ? ? ? ... There >>? ? ? ? *is* ARPANET IMP software which was recently restored and a small >>? ? ? ? ARPANET was run using simulated IMP hardware. >> >>? ? Who/What/When/Where/Why? >> >>? ? geoff >> >>? ? On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history >>? ? >? ? > wrote: >> >>? ? ? ? Lukasz, >> >>? ? ? ? I think that the earliest implementations of TTL called it >>? ? ? ? "Time", but >>? ? ? ? I'm not aware that anyone actually used time per se in >>? ? ? ? gateways, at >>? ? ? ? least in the early days (1977-1982 or so).? >> >>? ? ? ? TCP implementations didn't do anything with TTL other than >>? ? ? ? set it on >>? ? ? ? outgoing datagrams, and at least in my implementation (TCP >>? ? ? ? for Unix), it >>? ? ? ? was just set to some arbitrary value.? Until we had some data >>? ? ? ? from >>? ? ? ? experimentation it was hard to evaluate ideas about what >>? ? ? ? routers, hosts, >>? ? ? ? et al should actually do.?? The early TCPs did use time in >>? ? ? ? handling >>? ? ? ? retransmission timers, and there was work a bit later to >>? ? ? ? incorporate >>? ? ? ? time more powerfully into TCP behavior, e.g., Van Jacobson's >>? ? ? ? work. >> >>? ? ? ? The early gateways, IIRC, used the terminology "time", but in >>? ? ? ? practice >>? ? ? ? used just hop counts, since time measurements were difficult to >>? ? ? ? implement.?? The exception to that may be Dave Mills' >>? ? ? ? Fuzzballs, since >>? ? ? ? Dave was the implementor most interested in time and making >>? ? ? ? precise >>? ? ? ? measurements of network behavior.?? I *think* Dave may have >>? ? ? ? used time >>? ? ? ? values and delay-based routing amongst his "fuzzies". >> >>? ? ? ? The BBN doc you're seeking might have been one of many that >>? ? ? ? discussed >>? ? ? ? the ARPANET internal mechanisms, e.g., ones with titles like >>? ? ? ? "Routing >>? ? ? ? Algorithm Improvements".? The ARPANET internal mechanisms did >>? ? ? ? use time.? >>? ? ? ? It was fairly simple in the IMPs, since the delay introduced >>? ? ? ? by the >>? ? ? ? synchronous communications lines could be easily predicted, >>? ? ? ? and the >>? ? ? ? other major component of delay was the time spent in queues, >>? ? ? ? which could >>? ? ? ? be measured fairly easily.?? >> >>? ? ? ? I even found one BBN ARPANET Project QTR from circa 1975 that >>? ? ? ? discussed >>? ? ? ? the merits of the new-fangled TCP proposal that some >>? ? ? ? professor had >>? ? ? ? published -- and seemed to conclude it couldn't possibly work. >> >>? ? ? ? My involvement in implementations of TCPs and gateways lasted >>? ? ? ? through >>? ? ? ? about mid-1983, so I don't know much of the detail of subsequent >>? ? ? ? implementations.? For the various BBN gateway/router >>? ? ? ? equipment, Bob >>? ? ? ? Hinden would probably be a good source.? The other major >>? ? ? ? early player >>? ? ? ? was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will >>? ? ? ? remember.?? There's also at least one paper on the Fuzzballs >>? ? ? ? which may >>? ? ? ? have some details. >> >>? ? ? ? One thing I'd advise being careful of is the various >>? ? ? ? "specifications" in >>? ? ? ? RFCs.? Much of the wording in those was intentionally >>? ? ? ? non-prescriptive >>? ? ? ? (use of "should" or "may" instead of "must"), to provide as much >>? ? ? ? latitude as possible for experimentation with new ideas, >>? ? ? ? especially >>? ? ? ? within an AS.?? The Internet was an Experiment. >> >>? ? ? ? Also, there was no consistent enforcement mechanism to assure >>? ? ? ? that >>? ? ? ? implementations actually even conformed to the "must" >>? ? ? ? elements.?? So >>? ? ? ? Reality could be very different from Specification. >> >>? ? ? ? I don't know of any gateway implementations that have >>? ? ? ? survived.?? There >>? ? ? ? *is* ARPANET IMP software which was recently restored and a small >>? ? ? ? ARPANET was run using simulated IMP hardware.?? I still have >>? ? ? ? a ~1979 >>? ? ? ? listing of the TCP I wrote for Unix, but haven't scanned it >>? ? ? ? into digital >>? ? ? ? form yet. >> >>? ? ? ? Jack >> >>? ? ? ? On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: >>? ? ? ? > Jack, >>? ? ? ? > >>? ? ? ? > I was reading a lot of old BBN PDFs thanks to all good souls on >>? ? ? ? > this list that post nice URLs from time to time. >>? ? ? ? > >>? ? ? ? > I remember reading in at least one of them, that apparently >>? ? ? ? first >>? ? ? ? > TCP/IP implementations were indeed using TTL as literally >>? ? ? ? ?time?, >>? ? ? ? > not hop count. I believe there somewhere there between PDP docs >>? ? ? ? > and ARPANET docs I?ve read something to the effect ?and >>? ? ? ? from this >>? ? ? ? > time we changed from measuring time to simply count routing >>? ? ? ? hops?. >>? ? ? ? > Of course, right now google-fu is failing me. >>? ? ? ? > >>? ? ? ? > Quoting RFC 1009 that was already brought up, there?s quite >>? ? ? ? > direct ?definition? of the field: >>? ? ? ? > >>? ? ? ? > "4.8.? Time-To-Live >>? ? ? ? > >>? ? ? ? >? The Time-to-Live (TTL) field of the IP header is defined >>? ? ? ? to be a >>? ? ? ? >? timer limiting the lifetime of a datagram in the >>? ? ? ? Internet.? It is >>? ? ? ? >? an 8-bit field and the units are seconds.? This would >>? ? ? ? imply that >>? ? ? ? >? for a maximum TTL of 255 a datagram would time-out after >>? ? ? ? about 4 >>? ? ? ? >? and a quarter minutes.? Another aspect of the definition >>? ? ? ? requires >>? ? ? ? >? each gateway (or other module) that handles a datagram to >>? ? ? ? >? decrement the TTL by at least one, even if the elapsed >>? ? ? ? time was >>? ? ? ? >? much less than a second.? Since this is very often the >>? ? ? ? case, the >>? ? ? ? >? TTL effectively becomes a hop count limit on how far a >>? ? ? ? datagram >>? ? ? ? >? can propagate through the Internet." >>? ? ? ? > >>? ? ? ? > Were there any implementations that survived somewhere and >>? ? ? ? actually >>? ? ? ? > did exactly that - counted actual time/processing delay, >>? ? ? ? not hops? >>? ? ? ? > And if it took 2s to process packet, did they really >>? ? ? ? decrement TTL >>? ? ? ? > by two? >>? ? ? ? > >>? ? ? ? > Thanks for any pointers, >> >>? ? ? ? -- >>? ? ? ? Internet-history mailing list >>? ? ? ? Internet-history at elists.isoc.org >>? ? ? ? >>? ? ? ? https://elists.isoc.org/mailman/listinfo/internet-history >> >> >> >>? ? -- >>? ? Geoff.Goodfellow at iconia.com >>? ? living as The Truth is True >> >> >> > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From vint at google.com Mon Sep 7 04:13:43 2020 From: vint at google.com (Vint Cerf) Date: Mon, 7 Sep 2020 07:13:43 -0400 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: <1779558001.912243.1599461078378@mail.yahoo.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> Message-ID: Packet Radios were developed by Collins Radio. I do not recall that they downloaded from neighbors. As to the 1976 report, there was a famous test from Rosati's. There was an LSI-11 "terminal" connected to a packet radio. My guess is that they would have just TELNETTED into a PDP-10 at SRI and delivered the report that way. I doubt that they had email running in the LSI-11. v On Mon, Sep 7, 2020 at 2:47 AM Barbara Denny via Internet-history < internet-history at elists.isoc.org> wrote: > Because of BBN's involvement, I am thinking Packet Radio might have > reused many of the same ideas as the IMPs for loading new software from > another node. Do you know this was not the case? I never needed to look at > that part of the code. > I remember using XNET for examination of the Packet Radio station. Given > your recent email it sounds like you looked for old Packet Radio station > software and couldn't find it. Is this correct? > I don't think Rockwell released their Packet Radio software in the late > 70s/early 80s. I would have to contact Rockwell if I thought bugs required > a change to a packet radio, versus the Packet Radio station, when I worked > at BBN. I know several years later SRI did get some of their code because > I implemented one of the new routing algorithms ( I am pretty sure it was > called threshold distance vector routing if anyone is interested). BTW, I > think the software may have only been tested in a simulator due to delays > in the delivery of the LPR (Low Cost Packet Radio). This was during the > SURAN program. > The first demo of Packet Radio and ARPANET in 1976 involved submitting the > status report. Don Nielson would probably remember if that was done > through anything like email. Below is a link to an article that discusses > this event. The text from the article mentions email but more importantly > it has a link to a podcast with Don. I didn't know this podcast existed so > I still need to listen to it. I can see why you might think the report > submission may have been done by using a telnet connection to a SRI host > that had email. > > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > barbara > On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via > Internet-history wrote: > > Hi Geoff - thanks for that bit of history and kudos! > > I think there's an Internet connection in your experience. I'm not sure > what, legally, "wireless email" means. But I suspect that email was > being sent and received, wirelessly, well before even 1982, if only to > and from the SRI Packet Radio van that could occasionally be seen then > roaming around the Bay Area. > > Of course, technically, that probably involved a Telnet connection, > wirelessly, to some PDP-10 running an email program. But, legally, it > might meet the court accepted definition of "wireless email". I > learned from the lawyers that much of litigation involves arguing about > the meaning of words and phrases. > > So, perhaps someone could have looked for mouldering Packet Radio (aka > PR) hardware and software, and demonstrated wireless email circa 1978 > over one or more PRNETs. > > Sadly, although I was pretty sure that interesting "prior art" would be > found in the PR environment, we had little success 7 years ago while > trying to find anything that might show exactly how PR equipment > "downloaded instructions". > > There's remarkably little readily discoverable material about lots of > the computer and network systems of the 70s/80s, especially internal > details of operation, tools, procedures, etc. Plenty of stuff on > Routing, but little on other mechanisms, or other types of networks of > that era, at least that the lawyers and I could find. IMHO, that's a > huge gap even in Internet History, since the Internet did not evolve in > a vacuum, was itself composed of more than the ARPANET, and was > surrounded by competitors (remember multiprotocol routers). > > /Jack > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > > Jack, you're a Most Eloquent purveyor of history and that WHY explain > > is exactly what yours truly was hoping for... Thank You for the > > elucidation! :D > > > > along the lines vis-a-vis: > > > > So, that's a bit about the "Why", for history to ponder. The > > experience got me wondering about the "patent history" of The > > Internet. Clearly there was a lot of innovation in those days. > > My recollection is that very little was patented, even if only to > > make sure no one else could. Maybe someone will document the > > patent-related aspects of Internet History someday. > > > > please excuse/pardon this immodesty: yours truly had a kinda similar > > "lawyered" experience with respect to WHO was the purported > > "inventor"/originator of wireless email in a patent litigation case > > and the "challenge" of finding/presenting any extant legally > > submissive "artifactual proof" to that effect -- for which John > > Markoff at the New York Times wrote about in this 2006 article: > > > > In Silicon Valley, a Man Without a Patent > > > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > > > > for which some links of "proof" exist -- for some stuff mentioned in > > the above NYT article -- on my website https://iconia.com/ under > > "wireless email" (in case any historians are duly interested)... > > > > geoff > > > > On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > > wrote: > > > > Geoff, > > > > Dave's IEEE paper does an excellent job of the > > Who/What/When/Where . > He's right that it was about 7 years ago. > > Time flies... but I guess it's still "recent" when viewed as part > > of Internet History. > > > > For the curious, I can add a bit more about the Why. > > > > Sometime in 2013, I got an email out of the blue from Charlie > > Neuhauser, someone I didn't recognize or remember at all, asking > > if I was the "Jack Haverty" who authored IEN 158 - documenting the > > XNET protocol in 1980. Figuring that the statute of limitations > > must have expired after 30+ years, I cautiously said yes. Over > > the next few days, he hooked me up with the lawyers who were > > involved in a patent dispute - one that had been going on for > > several decades by then. In fact, the patent involved had been > > issued, ran its 17 year lifetime, and expired, but there was still > > litigation in process about whether or not the patent was valid, > > and 17 years of violations were alleged cause for compensation in > > the many millions. For the next few years I was involved in the > > battles, working with the lawyers scattered all over the country. > > I never met any of them. All our work was done by email and > > telephone. No Zoom then or we probably would have used it. > > > > The core issue in the patent battle concerned "downloading > > instructions", mechanisms such as would be involved in patching or > > issuing new software releases to remote equipment. XNET seemed > > to them to possibly have something to do with that, hence the > > interest. The goal was to find hard evidence that such procedures > > were being done by 1980, which would prove that prior art > > existed. Hard evidence literally means "hard" - opinions help, > > but physical equipment and running code is much more impressive in > > a courtroom. > > > > They hadn't found any XNET artifacts, and I couldn't point them to > > any surviving implementations. But I pointed out that my XNET > > document simply captured the technology that we "stole" from the > > ARPANET IMP experience, and that the IMPs routinely "downloaded > > code" from their neighbors and the NOC all during the life of the > > ARPANET. > > > > Since the IMPs had existed since the early 70s, that really > > sparked their interest, and a search (worldwide) ensued to find > > old IMPs, in the hope that just maybe one of them still had the > > IMP software in its magnetic-core memory. A few IMPs were > > located, but none were functional. The one in the museum at UCLA > > seemed promising, but the owners were reluctant to even hook it up > > to power after sitting idle for so many years, expecting it might > > go up in smoke. > > > > Then I learned from the BBN alumni mailing list that an ancient > > IMP listing had been found in a basement. The story from that > > point is pretty well described in Dave's paper. > > > > Personally, it was an interesting experience. I worked > > extensively with one lawyer in San Diego. I taught him how > > computers and networks actually work; he taught me a lot about the > > legal system regarding patents. IMHO, they are equally > > convoluted and complex when viewed from the other's perspective. > > > > I also learned a lot about the IMP code, which I had never even > > looked at while I was at BBN. One task I took on was to > > exhaustively analyze the parts of the IMP code that implemented > > the "download new instructions" functionality, writing up an > > instruction-by-instruction description of how the code > > accomplished that by interacting with a neighboring IMP. It was > > a very clever design, and extremely tight code, even including > > self-modifying instructions. Not easy to figure out (or explain > > in language amenable to a non-technical judge or jury). So there > > was great interest in being able to demonstrate the code in action > > using real software from the 70s and hardware simulators. > > Tangible evidence is much better than even expert opinions. > > > > The whole legal project came to a sudden end just a few months > > prior to the first court date. I was looking forward to going > > to Delaware (legal action was filed in Federal court in Delaware), > > and finally meeting some of the people. But the parties settled > > suddenly, the case was dropped, and AFAIK the patent question was > > never resolved. > > > > So, that's a bit about the "Why", for history to ponder. The > > experience got me wondering about the "patent history" of The > > Internet. Clearly there was a lot of innovation in those days. > > My recollection is that very little was patented, even if only to > > make sure no one else could. Maybe someone will document the > > patent-related aspects of Internet History someday. > > > > /Jack Haverty > > > > > > > > On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > >> jack, you've raised my curiosity with respect to: > >> > >> ... There > >> *is* ARPANET IMP software which was recently restored and a small > >> ARPANET was run using simulated IMP hardware. > >> > >> Who/What/When/Where/Why > ? > >> > >> geoff > >> > >> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history > >> >> > wrote: > >> > >> Lukasz, > >> > >> I think that the earliest implementations of TTL called it > >> "Time", but > >> I'm not aware that anyone actually used time per se in > >> gateways, at > >> least in the early days (1977-1982 or so). > >> > >> TCP implementations didn't do anything with TTL other than > >> set it on > >> outgoing datagrams, and at least in my implementation (TCP > >> for Unix), it > >> was just set to some arbitrary value. Until we had some data > >> from > >> experimentation it was hard to evaluate ideas about what > >> routers, hosts, > >> et al should actually do. The early TCPs did use time in > >> handling > >> retransmission timers, and there was work a bit later to > >> incorporate > >> time more powerfully into TCP behavior, e.g., Van Jacobson's > >> work. > >> > >> The early gateways, IIRC, used the terminology "time", but in > >> practice > >> used just hop counts, since time measurements were difficult to > >> implement. The exception to that may be Dave Mills' > >> Fuzzballs, since > >> Dave was the implementor most interested in time and making > >> precise > >> measurements of network behavior. I *think* Dave may have > >> used time > >> values and delay-based routing amongst his "fuzzies". > >> > >> The BBN doc you're seeking might have been one of many that > >> discussed > >> the ARPANET internal mechanisms, e.g., ones with titles like > >> "Routing > >> Algorithm Improvements". The ARPANET internal mechanisms did > >> use time. > >> It was fairly simple in the IMPs, since the delay introduced > >> by the > >> synchronous communications lines could be easily predicted, > >> and the > >> other major component of delay was the time spent in queues, > >> which could > >> be measured fairly easily. > >> > >> I even found one BBN ARPANET Project QTR from circa 1975 that > >> discussed > >> the merits of the new-fangled TCP proposal that some > >> professor had > >> published -- and seemed to conclude it couldn't possibly work. > >> > >> My involvement in implementations of TCPs and gateways lasted > >> through > >> about mid-1983, so I don't know much of the detail of subsequent > >> implementations. For the various BBN gateway/router > >> equipment, Bob > >> Hinden would probably be a good source. The other major > >> early player > >> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will > >> remember. There's also at least one paper on the Fuzzballs > >> which may > >> have some details. > >> > >> One thing I'd advise being careful of is the various > >> "specifications" in > >> RFCs. Much of the wording in those was intentionally > >> non-prescriptive > >> (use of "should" or "may" instead of "must"), to provide as much > >> latitude as possible for experimentation with new ideas, > >> especially > >> within an AS. The Internet was an Experiment. > >> > >> Also, there was no consistent enforcement mechanism to assure > >> that > >> implementations actually even conformed to the "must" > >> elements. So > >> Reality could be very different from Specification. > >> > >> I don't know of any gateway implementations that have > >> survived. There > >> *is* ARPANET IMP software which was recently restored and a small > >> ARPANET was run using simulated IMP hardware. I still have > >> a ~1979 > >> listing of the TCP I wrote for Unix, but haven't scanned it > >> into digital > >> form yet. > >> > >> Jack > >> > >> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > >> > Jack, > >> > > >> > I was reading a lot of old BBN PDFs thanks to all good souls on > >> > this list that post nice URLs from time to time. > >> > > >> > I remember reading in at least one of them, that apparently > >> first > >> > TCP/IP implementations were indeed using TTL as literally > >> ?time?, > >> > not hop count. I believe there somewhere there between PDP docs > >> > and ARPANET docs I?ve read something to the effect ?and > >> from this > >> > time we changed from measuring time to simply count routing > >> hops?. > >> > Of course, right now google-fu is failing me. > >> > > >> > Quoting RFC 1009 that was already brought up, there?s quite > >> > direct ?definition? of the field: > >> > > >> > "4.8. Time-To-Live > >> > > >> > The Time-to-Live (TTL) field of the IP header is defined > >> to be a > >> > timer limiting the lifetime of a datagram in the > >> Internet. It is > >> > an 8-bit field and the units are seconds. This would > >> imply that > >> > for a maximum TTL of 255 a datagram would time-out after > >> about 4 > >> > and a quarter minutes. Another aspect of the definition > >> requires > >> > each gateway (or other module) that handles a datagram to > >> > decrement the TTL by at least one, even if the elapsed > >> time was > >> > much less than a second. Since this is very often the > >> case, the > >> > TTL effectively becomes a hop count limit on how far a > >> datagram > >> > can propagate through the Internet." > >> > > >> > Were there any implementations that survived somewhere and > >> actually > >> > did exactly that - counted actual time/processing delay, > >> not hops? > >> > And if it took 2s to process packet, did they really > >> decrement TTL > >> > by two? > >> > > >> > Thanks for any pointers, > >> > >> -- > >> Internet-history mailing list > >> Internet-history at elists.isoc.org > >> > >> https://elists.isoc.org/mailman/listinfo/internet-history > >> > >> > >> > >> -- > >> Geoff.Goodfellow at iconia.com > >> living as The Truth is True > >> > >> > >> > > > > > > > > -- > > Geoff.Goodfellow at iconia.com > > living as The Truth is True > > > > > > > > -- > 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 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From jnc at mercury.lcs.mit.edu Mon Sep 7 07:14:20 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 7 Sep 2020 10:14:20 -0400 (EDT) Subject: [ih] Exterior Gateway Protocol Message-ID: <20200907141420.EC91A18C090@mercury.lcs.mit.edu> Wow, you all have been sending a lot of email. Let me package a few replies together, to minimize my list traffic. > From: Joseph Touch > Can you tell us more about what part of BGP's use of TCP was > controversial at the time? I don't directly remember what the concerns were, but I think I can probably re-create them. (Jack Haverty's comments are very epropos too.) At the time it was generally held in the OS field (where most of us had come from - networking was just getting started as a distinct field) that dependency loops among subsystems (i.e. subsystem A calls on B, which calls on C, which in turn calls on A) were bad. Some people may have had issues with provability (which was somewhat popular at the time), but I think for a lot of people, it was just more a general sense that i) it made it hard to fully understand how the system worked, and ii) it could give rise to problems, e.g. deadlocks. A good sense of the thinking on the topic can be found in Dave Reed's master's there, "Processor Multiplexing in a Layered Operating System": http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-164.pdf from 1976. It is mostly concerned with a dependency loop between processes/process-switching and virtual memory (some of the OS's process state may be paged; and paging may have to call on process switching when a process is paused for a page fault), but has a good overview of the contemporary thinking about dependency loops. Running BGP on top of TCP brings in the same kind of relationship: BGP is in some sense 'part of' the internetworking layer, and TCP is definitely a client of that layer, so running BGP on top of TCP is, de facto, a dependency loop - at least from a _subsystem structural_ viewpoint. In actual practise, problems are generally avoided by avoiding _operational_ dependency loops: e.g. IBGP does depend on the IGP to get packets between border routers of the AS, but that just means that EGP depends on the IGP, as it always did. And for EGP between border routers of two AS's, they must be on a common network, i.e. no routing needed. However, I believe that most people were made uneasy by the subsystem structural dependency loop of BGP on TCP. We'd had some experience of successfuly working with subsystem _structural_ dependency loops, with ICMP (which is in theory part of the internetwork layer) running on top of IP, without any major problems operationally _in the use cases which we had for it_ (which did not generally involve _operational_ dependency loops). That gave us confidence that the BGP on TCP case was probably workable (as long as we avoided _operational_ dependency loops), but at the same time we did know that we were pushing the envelope. Then again, the entire packet communication field was pushing the envelope, as the Bell people were always happy to remind us, so we held our breath and jumped! > From me: > I think in a really large network, doing congestion avoidance in one > subsystem, long with path selection, is not workable. I think it should > be done separately Of course, I doubt we'll ever do congestion avoidance (i.e. dynamically use an alternate path); these days the style seems to be to add bandwidth on gongested paths. > From: Scott Brim >> I have this vague memory that Scott Brim may have been at an FGP >> kick-off meeting > Either the first or the second. It was the third IETF. The meeting I am vaguely remembering was at Proteon. NOel From steve at shinkuro.com Mon Sep 7 07:41:31 2020 From: steve at shinkuro.com (Steve Crocker) Date: Mon, 7 Sep 2020 10:41:31 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: <20200907141420.EC91A18C090@mercury.lcs.mit.edu> References: <20200907141420.EC91A18C090@mercury.lcs.mit.edu> Message-ID: Related to but not quite the same as provability is the cold start problem. If there are layer violations, it?s not possible to restart the system from scratch layer by layer. Fortunately, the entire system is big enough that it doesn?t crash completely. Sent from my iPhone > On Sep 7, 2020, at 10:14 AM, Noel Chiappa via Internet-history wrote: > > ?Wow, you all have been sending a lot of email. Let me package a few replies > together, to minimize my list traffic. > >> From: Joseph Touch > >> Can you tell us more about what part of BGP's use of TCP was >> controversial at the time? > > I don't directly remember what the concerns were, but I think I can probably > re-create them. (Jack Haverty's comments are very epropos too.) > > At the time it was generally held in the OS field (where most of us had come > from - networking was just getting started as a distinct field) that > dependency loops among subsystems (i.e. subsystem A calls on B, which > calls on C, which in turn calls on A) were bad. > > Some people may have had issues with provability (which was somewhat popular > at the time), but I think for a lot of people, it was just more a general > sense that i) it made it hard to fully understand how the system worked, and > ii) it could give rise to problems, e.g. deadlocks. > > A good sense of the thinking on the topic can be found in Dave Reed's > master's there, "Processor Multiplexing in a Layered Operating System": > > http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-164.pdf > > from 1976. It is mostly concerned with a dependency loop between > processes/process-switching and virtual memory (some of the OS's process state > may be paged; and paging may have to call on process switching when a process > is paused for a page fault), but has a good overview of the contemporary > thinking about dependency loops. > > Running BGP on top of TCP brings in the same kind of relationship: BGP is in > some sense 'part of' the internetworking layer, and TCP is definitely a > client of that layer, so running BGP on top of TCP is, de facto, a dependency > loop - at least from a _subsystem structural_ viewpoint. > > In actual practise, problems are generally avoided by avoiding _operational_ > dependency loops: e.g. IBGP does depend on the IGP to get packets between > border routers of the AS, but that just means that EGP depends on the IGP, as > it always did. And for EGP between border routers of two AS's, they must be > on a common network, i.e. no routing needed. > > However, I believe that most people were made uneasy by the subsystem > structural dependency loop of BGP on TCP. We'd had some experience of > successfuly working with subsystem _structural_ dependency loops, with ICMP > (which is in theory part of the internetwork layer) running on top of IP, > without any major problems operationally _in the use cases which we had for > it_ (which did not generally involve _operational_ dependency loops). > > That gave us confidence that the BGP on TCP case was probably workable (as > long as we avoided _operational_ dependency loops), but at the same time we > did know that we were pushing the envelope. Then again, the entire packet > communication field was pushing the envelope, as the Bell people were always > happy to remind us, so we held our breath and jumped! > > >> From me: > >> I think in a really large network, doing congestion avoidance in one >> subsystem, long with path selection, is not workable. I think it should >> be done separately > > Of course, I doubt we'll ever do congestion avoidance (i.e. dynamically use > an alternate path); these days the style seems to be to add bandwidth on > gongested paths. > > >> From: Scott Brim > >>> I have this vague memory that Scott Brim may have been at an FGP >>> kick-off meeting > >> Either the first or the second. It was the third IETF. > > The meeting I am vaguely remembering was at Proteon. > > NOel > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From amckenzie3 at yahoo.com Mon Sep 7 07:51:36 2020 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Mon, 7 Sep 2020 14:51:36 +0000 (UTC) Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> Message-ID: <646228068.4006926.1599490296622@mail.yahoo.com> Geoff, Keep in mind that the original ARPA contract for the first 4 nodes did not call for any management or control.? I expect that Larry Roberts expected Len Kleinrock's Network Measurement Center contract to keep an eye on things.? The 4 node network was a "proof of concept" experiment, not a service.? If the proof of concept seemed to be successful there was an option in the BBN contract to expand the network to a total of as many 19 nodes.? The expansion in 1970 to BBN was an indication that Larry decided the experiment was successful and perhaps it was beginning to be time to think of "service".? When I got involved with the network in November 1970 Larry was beginning to put pressure on the Host organizations and the NWG to start using the network for resource sharing experiments, and it began to be clear that for the Hosts to do that BBN needed to shift its focus a bit away from network research and a bit more toward operations. Keep that background in mind when thinking about the techniques of phone calls and mailed paper tapes used to "manage" the network in 1969-1970. Cheers,Alex On Sunday, September 6, 2020, 8:58:51 PM EDT, the keyboard of geoff goodfellow via Internet-history wrote: Bernie, one thing yours truly has always been curious of is when the ARPANET was initially being rolled out, viz.: http://som.csudh.edu/fac/lpress/history/arpamaps/press.jpg : How were the first four IMPs (UCLA, SRI, UCSB & UTAH) managed/controlled until the cross country link to IMP #5 to y'all at BBN was installed? and What was the length of time the initial 4 ARPANET IMPs "ran" without the cross country link to IMP #5 in Boston? geoff On Sun, Sep 6, 2020 at 1:30 PM Bernie Cosell via Internet-history < internet-history at elists.isoc.org> wrote: > Let me add a little bit to Jack's explorations.? There are two things of > interest we > put in the IMP code that relates to this.? The first was the DDT/TTY > machinery > and other was the "reload from your neighbor" machinery. > > I remember that first quite well, since I mostly designed it [we did > EVERYTHING as a team so we co?perated and sorted stuff out together] and I > implemented it [so I was really responsible for the complicated machinery > that > made this aspect of the IMP work]: > > Early on as we were coding the IMP stuff the question arose as to what to > do > about the TTY [and how the hell were we to debug the damn thing].? We did > several things in this regard.? First I wrote a simple DDT [about as > powerful as > the test-word switches on our PDP-1 :o)] but it allowed us to poke around > in the > dead hulk of the code of a stopped system to see what went wrong and also > put > patches in.? I believe it was originally a stand alone - the imp would > crash or hit a > diagnostic trap and they we could run the DDT and look at buffers and > counters > and pointers and such and generally try to figure out what happened.? When > the > IMP was running solidly enough [which actually happened pretty early on in > its > development],? I can't remember the genesis of the underlying idea, but > we > thought we could route the DDT *over* the net to other IMPs and poke at > *then*. > I came up with a scheme that Will [I think] thought was way too > complicated: > >? ? 1) connect the DDT to the IMP as a "fake host", > &2) connect the TTY to the IMP as another "fake host" > > With those now residing *in* the IMP, instead of apart from it we got a > bunch of > benefits: >? ? 1) we could run the DDT *while* the IMP was up doing its thing, and >? ? 2) we could interrogate a *different* IMPs DDT [simply by pointing the > TTY to > the appropriate fake host on the other IMP. >? ? 3) We could "IM" between machines [simply by pointing the TTY to the > *TTY* > on the other machine. > > [on (3) that ability was very handy as Ben and Marty were bringing up IMPs > 1&2. > They knew, for example, long before any of the host interface and > machinery was > working, that the IMP was doing just fine, since they could exchange > messages > and *knew* it used the same code that the hosts would be using.? It also > replaced > lots of long-distance calls to co?rdinate what was happening at SRI and > UCLA] > > WE also had the IMPs send "health reports" [via a background process] and > they > were hard wired to send to the IMP 5 TTY and so virtually from the outset > we > could monitor [and with the DDT tweak] the whole network.? Until the > PDP-1 > was online it chewed up a fair bit of paper :o) > > It was all using the basic IMP packet-handling machinery, so that two IMPs > could be poking the DDT on a particular IMP and not interfere with one > another. > When the PDP-1 came online as the first proto-NCC, the DDT was as happy to > talk to a real host as one of its fake brethrens and ditto for the "health > reports" > that just changed which host they were going to and it all worked.? So > everything > was fitting together very nicely and very usefully [despite the > complicated code] > > A conceptually neat part about all this is that the *internals* of the IMP > were > host-agnostic.? They didn't care if they were fake or real, they just > sent the > packets where there were supposed to go.? and so we could implement > "satellite" > activities that used the underlying IMP code to do other useful things > beyond > just host-to-host. > > Expanding this principle a few years later, we had a H316 that had *two* > 16k > banks.? [and I think I've mentioned this before on this list].? We decided > to > implement the TIP as, what else?? :o), a host.? But in this case it was a > pseudo-real-host [as I've mentioned before]? this was done so that the TIP > code > could live in the upper memory bank and its "host interface" transferred > data and > control across the boundary.? The IMP didn't need to know or care that the > TIP > was there. > > Phew.? now to the second mechanism: reloading from a neighbor.? Maybe > dave > remembers this better than I do but I think that one of the things we did > as the > IMP got more solid was removed its "loader" [which could boot the machine > from paper tape] and replaced with with something that could live in 20 > words > [which was where the paper tape loader lived: in shadow memory behind the > registers]? I think that that code was *just* enough of a bootstrap to > send > message to a neighboring IMP and the first thing that IMP sent over a > smarter > loader that than received a whole memory-full of IMP code from the > neighbor > and then started the neighbor up.? I believe we could trigger this > remotely via > DDT and so if the IMP was up but just in need of an updated version it > could > suck it in from its neighbor. > > My opinion is that hacking in this kind of stuff [and piggybacking > "services" on > top of the IMP's 'day job' of handing real host data] helped a lot in the > ARPAnet > being virtually "operational" [and manageable] from the start. > >? /Bernie\ >? ? ? ? ? ? Bernie Cosell >? ? ? ? bernie at fantasyfarm.com > -- Too many people; too few sheep -- > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From amckenzie3 at yahoo.com Mon Sep 7 08:01:05 2020 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Mon, 7 Sep 2020 15:01:05 +0000 (UTC) Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> Message-ID: <1461413346.4001546.1599490865162@mail.yahoo.com> Geoff, There were two mag tape TIPs, at Tinker and McClellan Air Force Bases.? The motivation was to allow the Air Force to experiment with using the ARPAnet to replace whatever method they were using to exchange large amounts of data.? I think the test was successful and Tinker and McClellan then decided to attach Hosts to the TIPs to continue operational use of the net to do their data exchanges.? Steve Crocker was involved in helping the Air Force people design the Host software to use the ARPAnet, which led to an amusing story which Steve has recounted several times (it crashed the network, and one of the BBN people decided it was deliberate).? As I recall the test was run in the summer of 1972 and shortly after that the mag tape hardware and software stopped being supported by BBN. Cheers,Alex On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff goodfellow via Internet-history wrote: Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs (the TIPs that had a magnetic tape unit attached to them)? yours truly kinda recalls there were perhaps two of them... one being at GWC? why were they created and to whom did they send their data? geoff On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < internet-history at elists.isoc.org> wrote: > I can describe the genesis.? The IMP code was originally for one host > computer and several inter-IMP modems (that was what our contract > specified), and I coded the IMP/Host and Host/IMP code for that in > parallel with Bernie coding the DDT, etc. Then some host site wanted a > second host on its IMP -- I think maybe UCLA for its IBM 360.? ARPA > called us and asked if the IMP could handle more than one Host.? Our > hardware guys said the Honeywell computer could support (if I remember > correctly) up to seven interfaces which could be up to four Host > interfaces or up to four inter-IMP modem interfaces.? We looked at the > IMP/Host and Host/IMP code and it seemed fairly easy to make it > reentrant, so we told ARPANET "yes".? Once the IMP would know how to > handle multiple Hosts and given there was a bit in the header words > between IMPs and Host to say "real" Host or "fake" Host, the > possibilities were fairly clear.? I implemented the reentrant IMP-host > and host-IMP code, and Bernie changed the routines he had written or was > writing: > - TTY in/out > - DDT in/out > - parameter change packets into the IMP and trace packets out of the IMP > - into the IMP to be discarded and statistics packets out of the IMP > For the regular reports from IMPs to the Network Monitoring Center, a > bit of code in the IMP could send packets to a real host; I don't > remember which of the fake Hosts they looked like they were coming from > -- stats maybe. > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > Early on as we were coding the IMP stuff the question arose as to what > to do > > about the TTY [and how the hell were we to debug the damn thing].? We did > > several things in this regard.? First I wrote a simple DDT [about as > powerful as > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > around in the > > dead hulk of the code of a stopped system to see what went wrong and > also put > > patches in.? I believe it was originally a stand alone - the imp would > crash or hit a > > diagnostic trap and they we could run the DDT and look at buffers and > counters > > and pointers and such and generally try to figure out what happened. > When the > > IMP was running solidly enough [which actually happened pretty early on > in its > > development],? I can't remember the genesis of the underlying idea, > but? we > > thought we could route the DDT *over* the net to other IMPs and poke at > *then*. > > I came up with a scheme that Will [I think] thought was way too > complicated: > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From steve at shinkuro.com Mon Sep 7 08:07:22 2020 From: steve at shinkuro.com (Steve Crocker) Date: Mon, 7 Sep 2020 11:07:22 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <646228068.4006926.1599490296622@mail.yahoo.com> References: <646228068.4006926.1599490296622@mail.yahoo.com> Message-ID: Alex, Vint, Len or Bob might have some insight to add. My best guess is Larry didn?t have a complete plan in his head and certainly didn?t have one written down, but he was quick to see emerging issues and he had enough sufficient budgetary and programmatic flexibility to allow him to evolve the program as it went along. I think the idea of expanding beyond four nodes was pretty much a given even before the first contract was let. That is, the structuring of the contract into a four node initial net and with options to extend was just normal care in setting up the program and it would have been a huge surprise and disappointment if the installations hadn?t continued. But all the other pieces ? network management, TIPs, etc. ? emerged along the way. With respect to network management, I do recall we actively tried to set up an alternate network management site. The group we negotiated with didn?t put together a credible proposal and we abandoned the effort. Steve Sent from my iPhone > On Sep 7, 2020, at 10:52 AM, Alex McKenzie via Internet-history wrote: > > ? Geoff, > Keep in mind that the original ARPA contract for the first 4 nodes did not call for any management or control. I expect that Larry Roberts expected Len Kleinrock's Network Measurement Center contract to keep an eye on things. The 4 node network was a "proof of concept" experiment, not a service. If the proof of concept seemed to be successful there was an option in the BBN contract to expand the network to a total of as many 19 nodes. The expansion in 1970 to BBN was an indication that Larry decided the experiment was successful and perhaps it was beginning to be time to think of "service". When I got involved with the network in November 1970 Larry was beginning to put pressure on the Host organizations and the NWG to start using the network for resource sharing experiments, and it began to be clear that for the Hosts to do that BBN needed to shift its focus a bit away from network research and a bit more toward operations. > Keep that background in mind when thinking about the techniques of phone calls and mailed paper tapes used to "manage" the network in 1969-1970. > Cheers,Alex > On Sunday, September 6, 2020, 8:58:51 PM EDT, the keyboard of geoff goodfellow via Internet-history wrote: > > Bernie, one thing yours truly has always been curious of is when the > ARPANET was initially being rolled out, viz.: > http://som.csudh.edu/fac/lpress/history/arpamaps/press.jpg : > > How were the first four IMPs (UCLA, SRI, UCSB & UTAH) managed/controlled > until the cross country link to IMP #5 to y'all at BBN was installed? > and > What was the length of time the initial 4 ARPANET IMPs "ran" without the > cross country link to IMP #5 in Boston? > > geoff > >> On Sun, Sep 6, 2020 at 1:30 PM Bernie Cosell via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >> Let me add a little bit to Jack's explorations. There are two things of >> interest we >> put in the IMP code that relates to this. The first was the DDT/TTY >> machinery >> and other was the "reload from your neighbor" machinery. >> >> I remember that first quite well, since I mostly designed it [we did >> EVERYTHING as a team so we co?perated and sorted stuff out together] and I >> implemented it [so I was really responsible for the complicated machinery >> that >> made this aspect of the IMP work]: >> >> Early on as we were coding the IMP stuff the question arose as to what to >> do >> about the TTY [and how the hell were we to debug the damn thing]. We did >> several things in this regard. First I wrote a simple DDT [about as >> powerful as >> the test-word switches on our PDP-1 :o)] but it allowed us to poke around >> in the >> dead hulk of the code of a stopped system to see what went wrong and also >> put >> patches in. I believe it was originally a stand alone - the imp would >> crash or hit a >> diagnostic trap and they we could run the DDT and look at buffers and >> counters >> and pointers and such and generally try to figure out what happened. When >> the >> IMP was running solidly enough [which actually happened pretty early on in >> its >> development], I can't remember the genesis of the underlying idea, but >> we >> thought we could route the DDT *over* the net to other IMPs and poke at >> *then*. >> I came up with a scheme that Will [I think] thought was way too >> complicated: >> >> 1) connect the DDT to the IMP as a "fake host", >> &2) connect the TTY to the IMP as another "fake host" >> >> With those now residing *in* the IMP, instead of apart from it we got a >> bunch of >> benefits: >> 1) we could run the DDT *while* the IMP was up doing its thing, and >> 2) we could interrogate a *different* IMPs DDT [simply by pointing the >> TTY to >> the appropriate fake host on the other IMP. >> 3) We could "IM" between machines [simply by pointing the TTY to the >> *TTY* >> on the other machine. >> >> [on (3) that ability was very handy as Ben and Marty were bringing up IMPs >> 1&2. >> They knew, for example, long before any of the host interface and >> machinery was >> working, that the IMP was doing just fine, since they could exchange >> messages >> and *knew* it used the same code that the hosts would be using. It also >> replaced >> lots of long-distance calls to co?rdinate what was happening at SRI and >> UCLA] >> >> WE also had the IMPs send "health reports" [via a background process] and >> they >> were hard wired to send to the IMP 5 TTY and so virtually from the outset >> we >> could monitor [and with the DDT tweak] the whole network. Until the >> PDP-1 >> was online it chewed up a fair bit of paper :o) >> >> It was all using the basic IMP packet-handling machinery, so that two IMPs >> could be poking the DDT on a particular IMP and not interfere with one >> another. >> When the PDP-1 came online as the first proto-NCC, the DDT was as happy to >> talk to a real host as one of its fake brethrens and ditto for the "health >> reports" >> that just changed which host they were going to and it all worked. So >> everything >> was fitting together very nicely and very usefully [despite the >> complicated code] >> >> A conceptually neat part about all this is that the *internals* of the IMP >> were >> host-agnostic. They didn't care if they were fake or real, they just >> sent the >> packets where there were supposed to go. and so we could implement >> "satellite" >> activities that used the underlying IMP code to do other useful things >> beyond >> just host-to-host. >> >> Expanding this principle a few years later, we had a H316 that had *two* >> 16k >> banks. [and I think I've mentioned this before on this list]. We decided >> to >> implement the TIP as, what else?? :o), a host. But in this case it was a >> pseudo-real-host [as I've mentioned before] this was done so that the TIP >> code >> could live in the upper memory bank and its "host interface" transferred >> data and >> control across the boundary. The IMP didn't need to know or care that the >> TIP >> was there. >> >> Phew. now to the second mechanism: reloading from a neighbor. Maybe >> dave >> remembers this better than I do but I think that one of the things we did >> as the >> IMP got more solid was removed its "loader" [which could boot the machine >> from paper tape] and replaced with with something that could live in 20 >> words >> [which was where the paper tape loader lived: in shadow memory behind the >> registers] I think that that code was *just* enough of a bootstrap to >> send >> message to a neighboring IMP and the first thing that IMP sent over a >> smarter >> loader that than received a whole memory-full of IMP code from the >> neighbor >> and then started the neighbor up. I believe we could trigger this >> remotely via >> DDT and so if the IMP was up but just in need of an updated version it >> could >> suck it in from its neighbor. >> >> My opinion is that hacking in this kind of stuff [and piggybacking >> "services" on >> top of the IMP's 'day job' of handing real host data] helped a lot in the >> ARPAnet >> being virtually "operational" [and manageable] from the start. >> >> /Bernie\ >> Bernie Cosell >> bernie at fantasyfarm.com >> -- Too many people; too few sheep -- >> >> >> >> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> >> > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From steve at shinkuro.com Mon Sep 7 08:18:56 2020 From: steve at shinkuro.com (Steve Crocker) Date: Mon, 7 Sep 2020 11:18:56 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <1461413346.4001546.1599490865162@mail.yahoo.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> Message-ID: Alex, Wow! I had not known about the mag tape TIPs nor their installation at Tinker and McClellan. That fills in a key part of the story. I joined IPTO on 21 July 1971. Ten days later I visited Tinker in Oklahoma City to advise them on how to connect their 30 bit Univac computers to IMPs, one at Tinker and one at McClellan near Sacramento. Larry had made an arrangement for a side-by-side test of the Arpanet and Autodin I. I believe it was around February 1972 when they connected their computers to the IMPs. Tne test was transfer of a file and it was obvious that we wanted maximum throughput speed. They didn't need to implement the full protocol suite, so I advised them to gin up an ad hoc file transfer scheme that used multiple parallel virtual connections. I think I suggested eight links would be sufficient. When they fired up their software, the network flooded and crashed. I did not follow what happened after that. I never knew whether they got their computers working, shifted to PDP-11s or something else. You're saying mag tape TIPs were installed, which would certainly have done the job. But since they had already gotten their hardware connected, I would have thought they only needed to reduce the number of parallel connections to avoid crashing the network. Steve On Mon, Sep 7, 2020 at 11:01 AM Alex McKenzie via Internet-history < internet-history at elists.isoc.org> wrote: > Geoff, > There were two mag tape TIPs, at Tinker and McClellan Air Force Bases. > The motivation was to allow the Air Force to experiment with using the > ARPAnet to replace whatever method they were using to exchange large > amounts of data. I think the test was successful and Tinker and McClellan > then decided to attach Hosts to the TIPs to continue operational use of the > net to do their data exchanges. Steve Crocker was involved in helping the > Air Force people design the Host software to use the ARPAnet, which led to > an amusing story which Steve has recounted several times (it crashed the > network, and one of the BBN people decided it was deliberate). As I recall > the test was run in the summer of 1972 and shortly after that the mag tape > hardware and software stopped being supported by BBN. > Cheers,Alex > > On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff > goodfellow via Internet-history > wrote: > > Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs > (the > TIPs that had a magnetic tape unit attached to them)? > > yours truly kinda recalls there were perhaps two of them... one being at > GWC? > > why were they created and to whom did they send their data? > > geoff > > On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < > internet-history at elists.isoc.org> wrote: > > > I can describe the genesis. The IMP code was originally for one host > > computer and several inter-IMP modems (that was what our contract > > specified), and I coded the IMP/Host and Host/IMP code for that in > > parallel with Bernie coding the DDT, etc. Then some host site wanted a > > second host on its IMP -- I think maybe UCLA for its IBM 360. ARPA > > called us and asked if the IMP could handle more than one Host. Our > > hardware guys said the Honeywell computer could support (if I remember > > correctly) up to seven interfaces which could be up to four Host > > interfaces or up to four inter-IMP modem interfaces. We looked at the > > IMP/Host and Host/IMP code and it seemed fairly easy to make it > > reentrant, so we told ARPANET "yes". Once the IMP would know how to > > handle multiple Hosts and given there was a bit in the header words > > between IMPs and Host to say "real" Host or "fake" Host, the > > possibilities were fairly clear. I implemented the reentrant IMP-host > > and host-IMP code, and Bernie changed the routines he had written or was > > writing: > > - TTY in/out > > - DDT in/out > > - parameter change packets into the IMP and trace packets out of the IMP > > - into the IMP to be discarded and statistics packets out of the IMP > > For the regular reports from IMPs to the Network Monitoring Center, a > > bit of code in the IMP could send packets to a real host; I don't > > remember which of the fake Hosts they looked like they were coming from > > -- stats maybe. > > > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > > Early on as we were coding the IMP stuff the question arose as to what > > to do > > > about the TTY [and how the hell were we to debug the damn thing]. We > did > > > several things in this regard. First I wrote a simple DDT [about as > > powerful as > > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > > around in the > > > dead hulk of the code of a stopped system to see what went wrong and > > also put > > > patches in. I believe it was originally a stand alone - the imp would > > crash or hit a > > > diagnostic trap and they we could run the DDT and look at buffers and > > counters > > > and pointers and such and generally try to figure out what happened. > > When the > > > IMP was running solidly enough [which actually happened pretty early on > > in its > > > development], I can't remember the genesis of the underlying idea, > > but we > > > thought we could route the DDT *over* the net to other IMPs and poke at > > *then*. > > > I came up with a scheme that Will [I think] thought was way too > > complicated: > > > > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From jnc at mercury.lcs.mit.edu Mon Sep 7 08:22:22 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 7 Sep 2020 11:22:22 -0400 (EDT) Subject: [ih] Exterior Gateway Protocol Message-ID: <20200907152222.CC28218C090@mercury.lcs.mit.edu> Part II: > Jack Haverty > Yikes! When we created EGP circa 1982, IIRC we expected maybe a dozen > or so ASes would be sufficient to support experimentation with all the > research ideas. 64,000 ASes? No way. > From: Guy Almes > the weaknesses of this binary intra-AS / inter-AS split. > I became particularly aware of that weakness when the IETF moved to > expand the size of the AS field in BGP from 16 to 32 bits. In 1987, I > would not have anticipated 64,000 ASes. Oh well. > And then, again, when working with routers that had to usable in > backbone networks and thus have a "full" routing table in expensive > fast packet-forwarding cards. ... an example was the need for 10s of > thousands of inter-AS routes in the forwarding card of the IBM routers > used in the T3 version of the NSFnet backbone. Reading these comments, I think the underlying fundamental problem is the poor support-for/use-of 'names' (in the formal theory sense of the word/term 'name') for larger connectivity aggregates in the network. If you have a node A which is dozens of hops away from two areas, X and Y, which are connectivity neighbours, the chances that there will be any use/point to being able to distinguish between X and Y _at A_ is slim. Unfortunately, the system as built doesn't have a mechanism to allow X and Y to be 'aggregated' into a single named entity a long way away from them. (I have to say that I had originally assumed that the problem with that lack of aggretability was going to be computational overhead; but these days we can throw so much bandwidth and computing power at the path-selection problem that that doesn't seem to be the most serious issue. Yes, _delays_ cannot be extinguished with technology - in a gloal network, the speed of light will always be with us, so stabilization times after a change always been an issue... However, it seems that the _management_ of that many separate named things is the more pressing issue.) (A further comment is that alternate path issues make more use of names for larger aggregates problematic. I.e. if company A is connected to ISP's X and Y, making full use of the alternate paths to A provided by that is non-trivial; giving A 'connectivity names' associated with A make it harder to use its link to B, and vie versa. But to avoid a long note on this problem, I'll leave discussion of how to solve this, except to note that it was thought about at length, and there do seem to be solutions, _if_ one is willing to make adjustments to the overall system architecture in terms of what funcionality is in which subsystems, and particularly in terms of the information which flows across the subsystem boundaries. This margin is just big enough to note that a 'DNS lookip' has to return not just a single name, but a small section of map of what the nearby part of the network looks like. This will of course be easier to make use of in an MD/ER mapping system, of course! :-) This does touch on a related problem, which is the poverty of namespaces (in particular in IPv6, where we blew our best chance to do something about this). There's a quote I can't quite fetch out of my memory, about systems which have too few namespaces; I can't recall if it was something Jerry Saltzer or Dave Clark said (or maybe me :-). The irony is that the stated reason why separate namespaces for identity and location were not included in IPv6 was that people were concerned about the security of the bindings between the two. However, the same basic issue exists (and seems to have been solved) for i) the bindings between IPvN addresses and AS numbers, and ii) the bindings between IPvN addresses and DNS names. Oh well. Alas, the proponents of that separation (including me) weren't smart enough to pick up on the point - and use it in the campaign for their adoption - that having those separate namespaces would allow one to change one's connection point (i.e. one's ISP) without having to reconfigure one's IPvN addresses. (Our heads were too far in the clouds - we thought that if we pointed out that location and identity were fundamenally very different things, and having a _single_ naming system which didn't allow them to be named separately would _inevitably_ be restrictive, that's all that was needed. Alas....) Of course, the easy way to avoid that particular problem is to have one's _own_ addresses - but that just feeds back into the problem we started with. Well, that's it for today - my few remaining neurons are all worn out! Noel From vint at google.com Mon Sep 7 08:39:17 2020 From: vint at google.com (Vint Cerf) Date: Mon, 7 Sep 2020 11:39:17 -0400 Subject: [ih] Exterior Gateway Protocol In-Reply-To: References: <20200907141420.EC91A18C090@mercury.lcs.mit.edu> Message-ID: in the case of BGP, TCP is just a protocol running on IP and that network management "stack" is independent of the stack seen by client's of the standard stack. lI didn't see it that way at first but got more comfortable with the sense that network management stack is distinct v On Mon, Sep 7, 2020 at 10:41 AM Steve Crocker via Internet-history < internet-history at elists.isoc.org> wrote: > Related to but not quite the same as provability is the cold start > problem. If there are layer violations, it?s not possible to restart the > system from scratch layer by layer. > > Fortunately, the entire system is big enough that it doesn?t crash > completely. > > Sent from my iPhone > > > On Sep 7, 2020, at 10:14 AM, Noel Chiappa via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > ?Wow, you all have been sending a lot of email. Let me package a few > replies > > together, to minimize my list traffic. > > > >> From: Joseph Touch > > > >> Can you tell us more about what part of BGP's use of TCP was > >> controversial at the time? > > > > I don't directly remember what the concerns were, but I think I can > probably > > re-create them. (Jack Haverty's comments are very epropos too.) > > > > At the time it was generally held in the OS field (where most of us had > come > > from - networking was just getting started as a distinct field) that > > dependency loops among subsystems (i.e. subsystem A calls on B, which > > calls on C, which in turn calls on A) were bad. > > > > Some people may have had issues with provability (which was somewhat > popular > > at the time), but I think for a lot of people, it was just more a general > > sense that i) it made it hard to fully understand how the system worked, > and > > ii) it could give rise to problems, e.g. deadlocks. > > > > A good sense of the thinking on the topic can be found in Dave Reed's > > master's there, "Processor Multiplexing in a Layered Operating System": > > > > http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-164.pdf > > > > from 1976. It is mostly concerned with a dependency loop between > > processes/process-switching and virtual memory (some of the OS's process > state > > may be paged; and paging may have to call on process switching when a > process > > is paused for a page fault), but has a good overview of the contemporary > > thinking about dependency loops. > > > > Running BGP on top of TCP brings in the same kind of relationship: BGP > is in > > some sense 'part of' the internetworking layer, and TCP is definitely a > > client of that layer, so running BGP on top of TCP is, de facto, a > dependency > > loop - at least from a _subsystem structural_ viewpoint. > > > > In actual practise, problems are generally avoided by avoiding > _operational_ > > dependency loops: e.g. IBGP does depend on the IGP to get packets between > > border routers of the AS, but that just means that EGP depends on the > IGP, as > > it always did. And for EGP between border routers of two AS's, they must > be > > on a common network, i.e. no routing needed. > > > > However, I believe that most people were made uneasy by the subsystem > > structural dependency loop of BGP on TCP. We'd had some experience of > > successfuly working with subsystem _structural_ dependency loops, with > ICMP > > (which is in theory part of the internetwork layer) running on top of IP, > > without any major problems operationally _in the use cases which we had > for > > it_ (which did not generally involve _operational_ dependency loops). > > > > That gave us confidence that the BGP on TCP case was probably workable > (as > > long as we avoided _operational_ dependency loops), but at the same time > we > > did know that we were pushing the envelope. Then again, the entire packet > > communication field was pushing the envelope, as the Bell people were > always > > happy to remind us, so we held our breath and jumped! > > > > > >> From me: > > > >> I think in a really large network, doing congestion avoidance in one > >> subsystem, long with path selection, is not workable. I think it should > >> be done separately > > > > Of course, I doubt we'll ever do congestion avoidance (i.e. dynamically > use > > an alternate path); these days the style seems to be to add bandwidth on > > gongested paths. > > > > > >> From: Scott Brim > > > >>> I have this vague memory that Scott Brim may have been at an FGP > >>> kick-off meeting > > > >> Either the first or the second. It was the third IETF. > > > > The meeting I am vaguely remembering was at Proteon. > > > > NOel > > -- > > 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 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From b_a_denny at yahoo.com Mon Sep 7 08:41:12 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Mon, 7 Sep 2020 15:41:12 +0000 (UTC) Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <568F7435-3A35-490E-BCE4-F101202D814C@tony.li> <3f574a93-f614-f7df-136a-36e0d8bca74d@gmail.com> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3 kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> Message-ID: <1839809783.4016574.1599493272506@mail.yahoo.com> Interesting.? My recollection is just referring to the radio folks as Rockwell (John Jubin and Neil Gower?). They were located in Texas.? Just to straighten it out in my head I did a little searching and Wikipedia says Collins Radio was bought by Rockwell International in 1973 and they became Rockwell Collins. But in 2001 there was a split out of an avionics division from Rockwell International and that part is the current Rockwell Collins Inc. I hope I got this right.? I imagine I just shortened the name in my head at the time without realizing any potential problem.? Perhaps the first packet radio contract was with Collin Radio. I don't remember the date of the very beginning of packet radio.? I think the last generation of packet radio hardware, the LPR,? was done by Hazeltine.? There is a LPR in the Computer History Museum.? Maybe I will be able to double check with others about the download question. I thought we had that capability.? barbara? On Monday, September 7, 2020, 04:13:56 AM PDT, Vint Cerf wrote: Packet Radios were developed by Collins Radio. I do not recall that they downloaded from neighbors.? As to the 1976 report, there was a famous test from Rosati's. There was an LSI-11 "terminal" connected to a packet radio. My guess is that they would have just TELNETTED into a PDP-10 at SRI and delivered the report that way. I doubt that they had email running in the LSI-11.? v On Mon, Sep 7, 2020 at 2:47 AM Barbara Denny via Internet-history wrote: ?Because of BBN's involvement, I am thinking Packet Radio might have reused many of? the same ideas as the IMPs for loading new software from another node. Do you know this was not the case?? I never needed to look at that part of the code.? I remember using XNET for examination of the Packet Radio station. Given your recent email it sounds like you looked for old Packet Radio station software and couldn't find it. Is this correct?? I don't think Rockwell released their Packet Radio software in the late 70s/early 80s. I would have to contact Rockwell if I thought bugs required a change to a packet radio, versus the Packet Radio station, when I worked at BBN. I know several years later SRI did get some of their code? because I implemented one of the new routing algorithms ( I am pretty sure it was called threshold distance vector routing if anyone is interested). BTW, I think the software may have only been tested in a simulator due to delays in the delivery of the LPR (Low Cost Packet Radio). This was during the SURAN program.? The first demo of Packet Radio and ARPANET in 1976 involved submitting the status report.? Don Nielson would probably remember if that was done through anything like email. Below is a link to an article that discusses this event. The text from the article mentions email but more importantly it has a link to a podcast with Don. I didn't know this podcast existed so I still need to listen to it.? I can see why you might think the report submission may have been done by using a telnet connection to a SRI host that had email.? https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ barbara? ? ? On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via Internet-history wrote:? ?Hi Geoff - thanks for that bit of history and kudos!? I think there's an Internet connection in your experience.? I'm not sure what, legally, "wireless email" means.? But I suspect that email was being sent and received, wirelessly, well before even 1982, if only to and from the SRI Packet Radio van that could occasionally be seen then roaming around the Bay Area. Of course, technically, that probably involved a Telnet connection, wirelessly, to some PDP-10 running an email program.?? But, legally, it might meet the court accepted definition of "wireless email". ? I learned from the lawyers that much of litigation involves arguing about the meaning of words and phrases. So, perhaps someone could have looked for mouldering Packet Radio (aka PR) hardware and software, and demonstrated wireless email circa 1978 over one or more PRNETs. Sadly, although I was pretty sure that interesting "prior art" would be found in the PR environment, we had little success 7 years ago while trying to find anything that might show exactly how PR equipment "downloaded instructions".?? There's remarkably little readily discoverable material about lots of the computer and network systems of the 70s/80s, especially internal details of operation, tools, procedures, etc.?? Plenty of stuff on Routing, but little on other mechanisms, or other types of networks of that era, at least that the lawyers and I could find.?? IMHO, that's a huge gap even in Internet History, since the Internet did not evolve in a vacuum, was itself composed of more than the ARPANET, and was surrounded by competitors (remember multiprotocol routers). /Jack On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > Jack, you're a Most Eloquent purveyor of history and that WHY explain > is exactly what yours truly was hoping for... Thank You for the > elucidation! :D > > along the lines vis-a-vis: > >? ? So, that's a bit about the "Why", for history to ponder.? The >? ? experience got me wondering about the "patent history" of The >? ? Internet.? Clearly there was a lot of innovation in those days.? >? ? My recollection is that very little was patented, even if only to >? ? make sure no one else could.? Maybe someone will document the >? ? patent-related aspects of Internet History someday. > > please excuse/pardon this immodesty: yours truly had a kinda similar > "lawyered" experience with respect to WHO was the purported > "inventor"/originator of wireless email in a patent litigation case > and the "challenge" of finding/presenting any extant legally > submissive "artifactual?proof" to that effect -- for which John > Markoff at the New York Times wrote about in this 2006 article: > > In Silicon Valley, a Man Without a Patent > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > > for which some links of "proof" exist -- for some stuff mentioned in > the above NYT article -- on my website?https://iconia.com/?under > "wireless email" (in case any historians are duly interested)...? > > geoff > > On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > wrote: > >? ? Geoff, > >? ? Dave's IEEE paper does an excellent job of the >? ? Who/What/When/Where.? He's right that it was about 7 years ago.?? >? ? Time flies... but I guess it's still "recent" when viewed as part >? ? of Internet History. > >? ? For the curious, I can add a bit more about the Why. > >? ? Sometime in 2013, I got an email out of the blue from Charlie >? ? Neuhauser, someone I didn't recognize or remember at all, asking >? ? if I was the "Jack Haverty" who authored IEN 158 - documenting the >? ? XNET protocol in 1980.?? Figuring that the statute of limitations >? ? must have expired after 30+ years, I cautiously said yes.? Over >? ? the next few days, he hooked me up with the lawyers who were >? ? involved in a patent dispute - one that had been going on for >? ? several decades by then.? In fact, the patent involved had been >? ? issued, ran its 17 year lifetime, and expired, but there was still >? ? litigation in process about whether or not the patent was valid, >? ? and 17 years of violations were alleged cause for compensation in >? ? the many millions. ? For the next few years I was involved in the >? ? battles, working with the lawyers scattered all over the country.? >? ? I never met any of them.? All our work was done by email and >? ? telephone.?? No Zoom then or we probably would have used it. > >? ? The core issue in the patent battle concerned "downloading >? ? instructions", mechanisms such as would be involved in patching or >? ? issuing new software releases to remote equipment.?? XNET seemed >? ? to them to possibly have something to do with that, hence the >? ? interest.? The goal was to find hard evidence that such procedures >? ? were being done by 1980, which would prove that prior art >? ? existed.? Hard evidence literally means "hard" - opinions help, >? ? but physical equipment and running code is much more impressive in >? ? a courtroom. > >? ? They hadn't found any XNET artifacts, and I couldn't point them to >? ? any surviving implementations.?? But I pointed out that my XNET >? ? document simply captured the technology that we "stole" from the >? ? ARPANET IMP experience, and that the IMPs routinely "downloaded >? ? code" from their neighbors and the NOC all during the life of the >? ? ARPANET. > >? ? Since the IMPs had existed since the early 70s, that really >? ? sparked their interest, and a search (worldwide) ensued to find >? ? old IMPs, in the hope that just maybe one of them still had the >? ? IMP software in its magnetic-core memory.? A few IMPs were >? ? located, but none were functional.? The one in the museum at UCLA >? ? seemed promising, but the owners were reluctant to even hook it up >? ? to power after sitting idle for so many years, expecting it might >? ? go up in smoke. > >? ? Then I learned from the BBN alumni mailing list that an ancient >? ? IMP listing had been found in a basement.?? The story from that >? ? point is pretty well described in Dave's paper. > >? ? Personally, it was an interesting experience.? I worked >? ? extensively with one lawyer in San Diego.? I taught him how >? ? computers and networks actually work; he taught me a lot about the >? ? legal system regarding patents.?? IMHO, they are equally >? ? convoluted and complex when viewed from the other's perspective. > >? ? I also learned a lot about the IMP code, which I had never even >? ? looked at while I was at BBN.? One task I took on was to >? ? exhaustively analyze the parts of the IMP code that implemented >? ? the "download new instructions" functionality, writing up an >? ? instruction-by-instruction description of how the code >? ? accomplished that by interacting with a neighboring IMP.?? It was >? ? a very clever design, and extremely tight code, even including >? ? self-modifying instructions.?? Not easy to figure out (or explain >? ? in language amenable to a non-technical judge or jury).? So there >? ? was great interest in being able to demonstrate the code in action >? ? using real software from the 70s and hardware simulators.?? >? ? Tangible evidence is much better than even expert opinions. > >? ? The whole legal project came to a sudden end just a few months >? ? prior to the first court date.??? I was looking forward to going >? ? to Delaware (legal action was filed in Federal court in Delaware), >? ? and finally meeting some of the people.?? But the parties settled >? ? suddenly, the case was dropped, and AFAIK the patent question was >? ? never resolved.?? > >? ? So, that's a bit about the "Why", for history to ponder.??? The >? ? experience got me wondering about the "patent history" of The >? ? Internet.?? Clearly there was a lot of innovation in those days.?? >? ? My recollection is that very little was patented, even if only to >? ? make sure no one else could.?? Maybe someone will document the >? ? patent-related aspects of Internet History someday. > >? ? /Jack Haverty > > > >? ? On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: >>? ? jack, you've raised my curiosity with respect to: >> >>? ? ? ? ... There >>? ? ? ? *is* ARPANET IMP software which was recently restored and a small >>? ? ? ? ARPANET was run using simulated IMP hardware. >> >>? ? Who/What/When/Where/Why? >> >>? ? geoff >> >>? ? On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history >>? ? >? ? > wrote: >> >>? ? ? ? Lukasz, >> >>? ? ? ? I think that the earliest implementations of TTL called it >>? ? ? ? "Time", but >>? ? ? ? I'm not aware that anyone actually used time per se in >>? ? ? ? gateways, at >>? ? ? ? least in the early days (1977-1982 or so).? >> >>? ? ? ? TCP implementations didn't do anything with TTL other than >>? ? ? ? set it on >>? ? ? ? outgoing datagrams, and at least in my implementation (TCP >>? ? ? ? for Unix), it >>? ? ? ? was just set to some arbitrary value.? Until we had some data >>? ? ? ? from >>? ? ? ? experimentation it was hard to evaluate ideas about what >>? ? ? ? routers, hosts, >>? ? ? ? et al should actually do.?? The early TCPs did use time in >>? ? ? ? handling >>? ? ? ? retransmission timers, and there was work a bit later to >>? ? ? ? incorporate >>? ? ? ? time more powerfully into TCP behavior, e.g., Van Jacobson's >>? ? ? ? work. >> >>? ? ? ? The early gateways, IIRC, used the terminology "time", but in >>? ? ? ? practice >>? ? ? ? used just hop counts, since time measurements were difficult to >>? ? ? ? implement.?? The exception to that may be Dave Mills' >>? ? ? ? Fuzzballs, since >>? ? ? ? Dave was the implementor most interested in time and making >>? ? ? ? precise >>? ? ? ? measurements of network behavior.?? I *think* Dave may have >>? ? ? ? used time >>? ? ? ? values and delay-based routing amongst his "fuzzies". >> >>? ? ? ? The BBN doc you're seeking might have been one of many that >>? ? ? ? discussed >>? ? ? ? the ARPANET internal mechanisms, e.g., ones with titles like >>? ? ? ? "Routing >>? ? ? ? Algorithm Improvements".? The ARPANET internal mechanisms did >>? ? ? ? use time.? >>? ? ? ? It was fairly simple in the IMPs, since the delay introduced >>? ? ? ? by the >>? ? ? ? synchronous communications lines could be easily predicted, >>? ? ? ? and the >>? ? ? ? other major component of delay was the time spent in queues, >>? ? ? ? which could >>? ? ? ? be measured fairly easily.?? >> >>? ? ? ? I even found one BBN ARPANET Project QTR from circa 1975 that >>? ? ? ? discussed >>? ? ? ? the merits of the new-fangled TCP proposal that some >>? ? ? ? professor had >>? ? ? ? published -- and seemed to conclude it couldn't possibly work. >> >>? ? ? ? My involvement in implementations of TCPs and gateways lasted >>? ? ? ? through >>? ? ? ? about mid-1983, so I don't know much of the detail of subsequent >>? ? ? ? implementations.? For the various BBN gateway/router >>? ? ? ? equipment, Bob >>? ? ? ? Hinden would probably be a good source.? The other major >>? ? ? ? early player >>? ? ? ? was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will >>? ? ? ? remember.?? There's also at least one paper on the Fuzzballs >>? ? ? ? which may >>? ? ? ? have some details. >> >>? ? ? ? One thing I'd advise being careful of is the various >>? ? ? ? "specifications" in >>? ? ? ? RFCs.? Much of the wording in those was intentionally >>? ? ? ? non-prescriptive >>? ? ? ? (use of "should" or "may" instead of "must"), to provide as much >>? ? ? ? latitude as possible for experimentation with new ideas, >>? ? ? ? especially >>? ? ? ? within an AS.?? The Internet was an Experiment. >> >>? ? ? ? Also, there was no consistent enforcement mechanism to assure >>? ? ? ? that >>? ? ? ? implementations actually even conformed to the "must" >>? ? ? ? elements.?? So >>? ? ? ? Reality could be very different from Specification. >> >>? ? ? ? I don't know of any gateway implementations that have >>? ? ? ? survived.?? There >>? ? ? ? *is* ARPANET IMP software which was recently restored and a small >>? ? ? ? ARPANET was run using simulated IMP hardware.?? I still have >>? ? ? ? a ~1979 >>? ? ? ? listing of the TCP I wrote for Unix, but haven't scanned it >>? ? ? ? into digital >>? ? ? ? form yet. >> >>? ? ? ? Jack >> >>? ? ? ? On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: >>? ? ? ? > Jack, >>? ? ? ? > >>? ? ? ? > I was reading a lot of old BBN PDFs thanks to all good souls on >>? ? ? ? > this list that post nice URLs from time to time. >>? ? ? ? > >>? ? ? ? > I remember reading in at least one of them, that apparently >>? ? ? ? first >>? ? ? ? > TCP/IP implementations were indeed using TTL as literally >>? ? ? ? ?time?, >>? ? ? ? > not hop count. I believe there somewhere there between PDP docs >>? ? ? ? > and ARPANET docs I?ve read something to the effect ?and >>? ? ? ? from this >>? ? ? ? > time we changed from measuring time to simply count routing >>? ? ? ? hops?. >>? ? ? ? > Of course, right now google-fu is failing me. >>? ? ? ? > >>? ? ? ? > Quoting RFC 1009 that was already brought up, there?s quite >>? ? ? ? > direct ?definition? of the field: >>? ? ? ? > >>? ? ? ? > "4.8.? Time-To-Live >>? ? ? ? > >>? ? ? ? >? The Time-to-Live (TTL) field of the IP header is defined >>? ? ? ? to be a >>? ? ? ? >? timer limiting the lifetime of a datagram in the >>? ? ? ? Internet.? It is >>? ? ? ? >? an 8-bit field and the units are seconds.? This would >>? ? ? ? imply that >>? ? ? ? >? for a maximum TTL of 255 a datagram would time-out after >>? ? ? ? about 4 >>? ? ? ? >? and a quarter minutes.? Another aspect of the definition >>? ? ? ? requires >>? ? ? ? >? each gateway (or other module) that handles a datagram to >>? ? ? ? >? decrement the TTL by at least one, even if the elapsed >>? ? ? ? time was >>? ? ? ? >? much less than a second.? Since this is very often the >>? ? ? ? case, the >>? ? ? ? >? TTL effectively becomes a hop count limit on how far a >>? ? ? ? datagram >>? ? ? ? >? can propagate through the Internet." >>? ? ? ? > >>? ? ? ? > Were there any implementations that survived somewhere and >>? ? ? ? actually >>? ? ? ? > did exactly that - counted actual time/processing delay, >>? ? ? ? not hops? >>? ? ? ? > And if it took 2s to process packet, did they really >>? ? ? ? decrement TTL >>? ? ? ? > by two? >>? ? ? ? > >>? ? ? ? > Thanks for any pointers, >> >>? ? ? ? -- >>? ? ? ? Internet-history mailing list >>? ? ? ? Internet-history at elists.isoc.org >>? ? ? ? >>? ? ? ? https://elists.isoc.org/mailman/listinfo/internet-history >> >> >> >>? ? -- >>? ? Geoff.Goodfellow at iconia.com >>? ? living as The Truth is True >> >> >> > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > -- 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 Cerf1435 Woodhurst Blvd?McLean, VA 22102703-448-0965 until further notice From amckenzie3 at yahoo.com Mon Sep 7 08:53:25 2020 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Mon, 7 Sep 2020 15:53:25 +0000 (UTC) Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <1461413346.4001546.1599490865162@mail.yahoo.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> Message-ID: <1468336329.1023935.1599494005654@mail.yahoo.com> Geoff, I'm having second thoughts about the reliability of my memory.? I withdraw my comment about the two mag tape TIPs being at Tinker and McClellan.? I think I've mixed up two stories.? I'll do a bit more checking to see if I can find where the 2 mag tape TIPs were actually installed. Sorry,Alex On Monday, September 7, 2020, 11:01:20 AM EDT, Alex McKenzie via Internet-history wrote: Geoff, There were two mag tape TIPs, at Tinker and McClellan Air Force Bases.? The motivation was to allow the Air Force to experiment with using the ARPAnet to replace whatever method they were using to exchange large amounts of data.? I think the test was successful and Tinker and McClellan then decided to attach Hosts to the TIPs to continue operational use of the net to do their data exchanges.? Steve Crocker was involved in helping the Air Force people design the Host software to use the ARPAnet, which led to an amusing story which Steve has recounted several times (it crashed the network, and one of the BBN people decided it was deliberate).? As I recall the test was run in the summer of 1972 and shortly after that the mag tape hardware and software stopped being supported by BBN. Cheers,Alex ? ? On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff goodfellow via Internet-history wrote:? Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs (the TIPs that had a magnetic tape unit attached to them)? yours truly kinda recalls there were perhaps two of them... one being at GWC? why were they created and to whom did they send their data? geoff On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < internet-history at elists.isoc.org> wrote: > I can describe the genesis.? The IMP code was originally for one host > computer and several inter-IMP modems (that was what our contract > specified), and I coded the IMP/Host and Host/IMP code for that in > parallel with Bernie coding the DDT, etc. Then some host site wanted a > second host on its IMP -- I think maybe UCLA for its IBM 360.? ARPA > called us and asked if the IMP could handle more than one Host.? Our > hardware guys said the Honeywell computer could support (if I remember > correctly) up to seven interfaces which could be up to four Host > interfaces or up to four inter-IMP modem interfaces.? We looked at the > IMP/Host and Host/IMP code and it seemed fairly easy to make it > reentrant, so we told ARPANET "yes".? Once the IMP would know how to > handle multiple Hosts and given there was a bit in the header words > between IMPs and Host to say "real" Host or "fake" Host, the > possibilities were fairly clear.? I implemented the reentrant IMP-host > and host-IMP code, and Bernie changed the routines he had written or was > writing: > - TTY in/out > - DDT in/out > - parameter change packets into the IMP and trace packets out of the IMP > - into the IMP to be discarded and statistics packets out of the IMP > For the regular reports from IMPs to the Network Monitoring Center, a > bit of code in the IMP could send packets to a real host; I don't > remember which of the fake Hosts they looked like they were coming from > -- stats maybe. > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > Early on as we were coding the IMP stuff the question arose as to what > to do > > about the TTY [and how the hell were we to debug the damn thing].? We did > > several things in this regard.? First I wrote a simple DDT [about as > powerful as > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > around in the > > dead hulk of the code of a stopped system to see what went wrong and > also put > > patches in.? I believe it was originally a stand alone - the imp would > crash or hit a > > diagnostic trap and they we could run the DDT and look at buffers and > counters > > and pointers and such and generally try to figure out what happened. > When the > > IMP was running solidly enough [which actually happened pretty early on > in its > > development],? I can't remember the genesis of the underlying idea, > but? we > > thought we could route the DDT *over* the net to other IMPs and poke at > *then*. > > I came up with a scheme that Will [I think] thought was way too > complicated: > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history ? -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From amckenzie3 at yahoo.com Mon Sep 7 09:29:44 2020 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Mon, 7 Sep 2020 16:29:44 +0000 (UTC) Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <1461413346.4001546.1599490865162@mail.yahoo.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> Message-ID: <867424403.4037955.1599496184673@mail.yahoo.com> Geoff, Now that I've refreshed my memory, I can say that the 2 mag tape TIPs were installed at Global Weather Central, Offett AFB, NE, and Atmospheric Sciences Lab, Army Electronics R&D Command, White Sands Missile Range, NM.? As I said in my previous message, the motivation was to allow the two organizations to experiment with using the ARPAnet to replace whatever method they were using to exchange large amounts of data.? I cannot remember the dates associated with this test, nor can I recall if it was deemed a success. Sorry for the previous mis-information,Alex On Monday, September 7, 2020, 11:01:20 AM EDT, Alex McKenzie via Internet-history wrote: Geoff, There were two mag tape TIPs, at Tinker and McClellan Air Force Bases.? The motivation was to allow the Air Force to experiment with using the ARPAnet to replace whatever method they were using to exchange large amounts of data.? I think the test was successful and Tinker and McClellan then decided to attach Hosts to the TIPs to continue operational use of the net to do their data exchanges.? Steve Crocker was involved in helping the Air Force people design the Host software to use the ARPAnet, which led to an amusing story which Steve has recounted several times (it crashed the network, and one of the BBN people decided it was deliberate).? As I recall the test was run in the summer of 1972 and shortly after that the mag tape hardware and software stopped being supported by BBN. Cheers,Alex ? ? On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff goodfellow via Internet-history wrote:? Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs (the TIPs that had a magnetic tape unit attached to them)? yours truly kinda recalls there were perhaps two of them... one being at GWC? why were they created and to whom did they send their data? geoff On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < internet-history at elists.isoc.org> wrote: > I can describe the genesis.? The IMP code was originally for one host > computer and several inter-IMP modems (that was what our contract > specified), and I coded the IMP/Host and Host/IMP code for that in > parallel with Bernie coding the DDT, etc. Then some host site wanted a > second host on its IMP -- I think maybe UCLA for its IBM 360.? ARPA > called us and asked if the IMP could handle more than one Host.? Our > hardware guys said the Honeywell computer could support (if I remember > correctly) up to seven interfaces which could be up to four Host > interfaces or up to four inter-IMP modem interfaces.? We looked at the > IMP/Host and Host/IMP code and it seemed fairly easy to make it > reentrant, so we told ARPANET "yes".? Once the IMP would know how to > handle multiple Hosts and given there was a bit in the header words > between IMPs and Host to say "real" Host or "fake" Host, the > possibilities were fairly clear.? I implemented the reentrant IMP-host > and host-IMP code, and Bernie changed the routines he had written or was > writing: > - TTY in/out > - DDT in/out > - parameter change packets into the IMP and trace packets out of the IMP > - into the IMP to be discarded and statistics packets out of the IMP > For the regular reports from IMPs to the Network Monitoring Center, a > bit of code in the IMP could send packets to a real host; I don't > remember which of the fake Hosts they looked like they were coming from > -- stats maybe. > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > Early on as we were coding the IMP stuff the question arose as to what > to do > > about the TTY [and how the hell were we to debug the damn thing].? We did > > several things in this regard.? First I wrote a simple DDT [about as > powerful as > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > around in the > > dead hulk of the code of a stopped system to see what went wrong and > also put > > patches in.? I believe it was originally a stand alone - the imp would > crash or hit a > > diagnostic trap and they we could run the DDT and look at buffers and > counters > > and pointers and such and generally try to figure out what happened. > When the > > IMP was running solidly enough [which actually happened pretty early on > in its > > development],? I can't remember the genesis of the underlying idea, > but? we > > thought we could route the DDT *over* the net to other IMPs and poke at > *then*. > > I came up with a scheme that Will [I think] thought was way too > complicated: > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history ? -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From jack at 3kitty.org Mon Sep 7 11:00:19 2020 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 7 Sep 2020 11:00:19 -0700 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: <1779558001.912243.1599461078378@mail.yahoo.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3 kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> Message-ID: Hi Barbara, Packet Radio artifacts of any kind were elusive (at least in 2013 when we searched), except for a few conference papers.? Specifically, we were looking for things like QTRs or other project reports that SRI presumably submitted to ARPA, analogous to the BBN QTRs.?? We found a lot of the BBN reports online at DTIC, but little from SRI.? I'm not sure, but the BBN QTRs may have been found by the search engine because I had the BBN/ARPA contract numbers involved, but I didn't know the appropriate contract numbers for the SRI (or any other) contracts.?? Not much detail about Fuzzballs, or Port Expanders, or other such boxes that were prolific in the early days of the Internet.? Google wasn't much help, but that may be from lack of knowledge in how to best use the search mechanisms. IMHO, there wasn't as much collaboration between the ARPANET and Packet Radio as there was with the Internet/Gateway work at BBN. BBN had internal structure that to some extent influenced the "technology transfer" between projects.? In particular there were two "divisions", Div4 and Div6, that both did similar computer and network research.? Div6 was where the ARPANET project began and evolved to an operational service over the ten years preceding the Internet, so there was a lot of operational experience and war wounds there.?? Div4 was where the Packet Radio work was done, along with lots of other things, such as TENEX.?? Both were very competent, but had different experiences. Although the technical staffs of the two divisions got along pretty well, pragmatic details limited collaboration.? We were physically located in separate buildings, so hallway encounters and casual interactions were less likely.? Interesting "teaching events" that occurred in the ARPANET propagated quickly through Div6 where the NOC was literally just down the hallway, less so to Div4.?? Cross-charging (charging your time to the other Division's project) was possible but discouraged. The "Gateway Project" began in Div4, where Ginny Strazisar implemented the first gateway;? I don't know if that was a separate project/contract, or just a part of the Packet Radio contract at the time.?? Some few years later, as it became desirable for the Internet to stabilize and become an operational service, ARPA moved the gateway work from Div4 to Div6, folding it into the "Internet Project" contract that was my responsibility at the time (it included various TCP implementations, SATNET, WBNET, Remote Site Maintenance, etc.). That was the point where we started injecting "ARPANET DNA" into the Internet/gateways, blatantly adopting ARPANET techniques as the most obvious (to us in Div6) way to get the Internet to be as managed as the ARPANET. I know little about the internal mechanisms of the Packet Radio environment.?? But it did not move to Div6 (which became BBN Communications Corp at some point) at least during my involvement (roughly 1978-1990). So I suspect that the Packet Radio system did not reuse much of the IMP ideas/techniques, especially the ones that were rather mundane and not well documented or publicized (such as the "reload from neighbor" idea).? The Packet Radio QTRs, if they survive, would probably answer that question. I've often wondered, from a historical perspective now, to what extent things like internal corporate structure and organizational decisions influenced the design and implementation of the Internet. /Jack On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: > Because of BBN's involvement, I am thinking Packet Radio might have reused many of? the same ideas as the IMPs for loading new software from another node. Do you know this was not the case?? I never needed to look at that part of the code.? > I remember using XNET for examination of the Packet Radio station. Given your recent email it sounds like you looked for old Packet Radio station software and couldn't find it. Is this correct?? > I don't think Rockwell released their Packet Radio software in the late 70s/early 80s. I would have to contact Rockwell if I thought bugs required a change to a packet radio, versus the Packet Radio station, when I worked at BBN. I know several years later SRI did get some of their code? because I implemented one of the new routing algorithms ( I am pretty sure it was called threshold distance vector routing if anyone is interested). BTW, I think the software may have only been tested in a simulator due to delays in the delivery of the LPR (Low Cost Packet Radio). This was during the SURAN program.? > The first demo of Packet Radio and ARPANET in 1976 involved submitting the status report.? Don Nielson would probably remember if that was done through anything like email. Below is a link to an article that discusses this event. The text from the article mentions email but more importantly it has a link to a podcast with Don. I didn't know this podcast existed so I still need to listen to it.? I can see why you might think the report submission may have been done by using a telnet connection to a SRI host that had email.? > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > barbara? > On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via Internet-history wrote: > > Hi Geoff - thanks for that bit of history and kudos!? > > I think there's an Internet connection in your experience.? I'm not sure > what, legally, "wireless email" means.? But I suspect that email was > being sent and received, wirelessly, well before even 1982, if only to > and from the SRI Packet Radio van that could occasionally be seen then > roaming around the Bay Area. > > Of course, technically, that probably involved a Telnet connection, > wirelessly, to some PDP-10 running an email program.?? But, legally, it > might meet the court accepted definition of "wireless email". ? I > learned from the lawyers that much of litigation involves arguing about > the meaning of words and phrases. > > So, perhaps someone could have looked for mouldering Packet Radio (aka > PR) hardware and software, and demonstrated wireless email circa 1978 > over one or more PRNETs. > > Sadly, although I was pretty sure that interesting "prior art" would be > found in the PR environment, we had little success 7 years ago while > trying to find anything that might show exactly how PR equipment > "downloaded instructions".?? > > There's remarkably little readily discoverable material about lots of > the computer and network systems of the 70s/80s, especially internal > details of operation, tools, procedures, etc.?? Plenty of stuff on > Routing, but little on other mechanisms, or other types of networks of > that era, at least that the lawyers and I could find.?? IMHO, that's a > huge gap even in Internet History, since the Internet did not evolve in > a vacuum, was itself composed of more than the ARPANET, and was > surrounded by competitors (remember multiprotocol routers). > > /Jack > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: >> Jack, you're a Most Eloquent purveyor of history and that WHY explain >> is exactly what yours truly was hoping for... Thank You for the >> elucidation! :D >> >> along the lines vis-a-vis: >> >> ? ? So, that's a bit about the "Why", for history to ponder.? The >> ? ? experience got me wondering about the "patent history" of The >> ? ? Internet.? Clearly there was a lot of innovation in those days.? >> ? ? My recollection is that very little was patented, even if only to >> ? ? make sure no one else could.? Maybe someone will document the >> ? ? patent-related aspects of Internet History someday. >> >> please excuse/pardon this immodesty: yours truly had a kinda similar >> "lawyered" experience with respect to WHO was the purported >> "inventor"/originator of wireless email in a patent litigation case >> and the "challenge" of finding/presenting any extant legally >> submissive "artifactual?proof" to that effect -- for which John >> Markoff at the New York Times wrote about in this 2006 article: >> >> In Silicon Valley, a Man Without a Patent >> https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html >> >> for which some links of "proof" exist -- for some stuff mentioned in >> the above NYT article -- on my website?https://iconia.com/?under >> "wireless email" (in case any historians are duly interested)...? >> >> geoff >> >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > > wrote: >> >> ? ? Geoff, >> >> ? ? Dave's IEEE paper does an excellent job of the >> ? ? Who/What/When/Where.? He's right that it was about 7 years ago.?? >> ? ? Time flies... but I guess it's still "recent" when viewed as part >> ? ? of Internet History. >> >> ? ? For the curious, I can add a bit more about the Why. >> >> ? ? Sometime in 2013, I got an email out of the blue from Charlie >> ? ? Neuhauser, someone I didn't recognize or remember at all, asking >> ? ? if I was the "Jack Haverty" who authored IEN 158 - documenting the >> ? ? XNET protocol in 1980.?? Figuring that the statute of limitations >> ? ? must have expired after 30+ years, I cautiously said yes.? Over >> ? ? the next few days, he hooked me up with the lawyers who were >> ? ? involved in a patent dispute - one that had been going on for >> ? ? several decades by then.? In fact, the patent involved had been >> ? ? issued, ran its 17 year lifetime, and expired, but there was still >> ? ? litigation in process about whether or not the patent was valid, >> ? ? and 17 years of violations were alleged cause for compensation in >> ? ? the many millions. ? For the next few years I was involved in the >> ? ? battles, working with the lawyers scattered all over the country.? >> ? ? I never met any of them.? All our work was done by email and >> ? ? telephone.?? No Zoom then or we probably would have used it. >> >> ? ? The core issue in the patent battle concerned "downloading >> ? ? instructions", mechanisms such as would be involved in patching or >> ? ? issuing new software releases to remote equipment.?? XNET seemed >> ? ? to them to possibly have something to do with that, hence the >> ? ? interest.? The goal was to find hard evidence that such procedures >> ? ? were being done by 1980, which would prove that prior art >> ? ? existed.? Hard evidence literally means "hard" - opinions help, >> ? ? but physical equipment and running code is much more impressive in >> ? ? a courtroom. >> >> ? ? They hadn't found any XNET artifacts, and I couldn't point them to >> ? ? any surviving implementations.?? But I pointed out that my XNET >> ? ? document simply captured the technology that we "stole" from the >> ? ? ARPANET IMP experience, and that the IMPs routinely "downloaded >> ? ? code" from their neighbors and the NOC all during the life of the >> ? ? ARPANET. >> >> ? ? Since the IMPs had existed since the early 70s, that really >> ? ? sparked their interest, and a search (worldwide) ensued to find >> ? ? old IMPs, in the hope that just maybe one of them still had the >> ? ? IMP software in its magnetic-core memory.? A few IMPs were >> ? ? located, but none were functional.? The one in the museum at UCLA >> ? ? seemed promising, but the owners were reluctant to even hook it up >> ? ? to power after sitting idle for so many years, expecting it might >> ? ? go up in smoke. >> >> ? ? Then I learned from the BBN alumni mailing list that an ancient >> ? ? IMP listing had been found in a basement.?? The story from that >> ? ? point is pretty well described in Dave's paper. >> >> ? ? Personally, it was an interesting experience.? I worked >> ? ? extensively with one lawyer in San Diego.? I taught him how >> ? ? computers and networks actually work; he taught me a lot about the >> ? ? legal system regarding patents.?? IMHO, they are equally >> ? ? convoluted and complex when viewed from the other's perspective. >> >> ? ? I also learned a lot about the IMP code, which I had never even >> ? ? looked at while I was at BBN.? One task I took on was to >> ? ? exhaustively analyze the parts of the IMP code that implemented >> ? ? the "download new instructions" functionality, writing up an >> ? ? instruction-by-instruction description of how the code >> ? ? accomplished that by interacting with a neighboring IMP.?? It was >> ? ? a very clever design, and extremely tight code, even including >> ? ? self-modifying instructions.?? Not easy to figure out (or explain >> ? ? in language amenable to a non-technical judge or jury).? So there >> ? ? was great interest in being able to demonstrate the code in action >> ? ? using real software from the 70s and hardware simulators.?? >> ? ? Tangible evidence is much better than even expert opinions. >> >> ? ? The whole legal project came to a sudden end just a few months >> ? ? prior to the first court date.??? I was looking forward to going >> ? ? to Delaware (legal action was filed in Federal court in Delaware), >> ? ? and finally meeting some of the people.?? But the parties settled >> ? ? suddenly, the case was dropped, and AFAIK the patent question was >> ? ? never resolved.?? >> >> ? ? So, that's a bit about the "Why", for history to ponder.??? The >> ? ? experience got me wondering about the "patent history" of The >> ? ? Internet.?? Clearly there was a lot of innovation in those days.?? >> ? ? My recollection is that very little was patented, even if only to >> ? ? make sure no one else could.?? Maybe someone will document the >> ? ? patent-related aspects of Internet History someday. >> >> ? ? /Jack Haverty >> >> >> >> ? ? On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: >>> ? ? jack, you've raised my curiosity with respect to: >>> >>> ? ? ? ? ... There >>> ? ? ? ? *is* ARPANET IMP software which was recently restored and a small >>> ? ? ? ? ARPANET was run using simulated IMP hardware. >>> >>> ? ? Who/What/When/Where/Why? >>> >>> ? ? geoff >>> >>> ? ? On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history >>> ? ? >> ? ? > wrote: >>> >>> ? ? ? ? Lukasz, >>> >>> ? ? ? ? I think that the earliest implementations of TTL called it >>> ? ? ? ? "Time", but >>> ? ? ? ? I'm not aware that anyone actually used time per se in >>> ? ? ? ? gateways, at >>> ? ? ? ? least in the early days (1977-1982 or so).? >>> >>> ? ? ? ? TCP implementations didn't do anything with TTL other than >>> ? ? ? ? set it on >>> ? ? ? ? outgoing datagrams, and at least in my implementation (TCP >>> ? ? ? ? for Unix), it >>> ? ? ? ? was just set to some arbitrary value.? Until we had some data >>> ? ? ? ? from >>> ? ? ? ? experimentation it was hard to evaluate ideas about what >>> ? ? ? ? routers, hosts, >>> ? ? ? ? et al should actually do.?? The early TCPs did use time in >>> ? ? ? ? handling >>> ? ? ? ? retransmission timers, and there was work a bit later to >>> ? ? ? ? incorporate >>> ? ? ? ? time more powerfully into TCP behavior, e.g., Van Jacobson's >>> ? ? ? ? work. >>> >>> ? ? ? ? The early gateways, IIRC, used the terminology "time", but in >>> ? ? ? ? practice >>> ? ? ? ? used just hop counts, since time measurements were difficult to >>> ? ? ? ? implement.?? The exception to that may be Dave Mills' >>> ? ? ? ? Fuzzballs, since >>> ? ? ? ? Dave was the implementor most interested in time and making >>> ? ? ? ? precise >>> ? ? ? ? measurements of network behavior.?? I *think* Dave may have >>> ? ? ? ? used time >>> ? ? ? ? values and delay-based routing amongst his "fuzzies". >>> >>> ? ? ? ? The BBN doc you're seeking might have been one of many that >>> ? ? ? ? discussed >>> ? ? ? ? the ARPANET internal mechanisms, e.g., ones with titles like >>> ? ? ? ? "Routing >>> ? ? ? ? Algorithm Improvements".? The ARPANET internal mechanisms did >>> ? ? ? ? use time.? >>> ? ? ? ? It was fairly simple in the IMPs, since the delay introduced >>> ? ? ? ? by the >>> ? ? ? ? synchronous communications lines could be easily predicted, >>> ? ? ? ? and the >>> ? ? ? ? other major component of delay was the time spent in queues, >>> ? ? ? ? which could >>> ? ? ? ? be measured fairly easily.?? >>> >>> ? ? ? ? I even found one BBN ARPANET Project QTR from circa 1975 that >>> ? ? ? ? discussed >>> ? ? ? ? the merits of the new-fangled TCP proposal that some >>> ? ? ? ? professor had >>> ? ? ? ? published -- and seemed to conclude it couldn't possibly work. >>> >>> ? ? ? ? My involvement in implementations of TCPs and gateways lasted >>> ? ? ? ? through >>> ? ? ? ? about mid-1983, so I don't know much of the detail of subsequent >>> ? ? ? ? implementations.? For the various BBN gateway/router >>> ? ? ? ? equipment, Bob >>> ? ? ? ? Hinden would probably be a good source.? The other major >>> ? ? ? ? early player >>> ? ? ? ? was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will >>> ? ? ? ? remember.?? There's also at least one paper on the Fuzzballs >>> ? ? ? ? which may >>> ? ? ? ? have some details. >>> >>> ? ? ? ? One thing I'd advise being careful of is the various >>> ? ? ? ? "specifications" in >>> ? ? ? ? RFCs.? Much of the wording in those was intentionally >>> ? ? ? ? non-prescriptive >>> ? ? ? ? (use of "should" or "may" instead of "must"), to provide as much >>> ? ? ? ? latitude as possible for experimentation with new ideas, >>> ? ? ? ? especially >>> ? ? ? ? within an AS.?? The Internet was an Experiment. >>> >>> ? ? ? ? Also, there was no consistent enforcement mechanism to assure >>> ? ? ? ? that >>> ? ? ? ? implementations actually even conformed to the "must" >>> ? ? ? ? elements.?? So >>> ? ? ? ? Reality could be very different from Specification. >>> >>> ? ? ? ? I don't know of any gateway implementations that have >>> ? ? ? ? survived.?? There >>> ? ? ? ? *is* ARPANET IMP software which was recently restored and a small >>> ? ? ? ? ARPANET was run using simulated IMP hardware.?? I still have >>> ? ? ? ? a ~1979 >>> ? ? ? ? listing of the TCP I wrote for Unix, but haven't scanned it >>> ? ? ? ? into digital >>> ? ? ? ? form yet. >>> >>> ? ? ? ? Jack >>> >>> ? ? ? ? On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: >>> ? ? ? ? > Jack, >>> ? ? ? ? > >>> ? ? ? ? > I was reading a lot of old BBN PDFs thanks to all good souls on >>> ? ? ? ? > this list that post nice URLs from time to time. >>> ? ? ? ? > >>> ? ? ? ? > I remember reading in at least one of them, that apparently >>> ? ? ? ? first >>> ? ? ? ? > TCP/IP implementations were indeed using TTL as literally >>> ? ? ? ? ?time?, >>> ? ? ? ? > not hop count. I believe there somewhere there between PDP docs >>> ? ? ? ? > and ARPANET docs I?ve read something to the effect ?and >>> ? ? ? ? from this >>> ? ? ? ? > time we changed from measuring time to simply count routing >>> ? ? ? ? hops?. >>> ? ? ? ? > Of course, right now google-fu is failing me. >>> ? ? ? ? > >>> ? ? ? ? > Quoting RFC 1009 that was already brought up, there?s quite >>> ? ? ? ? > direct ?definition? of the field: >>> ? ? ? ? > >>> ? ? ? ? > "4.8.? Time-To-Live >>> ? ? ? ? > >>> ? ? ? ? >? The Time-to-Live (TTL) field of the IP header is defined >>> ? ? ? ? to be a >>> ? ? ? ? >? timer limiting the lifetime of a datagram in the >>> ? ? ? ? Internet.? It is >>> ? ? ? ? >? an 8-bit field and the units are seconds.? This would >>> ? ? ? ? imply that >>> ? ? ? ? >? for a maximum TTL of 255 a datagram would time-out after >>> ? ? ? ? about 4 >>> ? ? ? ? >? and a quarter minutes.? Another aspect of the definition >>> ? ? ? ? requires >>> ? ? ? ? >? each gateway (or other module) that handles a datagram to >>> ? ? ? ? >? decrement the TTL by at least one, even if the elapsed >>> ? ? ? ? time was >>> ? ? ? ? >? much less than a second.? Since this is very often the >>> ? ? ? ? case, the >>> ? ? ? ? >? TTL effectively becomes a hop count limit on how far a >>> ? ? ? ? datagram >>> ? ? ? ? >? can propagate through the Internet." >>> ? ? ? ? > >>> ? ? ? ? > Were there any implementations that survived somewhere and >>> ? ? ? ? actually >>> ? ? ? ? > did exactly that - counted actual time/processing delay, >>> ? ? ? ? not hops? >>> ? ? ? ? > And if it took 2s to process packet, did they really >>> ? ? ? ? decrement TTL >>> ? ? ? ? > by two? >>> ? ? ? ? > >>> ? ? ? ? > Thanks for any pointers, >>> >>> ? ? ? ? -- >>> ? ? ? ? Internet-history mailing list >>> ? ? ? ? Internet-history at elists.isoc.org >>> ? ? ? ? >>> ? ? ? ? https://elists.isoc.org/mailman/listinfo/internet-history >>> >>> >>> >>> ? ? -- >>> ? ? Geoff.Goodfellow at iconia.com >>> ? ? living as The Truth is True >>> >>> >>> >> >> >> -- >> Geoff.Goodfellow at iconia.com >> living as The Truth is True >> >> >> From geoff at iconia.com Mon Sep 7 11:05:41 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Mon, 7 Sep 2020 08:05:41 -1000 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <867424403.4037955.1599496184673@mail.yahoo.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> Message-ID: thanks for the clarification on the MTIPs Alex... was always curious as to the MTIPs, as they seemed "unique"/"forgotten" in the history of the ARPANET and never seemed to get much if any prominence (and now understandably given that there were only two of them). the MTIPs had come to yours truly's attention in that in the Tenex host table file, Host-Name/Descriptor-File.txt as well as IIRC in the NIC's (SRI-ARC) Hosts.txt there was a descriptor field of what type (i.e. functionality) a given host provided: User, Server, TIP or MTIP. one remaining question of the MTIPs: did they only transfer data between them exclusively over the ARPANET, MTIP to MTIP only, -OR- were they used to transfer/send data from a mag tape on an MTIP to some socket & receiving process on a "server" host? if the later, the next curious/pesky question would be: what was the protocol (and corresponding socket #) used to effectuate said data transference? geoff On Mon, Sep 7, 2020 at 6:30 AM Alex McKenzie via Internet-history < internet-history at elists.isoc.org> wrote: > Geoff, > Now that I've refreshed my memory, I can say that the 2 mag tape TIPs were > installed at Global Weather Central, Offett AFB, NE, and Atmospheric > Sciences Lab, Army Electronics R&D Command, White Sands Missile Range, NM. > As I said in my previous message, the motivation was to allow the two > organizations to experiment with using the ARPAnet to replace whatever > method they were using to exchange large amounts of data. I cannot > remember the dates associated with this test, nor can I recall if it was > deemed a success. > Sorry for the previous mis-information,Alex > > On Monday, September 7, 2020, 11:01:20 AM EDT, Alex McKenzie via > Internet-history wrote: > > Geoff, > There were two mag tape TIPs, at Tinker and McClellan Air Force Bases. > The motivation was to allow the Air Force to experiment with using the > ARPAnet to replace whatever method they were using to exchange large > amounts of data. I think the test was successful and Tinker and McClellan > then decided to attach Hosts to the TIPs to continue operational use of the > net to do their data exchanges. Steve Crocker was involved in helping the > Air Force people design the Host software to use the ARPAnet, which led to > an amusing story which Steve has recounted several times (it crashed the > network, and one of the BBN people decided it was deliberate). As I recall > the test was run in the summer of 1972 and shortly after that the mag tape > hardware and software stopped being supported by BBN. > Cheers,Alex > > On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff > goodfellow via Internet-history > wrote: > > Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs > (the > TIPs that had a magnetic tape unit attached to them)? > > yours truly kinda recalls there were perhaps two of them... one being at > GWC? > > why were they created and to whom did they send their data? > > geoff > > On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < > internet-history at elists.isoc.org> wrote: > > > I can describe the genesis. The IMP code was originally for one host > > computer and several inter-IMP modems (that was what our contract > > specified), and I coded the IMP/Host and Host/IMP code for that in > > parallel with Bernie coding the DDT, etc. Then some host site wanted a > > second host on its IMP -- I think maybe UCLA for its IBM 360. ARPA > > called us and asked if the IMP could handle more than one Host. Our > > hardware guys said the Honeywell computer could support (if I remember > > correctly) up to seven interfaces which could be up to four Host > > interfaces or up to four inter-IMP modem interfaces. We looked at the > > IMP/Host and Host/IMP code and it seemed fairly easy to make it > > reentrant, so we told ARPANET "yes". Once the IMP would know how to > > handle multiple Hosts and given there was a bit in the header words > > between IMPs and Host to say "real" Host or "fake" Host, the > > possibilities were fairly clear. I implemented the reentrant IMP-host > > and host-IMP code, and Bernie changed the routines he had written or was > > writing: > > - TTY in/out > > - DDT in/out > > - parameter change packets into the IMP and trace packets out of the IMP > > - into the IMP to be discarded and statistics packets out of the IMP > > For the regular reports from IMPs to the Network Monitoring Center, a > > bit of code in the IMP could send packets to a real host; I don't > > remember which of the fake Hosts they looked like they were coming from > > -- stats maybe. > > > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > > Early on as we were coding the IMP stuff the question arose as to what > > to do > > > about the TTY [and how the hell were we to debug the damn thing]. We > did > > > several things in this regard. First I wrote a simple DDT [about as > > powerful as > > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > > around in the > > > dead hulk of the code of a stopped system to see what went wrong and > > also put > > > patches in. I believe it was originally a stand alone - the imp would > > crash or hit a > > > diagnostic trap and they we could run the DDT and look at buffers and > > counters > > > and pointers and such and generally try to figure out what happened. > > When the > > > IMP was running solidly enough [which actually happened pretty early on > > in its > > > development], I can't remember the genesis of the underlying idea, > > but we > > > thought we could route the DDT *over* the net to other IMPs and poke at > > *then*. > > > I came up with a scheme that Will [I think] thought was way too > > complicated: > > > > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From steve at shinkuro.com Mon Sep 7 11:15:35 2020 From: steve at shinkuro.com (Steve Crocker) Date: Mon, 7 Sep 2020 14:15:35 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> Message-ID: I too would be interested in learning more. I believe the IBM 729 mod IV tape drive operated at 112.5 inches per second. High density tapes were 556 chars/inch, where a character was six bits. That works out to 62,500 chars/sec or 375,000 bits/sec. It would be interesting to know the transfer rate between MTIPs. Steve On Mon, Sep 7, 2020 at 2:06 PM the keyboard of geoff goodfellow via Internet-history wrote: > thanks for the clarification on the MTIPs Alex... was always curious as to > the MTIPs, as they seemed "unique"/"forgotten" in the history of the > ARPANET and never seemed to get much if any prominence (and now > understandably given that there were only two of them). > > the MTIPs had come to yours truly's attention in that in the Tenex host > table file, Host-Name/Descriptor-File.txt as well as IIRC in the > NIC's (SRI-ARC) Hosts.txt there was a descriptor field of what > type (i.e. functionality) a given host provided: User, Server, TIP or MTIP. > > one remaining question of the MTIPs: did they only transfer data between > them exclusively over the ARPANET, MTIP to MTIP only, -OR- were they used > to transfer/send data from a mag tape on an MTIP to some socket & receiving > process on a "server" host? > > if the later, the next curious/pesky question would be: what was the > protocol (and corresponding socket #) used to effectuate said data > transference? > > geoff > > On Mon, Sep 7, 2020 at 6:30 AM Alex McKenzie via Internet-history < > internet-history at elists.isoc.org> wrote: > > > Geoff, > > Now that I've refreshed my memory, I can say that the 2 mag tape TIPs > were > > installed at Global Weather Central, Offett AFB, NE, and Atmospheric > > Sciences Lab, Army Electronics R&D Command, White Sands Missile Range, > NM. > > As I said in my previous message, the motivation was to allow the two > > organizations to experiment with using the ARPAnet to replace whatever > > method they were using to exchange large amounts of data. I cannot > > remember the dates associated with this test, nor can I recall if it was > > deemed a success. > > Sorry for the previous mis-information,Alex > > > > On Monday, September 7, 2020, 11:01:20 AM EDT, Alex McKenzie via > > Internet-history wrote: > > > > Geoff, > > There were two mag tape TIPs, at Tinker and McClellan Air Force Bases. > > The motivation was to allow the Air Force to experiment with using the > > ARPAnet to replace whatever method they were using to exchange large > > amounts of data. I think the test was successful and Tinker and > McClellan > > then decided to attach Hosts to the TIPs to continue operational use of > the > > net to do their data exchanges. Steve Crocker was involved in helping > the > > Air Force people design the Host software to use the ARPAnet, which led > to > > an amusing story which Steve has recounted several times (it crashed the > > network, and one of the BBN people decided it was deliberate). As I > recall > > the test was run in the summer of 1972 and shortly after that the mag > tape > > hardware and software stopped being supported by BBN. > > Cheers,Alex > > > > On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff > > goodfellow via Internet-history > > wrote: > > > > Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs > > (the > > TIPs that had a magnetic tape unit attached to them)? > > > > yours truly kinda recalls there were perhaps two of them... one being at > > GWC? > > > > why were they created and to whom did they send their data? > > > > geoff > > > > On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > > > I can describe the genesis. The IMP code was originally for one host > > > computer and several inter-IMP modems (that was what our contract > > > specified), and I coded the IMP/Host and Host/IMP code for that in > > > parallel with Bernie coding the DDT, etc. Then some host site wanted a > > > second host on its IMP -- I think maybe UCLA for its IBM 360. ARPA > > > called us and asked if the IMP could handle more than one Host. Our > > > hardware guys said the Honeywell computer could support (if I remember > > > correctly) up to seven interfaces which could be up to four Host > > > interfaces or up to four inter-IMP modem interfaces. We looked at the > > > IMP/Host and Host/IMP code and it seemed fairly easy to make it > > > reentrant, so we told ARPANET "yes". Once the IMP would know how to > > > handle multiple Hosts and given there was a bit in the header words > > > between IMPs and Host to say "real" Host or "fake" Host, the > > > possibilities were fairly clear. I implemented the reentrant IMP-host > > > and host-IMP code, and Bernie changed the routines he had written or > was > > > writing: > > > - TTY in/out > > > - DDT in/out > > > - parameter change packets into the IMP and trace packets out of the > IMP > > > - into the IMP to be discarded and statistics packets out of the IMP > > > For the regular reports from IMPs to the Network Monitoring Center, a > > > bit of code in the IMP could send packets to a real host; I don't > > > remember which of the fake Hosts they looked like they were coming from > > > -- stats maybe. > > > > > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > > > Early on as we were coding the IMP stuff the question arose as to > what > > > to do > > > > about the TTY [and how the hell were we to debug the damn thing]. We > > did > > > > several things in this regard. First I wrote a simple DDT [about as > > > powerful as > > > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > > > around in the > > > > dead hulk of the code of a stopped system to see what went wrong and > > > also put > > > > patches in. I believe it was originally a stand alone - the imp > would > > > crash or hit a > > > > diagnostic trap and they we could run the DDT and look at buffers and > > > counters > > > > and pointers and such and generally try to figure out what happened. > > > When the > > > > IMP was running solidly enough [which actually happened pretty early > on > > > in its > > > > development], I can't remember the genesis of the underlying idea, > > > but we > > > > thought we could route the DDT *over* the net to other IMPs and poke > at > > > *then*. > > > > I came up with a scheme that Will [I think] thought was way too > > > complicated: > > > > > > > > > > > -- > > > Internet-history mailing list > > > Internet-history at elists.isoc.org > > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > > > > > -- > > Geoff.Goodfellow at iconia.com > > living as The Truth is True > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From dave.walden.family at gmail.com Mon Sep 7 11:24:14 2020 From: dave.walden.family at gmail.com (dave walden) Date: Mon, 7 Sep 2020 14:24:14 -0400 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3 kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> Message-ID: <581404fc-c6fe-053b-bcbf-3e604d57f3e9@gmail.com> Division 6 did not become BBN Communications Corporation. Rather, the existing BBN Computer Corporation became BBN Communications Corporation and the part of Division 6 Bob Bressler was leading moved to the renamed company Communications Corporation.? The more research part of Division 6 including people like Alex McKenzie, Craig Partridge, and Steve Blumenthal remained as Division 6 along the more traditional R&D projects; perhaps fewer people went to BBN than Communications than stayed in BBN's Professional Services Group, a new name for what had been just BBN.? A year or two later, this group became BBN Systems and Technologies, and around then Divisions 4 and 6 were merged into one division (with definite approval the ARPA IPTO people from whom we got a lot of our work). On 9/7/2020 2:00 PM, Jack Haverty via Internet-history wrote: > I know little about the internal mechanisms of the Packet Radio > environment.?? But it did not move to Div6 (which became BBN > Communications Corp at some point) at least during my involvement > (roughly 1978-1990). > > From jack at 3kitty.org Mon Sep 7 11:30:25 2020 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 7 Sep 2020 11:30:25 -0700 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> Message-ID: <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote: > It would be interesting to know the > transfer rate between MTIPs. This is the kind of thing that I'd expect the ARPANET NMC (Network Measurement Center at UCLA, as opposed to NOC - Network Operations Center at BBN) might have been measuring.? I don't remember ever seeing any results or raw data from Measurements, and don't know much about that part of the History.?? Were results published somewhere and did such reports survive? /Jack From steve at shinkuro.com Mon Sep 7 11:36:18 2020 From: steve at shinkuro.com (Steve Crocker) Date: Mon, 7 Sep 2020 14:36:18 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> Message-ID: I don't think the NMC measured anything at the host level, but I could be wrong. Vint and Len copied explicitly. Steve On Mon, Sep 7, 2020 at 2:30 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote: > > It would be interesting to know the > > transfer rate between MTIPs. > This is the kind of thing that I'd expect the ARPANET NMC (Network > Measurement Center at UCLA, as opposed to NOC - Network Operations > Center at BBN) might have been measuring. I don't remember ever seeing > any results or raw data from Measurements, and don't know much about > that part of the History. Were results published somewhere and did > such reports survive? > /Jack > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From jack at 3kitty.org Mon Sep 7 11:52:47 2020 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 7 Sep 2020 11:52:47 -0700 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. In-Reply-To: <581404fc-c6fe-053b-bcbf-3e604d57f3e9@gmail.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3 kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> <581404fc-c6fe-053b-bcbf-3e604d57f3e9@gmail.com> Message-ID: <65fc63a6-f43d-75b9-cd98-963e7781adee@3kitty.org> Dave's right, the details of who and which projects went where during reorganizations were complicated and I've forgotten much of that detail.?? I should have said that the IMP-focused and network operations projects (e.g., DDN) of Div6 migrated over a few years into BBNCC, which also became more focused on X.25 networking and later even SNA, as well as selling hardware and operating networks and moving into another building.? So it became even less likely that ideas from those operational experiences would easily feed back into research efforts such as Packet Radio or vice versa (I don't know if the PR project? was still active then). /Jack On 9/7/20 11:24 AM, dave walden via Internet-history wrote: > Division 6 did not become BBN Communications Corporation. Rather, the > existing BBN Computer Corporation became BBN Communications > Corporation and the part of Division 6 Bob Bressler was leading moved > to the renamed company Communications Corporation.? The more research > part of Division 6 including people like Alex McKenzie, Craig > Partridge, and Steve Blumenthal remained as Division 6 along the more > traditional R&D projects; perhaps fewer people went to BBN than > Communications than stayed in BBN's Professional Services Group, a new > name for what had been just BBN.? A year or two later, this group > became BBN Systems and Technologies, and around then Divisions 4 and 6 > were merged into one division (with definite approval the ARPA IPTO > people from whom we got a lot of our work). > > On 9/7/2020 2:00 PM, Jack Haverty via Internet-history wrote: >> I know little about the internal mechanisms of the Packet Radio >> environment.?? But it did not move to Div6 (which became BBN >> Communications Corp at some point) at least during my involvement >> (roughly 1978-1990). >> >> From geoff at iconia.com Mon Sep 7 11:54:55 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Mon, 7 Sep 2020 08:54:55 -1000 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> Message-ID: would be curious to know WHAT did UCLA-NMC measure and HOW did it measure it? i.e. was there a "precursor" to some kind of SNMP capability that allowed UCLA-NMC to peer inside IMPs or hosts? or were their processes on (all?) the ARPANET hosts at the time that collected data from their respective OS's that the UCLA-NMC machine would then periodically poll to get the data, kind of like the Tenex RSSER job processes did with respect to sharing load avg. data among themselves? [btw, believe that unless Leonard Kleinrock is on/subscriber to the IH list, any reply sent to IH would be black holed, as the IH list is most likely configured (Joe can confirm) to only allow submissions to it from its "subscribers"... ERGO, if Len does reply, even if cc'ng the list, you'd need to then manually fwd it to the list for everyone else to see.] geoff On Mon, Sep 7, 2020 at 8:36 AM Steve Crocker via Internet-history < internet-history at elists.isoc.org> wrote: > I don't think the NMC measured anything at the host level, but I could be > wrong. Vint and Len copied explicitly. > > Steve > > > On Mon, Sep 7, 2020 at 2:30 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > > > On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote: > > > It would be interesting to know the > > > transfer rate between MTIPs. > > This is the kind of thing that I'd expect the ARPANET NMC (Network > > Measurement Center at UCLA, as opposed to NOC - Network Operations > > Center at BBN) might have been measuring. I don't remember ever seeing > > any results or raw data from Measurements, and don't know much about > > that part of the History. Were results published somewhere and did > > such reports survive? > > /Jack > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From jack at 3kitty.org Mon Sep 7 12:37:25 2020 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 7 Sep 2020 12:37:25 -0700 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> Message-ID: <3fed5cdc-d4ea-46f3-5457-3da8fe42161b@3kitty.org> Geoff, Re: "were their processes on (all?) the ARPANET hosts at the time that collected data" While I was in Licklider's group at MIT, Marc Seriff implemented a "SURVEY" system that periodically (every 15 minutes) probed ARPANET hosts and recorded their up/down status.? Nothing about performance, just whether or not they were accessible. See https://www.rfc-editor.org/rfc/rfc308.txt SURVEY was included in the "Scenarios" booklet handed out to attendees at the ICCC conference/demo in 1972 (see page 3-4 of the brochure).?? You could connect to the SURVEY system at MIT-DM and examine the availability of ARPANET hosts from the data that was being collected. At the time, Lick's vision included providing such data services as core network services.?? The DataComputer was the obvious place to store Data.? At the time, I was involved in building the MIT-DM mail server, and I had incorporated an interface to the DataComputer.? Users could mark a message for archival, and it would be transferred to the DataComputer for posterity.?? At the time, we thought their Terabit (!!!) of online storage was plenty for everyone.?? The intent was that "important" messages (technical reports, etc.) would be good to archive, while ephemeral messages ("Anybody want lunch?") would not. IIRC, the SURVEY data was also to be archived as another interesting dataset.?? But I don't remember if Marc ever implemented that, or know if any of the DataComputer artifacts have survived. In the early days of the Internet, we replicated some of that ARPANET experience in the form of the CMCC (Catenet Monitoring and Control Center), with David Floodpage as the primary implementor.? There are historical discussions of that at least in the old BBN QTRs and maybe some IENs/RFCs.?? The CMCC was a precursor to the incorporation of the gateways into the ARPANET NOC mechanisms so gateways were handled much as the IMPS were. /Jack On 9/7/20 11:54 AM, the keyboard of geoff goodfellow wrote: > would be curious to know WHAT did UCLA-NMC measure and HOW did it > measure it? > > i.e. was there?a "precursor" to some kind of SNMP capability that > allowed UCLA-NMC to peer inside IMPs or hosts? > > or were their processes on (all?) the ARPANET hosts at the time that > collected data from their respective OS's that the UCLA-NMC machine > would then periodically poll to get the data, kind of like the Tenex > RSSER job processes did with respect to sharing load avg. data among > themselves? > > [btw, believe that unless?Leonard Kleinrock > is on/subscriber to the IH list, any reply > sent to IH would be black holed, as the IH list is most likely > configured (Joe can confirm) to only allow submissions to it from its > "subscribers"... ERGO, if Len does reply, even if cc'ng the list, > you'd need to then manually fwd it to the list for everyone else to see.] > > geoff > > > On Mon, Sep 7, 2020 at 8:36 AM Steve Crocker via Internet-history > > wrote: > > I don't think the NMC measured anything at the host level, but I > could be > wrong.? Vint and Len copied explicitly. > > Steve > > > On Mon, Sep 7, 2020 at 2:30 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org > > wrote: > > > On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote: > > > It would be interesting to know the > > > transfer rate between MTIPs. > > This is the kind of thing that I'd expect the ARPANET NMC (Network > > Measurement Center at UCLA, as opposed to NOC - Network Operations > > Center at BBN) might have been measuring.? I don't remember ever > seeing > > any results or raw data from Measurements, and don't know much about > > that part of the History.? ?Were results published somewhere and did > > such reports survive? > > /Jack > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > > https://elists.isoc.org/mailman/listinfo/internet-history > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > From lars at nocrew.org Mon Sep 7 12:43:37 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 07 Sep 2020 19:43:37 +0000 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <3fed5cdc-d4ea-46f3-5457-3da8fe42161b@3kitty.org> (Jack Haverty via Internet-history's message of "Mon, 7 Sep 2020 12:37:25 -0700") References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> <3fed5cdc-d4ea-46f3-5457-3da8fe42161b@3kitty.org> Message-ID: <7w363tgyom.fsf@junk.nocrew.org> Jack Haverty wrote: > While I was in Licklider's group at MIT, Marc Seriff implemented a > "SURVEY" system that periodically (every 15 minutes) probed ARPANET > hosts and recorded their up/down status. Seriff wrote to me about SURVEY: | For a few days, the whole ARPANET was pissed at me since, in those | days, all the systems logged every connection attempt - typically to | a model 33 teletype machine sitting in front of the PDP/10 or | whatever. A decent system since the few computers on the network at | the time weren't likely to get more than a few connections a day. | All of sudden, I'm poking them once a minute or so. System managers | would come in in the morning to find paper piled behind the teletype | and, frequently, ink ribbons that had been torn to shreds! > At the time, Lick's vision included providing such data services as > core network services.?? The DataComputer was the obvious place to > store Data. I wonder where all that data went when the DataComputer ceased operations in 1980? From vgcerf at gmail.com Mon Sep 7 12:56:26 2020 From: vgcerf at gmail.com (vinton cerf) Date: Mon, 7 Sep 2020 15:56:26 -0400 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> Message-ID: I am pretty sure we did host/host or at least host/end-IMP (eg. send to fake host) tests. I generated traffic from the Sigma-7 and measured transfer rates to the destination (fake host or possibly real-host). We used statistical traffic generators in the Sigma-7 and IIRC there were fake hosts that could generate traffic in accordance to statistical parameters. We were able to collect host level and IMP level statistics from the ARPANET. When Bob Kahn and Dave Walden came to visit UCLA in Jan 1970, I programmed a lot of different traffic patterns to test bob kahn's hypotheses that there were certain weaknesses in the routing and flow control algorithms of the IMPs. vint On Mon, Sep 7, 2020 at 2:36 PM Steve Crocker wrote: > I don't think the NMC measured anything at the host level, but I could be > wrong. Vint and Len copied explicitly. > > Steve > > > On Mon, Sep 7, 2020 at 2:30 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > >> On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote: >> > It would be interesting to know the >> > transfer rate between MTIPs. >> This is the kind of thing that I'd expect the ARPANET NMC (Network >> Measurement Center at UCLA, as opposed to NOC - Network Operations >> Center at BBN) might have been measuring. I don't remember ever seeing >> any results or raw data from Measurements, and don't know much about >> that part of the History. Were results published somewhere and did >> such reports survive? >> /Jack >> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> > From jack at 3kitty.org Mon Sep 7 13:05:36 2020 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 7 Sep 2020 13:05:36 -0700 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <7w363tgyom.fsf@junk.nocrew.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> <3fed5cdc-d4ea-46f3-5457-3da8fe42161b@3kitty.org> <7w363tgyom.fsf@junk.nocrew.org> Message-ID: <952ead1f-102e-9cd5-a4f2-152d37608225@3kitty.org> Thanks, Lars.? Now that you remind me, I remember that episode.? That may have discouraged gathering more data such as throughput tests.? Consuming some computer manager's paper and ink was cause for anger, the reaction from consuming their bandwidth and cycles was too horrendous to risk. /Jack On 9/7/20 12:43 PM, Lars Brinkhoff wrote: > Jack Haverty wrote: >> While I was in Licklider's group at MIT, Marc Seriff implemented a >> "SURVEY" system that periodically (every 15 minutes) probed ARPANET >> hosts and recorded their up/down status. > Seriff wrote to me about SURVEY: > > | For a few days, the whole ARPANET was pissed at me since, in those > | days, all the systems logged every connection attempt - typically to > | a model 33 teletype machine sitting in front of the PDP/10 or > | whatever. A decent system since the few computers on the network at > | the time weren't likely to get more than a few connections a day. > | All of sudden, I'm poking them once a minute or so. System managers > | would come in in the morning to find paper piled behind the teletype > | and, frequently, ink ribbons that had been torn to shreds! > > >> At the time, Lick's vision included providing such data services as >> core network services.?? The DataComputer was the obvious place to >> store Data. > I wonder where all that data went when the DataComputer ceased > operations in 1980? From geoff at iconia.com Mon Sep 7 13:12:33 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Mon, 7 Sep 2020 10:12:33 -1000 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: <3fed5cdc-d4ea-46f3-5457-3da8fe42161b@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> <3fed5cdc-d4ea-46f3-5457-3da8fe42161b@3kitty.org> Message-ID: jack, there was a program on Tenex IIRC called HOSTAT that when invoked established a connection to your SURVEY server at MIT-DM and then downloaded and printed out your latest results in a friendly fashion. yours truly recalls visiting the folks (Hal Murray and Phil Petersen ) from time to time at CCA when in Boston and seeing the two Datacomputer storage incarnations: the first being a line of disks drives pre-arrival of the TBM monster noisy tape drive unit and it's compressor (IIRC). the second being after the TBM was installed and operational... and the washing machine sized line of "simulating" TBM Disk Drives were then used/repurposed IIRC for caching data between the ARPANET users and the TBM tape drive unit. yours truly was curious about, well, is this the only TBM device and why was it created... just for this? who had the need to store that much data like this and the budget to make such a product a viable business? the answer, of course, was: No Such Agency. geoff On Mon, Sep 7, 2020 at 9:37 AM Jack Haverty wrote: > Geoff, > > Re: "were their processes on (all?) the ARPANET hosts at the time that > collected data" > > While I was in Licklider's group at MIT, Marc Seriff implemented a > "SURVEY" system that periodically (every 15 minutes) probed ARPANET hosts > and recorded their up/down status. Nothing about performance, just whether > or not they were accessible. > > See https://www.rfc-editor.org/rfc/rfc308.txt > > SURVEY was included in the "Scenarios" booklet handed out to attendees at > the ICCC conference/demo in 1972 (see page 3-4 of the brochure). You > could connect to the SURVEY system at MIT-DM and examine the availability > of ARPANET hosts from the data that was being collected. > > At the time, Lick's vision included providing such data services as core > network services. The DataComputer was the obvious place to store Data. > At the time, I was involved in building the MIT-DM mail server, and I had > incorporated an interface to the DataComputer. Users could mark a message > for archival, and it would be transferred to the DataComputer for > posterity. At the time, we thought their Terabit (!!!) of online storage > was plenty for everyone. The intent was that "important" messages > (technical reports, etc.) would be good to archive, while ephemeral > messages ("Anybody want lunch?") would not. > > IIRC, the SURVEY data was also to be archived as another interesting > dataset. But I don't remember if Marc ever implemented that, or know if > any of the DataComputer artifacts have survived. > > In the early days of the Internet, we replicated some of that ARPANET > experience in the form of the CMCC (Catenet Monitoring and Control Center), > with David Floodpage as the primary implementor. There are historical > discussions of that at least in the old BBN QTRs and maybe some > IENs/RFCs. The CMCC was a precursor to the incorporation of the gateways > into the ARPANET NOC mechanisms so gateways were handled much as the IMPS > were. > > /Jack > > > > On 9/7/20 11:54 AM, the keyboard of geoff goodfellow wrote: > > would be curious to know WHAT did UCLA-NMC measure and HOW did it measure > it? > > i.e. was there a "precursor" to some kind of SNMP capability that allowed > UCLA-NMC to peer inside IMPs or hosts? > > or were their processes on (all?) the ARPANET hosts at the time that > collected data from their respective OS's that the UCLA-NMC machine would > then periodically poll to get the data, kind of like the Tenex RSSER job > processes did with respect to sharing load avg. data among themselves? > > [btw, believe that unless Leonard Kleinrock is > on/subscriber to the IH list, any reply sent to IH would be black holed, as > the IH list is most likely configured (Joe can confirm) to only allow > submissions to it from its "subscribers"... ERGO, if Len does reply, even > if cc'ng the list, you'd need to then manually fwd it to the list for > everyone else to see.] > > geoff > > > On Mon, Sep 7, 2020 at 8:36 AM Steve Crocker via Internet-history < > internet-history at elists.isoc.org> wrote: > >> I don't think the NMC measured anything at the host level, but I could be >> wrong. Vint and Len copied explicitly. >> >> Steve >> >> >> On Mon, Sep 7, 2020 at 2:30 PM Jack Haverty via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >> > On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote: >> > > It would be interesting to know the >> > > transfer rate between MTIPs. >> > This is the kind of thing that I'd expect the ARPANET NMC (Network >> > Measurement Center at UCLA, as opposed to NOC - Network Operations >> > Center at BBN) might have been measuring. I don't remember ever seeing >> > any results or raw data from Measurements, and don't know much about >> > that part of the History. Were results published somewhere and did >> > such reports survive? >> > /Jack >> > >> > -- >> > Internet-history mailing list >> > Internet-history at elists.isoc.org >> > https://elists.isoc.org/mailman/listinfo/internet-history >> > >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> >> > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From amckenzie3 at yahoo.com Mon Sep 7 13:26:00 2020 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Mon, 7 Sep 2020 20:26:00 +0000 (UTC) Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> Message-ID: <1085132283.1107108.1599510360228@mail.yahoo.com> Geoff, As far as I can recall, the only actual use of the mag tape TIPs was to transfer data from one to another.? However, I believe they implemented a (undoubtedly small) subset of FTP so in theory they could have exchanged data with other Hosts.? I know no details of their actual use (if any).? I don't know what bandwidth they achieved although the ARPAnet design would not have allowed them to exceed the bandwidth of a single IMP-IMP phone circuit, and those were almost all 50kbs.? If there were any measurements of performance in the field it would have been by GWC and/or ASL, not the NOC or NMC.? I think it is fair to say the mag tape TIP was an experiment that didn't catch on. Cheers,Alex On Monday, September 7, 2020, 2:06:27 PM EDT, the keyboard of geoff goodfellow wrote: thanks for the clarification on the MTIPs Alex... was always curious as to the MTIPs, as they seemed "unique"/"forgotten" in the history of the ARPANET and never seemed to get much if any?prominence (and now understandably?given that there were only two of them). the MTIPs had come to yours truly's attention in that in the Tenex host table file, Host-Name/Descriptor-File.txt as well as IIRC in the NIC's (SRI-ARC) Hosts.txt there was a descriptor field of what type?(i.e. functionality) a given host provided: User, Server, TIP or MTIP. one remaining question of the MTIPs: did they only transfer data between them exclusively over the ARPANET, MTIP to MTIP only, -OR- were they used to transfer/send data from a mag tape on an MTIP to some socket & receiving process on a "server" host? if the later, the next curious/pesky question would be: what was the protocol (and corresponding socket #) used to effectuate said data transference??geoff On Mon, Sep 7, 2020 at 6:30 AM Alex McKenzie via Internet-history wrote: ?Geoff, Now that I've refreshed my memory, I can say that the 2 mag tape TIPs were installed at Global Weather Central, Offett AFB, NE, and Atmospheric Sciences Lab, Army Electronics R&D Command, White Sands Missile Range, NM.? As I said in my previous message, the motivation was to allow the two organizations? to experiment with using the ARPAnet to replace whatever method they were using to exchange large amounts of data.? I cannot remember the dates associated with this test, nor can I recall if it was deemed a success. Sorry for the previous mis-information,Alex ? ? On Monday, September 7, 2020, 11:01:20 AM EDT, Alex McKenzie via Internet-history wrote:? ? Geoff, There were two mag tape TIPs, at Tinker and McClellan Air Force Bases.? The motivation was to allow the Air Force to experiment with using the ARPAnet to replace whatever method they were using to exchange large amounts of data.? I think the test was successful and Tinker and McClellan then decided to attach Hosts to the TIPs to continue operational use of the net to do their data exchanges.? Steve Crocker was involved in helping the Air Force people design the Host software to use the ARPAnet, which led to an amusing story which Steve has recounted several times (it crashed the network, and one of the BBN people decided it was deliberate).? As I recall the test was run in the summer of 1972 and shortly after that the mag tape hardware and software stopped being supported by BBN. Cheers,Alex ? ? On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff goodfellow via Internet-history wrote:? ?Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs (the TIPs that had a magnetic tape unit attached to them)? yours truly kinda recalls there were perhaps two of them... one being at GWC? why were they created and to whom did they send their data? geoff On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < internet-history at elists.isoc.org> wrote: > I can describe the genesis.? The IMP code was originally for one host > computer and several inter-IMP modems (that was what our contract > specified), and I coded the IMP/Host and Host/IMP code for that in > parallel with Bernie coding the DDT, etc. Then some host site wanted a > second host on its IMP -- I think maybe UCLA for its IBM 360.? ARPA > called us and asked if the IMP could handle more than one Host.? Our > hardware guys said the Honeywell computer could support (if I remember > correctly) up to seven interfaces which could be up to four Host > interfaces or up to four inter-IMP modem interfaces.? We looked at the > IMP/Host and Host/IMP code and it seemed fairly easy to make it > reentrant, so we told ARPANET "yes".? Once the IMP would know how to > handle multiple Hosts and given there was a bit in the header words > between IMPs and Host to say "real" Host or "fake" Host, the > possibilities were fairly clear.? I implemented the reentrant IMP-host > and host-IMP code, and Bernie changed the routines he had written or was > writing: > - TTY in/out > - DDT in/out > - parameter change packets into the IMP and trace packets out of the IMP > - into the IMP to be discarded and statistics packets out of the IMP > For the regular reports from IMPs to the Network Monitoring Center, a > bit of code in the IMP could send packets to a real host; I don't > remember which of the fake Hosts they looked like they were coming from > -- stats maybe. > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > Early on as we were coding the IMP stuff the question arose as to what > to do > > about the TTY [and how the hell were we to debug the damn thing].? We did > > several things in this regard.? First I wrote a simple DDT [about as > powerful as > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > around in the > > dead hulk of the code of a stopped system to see what went wrong and > also put > > patches in.? I believe it was originally a stand alone - the imp would > crash or hit a > > diagnostic trap and they we could run the DDT and look at buffers and > counters > > and pointers and such and generally try to figure out what happened. > When the > > IMP was running solidly enough [which actually happened pretty early on > in its > > development],? I can't remember the genesis of the underlying idea, > but? we > > thought we could route the DDT *over* the net to other IMPs and poke at > *then*. > > I came up with a scheme that Will [I think] thought was way too > complicated: > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history ? -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history -- Geoff.Goodfellow at iconia.com living as The Truth is True From amckenzie3 at yahoo.com Mon Sep 7 13:44:40 2020 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Mon, 7 Sep 2020 20:44:40 +0000 (UTC) Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> Message-ID: <473718283.4103758.1599511480307@mail.yahoo.com> Geoff, The NOC in the early 1970s was interested in the up/down status of IMPs, lines, and eventually Hosts, diagnosing IMP failures, and coordinating IMP software releases. The NOC also published network? traffic statistics to ARPA and via the RFC series to the NWG.? The NMC was interested in measuring the internal performance of the network under both real and artificial load, looking at things like queue lengths, packet lifetimes, maximum achievable throughputs, end-to-end delays, and so on.? In some sense they were responsible for telling ARPA whether the network BBN delivered met the specs of the RFQ.? They were also interested in comparing the actually performance to the predictions of queuing theory.? They made extensive use of traffic generation tools and statistics reporting tools built into the IMPs by BBN as "fake hosts", and collected? and analyzed the data on their Sigma-7.? Their experiments were often disruptive of network performance as seen by other Hosts, and therefore their experiment times were scheduled and controlled by the NOC.? This led to a certain degree of tension between the personnel at the NOC and the NMC, but nothing that couldn't be handled.? I believe the first publication of the NMC's work was a paper by Gerald Cole (one of Kleinrock's students) titled "Performance Measurements on the ARPA Computer Network" in the Proceedings of the ACM second symposium on Problems in the optimizations of data communications systems January 1971. Hope this helps,Alex On Monday, September 7, 2020, 2:55:50 PM EDT, the keyboard of geoff goodfellow via Internet-history wrote: would be curious to know WHAT did UCLA-NMC measure and HOW did it measure it? i.e. was there a "precursor" to some kind of SNMP capability that allowed UCLA-NMC to peer inside IMPs or hosts? or were their processes on (all?) the ARPANET hosts at the time that collected data from their respective OS's that the UCLA-NMC machine would then periodically poll to get the data, kind of like the Tenex RSSER job processes did with respect to sharing load avg. data among themselves? [btw, believe that unless Leonard Kleinrock is on/subscriber to the IH list, any reply sent to IH would be black holed, as the IH list is most likely configured (Joe can confirm) to only allow submissions to it from its "subscribers"... ERGO, if Len does reply, even if cc'ng the list, you'd need to then manually fwd it to the list for everyone else to see.] geoff On Mon, Sep 7, 2020 at 8:36 AM Steve Crocker via Internet-history < internet-history at elists.isoc.org> wrote: > I don't think the NMC measured anything at the host level, but I could be > wrong.? Vint and Len copied explicitly. > > Steve > > > On Mon, Sep 7, 2020 at 2:30 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > > > On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote: > > > It would be interesting to know the > > > transfer rate between MTIPs. > > This is the kind of thing that I'd expect the ARPANET NMC (Network > > Measurement Center at UCLA, as opposed to NOC - Network Operations > > Center at BBN) might have been measuring.? I don't remember ever seeing > > any results or raw data from Measurements, and don't know much about > > that part of the History.? Were results published somewhere and did > > such reports survive? > > /Jack > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From craig at tereschau.net Mon Sep 7 15:30:15 2020 From: craig at tereschau.net (Craig Partridge) Date: Mon, 7 Sep 2020 16:30:15 -0600 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> Message-ID: Two quick followups to Jack's note. Dave Mills wrote a retrospective on the Fuzzball in 1988 in SIGCOMM '88. ( https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf). When I knew the Packet Radio work, it was supervised by Jil Westcott (Div 4) and there was a rack of PRs in a computer room in 10 Moulton right by the bridge. Data rates, even over a few feet, were painfully slow and the late Charlie Lynn was the lead programmer. I have a vague recollection (perhaps wrong) of Charlie commenting that the links were so bad, that getting even minimal information between the devices was a challenge. Craig On Mon, Sep 7, 2020 at 12:00 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > Hi Barbara, > > Packet Radio artifacts of any kind were elusive (at least in 2013 when > we searched), except for a few conference papers. Specifically, we were > looking for things like QTRs or other project reports that SRI > presumably submitted to ARPA, analogous to the BBN QTRs. We found a > lot of the BBN reports online at DTIC, but little from SRI. I'm not > sure, but the BBN QTRs may have been found by the search engine because > I had the BBN/ARPA contract numbers involved, but I didn't know the > appropriate contract numbers for the SRI (or any other) contracts. > > Not much detail about Fuzzballs, or Port Expanders, or other such boxes > that were prolific in the early days of the Internet. Google wasn't > much help, but that may be from lack of knowledge in how to best use the > search mechanisms. > > IMHO, there wasn't as much collaboration between the ARPANET and Packet > Radio as there was with the Internet/Gateway work at BBN. > > BBN had internal structure that to some extent influenced the > "technology transfer" between projects. In particular there were two > "divisions", Div4 and Div6, that both did similar computer and network > research. Div6 was where the ARPANET project began and evolved to an > operational service over the ten years preceding the Internet, so there > was a lot of operational experience and war wounds there. Div4 was > where the Packet Radio work was done, along with lots of other things, > such as TENEX. Both were very competent, but had different experiences. > > Although the technical staffs of the two divisions got along pretty > well, pragmatic details limited collaboration. We were physically > located in separate buildings, so hallway encounters and casual > interactions were less likely. Interesting "teaching events" that > occurred in the ARPANET propagated quickly through Div6 where the NOC > was literally just down the hallway, less so to Div4. Cross-charging > (charging your time to the other Division's project) was possible but > discouraged. > > The "Gateway Project" began in Div4, where Ginny Strazisar implemented > the first gateway; I don't know if that was a separate > project/contract, or just a part of the Packet Radio contract at the > time. Some few years later, as it became desirable for the Internet to > stabilize and become an operational service, ARPA moved the gateway work > from Div4 to Div6, folding it into the "Internet Project" contract that > was my responsibility at the time (it included various TCP > implementations, SATNET, WBNET, Remote Site Maintenance, etc.). > > That was the point where we started injecting "ARPANET DNA" into the > Internet/gateways, blatantly adopting ARPANET techniques as the most > obvious (to us in Div6) way to get the Internet to be as managed as the > ARPANET. > > I know little about the internal mechanisms of the Packet Radio > environment. But it did not move to Div6 (which became BBN > Communications Corp at some point) at least during my involvement > (roughly 1978-1990). > > So I suspect that the Packet Radio system did not reuse much of the IMP > ideas/techniques, especially the ones that were rather mundane and not > well documented or publicized (such as the "reload from neighbor" > idea). The Packet Radio QTRs, if they survive, would probably answer > that question. > > I've often wondered, from a historical perspective now, to what extent > things like internal corporate structure and organizational decisions > influenced the design and implementation of the Internet. > > /Jack > > > On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: > > Because of BBN's involvement, I am thinking Packet Radio might have > reused many of the same ideas as the IMPs for loading new software from > another node. Do you know this was not the case? I never needed to look at > that part of the code. > > I remember using XNET for examination of the Packet Radio station. Given > your recent email it sounds like you looked for old Packet Radio station > software and couldn't find it. Is this correct? > > I don't think Rockwell released their Packet Radio software in the late > 70s/early 80s. I would have to contact Rockwell if I thought bugs required > a change to a packet radio, versus the Packet Radio station, when I worked > at BBN. I know several years later SRI did get some of their code because > I implemented one of the new routing algorithms ( I am pretty sure it was > called threshold distance vector routing if anyone is interested). BTW, I > think the software may have only been tested in a simulator due to delays > in the delivery of the LPR (Low Cost Packet Radio). This was during the > SURAN program. > > The first demo of Packet Radio and ARPANET in 1976 involved submitting > the status report. Don Nielson would probably remember if that was done > through anything like email. Below is a link to an article that discusses > this event. The text from the article mentions email but more importantly > it has a link to a podcast with Don. I didn't know this podcast existed so > I still need to listen to it. I can see why you might think the report > submission may have been done by using a telnet connection to a SRI host > that had email. > > > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > > barbara > > On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via > Internet-history wrote: > > > > Hi Geoff - thanks for that bit of history and kudos! > > > > I think there's an Internet connection in your experience. I'm not sure > > what, legally, "wireless email" means. But I suspect that email was > > being sent and received, wirelessly, well before even 1982, if only to > > and from the SRI Packet Radio van that could occasionally be seen then > > roaming around the Bay Area. > > > > Of course, technically, that probably involved a Telnet connection, > > wirelessly, to some PDP-10 running an email program. But, legally, it > > might meet the court accepted definition of "wireless email". I > > learned from the lawyers that much of litigation involves arguing about > > the meaning of words and phrases. > > > > So, perhaps someone could have looked for mouldering Packet Radio (aka > > PR) hardware and software, and demonstrated wireless email circa 1978 > > over one or more PRNETs. > > > > Sadly, although I was pretty sure that interesting "prior art" would be > > found in the PR environment, we had little success 7 years ago while > > trying to find anything that might show exactly how PR equipment > > "downloaded instructions". > > > > There's remarkably little readily discoverable material about lots of > > the computer and network systems of the 70s/80s, especially internal > > details of operation, tools, procedures, etc. Plenty of stuff on > > Routing, but little on other mechanisms, or other types of networks of > > that era, at least that the lawyers and I could find. IMHO, that's a > > huge gap even in Internet History, since the Internet did not evolve in > > a vacuum, was itself composed of more than the ARPANET, and was > > surrounded by competitors (remember multiprotocol routers). > > > > /Jack > > > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > >> Jack, you're a Most Eloquent purveyor of history and that WHY explain > >> is exactly what yours truly was hoping for... Thank You for the > >> elucidation! :D > >> > >> along the lines vis-a-vis: > >> > >> So, that's a bit about the "Why", for history to ponder. The > >> experience got me wondering about the "patent history" of The > >> Internet. Clearly there was a lot of innovation in those days. > >> My recollection is that very little was patented, even if only to > >> make sure no one else could. Maybe someone will document the > >> patent-related aspects of Internet History someday. > >> > >> please excuse/pardon this immodesty: yours truly had a kinda similar > >> "lawyered" experience with respect to WHO was the purported > >> "inventor"/originator of wireless email in a patent litigation case > >> and the "challenge" of finding/presenting any extant legally > >> submissive "artifactual proof" to that effect -- for which John > >> Markoff at the New York Times wrote about in this 2006 article: > >> > >> In Silicon Valley, a Man Without a Patent > >> > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > >> > >> for which some links of "proof" exist -- for some stuff mentioned in > >> the above NYT article -- on my website https://iconia.com/ under > >> "wireless email" (in case any historians are duly interested)... > >> > >> geoff > >> > >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty >> > wrote: > >> > >> Geoff, > >> > >> Dave's IEEE paper does an excellent job of the > >> Who/What/When/Where. He's right that it was about 7 years ago. > >> Time flies... but I guess it's still "recent" when viewed as part > >> of Internet History. > >> > >> For the curious, I can add a bit more about the Why. > >> > >> Sometime in 2013, I got an email out of the blue from Charlie > >> Neuhauser, someone I didn't recognize or remember at all, asking > >> if I was the "Jack Haverty" who authored IEN 158 - documenting the > >> XNET protocol in 1980. Figuring that the statute of limitations > >> must have expired after 30+ years, I cautiously said yes. Over > >> the next few days, he hooked me up with the lawyers who were > >> involved in a patent dispute - one that had been going on for > >> several decades by then. In fact, the patent involved had been > >> issued, ran its 17 year lifetime, and expired, but there was still > >> litigation in process about whether or not the patent was valid, > >> and 17 years of violations were alleged cause for compensation in > >> the many millions. For the next few years I was involved in the > >> battles, working with the lawyers scattered all over the country. > >> I never met any of them. All our work was done by email and > >> telephone. No Zoom then or we probably would have used it. > >> > >> The core issue in the patent battle concerned "downloading > >> instructions", mechanisms such as would be involved in patching or > >> issuing new software releases to remote equipment. XNET seemed > >> to them to possibly have something to do with that, hence the > >> interest. The goal was to find hard evidence that such procedures > >> were being done by 1980, which would prove that prior art > >> existed. Hard evidence literally means "hard" - opinions help, > >> but physical equipment and running code is much more impressive in > >> a courtroom. > >> > >> They hadn't found any XNET artifacts, and I couldn't point them to > >> any surviving implementations. But I pointed out that my XNET > >> document simply captured the technology that we "stole" from the > >> ARPANET IMP experience, and that the IMPs routinely "downloaded > >> code" from their neighbors and the NOC all during the life of the > >> ARPANET. > >> > >> Since the IMPs had existed since the early 70s, that really > >> sparked their interest, and a search (worldwide) ensued to find > >> old IMPs, in the hope that just maybe one of them still had the > >> IMP software in its magnetic-core memory. A few IMPs were > >> located, but none were functional. The one in the museum at UCLA > >> seemed promising, but the owners were reluctant to even hook it up > >> to power after sitting idle for so many years, expecting it might > >> go up in smoke. > >> > >> Then I learned from the BBN alumni mailing list that an ancient > >> IMP listing had been found in a basement. The story from that > >> point is pretty well described in Dave's paper. > >> > >> Personally, it was an interesting experience. I worked > >> extensively with one lawyer in San Diego. I taught him how > >> computers and networks actually work; he taught me a lot about the > >> legal system regarding patents. IMHO, they are equally > >> convoluted and complex when viewed from the other's perspective. > >> > >> I also learned a lot about the IMP code, which I had never even > >> looked at while I was at BBN. One task I took on was to > >> exhaustively analyze the parts of the IMP code that implemented > >> the "download new instructions" functionality, writing up an > >> instruction-by-instruction description of how the code > >> accomplished that by interacting with a neighboring IMP. It was > >> a very clever design, and extremely tight code, even including > >> self-modifying instructions. Not easy to figure out (or explain > >> in language amenable to a non-technical judge or jury). So there > >> was great interest in being able to demonstrate the code in action > >> using real software from the 70s and hardware simulators. > >> Tangible evidence is much better than even expert opinions. > >> > >> The whole legal project came to a sudden end just a few months > >> prior to the first court date. I was looking forward to going > >> to Delaware (legal action was filed in Federal court in Delaware), > >> and finally meeting some of the people. But the parties settled > >> suddenly, the case was dropped, and AFAIK the patent question was > >> never resolved. > >> > >> So, that's a bit about the "Why", for history to ponder. The > >> experience got me wondering about the "patent history" of The > >> Internet. Clearly there was a lot of innovation in those days. > >> My recollection is that very little was patented, even if only to > >> make sure no one else could. Maybe someone will document the > >> patent-related aspects of Internet History someday. > >> > >> /Jack Haverty > >> > >> > >> > >> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > >>> jack, you've raised my curiosity with respect to: > >>> > >>> ... There > >>> *is* ARPANET IMP software which was recently restored and a > small > >>> ARPANET was run using simulated IMP hardware. > >>> > >>> Who/What/When/Where/Why? > >>> > >>> geoff > >>> > >>> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history > >>> >>> > wrote: > >>> > >>> Lukasz, > >>> > >>> I think that the earliest implementations of TTL called it > >>> "Time", but > >>> I'm not aware that anyone actually used time per se in > >>> gateways, at > >>> least in the early days (1977-1982 or so). > >>> > >>> TCP implementations didn't do anything with TTL other than > >>> set it on > >>> outgoing datagrams, and at least in my implementation (TCP > >>> for Unix), it > >>> was just set to some arbitrary value. Until we had some data > >>> from > >>> experimentation it was hard to evaluate ideas about what > >>> routers, hosts, > >>> et al should actually do. The early TCPs did use time in > >>> handling > >>> retransmission timers, and there was work a bit later to > >>> incorporate > >>> time more powerfully into TCP behavior, e.g., Van Jacobson's > >>> work. > >>> > >>> The early gateways, IIRC, used the terminology "time", but in > >>> practice > >>> used just hop counts, since time measurements were difficult to > >>> implement. The exception to that may be Dave Mills' > >>> Fuzzballs, since > >>> Dave was the implementor most interested in time and making > >>> precise > >>> measurements of network behavior. I *think* Dave may have > >>> used time > >>> values and delay-based routing amongst his "fuzzies". > >>> > >>> The BBN doc you're seeking might have been one of many that > >>> discussed > >>> the ARPANET internal mechanisms, e.g., ones with titles like > >>> "Routing > >>> Algorithm Improvements". The ARPANET internal mechanisms did > >>> use time. > >>> It was fairly simple in the IMPs, since the delay introduced > >>> by the > >>> synchronous communications lines could be easily predicted, > >>> and the > >>> other major component of delay was the time spent in queues, > >>> which could > >>> be measured fairly easily. > >>> > >>> I even found one BBN ARPANET Project QTR from circa 1975 that > >>> discussed > >>> the merits of the new-fangled TCP proposal that some > >>> professor had > >>> published -- and seemed to conclude it couldn't possibly work. > >>> > >>> My involvement in implementations of TCPs and gateways lasted > >>> through > >>> about mid-1983, so I don't know much of the detail of > subsequent > >>> implementations. For the various BBN gateway/router > >>> equipment, Bob > >>> Hinden would probably be a good source. The other major > >>> early player > >>> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will > >>> remember. There's also at least one paper on the Fuzzballs > >>> which may > >>> have some details. > >>> > >>> One thing I'd advise being careful of is the various > >>> "specifications" in > >>> RFCs. Much of the wording in those was intentionally > >>> non-prescriptive > >>> (use of "should" or "may" instead of "must"), to provide as > much > >>> latitude as possible for experimentation with new ideas, > >>> especially > >>> within an AS. The Internet was an Experiment. > >>> > >>> Also, there was no consistent enforcement mechanism to assure > >>> that > >>> implementations actually even conformed to the "must" > >>> elements. So > >>> Reality could be very different from Specification. > >>> > >>> I don't know of any gateway implementations that have > >>> survived. There > >>> *is* ARPANET IMP software which was recently restored and a > small > >>> ARPANET was run using simulated IMP hardware. I still have > >>> a ~1979 > >>> listing of the TCP I wrote for Unix, but haven't scanned it > >>> into digital > >>> form yet. > >>> > >>> Jack > >>> > >>> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > >>> > Jack, > >>> > > >>> > I was reading a lot of old BBN PDFs thanks to all good souls > on > >>> > this list that post nice URLs from time to time. > >>> > > >>> > I remember reading in at least one of them, that apparently > >>> first > >>> > TCP/IP implementations were indeed using TTL as literally > >>> ?time?, > >>> > not hop count. I believe there somewhere there between PDP > docs > >>> > and ARPANET docs I?ve read something to the effect ?and > >>> from this > >>> > time we changed from measuring time to simply count routing > >>> hops?. > >>> > Of course, right now google-fu is failing me. > >>> > > >>> > Quoting RFC 1009 that was already brought up, there?s quite > >>> > direct ?definition? of the field: > >>> > > >>> > "4.8. Time-To-Live > >>> > > >>> > The Time-to-Live (TTL) field of the IP header is defined > >>> to be a > >>> > timer limiting the lifetime of a datagram in the > >>> Internet. It is > >>> > an 8-bit field and the units are seconds. This would > >>> imply that > >>> > for a maximum TTL of 255 a datagram would time-out after > >>> about 4 > >>> > and a quarter minutes. Another aspect of the definition > >>> requires > >>> > each gateway (or other module) that handles a datagram to > >>> > decrement the TTL by at least one, even if the elapsed > >>> time was > >>> > much less than a second. Since this is very often the > >>> case, the > >>> > TTL effectively becomes a hop count limit on how far a > >>> datagram > >>> > can propagate through the Internet." > >>> > > >>> > Were there any implementations that survived somewhere and > >>> actually > >>> > did exactly that - counted actual time/processing delay, > >>> not hops? > >>> > And if it took 2s to process packet, did they really > >>> decrement TTL > >>> > by two? > >>> > > >>> > Thanks for any pointers, > >>> > >>> -- > >>> Internet-history mailing list > >>> Internet-history at elists.isoc.org > >>> > >>> https://elists.isoc.org/mailman/listinfo/internet-history > >>> > >>> > >>> > >>> -- > >>> Geoff.Goodfellow at iconia.com > >>> living as The Truth is True > >>> > >>> > >>> > >> > >> > >> -- > >> Geoff.Goodfellow at iconia.com > >> living as The Truth is True > >> > >> > >> > > -- > 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 craig at tereschau.net Mon Sep 7 15:49:50 2020 From: craig at tereschau.net (Craig Partridge) Date: Mon, 7 Sep 2020 16:49:50 -0600 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> Message-ID: On Mon, Sep 7, 2020 at 12:55 PM the keyboard of geoff goodfellow via Internet-history wrote: > > i.e. was there a "precursor" to some kind of SNMP capability that allowed > UCLA-NMC to peer inside IMPs or hosts? > There was certainly something as Bernie Cosell published RFC 218 to say that the format of reporting status reporting was changing from text to binary. RFC 381 (Walden and McQuillan) lists information the host could extract from its local IMP about the state of the network. Much much later there were tools such as the Host Monitoring Protocol (HMP), which despite its name, was used to monitor BBN routers. See IEN-197 and RFC-869 and view the contents of the messages as rough guidance. I wrote an implementation of HMP in late 1984 or early 1985 and discovered the data I got back did not conform to RFC-869 in any way, shape or form. Fond memory. The first HMP packet I sent was to 128.89.01 from the Sun workstation on my desk. 128.89.01 was the BBN router between our interior Ethernet (vs. net 8, which was our internal ARPANET) and ARPANET. I got no reply, so I read through my code, thought it was right, and tried again. My phone rang -- it was Mike Brescia asking if I was trying to send an HMP packet to his router. I said yes, and his reply was, "you've got the bytes swapped in the password field." Better than ICMP! Craig -- ***** Craig Partridge's email account for professional society activities and mailing lists. From jack at 3kitty.org Mon Sep 7 16:14:28 2020 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 7 Sep 2020 16:14:28 -0700 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> Message-ID: <897d71f4-53bd-5e2f-4b09-6150959b9412@3kitty.org> Two other relevant recollections came to mind... Mike Brescia was for a while a human Internet NOC.? He would watch the Internet (specifically the gateways under our control), and the gateways reported various anomalies they detected. Another "who's looking over my shoulder" MikeNOC incident occurred when someone was apparently just bringing up a new TCP implementation (somewhere in the Midwest IIRC).? Mike noticed that the gateways were getting lots of checksum errors, but only from one host.? So he captured some "bad" datagrams, noticed swapped bytes somewhere, looked up the host info in the NIC, and emailed the relevant contact person recommending swapping the particular header byte fields.?? Shortly thereafter, he received email something like "Hey, thanks, that was the problem!"??? A little while later, after the programmer realized the suggestion had come from 1000 miles away, Mike received another email, "How the hell did you do that?". Such monitoring activity continued.? Much later, we created a tool that was used to capture packets as they pased through an IMP, and send them back to Cambridge for analysis.? We used that feature (not sure if it was the existing feature or we had to add some code) to capture IP datagrams, basically the IP header plus at least some of the next level protocol.?? It was invaluable within DDN to help various user systems come online with their brand-new TCP-based implementations by big government contractors.?? We could look at datagrams as they entered or exitted a host, rather than just at a gateway, which usually wasn't in the host-host path at that stage of DDN evolution anyway. Word about the tool spread around, and before long there were network customers who refused to purchase IMPs unless they also got the monitoring tool.?? So it became an official product - the BBNCC "Remote Datascope". Moral - Protocols and algorithms are great, but tools make networks work. /Jack On 9/7/20 3:49 PM, Craig Partridge via Internet-history wrote: > On Mon, Sep 7, 2020 at 12:55 PM the keyboard of geoff goodfellow via > Internet-history wrote: > >> i.e. was there a "precursor" to some kind of SNMP capability that allowed >> UCLA-NMC to peer inside IMPs or hosts? >> > There was certainly something as Bernie Cosell published RFC 218 to say > that the format of reporting status reporting was changing from text to > binary. > > RFC 381 (Walden and McQuillan) lists information the host could extract > from its local IMP about the state of the network. > > Much much later there were tools such as the Host Monitoring Protocol > (HMP), which despite its name, was used to monitor BBN routers. See > IEN-197 and RFC-869 and view the contents of the messages as rough > guidance. I wrote an implementation of HMP in late 1984 or early 1985 and > discovered the data I got back did not conform to RFC-869 in any way, shape > or form. > > Fond memory. The first HMP packet I sent was to 128.89.01 from the Sun > workstation on my desk. 128.89.01 was the BBN router between our interior > Ethernet (vs. net 8, which was our internal ARPANET) and ARPANET. I got no > reply, so I read through my code, thought it was right, and tried again. > My phone rang -- it was Mike Brescia asking if I was trying to send an HMP > packet to his router. I said yes, and his reply was, "you've got the bytes > swapped in the password field." Better than ICMP! > > Craig From j at shoch.com Mon Sep 7 16:16:10 2020 From: j at shoch.com (John Shoch) Date: Mon, 7 Sep 2020 16:16:10 -0700 Subject: [ih] Internet-history Digest, Vol 12, Issue 36 In-Reply-To: References: Message-ID: Well, I'm not sure of the time frame for that comment on Packet Radio Network performance, but we had a better experience. At the 6th Data Comm. Symposium in the fall of 1979 [over 40 years ago] we reported 12-20 Kbps, internetwork end-to-end: https://dl.acm.org/doi/10.1145/800092.802993 --With support from Vint and SRI we used the PRNet as a transit network, part of our PUP internet deployment. --Running our regular test programs we got 12-15 Kbps through 3 networks (reliable byte streams, Alto-Ethernet-PUP Gateway-PRNet-PUP Gateway-Ethernet-Alto). --I presume that included network-specific fragmentation and reassembly required for the PRNet, which had a smaller native packet size than a PUP packet. --We apparently tweaked some PRNet parameters and got the throughput up to 20 Kbps. --That link ran in parallel with our 9.2 Kbps phone line, at the time. --We did have to sort out a few issues -- "...it is worth noting that the Ethernet and the Radionet are systems whose overall performance differs by at least two decimal orders of magnitude -- a range which will continue to challenge the design of good flow control and congestion control procedures." It was a fun time; kudos to SRI and everyone else.... John Shoch Date: Mon, 7 Sep 2020 16:30:15 -0600 From: Craig Partridge To: Craig Partridge via Internet-history Subject: Re: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) Message-ID: Content-Type: text/plain; charset="UTF-8" Two quick followups to Jack's note. Dave Mills wrote a retrospective on the Fuzzball in 1988 in SIGCOMM '88. ( https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf). When I knew the Packet Radio work, it was supervised by Jil Westcott (Div 4) and there was a rack of PRs in a computer room in 10 Moulton right by the bridge. Data rates, even over a few feet, were painfully slow and the late Charlie Lynn was the lead programmer. I have a vague recollection (perhaps wrong) of Charlie commenting that the links were so bad, that getting even minimal information between the devices was a challenge. Craig On Mon, Sep 7, 2020 at 3:30 PM wrote: > Send Internet-history mailing list submissions to > internet-history at elists.isoc.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://elists.isoc.org/mailman/listinfo/internet-history > or, via email, send a message with subject or body 'help' to > internet-history-request at elists.isoc.org > > You can reach the person managing the list at > internet-history-owner at elists.isoc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Internet-history digest..." > > > Today's Topics: > > 1. Re: inter IMP hackery [was Recently restored and a small > ARPANET was run using simulated IMP hardware, ] (Alex McKenzie) > 2. Re: inter IMP hackery [was Recently restored and a small > ARPANET was run using simulated IMP hardware, ] (Alex McKenzie) > 3. Re: Recently restored and a small ARPANET was run using > simulated IMP hardware. (was: TTL [was Exterior Gateway > Protocol]) (Craig Partridge) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Sep 2020 20:26:00 +0000 (UTC) > From: Alex McKenzie > To: Internet-history > Subject: Re: [ih] inter IMP hackery [was Recently restored and a small > ARPANET was run using simulated IMP hardware, ] > Message-ID: <1085132283.1107108.1599510360228 at mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > Geoff, > As far as I can recall, the only actual use of the mag tape TIPs was to > transfer data from one to another.? However, I believe they implemented a > (undoubtedly small) subset of FTP so in theory they could have exchanged > data with other Hosts.? I know no details of their actual use (if any).? I > don't know what bandwidth they achieved although the ARPAnet design would > not have allowed them to exceed the bandwidth of a single IMP-IMP phone > circuit, and those were almost all 50kbs.? If there were any measurements > of performance in the field it would have been by GWC and/or ASL, not the > NOC or NMC.? I think it is fair to say the mag tape TIP was an experiment > that didn't catch on. > > Cheers,Alex > > On Monday, September 7, 2020, 2:06:27 PM EDT, the keyboard of geoff > goodfellow wrote: > > thanks for the clarification on the MTIPs Alex... was always curious as > to the MTIPs, as they seemed "unique"/"forgotten" in the history of the > ARPANET and never seemed to get much if any?prominence (and now > understandably?given that there were only two of them). > the MTIPs had come to yours truly's attention in that in the Tenex host > table file, Host-Name/Descriptor-File.txt as well as IIRC in the > NIC's (SRI-ARC) Hosts.txt there was a descriptor field of what > type?(i.e. functionality) a given host provided: User, Server, TIP or MTIP. > one remaining question of the MTIPs: did they only transfer data between > them exclusively over the ARPANET, MTIP to MTIP only, -OR- were they used > to transfer/send data from a mag tape on an MTIP to some socket & receiving > process on a "server" host? > if the later, the next curious/pesky question would be: what was the > protocol (and corresponding socket #) used to effectuate said data > transference??geoff > On Mon, Sep 7, 2020 at 6:30 AM Alex McKenzie via Internet-history < > internet-history at elists.isoc.org> wrote: > > ?Geoff, > Now that I've refreshed my memory, I can say that the 2 mag tape TIPs were > installed at Global Weather Central, Offett AFB, NE, and Atmospheric > Sciences Lab, Army Electronics R&D Command, White Sands Missile Range, NM.? > As I said in my previous message, the motivation was to allow the two > organizations? to experiment with using the ARPAnet to replace whatever > method they were using to exchange large amounts of data.? I cannot > remember the dates associated with this test, nor can I recall if it was > deemed a success. > Sorry for the previous mis-information,Alex > > ? ? On Monday, September 7, 2020, 11:01:20 AM EDT, Alex McKenzie via > Internet-history wrote:? > > ? Geoff, > There were two mag tape TIPs, at Tinker and McClellan Air Force Bases.? > The motivation was to allow the Air Force to experiment with using the > ARPAnet to replace whatever method they were using to exchange large > amounts of data.? I think the test was successful and Tinker and McClellan > then decided to attach Hosts to the TIPs to continue operational use of the > net to do their data exchanges.? Steve Crocker was involved in helping the > Air Force people design the Host software to use the ARPAnet, which led to > an amusing story which Steve has recounted several times (it crashed the > network, and one of the BBN people decided it was deliberate).? As I recall > the test was run in the summer of 1972 and shortly after that the mag tape > hardware and software stopped being supported by BBN. > Cheers,Alex > > ? ? On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff > goodfellow via Internet-history > wrote:? > > ?Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs > (the > TIPs that had a magnetic tape unit attached to them)? > > yours truly kinda recalls there were perhaps two of them... one being at > GWC? > > why were they created and to whom did they send their data? > > geoff > > On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < > internet-history at elists.isoc.org> wrote: > > > I can describe the genesis.? The IMP code was originally for one host > > computer and several inter-IMP modems (that was what our contract > > specified), and I coded the IMP/Host and Host/IMP code for that in > > parallel with Bernie coding the DDT, etc. Then some host site wanted a > > second host on its IMP -- I think maybe UCLA for its IBM 360.? ARPA > > called us and asked if the IMP could handle more than one Host.? Our > > hardware guys said the Honeywell computer could support (if I remember > > correctly) up to seven interfaces which could be up to four Host > > interfaces or up to four inter-IMP modem interfaces.? We looked at the > > IMP/Host and Host/IMP code and it seemed fairly easy to make it > > reentrant, so we told ARPANET "yes".? Once the IMP would know how to > > handle multiple Hosts and given there was a bit in the header words > > between IMPs and Host to say "real" Host or "fake" Host, the > > possibilities were fairly clear.? I implemented the reentrant IMP-host > > and host-IMP code, and Bernie changed the routines he had written or was > > writing: > > - TTY in/out > > - DDT in/out > > - parameter change packets into the IMP and trace packets out of the IMP > > - into the IMP to be discarded and statistics packets out of the IMP > > For the regular reports from IMPs to the Network Monitoring Center, a > > bit of code in the IMP could send packets to a real host; I don't > > remember which of the fake Hosts they looked like they were coming from > > -- stats maybe. > > > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > > Early on as we were coding the IMP stuff the question arose as to what > > to do > > > about the TTY [and how the hell were we to debug the damn thing].? We > did > > > several things in this regard.? First I wrote a simple DDT [about as > > powerful as > > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > > around in the > > > dead hulk of the code of a stopped system to see what went wrong and > > also put > > > patches in.? I believe it was originally a stand alone - the imp would > > crash or hit a > > > diagnostic trap and they we could run the DDT and look at buffers and > > counters > > > and pointers and such and generally try to figure out what happened. > > When the > > > IMP was running solidly enough [which actually happened pretty early on > > in its > > > development],? I can't remember the genesis of the underlying idea, > > but? we > > > thought we could route the DDT *over* the net to other IMPs and poke at > > *then*. > > > I came up with a scheme that Will [I think] thought was way too > > complicated: > > > > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > ? > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Sep 2020 20:44:40 +0000 (UTC) > From: Alex McKenzie > To: Internet-history > Subject: Re: [ih] inter IMP hackery [was Recently restored and a small > ARPANET was run using simulated IMP hardware, ] > Message-ID: <473718283.4103758.1599511480307 at mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > Geoff, > The NOC in the early 1970s was interested in the up/down status of IMPs, > lines, and eventually Hosts, diagnosing IMP failures, and coordinating IMP > software releases. The NOC also published network? traffic statistics to > ARPA and via the RFC series to the NWG.? The NMC was interested in > measuring the internal performance of the network under both real and > artificial load, looking at things like queue lengths, packet lifetimes, > maximum achievable throughputs, end-to-end delays, and so on.? In some > sense they were responsible for telling ARPA whether the network BBN > delivered met the specs of the RFQ.? They were also interested in comparing > the actually performance to the predictions of queuing theory.? They made > extensive use of traffic generation tools and statistics reporting tools > built into the IMPs by BBN as "fake hosts", and collected? and analyzed the > data on their Sigma-7.? Their experiments were often disruptive of network > performance as seen by other Hosts, and therefore the > ir experiment times were scheduled and controlled by the NOC.? This led > to a certain degree of tension between the personnel at the NOC and the > NMC, but nothing that couldn't be handled.? I believe the first publication > of the NMC's work was a paper by Gerald Cole (one of Kleinrock's students) > titled "Performance Measurements on the ARPA Computer Network" in the > Proceedings of the ACM second symposium on Problems in the optimizations of > data communications systems January 1971. > Hope this helps,Alex > > > > > > On Monday, September 7, 2020, 2:55:50 PM EDT, the keyboard of geoff > goodfellow via Internet-history > wrote: > > would be curious to know WHAT did UCLA-NMC measure and HOW did it measure > it? > > i.e. was there a "precursor" to some kind of SNMP capability that allowed > UCLA-NMC to peer inside IMPs or hosts? > > or were their processes on (all?) the ARPANET hosts at the time that > collected data from their respective OS's that the UCLA-NMC machine would > then periodically poll to get the data, kind of like the Tenex RSSER job > processes did with respect to sharing load avg. data among themselves? > > [btw, believe that unless Leonard Kleinrock is > on/subscriber to the IH list, any reply sent to IH would be black holed, as > the IH list is most likely configured (Joe can confirm) to only allow > submissions to it from its "subscribers"... ERGO, if Len does reply, even > if cc'ng the list, you'd need to then manually fwd it to the list for > everyone else to see.] > > geoff > > > On Mon, Sep 7, 2020 at 8:36 AM Steve Crocker via Internet-history < > internet-history at elists.isoc.org> wrote: > > > I don't think the NMC measured anything at the host level, but I could be > > wrong.? Vint and Len copied explicitly. > > > > Steve > > > > > > On Mon, Sep 7, 2020 at 2:30 PM Jack Haverty via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > > > On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote: > > > > It would be interesting to know the > > > > transfer rate between MTIPs. > > > This is the kind of thing that I'd expect the ARPANET NMC (Network > > > Measurement Center at UCLA, as opposed to NOC - Network Operations > > > Center at BBN) might have been measuring.? I don't remember ever seeing > > > any results or raw data from Measurements, and don't know much about > > > that part of the History.? Were results published somewhere and did > > > such reports survive? > > > /Jack > > > > > > -- > > > Internet-history mailing list > > > Internet-history at elists.isoc.org > > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Sep 2020 16:30:15 -0600 > From: Craig Partridge > To: Craig Partridge via Internet-history > > Subject: Re: [ih] Recently restored and a small ARPANET was run using > simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) > Message-ID: > < > CAHQj4Cc8TQVy_Z8CYHV_+eHocQb2YjvagVSQAPHe0ewxqZV82A at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Two quick followups to Jack's note. > > Dave Mills wrote a retrospective on the Fuzzball in 1988 in SIGCOMM '88. ( > https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf). > > When I knew the Packet Radio work, it was supervised by Jil Westcott (Div > 4) and there was a rack of PRs in a computer room in 10 Moulton right by > the bridge. Data rates, even over a few feet, were painfully slow and the > late Charlie Lynn was the lead programmer. I have a vague recollection > (perhaps wrong) of Charlie commenting that the links were so bad, that > getting even minimal information between the devices was a challenge. > > Craig > > > > On Mon, Sep 7, 2020 at 12:00 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > > > Hi Barbara, > > > > Packet Radio artifacts of any kind were elusive (at least in 2013 when > > we searched), except for a few conference papers. Specifically, we were > > looking for things like QTRs or other project reports that SRI > > presumably submitted to ARPA, analogous to the BBN QTRs. We found a > > lot of the BBN reports online at DTIC, but little from SRI. I'm not > > sure, but the BBN QTRs may have been found by the search engine because > > I had the BBN/ARPA contract numbers involved, but I didn't know the > > appropriate contract numbers for the SRI (or any other) contracts. > > > > Not much detail about Fuzzballs, or Port Expanders, or other such boxes > > that were prolific in the early days of the Internet. Google wasn't > > much help, but that may be from lack of knowledge in how to best use the > > search mechanisms. > > > > IMHO, there wasn't as much collaboration between the ARPANET and Packet > > Radio as there was with the Internet/Gateway work at BBN. > > > > BBN had internal structure that to some extent influenced the > > "technology transfer" between projects. In particular there were two > > "divisions", Div4 and Div6, that both did similar computer and network > > research. Div6 was where the ARPANET project began and evolved to an > > operational service over the ten years preceding the Internet, so there > > was a lot of operational experience and war wounds there. Div4 was > > where the Packet Radio work was done, along with lots of other things, > > such as TENEX. Both were very competent, but had different experiences. > > > > Although the technical staffs of the two divisions got along pretty > > well, pragmatic details limited collaboration. We were physically > > located in separate buildings, so hallway encounters and casual > > interactions were less likely. Interesting "teaching events" that > > occurred in the ARPANET propagated quickly through Div6 where the NOC > > was literally just down the hallway, less so to Div4. Cross-charging > > (charging your time to the other Division's project) was possible but > > discouraged. > > > > The "Gateway Project" began in Div4, where Ginny Strazisar implemented > > the first gateway; I don't know if that was a separate > > project/contract, or just a part of the Packet Radio contract at the > > time. Some few years later, as it became desirable for the Internet to > > stabilize and become an operational service, ARPA moved the gateway work > > from Div4 to Div6, folding it into the "Internet Project" contract that > > was my responsibility at the time (it included various TCP > > implementations, SATNET, WBNET, Remote Site Maintenance, etc.). > > > > That was the point where we started injecting "ARPANET DNA" into the > > Internet/gateways, blatantly adopting ARPANET techniques as the most > > obvious (to us in Div6) way to get the Internet to be as managed as the > > ARPANET. > > > > I know little about the internal mechanisms of the Packet Radio > > environment. But it did not move to Div6 (which became BBN > > Communications Corp at some point) at least during my involvement > > (roughly 1978-1990). > > > > So I suspect that the Packet Radio system did not reuse much of the IMP > > ideas/techniques, especially the ones that were rather mundane and not > > well documented or publicized (such as the "reload from neighbor" > > idea). The Packet Radio QTRs, if they survive, would probably answer > > that question. > > > > I've often wondered, from a historical perspective now, to what extent > > things like internal corporate structure and organizational decisions > > influenced the design and implementation of the Internet. > > > > /Jack > > > > > > On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: > > > Because of BBN's involvement, I am thinking Packet Radio might have > > reused many of the same ideas as the IMPs for loading new software from > > another node. Do you know this was not the case? I never needed to look > at > > that part of the code. > > > I remember using XNET for examination of the Packet Radio station. > Given > > your recent email it sounds like you looked for old Packet Radio station > > software and couldn't find it. Is this correct? > > > I don't think Rockwell released their Packet Radio software in the late > > 70s/early 80s. I would have to contact Rockwell if I thought bugs > required > > a change to a packet radio, versus the Packet Radio station, when I > worked > > at BBN. I know several years later SRI did get some of their code > because > > I implemented one of the new routing algorithms ( I am pretty sure it was > > called threshold distance vector routing if anyone is interested). BTW, I > > think the software may have only been tested in a simulator due to delays > > in the delivery of the LPR (Low Cost Packet Radio). This was during the > > SURAN program. > > > The first demo of Packet Radio and ARPANET in 1976 involved submitting > > the status report. Don Nielson would probably remember if that was done > > through anything like email. Below is a link to an article that discusses > > this event. The text from the article mentions email but more importantly > > it has a link to a podcast with Don. I didn't know this podcast existed > so > > I still need to listen to it. I can see why you might think the report > > submission may have been done by using a telnet connection to a SRI host > > that had email. > > > > > > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > > > barbara > > > On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via > > Internet-history wrote: > > > > > > Hi Geoff - thanks for that bit of history and kudos! > > > > > > I think there's an Internet connection in your experience. I'm not > sure > > > what, legally, "wireless email" means. But I suspect that email was > > > being sent and received, wirelessly, well before even 1982, if only to > > > and from the SRI Packet Radio van that could occasionally be seen then > > > roaming around the Bay Area. > > > > > > Of course, technically, that probably involved a Telnet connection, > > > wirelessly, to some PDP-10 running an email program. But, legally, it > > > might meet the court accepted definition of "wireless email". I > > > learned from the lawyers that much of litigation involves arguing about > > > the meaning of words and phrases. > > > > > > So, perhaps someone could have looked for mouldering Packet Radio (aka > > > PR) hardware and software, and demonstrated wireless email circa 1978 > > > over one or more PRNETs. > > > > > > Sadly, although I was pretty sure that interesting "prior art" would be > > > found in the PR environment, we had little success 7 years ago while > > > trying to find anything that might show exactly how PR equipment > > > "downloaded instructions". > > > > > > There's remarkably little readily discoverable material about lots of > > > the computer and network systems of the 70s/80s, especially internal > > > details of operation, tools, procedures, etc. Plenty of stuff on > > > Routing, but little on other mechanisms, or other types of networks of > > > that era, at least that the lawyers and I could find. IMHO, that's a > > > huge gap even in Internet History, since the Internet did not evolve in > > > a vacuum, was itself composed of more than the ARPANET, and was > > > surrounded by competitors (remember multiprotocol routers). > > > > > > /Jack > > > > > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > > >> Jack, you're a Most Eloquent purveyor of history and that WHY explain > > >> is exactly what yours truly was hoping for... Thank You for the > > >> elucidation! :D > > >> > > >> along the lines vis-a-vis: > > >> > > >> So, that's a bit about the "Why", for history to ponder. The > > >> experience got me wondering about the "patent history" of The > > >> Internet. Clearly there was a lot of innovation in those days. > > >> My recollection is that very little was patented, even if only to > > >> make sure no one else could. Maybe someone will document the > > >> patent-related aspects of Internet History someday. > > >> > > >> please excuse/pardon this immodesty: yours truly had a kinda similar > > >> "lawyered" experience with respect to WHO was the purported > > >> "inventor"/originator of wireless email in a patent litigation case > > >> and the "challenge" of finding/presenting any extant legally > > >> submissive "artifactual proof" to that effect -- for which John > > >> Markoff at the New York Times wrote about in this 2006 article: > > >> > > >> In Silicon Valley, a Man Without a Patent > > >> > > > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > > >> > > >> for which some links of "proof" exist -- for some stuff mentioned in > > >> the above NYT article -- on my website https://iconia.com/ under > > >> "wireless email" (in case any historians are duly interested)... > > >> > > >> geoff > > >> > > >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > >> > wrote: > > >> > > >> Geoff, > > >> > > >> Dave's IEEE paper does an excellent job of the > > >> Who/What/When/Where. He's right that it was about 7 years ago. > > >> Time flies... but I guess it's still "recent" when viewed as part > > >> of Internet History. > > >> > > >> For the curious, I can add a bit more about the Why. > > >> > > >> Sometime in 2013, I got an email out of the blue from Charlie > > >> Neuhauser, someone I didn't recognize or remember at all, asking > > >> if I was the "Jack Haverty" who authored IEN 158 - documenting the > > >> XNET protocol in 1980. Figuring that the statute of limitations > > >> must have expired after 30+ years, I cautiously said yes. Over > > >> the next few days, he hooked me up with the lawyers who were > > >> involved in a patent dispute - one that had been going on for > > >> several decades by then. In fact, the patent involved had been > > >> issued, ran its 17 year lifetime, and expired, but there was still > > >> litigation in process about whether or not the patent was valid, > > >> and 17 years of violations were alleged cause for compensation in > > >> the many millions. For the next few years I was involved in the > > >> battles, working with the lawyers scattered all over the country. > > >> I never met any of them. All our work was done by email and > > >> telephone. No Zoom then or we probably would have used it. > > >> > > >> The core issue in the patent battle concerned "downloading > > >> instructions", mechanisms such as would be involved in patching or > > >> issuing new software releases to remote equipment. XNET seemed > > >> to them to possibly have something to do with that, hence the > > >> interest. The goal was to find hard evidence that such procedures > > >> were being done by 1980, which would prove that prior art > > >> existed. Hard evidence literally means "hard" - opinions help, > > >> but physical equipment and running code is much more impressive in > > >> a courtroom. > > >> > > >> They hadn't found any XNET artifacts, and I couldn't point them to > > >> any surviving implementations. But I pointed out that my XNET > > >> document simply captured the technology that we "stole" from the > > >> ARPANET IMP experience, and that the IMPs routinely "downloaded > > >> code" from their neighbors and the NOC all during the life of the > > >> ARPANET. > > >> > > >> Since the IMPs had existed since the early 70s, that really > > >> sparked their interest, and a search (worldwide) ensued to find > > >> old IMPs, in the hope that just maybe one of them still had the > > >> IMP software in its magnetic-core memory. A few IMPs were > > >> located, but none were functional. The one in the museum at UCLA > > >> seemed promising, but the owners were reluctant to even hook it up > > >> to power after sitting idle for so many years, expecting it might > > >> go up in smoke. > > >> > > >> Then I learned from the BBN alumni mailing list that an ancient > > >> IMP listing had been found in a basement. The story from that > > >> point is pretty well described in Dave's paper. > > >> > > >> Personally, it was an interesting experience. I worked > > >> extensively with one lawyer in San Diego. I taught him how > > >> computers and networks actually work; he taught me a lot about the > > >> legal system regarding patents. IMHO, they are equally > > >> convoluted and complex when viewed from the other's perspective. > > >> > > >> I also learned a lot about the IMP code, which I had never even > > >> looked at while I was at BBN. One task I took on was to > > >> exhaustively analyze the parts of the IMP code that implemented > > >> the "download new instructions" functionality, writing up an > > >> instruction-by-instruction description of how the code > > >> accomplished that by interacting with a neighboring IMP. It was > > >> a very clever design, and extremely tight code, even including > > >> self-modifying instructions. Not easy to figure out (or explain > > >> in language amenable to a non-technical judge or jury). So there > > >> was great interest in being able to demonstrate the code in action > > >> using real software from the 70s and hardware simulators. > > >> Tangible evidence is much better than even expert opinions. > > >> > > >> The whole legal project came to a sudden end just a few months > > >> prior to the first court date. I was looking forward to going > > >> to Delaware (legal action was filed in Federal court in Delaware), > > >> and finally meeting some of the people. But the parties settled > > >> suddenly, the case was dropped, and AFAIK the patent question was > > >> never resolved. > > >> > > >> So, that's a bit about the "Why", for history to ponder. The > > >> experience got me wondering about the "patent history" of The > > >> Internet. Clearly there was a lot of innovation in those days. > > >> My recollection is that very little was patented, even if only to > > >> make sure no one else could. Maybe someone will document the > > >> patent-related aspects of Internet History someday. > > >> > > >> /Jack Haverty > > >> > > >> > > >> > > >> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > > >>> jack, you've raised my curiosity with respect to: > > >>> > > >>> ... There > > >>> *is* ARPANET IMP software which was recently restored and a > > small > > >>> ARPANET was run using simulated IMP hardware. > > >>> > > >>> Who/What/When/Where/Why? > > >>> > > >>> geoff > > >>> > > >>> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history > > >>> > >>> > wrote: > > >>> > > >>> Lukasz, > > >>> > > >>> I think that the earliest implementations of TTL called it > > >>> "Time", but > > >>> I'm not aware that anyone actually used time per se in > > >>> gateways, at > > >>> least in the early days (1977-1982 or so). > > >>> > > >>> TCP implementations didn't do anything with TTL other than > > >>> set it on > > >>> outgoing datagrams, and at least in my implementation (TCP > > >>> for Unix), it > > >>> was just set to some arbitrary value. Until we had some data > > >>> from > > >>> experimentation it was hard to evaluate ideas about what > > >>> routers, hosts, > > >>> et al should actually do. The early TCPs did use time in > > >>> handling > > >>> retransmission timers, and there was work a bit later to > > >>> incorporate > > >>> time more powerfully into TCP behavior, e.g., Van Jacobson's > > >>> work. > > >>> > > >>> The early gateways, IIRC, used the terminology "time", but in > > >>> practice > > >>> used just hop counts, since time measurements were difficult > to > > >>> implement. The exception to that may be Dave Mills' > > >>> Fuzzballs, since > > >>> Dave was the implementor most interested in time and making > > >>> precise > > >>> measurements of network behavior. I *think* Dave may have > > >>> used time > > >>> values and delay-based routing amongst his "fuzzies". > > >>> > > >>> The BBN doc you're seeking might have been one of many that > > >>> discussed > > >>> the ARPANET internal mechanisms, e.g., ones with titles like > > >>> "Routing > > >>> Algorithm Improvements". The ARPANET internal mechanisms did > > >>> use time. > > >>> It was fairly simple in the IMPs, since the delay introduced > > >>> by the > > >>> synchronous communications lines could be easily predicted, > > >>> and the > > >>> other major component of delay was the time spent in queues, > > >>> which could > > >>> be measured fairly easily. > > >>> > > >>> I even found one BBN ARPANET Project QTR from circa 1975 that > > >>> discussed > > >>> the merits of the new-fangled TCP proposal that some > > >>> professor had > > >>> published -- and seemed to conclude it couldn't possibly > work. > > >>> > > >>> My involvement in implementations of TCPs and gateways lasted > > >>> through > > >>> about mid-1983, so I don't know much of the detail of > > subsequent > > >>> implementations. For the various BBN gateway/router > > >>> equipment, Bob > > >>> Hinden would probably be a good source. The other major > > >>> early player > > >>> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa > will > > >>> remember. There's also at least one paper on the Fuzzballs > > >>> which may > > >>> have some details. > > >>> > > >>> One thing I'd advise being careful of is the various > > >>> "specifications" in > > >>> RFCs. Much of the wording in those was intentionally > > >>> non-prescriptive > > >>> (use of "should" or "may" instead of "must"), to provide as > > much > > >>> latitude as possible for experimentation with new ideas, > > >>> especially > > >>> within an AS. The Internet was an Experiment. > > >>> > > >>> Also, there was no consistent enforcement mechanism to assure > > >>> that > > >>> implementations actually even conformed to the "must" > > >>> elements. So > > >>> Reality could be very different from Specification. > > >>> > > >>> I don't know of any gateway implementations that have > > >>> survived. There > > >>> *is* ARPANET IMP software which was recently restored and a > > small > > >>> ARPANET was run using simulated IMP hardware. I still have > > >>> a ~1979 > > >>> listing of the TCP I wrote for Unix, but haven't scanned it > > >>> into digital > > >>> form yet. > > >>> > > >>> Jack > > >>> > > >>> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > > >>> > Jack, > > >>> > > > >>> > I was reading a lot of old BBN PDFs thanks to all good > souls > > on > > >>> > this list that post nice URLs from time to time. > > >>> > > > >>> > I remember reading in at least one of them, that apparently > > >>> first > > >>> > TCP/IP implementations were indeed using TTL as literally > > >>> ?time?, > > >>> > not hop count. I believe there somewhere there between PDP > > docs > > >>> > and ARPANET docs I?ve read something to the effect ?and > > >>> from this > > >>> > time we changed from measuring time to simply count routing > > >>> hops?. > > >>> > Of course, right now google-fu is failing me. > > >>> > > > >>> > Quoting RFC 1009 that was already brought up, there?s quite > > >>> > direct ?definition? of the field: > > >>> > > > >>> > "4.8. Time-To-Live > > >>> > > > >>> > The Time-to-Live (TTL) field of the IP header is defined > > >>> to be a > > >>> > timer limiting the lifetime of a datagram in the > > >>> Internet. It is > > >>> > an 8-bit field and the units are seconds. This would > > >>> imply that > > >>> > for a maximum TTL of 255 a datagram would time-out after > > >>> about 4 > > >>> > and a quarter minutes. Another aspect of the definition > > >>> requires > > >>> > each gateway (or other module) that handles a datagram to > > >>> > decrement the TTL by at least one, even if the elapsed > > >>> time was > > >>> > much less than a second. Since this is very often the > > >>> case, the > > >>> > TTL effectively becomes a hop count limit on how far a > > >>> datagram > > >>> > can propagate through the Internet." > > >>> > > > >>> > Were there any implementations that survived somewhere and > > >>> actually > > >>> > did exactly that - counted actual time/processing delay, > > >>> not hops? > > >>> > And if it took 2s to process packet, did they really > > >>> decrement TTL > > >>> > by two? > > >>> > > > >>> > Thanks for any pointers, > > >>> > > >>> -- > > >>> Internet-history mailing list > > >>> Internet-history at elists.isoc.org > > >>> > > >>> https://elists.isoc.org/mailman/listinfo/internet-history > > >>> > > >>> > > >>> > > >>> -- > > >>> Geoff.Goodfellow at iconia.com > > >>> living as The Truth is True > > >>> > > >>> > > >>> > > >> > > >> > > >> -- > > >> Geoff.Goodfellow at iconia.com > > >> living as The Truth is True > > >> > > >> > > >> > > > > -- > > 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. > > > ------------------------------ > > Subject: Digest Footer > > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > > ------------------------------ > > End of Internet-history Digest, Vol 12, Issue 36 > ************************************************ > From jack at 3kitty.org Mon Sep 7 16:55:09 2020 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 7 Sep 2020 16:55:09 -0700 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> Message-ID: <4b756753-8a67-0a6e-8d95-c1a984ec40d4@3kitty.org> Thanks Craig, I remember Dave's paper but didn't know where to find it. Re: radios.?? There is an RF phenomenon called "desensing", which refers to a situation when a radio gets a very strong signal.? Even if the radio is not tuned to the frequency being transmitted by another radio, it becomes unable to hear other signals, even on the frequency it is tuned to receive. During a "Understanding Morse Code" project at MIT in the 70s, we had configured a test network with a bunch of small radio transceivers.?? They weren't very usable when close together on a lab bench, but worked fine when they were scattered down offices along the halls so they no longer desensed each other. In radio, too much signal can be as bad as not enough.? Your "rack of PRs in a computer room" may have been densensing each other, which might explain why John Schoch's system got better performance. /Jack On 9/7/20 3:30 PM, Craig Partridge via Internet-history wrote: > Two quick followups to Jack's note. > > Dave Mills wrote a retrospective on the Fuzzball in 1988 in SIGCOMM '88. ( > https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf). > > When I knew the Packet Radio work, it was supervised by Jil Westcott (Div > 4) and there was a rack of PRs in a computer room in 10 Moulton right by > the bridge. Data rates, even over a few feet, were painfully slow and the > late Charlie Lynn was the lead programmer. I have a vague recollection > (perhaps wrong) of Charlie commenting that the links were so bad, that > getting even minimal information between the devices was a challenge. > > Craig > > > > On Mon, Sep 7, 2020 at 12:00 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > >> Hi Barbara, >> >> Packet Radio artifacts of any kind were elusive (at least in 2013 when >> we searched), except for a few conference papers. Specifically, we were >> looking for things like QTRs or other project reports that SRI >> presumably submitted to ARPA, analogous to the BBN QTRs. We found a >> lot of the BBN reports online at DTIC, but little from SRI. I'm not >> sure, but the BBN QTRs may have been found by the search engine because >> I had the BBN/ARPA contract numbers involved, but I didn't know the >> appropriate contract numbers for the SRI (or any other) contracts. >> >> Not much detail about Fuzzballs, or Port Expanders, or other such boxes >> that were prolific in the early days of the Internet. Google wasn't >> much help, but that may be from lack of knowledge in how to best use the >> search mechanisms. >> >> IMHO, there wasn't as much collaboration between the ARPANET and Packet >> Radio as there was with the Internet/Gateway work at BBN. >> >> BBN had internal structure that to some extent influenced the >> "technology transfer" between projects. In particular there were two >> "divisions", Div4 and Div6, that both did similar computer and network >> research. Div6 was where the ARPANET project began and evolved to an >> operational service over the ten years preceding the Internet, so there >> was a lot of operational experience and war wounds there. Div4 was >> where the Packet Radio work was done, along with lots of other things, >> such as TENEX. Both were very competent, but had different experiences. >> >> Although the technical staffs of the two divisions got along pretty >> well, pragmatic details limited collaboration. We were physically >> located in separate buildings, so hallway encounters and casual >> interactions were less likely. Interesting "teaching events" that >> occurred in the ARPANET propagated quickly through Div6 where the NOC >> was literally just down the hallway, less so to Div4. Cross-charging >> (charging your time to the other Division's project) was possible but >> discouraged. >> >> The "Gateway Project" began in Div4, where Ginny Strazisar implemented >> the first gateway; I don't know if that was a separate >> project/contract, or just a part of the Packet Radio contract at the >> time. Some few years later, as it became desirable for the Internet to >> stabilize and become an operational service, ARPA moved the gateway work >> from Div4 to Div6, folding it into the "Internet Project" contract that >> was my responsibility at the time (it included various TCP >> implementations, SATNET, WBNET, Remote Site Maintenance, etc.). >> >> That was the point where we started injecting "ARPANET DNA" into the >> Internet/gateways, blatantly adopting ARPANET techniques as the most >> obvious (to us in Div6) way to get the Internet to be as managed as the >> ARPANET. >> >> I know little about the internal mechanisms of the Packet Radio >> environment. But it did not move to Div6 (which became BBN >> Communications Corp at some point) at least during my involvement >> (roughly 1978-1990). >> >> So I suspect that the Packet Radio system did not reuse much of the IMP >> ideas/techniques, especially the ones that were rather mundane and not >> well documented or publicized (such as the "reload from neighbor" >> idea). The Packet Radio QTRs, if they survive, would probably answer >> that question. >> >> I've often wondered, from a historical perspective now, to what extent >> things like internal corporate structure and organizational decisions >> influenced the design and implementation of the Internet. >> >> /Jack >> >> >> On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: >>> Because of BBN's involvement, I am thinking Packet Radio might have >> reused many of the same ideas as the IMPs for loading new software from >> another node. Do you know this was not the case? I never needed to look at >> that part of the code. >>> I remember using XNET for examination of the Packet Radio station. Given >> your recent email it sounds like you looked for old Packet Radio station >> software and couldn't find it. Is this correct? >>> I don't think Rockwell released their Packet Radio software in the late >> 70s/early 80s. I would have to contact Rockwell if I thought bugs required >> a change to a packet radio, versus the Packet Radio station, when I worked >> at BBN. I know several years later SRI did get some of their code because >> I implemented one of the new routing algorithms ( I am pretty sure it was >> called threshold distance vector routing if anyone is interested). BTW, I >> think the software may have only been tested in a simulator due to delays >> in the delivery of the LPR (Low Cost Packet Radio). This was during the >> SURAN program. >>> The first demo of Packet Radio and ARPANET in 1976 involved submitting >> the status report. Don Nielson would probably remember if that was done >> through anything like email. Below is a link to an article that discusses >> this event. The text from the article mentions email but more importantly >> it has a link to a podcast with Don. I didn't know this podcast existed so >> I still need to listen to it. I can see why you might think the report >> submission may have been done by using a telnet connection to a SRI host >> that had email. >> https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ >>> barbara >>> On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via >> Internet-history wrote: >>> Hi Geoff - thanks for that bit of history and kudos! >>> >>> I think there's an Internet connection in your experience. I'm not sure >>> what, legally, "wireless email" means. But I suspect that email was >>> being sent and received, wirelessly, well before even 1982, if only to >>> and from the SRI Packet Radio van that could occasionally be seen then >>> roaming around the Bay Area. >>> >>> Of course, technically, that probably involved a Telnet connection, >>> wirelessly, to some PDP-10 running an email program. But, legally, it >>> might meet the court accepted definition of "wireless email". I >>> learned from the lawyers that much of litigation involves arguing about >>> the meaning of words and phrases. >>> >>> So, perhaps someone could have looked for mouldering Packet Radio (aka >>> PR) hardware and software, and demonstrated wireless email circa 1978 >>> over one or more PRNETs. >>> >>> Sadly, although I was pretty sure that interesting "prior art" would be >>> found in the PR environment, we had little success 7 years ago while >>> trying to find anything that might show exactly how PR equipment >>> "downloaded instructions". >>> >>> There's remarkably little readily discoverable material about lots of >>> the computer and network systems of the 70s/80s, especially internal >>> details of operation, tools, procedures, etc. Plenty of stuff on >>> Routing, but little on other mechanisms, or other types of networks of >>> that era, at least that the lawyers and I could find. IMHO, that's a >>> huge gap even in Internet History, since the Internet did not evolve in >>> a vacuum, was itself composed of more than the ARPANET, and was >>> surrounded by competitors (remember multiprotocol routers). >>> >>> /Jack >>> >>> On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: >>>> Jack, you're a Most Eloquent purveyor of history and that WHY explain >>>> is exactly what yours truly was hoping for... Thank You for the >>>> elucidation! :D >>>> >>>> along the lines vis-a-vis: >>>> >>>> So, that's a bit about the "Why", for history to ponder. The >>>> experience got me wondering about the "patent history" of The >>>> Internet. Clearly there was a lot of innovation in those days. >>>> My recollection is that very little was patented, even if only to >>>> make sure no one else could. Maybe someone will document the >>>> patent-related aspects of Internet History someday. >>>> >>>> please excuse/pardon this immodesty: yours truly had a kinda similar >>>> "lawyered" experience with respect to WHO was the purported >>>> "inventor"/originator of wireless email in a patent litigation case >>>> and the "challenge" of finding/presenting any extant legally >>>> submissive "artifactual proof" to that effect -- for which John >>>> Markoff at the New York Times wrote about in this 2006 article: >>>> >>>> In Silicon Valley, a Man Without a Patent >>>> >> https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html >>>> for which some links of "proof" exist -- for some stuff mentioned in >>>> the above NYT article -- on my website https://iconia.com/ under >>>> "wireless email" (in case any historians are duly interested)... >>>> >>>> geoff >>>> >>>> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty >>> > wrote: >>>> >>>> Geoff, >>>> >>>> Dave's IEEE paper does an excellent job of the >>>> Who/What/When/Where. He's right that it was about 7 years ago. >>>> Time flies... but I guess it's still "recent" when viewed as part >>>> of Internet History. >>>> >>>> For the curious, I can add a bit more about the Why. >>>> >>>> Sometime in 2013, I got an email out of the blue from Charlie >>>> Neuhauser, someone I didn't recognize or remember at all, asking >>>> if I was the "Jack Haverty" who authored IEN 158 - documenting the >>>> XNET protocol in 1980. Figuring that the statute of limitations >>>> must have expired after 30+ years, I cautiously said yes. Over >>>> the next few days, he hooked me up with the lawyers who were >>>> involved in a patent dispute - one that had been going on for >>>> several decades by then. In fact, the patent involved had been >>>> issued, ran its 17 year lifetime, and expired, but there was still >>>> litigation in process about whether or not the patent was valid, >>>> and 17 years of violations were alleged cause for compensation in >>>> the many millions. For the next few years I was involved in the >>>> battles, working with the lawyers scattered all over the country. >>>> I never met any of them. All our work was done by email and >>>> telephone. No Zoom then or we probably would have used it. >>>> >>>> The core issue in the patent battle concerned "downloading >>>> instructions", mechanisms such as would be involved in patching or >>>> issuing new software releases to remote equipment. XNET seemed >>>> to them to possibly have something to do with that, hence the >>>> interest. The goal was to find hard evidence that such procedures >>>> were being done by 1980, which would prove that prior art >>>> existed. Hard evidence literally means "hard" - opinions help, >>>> but physical equipment and running code is much more impressive in >>>> a courtroom. >>>> >>>> They hadn't found any XNET artifacts, and I couldn't point them to >>>> any surviving implementations. But I pointed out that my XNET >>>> document simply captured the technology that we "stole" from the >>>> ARPANET IMP experience, and that the IMPs routinely "downloaded >>>> code" from their neighbors and the NOC all during the life of the >>>> ARPANET. >>>> >>>> Since the IMPs had existed since the early 70s, that really >>>> sparked their interest, and a search (worldwide) ensued to find >>>> old IMPs, in the hope that just maybe one of them still had the >>>> IMP software in its magnetic-core memory. A few IMPs were >>>> located, but none were functional. The one in the museum at UCLA >>>> seemed promising, but the owners were reluctant to even hook it up >>>> to power after sitting idle for so many years, expecting it might >>>> go up in smoke. >>>> >>>> Then I learned from the BBN alumni mailing list that an ancient >>>> IMP listing had been found in a basement. The story from that >>>> point is pretty well described in Dave's paper. >>>> >>>> Personally, it was an interesting experience. I worked >>>> extensively with one lawyer in San Diego. I taught him how >>>> computers and networks actually work; he taught me a lot about the >>>> legal system regarding patents. IMHO, they are equally >>>> convoluted and complex when viewed from the other's perspective. >>>> >>>> I also learned a lot about the IMP code, which I had never even >>>> looked at while I was at BBN. One task I took on was to >>>> exhaustively analyze the parts of the IMP code that implemented >>>> the "download new instructions" functionality, writing up an >>>> instruction-by-instruction description of how the code >>>> accomplished that by interacting with a neighboring IMP. It was >>>> a very clever design, and extremely tight code, even including >>>> self-modifying instructions. Not easy to figure out (or explain >>>> in language amenable to a non-technical judge or jury). So there >>>> was great interest in being able to demonstrate the code in action >>>> using real software from the 70s and hardware simulators. >>>> Tangible evidence is much better than even expert opinions. >>>> >>>> The whole legal project came to a sudden end just a few months >>>> prior to the first court date. I was looking forward to going >>>> to Delaware (legal action was filed in Federal court in Delaware), >>>> and finally meeting some of the people. But the parties settled >>>> suddenly, the case was dropped, and AFAIK the patent question was >>>> never resolved. >>>> >>>> So, that's a bit about the "Why", for history to ponder. The >>>> experience got me wondering about the "patent history" of The >>>> Internet. Clearly there was a lot of innovation in those days. >>>> My recollection is that very little was patented, even if only to >>>> make sure no one else could. Maybe someone will document the >>>> patent-related aspects of Internet History someday. >>>> >>>> /Jack Haverty >>>> >>>> >>>> >>>> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: >>>>> jack, you've raised my curiosity with respect to: >>>>> >>>>> ... There >>>>> *is* ARPANET IMP software which was recently restored and a >> small >>>>> ARPANET was run using simulated IMP hardware. >>>>> >>>>> Who/What/When/Where/Why? >>>>> >>>>> geoff >>>>> >>>>> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history >>>>> >>>> > wrote: >>>>> >>>>> Lukasz, >>>>> >>>>> I think that the earliest implementations of TTL called it >>>>> "Time", but >>>>> I'm not aware that anyone actually used time per se in >>>>> gateways, at >>>>> least in the early days (1977-1982 or so). >>>>> >>>>> TCP implementations didn't do anything with TTL other than >>>>> set it on >>>>> outgoing datagrams, and at least in my implementation (TCP >>>>> for Unix), it >>>>> was just set to some arbitrary value. Until we had some data >>>>> from >>>>> experimentation it was hard to evaluate ideas about what >>>>> routers, hosts, >>>>> et al should actually do. The early TCPs did use time in >>>>> handling >>>>> retransmission timers, and there was work a bit later to >>>>> incorporate >>>>> time more powerfully into TCP behavior, e.g., Van Jacobson's >>>>> work. >>>>> >>>>> The early gateways, IIRC, used the terminology "time", but in >>>>> practice >>>>> used just hop counts, since time measurements were difficult to >>>>> implement. The exception to that may be Dave Mills' >>>>> Fuzzballs, since >>>>> Dave was the implementor most interested in time and making >>>>> precise >>>>> measurements of network behavior. I *think* Dave may have >>>>> used time >>>>> values and delay-based routing amongst his "fuzzies". >>>>> >>>>> The BBN doc you're seeking might have been one of many that >>>>> discussed >>>>> the ARPANET internal mechanisms, e.g., ones with titles like >>>>> "Routing >>>>> Algorithm Improvements". The ARPANET internal mechanisms did >>>>> use time. >>>>> It was fairly simple in the IMPs, since the delay introduced >>>>> by the >>>>> synchronous communications lines could be easily predicted, >>>>> and the >>>>> other major component of delay was the time spent in queues, >>>>> which could >>>>> be measured fairly easily. >>>>> >>>>> I even found one BBN ARPANET Project QTR from circa 1975 that >>>>> discussed >>>>> the merits of the new-fangled TCP proposal that some >>>>> professor had >>>>> published -- and seemed to conclude it couldn't possibly work. >>>>> >>>>> My involvement in implementations of TCPs and gateways lasted >>>>> through >>>>> about mid-1983, so I don't know much of the detail of >> subsequent >>>>> implementations. For the various BBN gateway/router >>>>> equipment, Bob >>>>> Hinden would probably be a good source. The other major >>>>> early player >>>>> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will >>>>> remember. There's also at least one paper on the Fuzzballs >>>>> which may >>>>> have some details. >>>>> >>>>> One thing I'd advise being careful of is the various >>>>> "specifications" in >>>>> RFCs. Much of the wording in those was intentionally >>>>> non-prescriptive >>>>> (use of "should" or "may" instead of "must"), to provide as >> much >>>>> latitude as possible for experimentation with new ideas, >>>>> especially >>>>> within an AS. The Internet was an Experiment. >>>>> >>>>> Also, there was no consistent enforcement mechanism to assure >>>>> that >>>>> implementations actually even conformed to the "must" >>>>> elements. So >>>>> Reality could be very different from Specification. >>>>> >>>>> I don't know of any gateway implementations that have >>>>> survived. There >>>>> *is* ARPANET IMP software which was recently restored and a >> small >>>>> ARPANET was run using simulated IMP hardware. I still have >>>>> a ~1979 >>>>> listing of the TCP I wrote for Unix, but haven't scanned it >>>>> into digital >>>>> form yet. >>>>> >>>>> Jack >>>>> >>>>> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: >>>>> > Jack, >>>>> > >>>>> > I was reading a lot of old BBN PDFs thanks to all good souls >> on >>>>> > this list that post nice URLs from time to time. >>>>> > >>>>> > I remember reading in at least one of them, that apparently >>>>> first >>>>> > TCP/IP implementations were indeed using TTL as literally >>>>> ?time?, >>>>> > not hop count. I believe there somewhere there between PDP >> docs >>>>> > and ARPANET docs I?ve read something to the effect ?and >>>>> from this >>>>> > time we changed from measuring time to simply count routing >>>>> hops?. >>>>> > Of course, right now google-fu is failing me. >>>>> > >>>>> > Quoting RFC 1009 that was already brought up, there?s quite >>>>> > direct ?definition? of the field: >>>>> > >>>>> > "4.8. Time-To-Live >>>>> > >>>>> > The Time-to-Live (TTL) field of the IP header is defined >>>>> to be a >>>>> > timer limiting the lifetime of a datagram in the >>>>> Internet. It is >>>>> > an 8-bit field and the units are seconds. This would >>>>> imply that >>>>> > for a maximum TTL of 255 a datagram would time-out after >>>>> about 4 >>>>> > and a quarter minutes. Another aspect of the definition >>>>> requires >>>>> > each gateway (or other module) that handles a datagram to >>>>> > decrement the TTL by at least one, even if the elapsed >>>>> time was >>>>> > much less than a second. Since this is very often the >>>>> case, the >>>>> > TTL effectively becomes a hop count limit on how far a >>>>> datagram >>>>> > can propagate through the Internet." >>>>> > >>>>> > Were there any implementations that survived somewhere and >>>>> actually >>>>> > did exactly that - counted actual time/processing delay, >>>>> not hops? >>>>> > And if it took 2s to process packet, did they really >>>>> decrement TTL >>>>> > by two? >>>>> > >>>>> > Thanks for any pointers, >>>>> >>>>> -- >>>>> Internet-history mailing list >>>>> Internet-history at elists.isoc.org >>>>> >>>>> https://elists.isoc.org/mailman/listinfo/internet-history >>>>> >>>>> >>>>> >>>>> -- >>>>> Geoff.Goodfellow at iconia.com >>>>> living as The Truth is True >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Geoff.Goodfellow at iconia.com >>>> living as The Truth is True >>>> >>>> >>>> >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> > From craig at tereschau.net Mon Sep 7 19:23:48 2020 From: craig at tereschau.net (Craig Partridge) Date: Mon, 7 Sep 2020 20:23:48 -0600 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: <4b756753-8a67-0a6e-8d95-c1a984ec40d4@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> <4b756753-8a67-0a6e-8d95-c1a984ec40d4@3kitty.org> Message-ID: Hi Jack: That could well be. I was not on the project -- simply worked side by side with folks who were, so (a) my memories may be defective; and (b) it is hearsay. I do remember getting a tour of the room, packed with racks of radios. Craig On Mon, Sep 7, 2020 at 5:55 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > Thanks Craig, I remember Dave's paper but didn't know where to find it. > > Re: radios. > > There is an RF phenomenon called "desensing", which refers to a > situation when a radio gets a very strong signal. Even if the radio is > not tuned to the frequency being transmitted by another radio, it > becomes unable to hear other signals, even on the frequency it is tuned > to receive. > > During a "Understanding Morse Code" project at MIT in the 70s, we had > configured a test network with a bunch of small radio transceivers. > They weren't very usable when close together on a lab bench, but worked > fine when they were scattered down offices along the halls so they no > longer desensed each other. > > In radio, too much signal can be as bad as not enough. Your "rack of > PRs in a computer room" may have been densensing each other, which might > explain why John Schoch's system got better performance. > > /Jack > > On 9/7/20 3:30 PM, Craig Partridge via Internet-history wrote: > > Two quick followups to Jack's note. > > > > Dave Mills wrote a retrospective on the Fuzzball in 1988 in SIGCOMM '88. > ( > > https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf). > > > > When I knew the Packet Radio work, it was supervised by Jil Westcott (Div > > 4) and there was a rack of PRs in a computer room in 10 Moulton right by > > the bridge. Data rates, even over a few feet, were painfully slow and > the > > late Charlie Lynn was the lead programmer. I have a vague recollection > > (perhaps wrong) of Charlie commenting that the links were so bad, that > > getting even minimal information between the devices was a challenge. > > > > Craig > > > > > > > > On Mon, Sep 7, 2020 at 12:00 PM Jack Haverty via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > >> Hi Barbara, > >> > >> Packet Radio artifacts of any kind were elusive (at least in 2013 when > >> we searched), except for a few conference papers. Specifically, we were > >> looking for things like QTRs or other project reports that SRI > >> presumably submitted to ARPA, analogous to the BBN QTRs. We found a > >> lot of the BBN reports online at DTIC, but little from SRI. I'm not > >> sure, but the BBN QTRs may have been found by the search engine because > >> I had the BBN/ARPA contract numbers involved, but I didn't know the > >> appropriate contract numbers for the SRI (or any other) contracts. > >> > >> Not much detail about Fuzzballs, or Port Expanders, or other such boxes > >> that were prolific in the early days of the Internet. Google wasn't > >> much help, but that may be from lack of knowledge in how to best use the > >> search mechanisms. > >> > >> IMHO, there wasn't as much collaboration between the ARPANET and Packet > >> Radio as there was with the Internet/Gateway work at BBN. > >> > >> BBN had internal structure that to some extent influenced the > >> "technology transfer" between projects. In particular there were two > >> "divisions", Div4 and Div6, that both did similar computer and network > >> research. Div6 was where the ARPANET project began and evolved to an > >> operational service over the ten years preceding the Internet, so there > >> was a lot of operational experience and war wounds there. Div4 was > >> where the Packet Radio work was done, along with lots of other things, > >> such as TENEX. Both were very competent, but had different > experiences. > >> > >> Although the technical staffs of the two divisions got along pretty > >> well, pragmatic details limited collaboration. We were physically > >> located in separate buildings, so hallway encounters and casual > >> interactions were less likely. Interesting "teaching events" that > >> occurred in the ARPANET propagated quickly through Div6 where the NOC > >> was literally just down the hallway, less so to Div4. Cross-charging > >> (charging your time to the other Division's project) was possible but > >> discouraged. > >> > >> The "Gateway Project" began in Div4, where Ginny Strazisar implemented > >> the first gateway; I don't know if that was a separate > >> project/contract, or just a part of the Packet Radio contract at the > >> time. Some few years later, as it became desirable for the Internet to > >> stabilize and become an operational service, ARPA moved the gateway work > >> from Div4 to Div6, folding it into the "Internet Project" contract that > >> was my responsibility at the time (it included various TCP > >> implementations, SATNET, WBNET, Remote Site Maintenance, etc.). > >> > >> That was the point where we started injecting "ARPANET DNA" into the > >> Internet/gateways, blatantly adopting ARPANET techniques as the most > >> obvious (to us in Div6) way to get the Internet to be as managed as the > >> ARPANET. > >> > >> I know little about the internal mechanisms of the Packet Radio > >> environment. But it did not move to Div6 (which became BBN > >> Communications Corp at some point) at least during my involvement > >> (roughly 1978-1990). > >> > >> So I suspect that the Packet Radio system did not reuse much of the IMP > >> ideas/techniques, especially the ones that were rather mundane and not > >> well documented or publicized (such as the "reload from neighbor" > >> idea). The Packet Radio QTRs, if they survive, would probably answer > >> that question. > >> > >> I've often wondered, from a historical perspective now, to what extent > >> things like internal corporate structure and organizational decisions > >> influenced the design and implementation of the Internet. > >> > >> /Jack > >> > >> > >> On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: > >>> Because of BBN's involvement, I am thinking Packet Radio might have > >> reused many of the same ideas as the IMPs for loading new software from > >> another node. Do you know this was not the case? I never needed to > look at > >> that part of the code. > >>> I remember using XNET for examination of the Packet Radio station. > Given > >> your recent email it sounds like you looked for old Packet Radio station > >> software and couldn't find it. Is this correct? > >>> I don't think Rockwell released their Packet Radio software in the late > >> 70s/early 80s. I would have to contact Rockwell if I thought bugs > required > >> a change to a packet radio, versus the Packet Radio station, when I > worked > >> at BBN. I know several years later SRI did get some of their code > because > >> I implemented one of the new routing algorithms ( I am pretty sure it > was > >> called threshold distance vector routing if anyone is interested). BTW, > I > >> think the software may have only been tested in a simulator due to > delays > >> in the delivery of the LPR (Low Cost Packet Radio). This was during the > >> SURAN program. > >>> The first demo of Packet Radio and ARPANET in 1976 involved submitting > >> the status report. Don Nielson would probably remember if that was done > >> through anything like email. Below is a link to an article that > discusses > >> this event. The text from the article mentions email but more > importantly > >> it has a link to a podcast with Don. I didn't know this podcast existed > so > >> I still need to listen to it. I can see why you might think the report > >> submission may have been done by using a telnet connection to a SRI host > >> that had email. > >> > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > >>> barbara > >>> On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via > >> Internet-history wrote: > >>> Hi Geoff - thanks for that bit of history and kudos! > >>> > >>> I think there's an Internet connection in your experience. I'm not > sure > >>> what, legally, "wireless email" means. But I suspect that email was > >>> being sent and received, wirelessly, well before even 1982, if only to > >>> and from the SRI Packet Radio van that could occasionally be seen then > >>> roaming around the Bay Area. > >>> > >>> Of course, technically, that probably involved a Telnet connection, > >>> wirelessly, to some PDP-10 running an email program. But, legally, it > >>> might meet the court accepted definition of "wireless email". I > >>> learned from the lawyers that much of litigation involves arguing about > >>> the meaning of words and phrases. > >>> > >>> So, perhaps someone could have looked for mouldering Packet Radio (aka > >>> PR) hardware and software, and demonstrated wireless email circa 1978 > >>> over one or more PRNETs. > >>> > >>> Sadly, although I was pretty sure that interesting "prior art" would be > >>> found in the PR environment, we had little success 7 years ago while > >>> trying to find anything that might show exactly how PR equipment > >>> "downloaded instructions". > >>> > >>> There's remarkably little readily discoverable material about lots of > >>> the computer and network systems of the 70s/80s, especially internal > >>> details of operation, tools, procedures, etc. Plenty of stuff on > >>> Routing, but little on other mechanisms, or other types of networks of > >>> that era, at least that the lawyers and I could find. IMHO, that's a > >>> huge gap even in Internet History, since the Internet did not evolve in > >>> a vacuum, was itself composed of more than the ARPANET, and was > >>> surrounded by competitors (remember multiprotocol routers). > >>> > >>> /Jack > >>> > >>> On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > >>>> Jack, you're a Most Eloquent purveyor of history and that WHY explain > >>>> is exactly what yours truly was hoping for... Thank You for the > >>>> elucidation! :D > >>>> > >>>> along the lines vis-a-vis: > >>>> > >>>> So, that's a bit about the "Why", for history to ponder. The > >>>> experience got me wondering about the "patent history" of The > >>>> Internet. Clearly there was a lot of innovation in those days. > >>>> My recollection is that very little was patented, even if only to > >>>> make sure no one else could. Maybe someone will document the > >>>> patent-related aspects of Internet History someday. > >>>> > >>>> please excuse/pardon this immodesty: yours truly had a kinda similar > >>>> "lawyered" experience with respect to WHO was the purported > >>>> "inventor"/originator of wireless email in a patent litigation case > >>>> and the "challenge" of finding/presenting any extant legally > >>>> submissive "artifactual proof" to that effect -- for which John > >>>> Markoff at the New York Times wrote about in this 2006 article: > >>>> > >>>> In Silicon Valley, a Man Without a Patent > >>>> > >> > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > >>>> for which some links of "proof" exist -- for some stuff mentioned in > >>>> the above NYT article -- on my website https://iconia.com/ under > >>>> "wireless email" (in case any historians are duly interested)... > >>>> > >>>> geoff > >>>> > >>>> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty >>>> > wrote: > >>>> > >>>> Geoff, > >>>> > >>>> Dave's IEEE paper does an excellent job of the > >>>> Who/What/When/Where. He's right that it was about 7 years ago. > >>>> Time flies... but I guess it's still "recent" when viewed as part > >>>> of Internet History. > >>>> > >>>> For the curious, I can add a bit more about the Why. > >>>> > >>>> Sometime in 2013, I got an email out of the blue from Charlie > >>>> Neuhauser, someone I didn't recognize or remember at all, asking > >>>> if I was the "Jack Haverty" who authored IEN 158 - documenting the > >>>> XNET protocol in 1980. Figuring that the statute of limitations > >>>> must have expired after 30+ years, I cautiously said yes. Over > >>>> the next few days, he hooked me up with the lawyers who were > >>>> involved in a patent dispute - one that had been going on for > >>>> several decades by then. In fact, the patent involved had been > >>>> issued, ran its 17 year lifetime, and expired, but there was still > >>>> litigation in process about whether or not the patent was valid, > >>>> and 17 years of violations were alleged cause for compensation in > >>>> the many millions. For the next few years I was involved in the > >>>> battles, working with the lawyers scattered all over the country. > >>>> I never met any of them. All our work was done by email and > >>>> telephone. No Zoom then or we probably would have used it. > >>>> > >>>> The core issue in the patent battle concerned "downloading > >>>> instructions", mechanisms such as would be involved in patching or > >>>> issuing new software releases to remote equipment. XNET seemed > >>>> to them to possibly have something to do with that, hence the > >>>> interest. The goal was to find hard evidence that such procedures > >>>> were being done by 1980, which would prove that prior art > >>>> existed. Hard evidence literally means "hard" - opinions help, > >>>> but physical equipment and running code is much more impressive in > >>>> a courtroom. > >>>> > >>>> They hadn't found any XNET artifacts, and I couldn't point them to > >>>> any surviving implementations. But I pointed out that my XNET > >>>> document simply captured the technology that we "stole" from the > >>>> ARPANET IMP experience, and that the IMPs routinely "downloaded > >>>> code" from their neighbors and the NOC all during the life of the > >>>> ARPANET. > >>>> > >>>> Since the IMPs had existed since the early 70s, that really > >>>> sparked their interest, and a search (worldwide) ensued to find > >>>> old IMPs, in the hope that just maybe one of them still had the > >>>> IMP software in its magnetic-core memory. A few IMPs were > >>>> located, but none were functional. The one in the museum at UCLA > >>>> seemed promising, but the owners were reluctant to even hook it up > >>>> to power after sitting idle for so many years, expecting it might > >>>> go up in smoke. > >>>> > >>>> Then I learned from the BBN alumni mailing list that an ancient > >>>> IMP listing had been found in a basement. The story from that > >>>> point is pretty well described in Dave's paper. > >>>> > >>>> Personally, it was an interesting experience. I worked > >>>> extensively with one lawyer in San Diego. I taught him how > >>>> computers and networks actually work; he taught me a lot about the > >>>> legal system regarding patents. IMHO, they are equally > >>>> convoluted and complex when viewed from the other's perspective. > >>>> > >>>> I also learned a lot about the IMP code, which I had never even > >>>> looked at while I was at BBN. One task I took on was to > >>>> exhaustively analyze the parts of the IMP code that implemented > >>>> the "download new instructions" functionality, writing up an > >>>> instruction-by-instruction description of how the code > >>>> accomplished that by interacting with a neighboring IMP. It was > >>>> a very clever design, and extremely tight code, even including > >>>> self-modifying instructions. Not easy to figure out (or explain > >>>> in language amenable to a non-technical judge or jury). So there > >>>> was great interest in being able to demonstrate the code in action > >>>> using real software from the 70s and hardware simulators. > >>>> Tangible evidence is much better than even expert opinions. > >>>> > >>>> The whole legal project came to a sudden end just a few months > >>>> prior to the first court date. I was looking forward to going > >>>> to Delaware (legal action was filed in Federal court in Delaware), > >>>> and finally meeting some of the people. But the parties settled > >>>> suddenly, the case was dropped, and AFAIK the patent question was > >>>> never resolved. > >>>> > >>>> So, that's a bit about the "Why", for history to ponder. The > >>>> experience got me wondering about the "patent history" of The > >>>> Internet. Clearly there was a lot of innovation in those days. > >>>> My recollection is that very little was patented, even if only to > >>>> make sure no one else could. Maybe someone will document the > >>>> patent-related aspects of Internet History someday. > >>>> > >>>> /Jack Haverty > >>>> > >>>> > >>>> > >>>> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > >>>>> jack, you've raised my curiosity with respect to: > >>>>> > >>>>> ... There > >>>>> *is* ARPANET IMP software which was recently restored and a > >> small > >>>>> ARPANET was run using simulated IMP hardware. > >>>>> > >>>>> Who/What/When/Where/Why? > >>>>> > >>>>> geoff > >>>>> > >>>>> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history > >>>>> >>>>> > wrote: > >>>>> > >>>>> Lukasz, > >>>>> > >>>>> I think that the earliest implementations of TTL called it > >>>>> "Time", but > >>>>> I'm not aware that anyone actually used time per se in > >>>>> gateways, at > >>>>> least in the early days (1977-1982 or so). > >>>>> > >>>>> TCP implementations didn't do anything with TTL other than > >>>>> set it on > >>>>> outgoing datagrams, and at least in my implementation (TCP > >>>>> for Unix), it > >>>>> was just set to some arbitrary value. Until we had some data > >>>>> from > >>>>> experimentation it was hard to evaluate ideas about what > >>>>> routers, hosts, > >>>>> et al should actually do. The early TCPs did use time in > >>>>> handling > >>>>> retransmission timers, and there was work a bit later to > >>>>> incorporate > >>>>> time more powerfully into TCP behavior, e.g., Van Jacobson's > >>>>> work. > >>>>> > >>>>> The early gateways, IIRC, used the terminology "time", but in > >>>>> practice > >>>>> used just hop counts, since time measurements were difficult > to > >>>>> implement. The exception to that may be Dave Mills' > >>>>> Fuzzballs, since > >>>>> Dave was the implementor most interested in time and making > >>>>> precise > >>>>> measurements of network behavior. I *think* Dave may have > >>>>> used time > >>>>> values and delay-based routing amongst his "fuzzies". > >>>>> > >>>>> The BBN doc you're seeking might have been one of many that > >>>>> discussed > >>>>> the ARPANET internal mechanisms, e.g., ones with titles like > >>>>> "Routing > >>>>> Algorithm Improvements". The ARPANET internal mechanisms did > >>>>> use time. > >>>>> It was fairly simple in the IMPs, since the delay introduced > >>>>> by the > >>>>> synchronous communications lines could be easily predicted, > >>>>> and the > >>>>> other major component of delay was the time spent in queues, > >>>>> which could > >>>>> be measured fairly easily. > >>>>> > >>>>> I even found one BBN ARPANET Project QTR from circa 1975 that > >>>>> discussed > >>>>> the merits of the new-fangled TCP proposal that some > >>>>> professor had > >>>>> published -- and seemed to conclude it couldn't possibly > work. > >>>>> > >>>>> My involvement in implementations of TCPs and gateways lasted > >>>>> through > >>>>> about mid-1983, so I don't know much of the detail of > >> subsequent > >>>>> implementations. For the various BBN gateway/router > >>>>> equipment, Bob > >>>>> Hinden would probably be a good source. The other major > >>>>> early player > >>>>> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa > will > >>>>> remember. There's also at least one paper on the Fuzzballs > >>>>> which may > >>>>> have some details. > >>>>> > >>>>> One thing I'd advise being careful of is the various > >>>>> "specifications" in > >>>>> RFCs. Much of the wording in those was intentionally > >>>>> non-prescriptive > >>>>> (use of "should" or "may" instead of "must"), to provide as > >> much > >>>>> latitude as possible for experimentation with new ideas, > >>>>> especially > >>>>> within an AS. The Internet was an Experiment. > >>>>> > >>>>> Also, there was no consistent enforcement mechanism to assure > >>>>> that > >>>>> implementations actually even conformed to the "must" > >>>>> elements. So > >>>>> Reality could be very different from Specification. > >>>>> > >>>>> I don't know of any gateway implementations that have > >>>>> survived. There > >>>>> *is* ARPANET IMP software which was recently restored and a > >> small > >>>>> ARPANET was run using simulated IMP hardware. I still have > >>>>> a ~1979 > >>>>> listing of the TCP I wrote for Unix, but haven't scanned it > >>>>> into digital > >>>>> form yet. > >>>>> > >>>>> Jack > >>>>> > >>>>> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > >>>>> > Jack, > >>>>> > > >>>>> > I was reading a lot of old BBN PDFs thanks to all good > souls > >> on > >>>>> > this list that post nice URLs from time to time. > >>>>> > > >>>>> > I remember reading in at least one of them, that apparently > >>>>> first > >>>>> > TCP/IP implementations were indeed using TTL as literally > >>>>> ?time?, > >>>>> > not hop count. I believe there somewhere there between PDP > >> docs > >>>>> > and ARPANET docs I?ve read something to the effect ?and > >>>>> from this > >>>>> > time we changed from measuring time to simply count routing > >>>>> hops?. > >>>>> > Of course, right now google-fu is failing me. > >>>>> > > >>>>> > Quoting RFC 1009 that was already brought up, there?s quite > >>>>> > direct ?definition? of the field: > >>>>> > > >>>>> > "4.8. Time-To-Live > >>>>> > > >>>>> > The Time-to-Live (TTL) field of the IP header is defined > >>>>> to be a > >>>>> > timer limiting the lifetime of a datagram in the > >>>>> Internet. It is > >>>>> > an 8-bit field and the units are seconds. This would > >>>>> imply that > >>>>> > for a maximum TTL of 255 a datagram would time-out after > >>>>> about 4 > >>>>> > and a quarter minutes. Another aspect of the definition > >>>>> requires > >>>>> > each gateway (or other module) that handles a datagram to > >>>>> > decrement the TTL by at least one, even if the elapsed > >>>>> time was > >>>>> > much less than a second. Since this is very often the > >>>>> case, the > >>>>> > TTL effectively becomes a hop count limit on how far a > >>>>> datagram > >>>>> > can propagate through the Internet." > >>>>> > > >>>>> > Were there any implementations that survived somewhere and > >>>>> actually > >>>>> > did exactly that - counted actual time/processing delay, > >>>>> not hops? > >>>>> > And if it took 2s to process packet, did they really > >>>>> decrement TTL > >>>>> > by two? > >>>>> > > >>>>> > Thanks for any pointers, > >>>>> > >>>>> -- > >>>>> Internet-history mailing list > >>>>> Internet-history at elists.isoc.org > >>>>> > >>>>> https://elists.isoc.org/mailman/listinfo/internet-history > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Geoff.Goodfellow at iconia.com > >>>>> living as The Truth is True > >>>>> > >>>>> > >>>>> > >>>> > >>>> -- > >>>> Geoff.Goodfellow at iconia.com > >>>> living as The Truth is True > >>>> > >>>> > >>>> > >> -- > >> 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 > -- ***** Craig Partridge's email account for professional society activities and mailing lists. From b_a_denny at yahoo.com Mon Sep 7 19:43:24 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Tue, 8 Sep 2020 02:43:24 +0000 (UTC) Subject: [ih] Internet-history Digest, Vol 12, Issue 36 In-Reply-To: References: Message-ID: <231612573.4195622.1599533004565@mail.yahoo.com> ?I believe a packet radio sent data at either 400 or 100 Kbps depending on the link quality.? ? barbara? On Monday, September 7, 2020, 04:16:40 PM PDT, John Shoch via Internet-history wrote: Well, I'm not sure of the time frame for that comment on Packet Radio Network performance, but we had a better experience. At the 6th Data Comm. Symposium in the fall of 1979 [over 40 years ago] we reported 12-20 Kbps, internetwork end-to-end: https://dl.acm.org/doi/10.1145/800092.802993 --With support from Vint and SRI we used the PRNet as a transit network, part of our PUP internet deployment. --Running our regular test programs we got 12-15 Kbps through 3 networks (reliable byte streams, Alto-Ethernet-PUP Gateway-PRNet-PUP Gateway-Ethernet-Alto). --I presume that included network-specific fragmentation and reassembly required for the PRNet, which had a smaller native packet size than a PUP packet. --We apparently tweaked some PRNet parameters and got the throughput up to 20 Kbps. --That link ran in parallel with our 9.2 Kbps phone line, at the time. --We did have to sort out a few issues -- "...it is worth noting that the Ethernet and the Radionet are systems whose overall performance differs by at least two decimal orders of magnitude -- a range which will continue to challenge the design of good flow control and congestion control procedures." It was a fun time;? kudos to SRI and everyone else.... John Shoch Date: Mon, 7 Sep 2020 16:30:15 -0600 From: Craig Partridge To: Craig Partridge via Internet-history ? ? ? ? Subject: Re: [ih] Recently restored and a small ARPANET was run using ? ? ? ? simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) Message-ID: ? ? ? ? Content-Type: text/plain; charset="UTF-8" Two quick followups to Jack's note. Dave Mills wrote a retrospective on the Fuzzball in 1988 in SIGCOMM '88. ( https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf). When I knew the Packet Radio work, it was supervised by Jil Westcott (Div 4) and there was a rack of PRs in a computer room in 10 Moulton right by the bridge.? Data rates, even over a few feet, were painfully slow and the late Charlie Lynn was the lead programmer.? I have a vague recollection (perhaps wrong) of Charlie commenting that the links were so bad, that getting even minimal information between the devices was a challenge. Craig On Mon, Sep 7, 2020 at 3:30 PM wrote: > Send Internet-history mailing list submissions to >? ? ? ? internet-history at elists.isoc.org > > To subscribe or unsubscribe via the World Wide Web, visit >? ? ? ? https://elists.isoc.org/mailman/listinfo/internet-history > or, via email, send a message with subject or body 'help' to >? ? ? ? internet-history-request at elists.isoc.org > > You can reach the person managing the list at >? ? ? ? internet-history-owner at elists.isoc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Internet-history digest..." > > > Today's Topics: > >? ? 1. Re: inter IMP hackery [was Recently restored and a small >? ? ? ARPANET was run using simulated IMP hardware, ] (Alex McKenzie) >? ? 2. Re: inter IMP hackery [was Recently restored and a small >? ? ? ARPANET was run using simulated IMP hardware, ] (Alex McKenzie) >? ? 3. Re: Recently restored and a small ARPANET was run using >? ? ? simulated IMP hardware. (was: TTL [was Exterior Gateway >? ? ? Protocol]) (Craig Partridge) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Sep 2020 20:26:00 +0000 (UTC) > From: Alex McKenzie > To: Internet-history > Subject: Re: [ih] inter IMP hackery [was Recently restored and a small >? ? ? ? ARPANET was run using simulated IMP hardware, ] > Message-ID: <1085132283.1107108.1599510360228 at mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > >? Geoff, > As far as I can recall, the only actual use of the mag tape TIPs was to > transfer data from one to another.? However, I believe they implemented a > (undoubtedly small) subset of FTP so in theory they could have exchanged > data with other Hosts.? I know no details of their actual use (if any).? I > don't know what bandwidth they achieved although the ARPAnet design would > not have allowed them to exceed the bandwidth of a single IMP-IMP phone > circuit, and those were almost all 50kbs.? If there were any measurements > of performance in the field it would have been by GWC and/or ASL, not the > NOC or NMC.? I think it is fair to say the mag tape TIP was an experiment > that didn't catch on. > > Cheers,Alex > > On Monday, September 7, 2020, 2:06:27 PM EDT, the keyboard of geoff > goodfellow wrote: > >? thanks for the clarification on the MTIPs Alex... was always curious as > to the MTIPs, as they seemed "unique"/"forgotten" in the history of the > ARPANET and never seemed to get much if any?prominence (and now > understandably?given that there were only two of them). > the MTIPs had come to yours truly's attention in that in the Tenex host > table file, Host-Name/Descriptor-File.txt as well as IIRC in the > NIC's (SRI-ARC) Hosts.txt there was a descriptor field of what > type?(i.e. functionality) a given host provided: User, Server, TIP or MTIP. > one remaining question of the MTIPs: did they only transfer data between > them exclusively over the ARPANET, MTIP to MTIP only, -OR- were they used > to transfer/send data from a mag tape on an MTIP to some socket & receiving > process on a "server" host? > if the later, the next curious/pesky question would be: what was the > protocol (and corresponding socket #) used to effectuate said data > transference??geoff > On Mon, Sep 7, 2020 at 6:30 AM Alex McKenzie via Internet-history < > internet-history at elists.isoc.org> wrote: > > ?Geoff, > Now that I've refreshed my memory, I can say that the 2 mag tape TIPs were > installed at Global Weather Central, Offett AFB, NE, and Atmospheric > Sciences Lab, Army Electronics R&D Command, White Sands Missile Range, NM.? > As I said in my previous message, the motivation was to allow the two > organizations? to experiment with using the ARPAnet to replace whatever > method they were using to exchange large amounts of data.? I cannot > remember the dates associated with this test, nor can I recall if it was > deemed a success. > Sorry for the previous mis-information,Alex > > ? ? On Monday, September 7, 2020, 11:01:20 AM EDT, Alex McKenzie via > Internet-history wrote:? > > ? Geoff, > There were two mag tape TIPs, at Tinker and McClellan Air Force Bases.? > The motivation was to allow the Air Force to experiment with using the > ARPAnet to replace whatever method they were using to exchange large > amounts of data.? I think the test was successful and Tinker and McClellan > then decided to attach Hosts to the TIPs to continue operational use of the > net to do their data exchanges.? Steve Crocker was involved in helping the > Air Force people design the Host software to use the ARPAnet, which led to > an amusing story which Steve has recounted several times (it crashed the > network, and one of the BBN people decided it was deliberate).? As I recall > the test was run in the summer of 1972 and shortly after that the mag tape > hardware and software stopped being supported by BBN. > Cheers,Alex > > ? ? On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff > goodfellow via Internet-history > wrote:? > > ?Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs > (the > TIPs that had a magnetic tape unit attached to them)? > > yours truly kinda recalls there were perhaps two of them... one being at > GWC? > > why were they created and to whom did they send their data? > > geoff > > On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history < > internet-history at elists.isoc.org> wrote: > > > I can describe the genesis.? The IMP code was originally for one host > > computer and several inter-IMP modems (that was what our contract > > specified), and I coded the IMP/Host and Host/IMP code for that in > > parallel with Bernie coding the DDT, etc. Then some host site wanted a > > second host on its IMP -- I think maybe UCLA for its IBM 360.? ARPA > > called us and asked if the IMP could handle more than one Host.? Our > > hardware guys said the Honeywell computer could support (if I remember > > correctly) up to seven interfaces which could be up to four Host > > interfaces or up to four inter-IMP modem interfaces.? We looked at the > > IMP/Host and Host/IMP code and it seemed fairly easy to make it > > reentrant, so we told ARPANET "yes".? Once the IMP would know how to > > handle multiple Hosts and given there was a bit in the header words > > between IMPs and Host to say "real" Host or "fake" Host, the > > possibilities were fairly clear.? I implemented the reentrant IMP-host > > and host-IMP code, and Bernie changed the routines he had written or was > > writing: > > - TTY in/out > > - DDT in/out > > - parameter change packets into the IMP and trace packets out of the IMP > > - into the IMP to be discarded and statistics packets out of the IMP > > For the regular reports from IMPs to the Network Monitoring Center, a > > bit of code in the IMP could send packets to a real host; I don't > > remember which of the fake Hosts they looked like they were coming from > > -- stats maybe. > > > > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote: > > > Early on as we were coding the IMP stuff the question arose as to what > > to do > > > about the TTY [and how the hell were we to debug the damn thing].? We > did > > > several things in this regard.? First I wrote a simple DDT [about as > > powerful as > > > the test-word switches on our PDP-1 :o)] but it allowed us to poke > > around in the > > > dead hulk of the code of a stopped system to see what went wrong and > > also put > > > patches in.? I believe it was originally a stand alone - the imp would > > crash or hit a > > > diagnostic trap and they we could run the DDT and look at buffers and > > counters > > > and pointers and such and generally try to figure out what happened. > > When the > > > IMP was running solidly enough [which actually happened pretty early on > > in its > > > development],? I can't remember the genesis of the underlying idea, > > but? we > > > thought we could route the DDT *over* the net to other IMPs and poke at > > *then*. > > > I came up with a scheme that Will [I think] thought was way too > > complicated: > > > > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > ? > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Sep 2020 20:44:40 +0000 (UTC) > From: Alex McKenzie > To: Internet-history > Subject: Re: [ih] inter IMP hackery [was Recently restored and a small >? ? ? ? ARPANET was run using simulated IMP hardware, ] > Message-ID: <473718283.4103758.1599511480307 at mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > >? Geoff, > The NOC in the early 1970s was interested in the up/down status of IMPs, > lines, and eventually Hosts, diagnosing IMP failures, and coordinating IMP > software releases. The NOC also published network? traffic statistics to > ARPA and via the RFC series to the NWG.? The NMC was interested in > measuring the internal performance of the network under both real and > artificial load, looking at things like queue lengths, packet lifetimes, > maximum achievable throughputs, end-to-end delays, and so on.? In some > sense they were responsible for telling ARPA whether the network BBN > delivered met the specs of the RFQ.? They were also interested in comparing > the actually performance to the predictions of queuing theory.? They made > extensive use of traffic generation tools and statistics reporting tools > built into the IMPs by BBN as "fake hosts", and collected? and analyzed the > data on their Sigma-7.? Their experiments were often disruptive of network > performance as seen by other Hosts, and therefore the >? ir experiment times were scheduled and controlled by the NOC.? This led > to a certain degree of tension between the personnel at the NOC and the > NMC, but nothing that couldn't be handled.? I believe the first publication > of the NMC's work was a paper by Gerald Cole (one of Kleinrock's students) > titled "Performance Measurements on the ARPA Computer Network" in the > Proceedings of the ACM second symposium on Problems in the optimizations of > data communications systems January 1971. > Hope this helps,Alex > > > > > >? ? On Monday, September 7, 2020, 2:55:50 PM EDT, the keyboard of geoff > goodfellow via Internet-history > wrote: > >? would be curious to know WHAT did UCLA-NMC measure and HOW did it measure > it? > > i.e. was there a "precursor" to some kind of SNMP capability that allowed > UCLA-NMC to peer inside IMPs or hosts? > > or were their processes on (all?) the ARPANET hosts at the time that > collected data from their respective OS's that the UCLA-NMC machine would > then periodically poll to get the data, kind of like the Tenex RSSER job > processes did with respect to sharing load avg. data among themselves? > > [btw, believe that unless Leonard Kleinrock is > on/subscriber to the IH list, any reply sent to IH would be black holed, as > the IH list is most likely configured (Joe can confirm) to only allow > submissions to it from its "subscribers"... ERGO, if Len does reply, even > if cc'ng the list, you'd need to then manually fwd it to the list for > everyone else to see.] > > geoff > > > On Mon, Sep 7, 2020 at 8:36 AM Steve Crocker via Internet-history < > internet-history at elists.isoc.org> wrote: > > > I don't think the NMC measured anything at the host level, but I could be > > wrong.? Vint and Len copied explicitly. > > > > Steve > > > > > > On Mon, Sep 7, 2020 at 2:30 PM Jack Haverty via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > > > On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote: > > > > It would be interesting to know the > > > > transfer rate between MTIPs. > > > This is the kind of thing that I'd expect the ARPANET NMC (Network > > > Measurement Center at UCLA, as opposed to NOC - Network Operations > > > Center at BBN) might have been measuring.? I don't remember ever seeing > > > any results or raw data from Measurements, and don't know much about > > > that part of the History.? Were results published somewhere and did > > > such reports survive? > > > /Jack > > > > > > -- > > > Internet-history mailing list > > > Internet-history at elists.isoc.org > > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Sep 2020 16:30:15 -0600 > From: Craig Partridge > To: Craig Partridge via Internet-history >? ? ? ? > Subject: Re: [ih] Recently restored and a small ARPANET was run using >? ? ? ? simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) > Message-ID: >? ? ? ? < > CAHQj4Cc8TQVy_Z8CYHV_+eHocQb2YjvagVSQAPHe0ewxqZV82A at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Two quick followups to Jack's note. > > Dave Mills wrote a retrospective on the Fuzzball in 1988 in SIGCOMM '88. ( > https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf). > > When I knew the Packet Radio work, it was supervised by Jil Westcott (Div > 4) and there was a rack of PRs in a computer room in 10 Moulton right by > the bridge.? Data rates, even over a few feet, were painfully slow and the > late Charlie Lynn was the lead programmer.? I have a vague recollection > (perhaps wrong) of Charlie commenting that the links were so bad, that > getting even minimal information between the devices was a challenge. > > Craig > > > > On Mon, Sep 7, 2020 at 12:00 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > > > Hi Barbara, > > > > Packet Radio artifacts of any kind were elusive (at least in 2013 when > > we searched), except for a few conference papers.? Specifically, we were > > looking for things like QTRs or other project reports that SRI > > presumably submitted to ARPA, analogous to the BBN QTRs.? We found a > > lot of the BBN reports online at DTIC, but little from SRI.? I'm not > > sure, but the BBN QTRs may have been found by the search engine because > > I had the BBN/ARPA contract numbers involved, but I didn't know the > > appropriate contract numbers for the SRI (or any other) contracts. > > > > Not much detail about Fuzzballs, or Port Expanders, or other such boxes > > that were prolific in the early days of the Internet.? Google wasn't > > much help, but that may be from lack of knowledge in how to best use the > > search mechanisms. > > > > IMHO, there wasn't as much collaboration between the ARPANET and Packet > > Radio as there was with the Internet/Gateway work at BBN. > > > > BBN had internal structure that to some extent influenced the > > "technology transfer" between projects.? In particular there were two > > "divisions", Div4 and Div6, that both did similar computer and network > > research.? Div6 was where the ARPANET project began and evolved to an > > operational service over the ten years preceding the Internet, so there > > was a lot of operational experience and war wounds there.? Div4 was > > where the Packet Radio work was done, along with lots of other things, > > such as TENEX.? Both were very competent, but had different experiences. > > > > Although the technical staffs of the two divisions got along pretty > > well, pragmatic details limited collaboration.? We were physically > > located in separate buildings, so hallway encounters and casual > > interactions were less likely.? Interesting "teaching events" that > > occurred in the ARPANET propagated quickly through Div6 where the NOC > > was literally just down the hallway, less so to Div4.? Cross-charging > > (charging your time to the other Division's project) was possible but > > discouraged. > > > > The "Gateway Project" began in Div4, where Ginny Strazisar implemented > > the first gateway;? I don't know if that was a separate > > project/contract, or just a part of the Packet Radio contract at the > > time.? Some few years later, as it became desirable for the Internet to > > stabilize and become an operational service, ARPA moved the gateway work > > from Div4 to Div6, folding it into the "Internet Project" contract that > > was my responsibility at the time (it included various TCP > > implementations, SATNET, WBNET, Remote Site Maintenance, etc.). > > > > That was the point where we started injecting "ARPANET DNA" into the > > Internet/gateways, blatantly adopting ARPANET techniques as the most > > obvious (to us in Div6) way to get the Internet to be as managed as the > > ARPANET. > > > > I know little about the internal mechanisms of the Packet Radio > > environment.? But it did not move to Div6 (which became BBN > > Communications Corp at some point) at least during my involvement > > (roughly 1978-1990). > > > > So I suspect that the Packet Radio system did not reuse much of the IMP > > ideas/techniques, especially the ones that were rather mundane and not > > well documented or publicized (such as the "reload from neighbor" > > idea).? The Packet Radio QTRs, if they survive, would probably answer > > that question. > > > > I've often wondered, from a historical perspective now, to what extent > > things like internal corporate structure and organizational decisions > > influenced the design and implementation of the Internet. > > > > /Jack > > > > > > On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: > > >? Because of BBN's involvement, I am thinking Packet Radio might have > > reused many of? the same ideas as the IMPs for loading new software from > > another node. Do you know this was not the case?? I never needed to look > at > > that part of the code. > > > I remember using XNET for examination of the Packet Radio station. > Given > > your recent email it sounds like you looked for old Packet Radio station > > software and couldn't find it. Is this correct? > > > I don't think Rockwell released their Packet Radio software in the late > > 70s/early 80s. I would have to contact Rockwell if I thought bugs > required > > a change to a packet radio, versus the Packet Radio station, when I > worked > > at BBN. I know several years later SRI did get some of their code > because > > I implemented one of the new routing algorithms ( I am pretty sure it was > > called threshold distance vector routing if anyone is interested). BTW, I > > think the software may have only been tested in a simulator due to delays > > in the delivery of the LPR (Low Cost Packet Radio). This was during the > > SURAN program. > > > The first demo of Packet Radio and ARPANET in 1976 involved submitting > > the status report.? Don Nielson would probably remember if that was done > > through anything like email. Below is a link to an article that discusses > > this event. The text from the article mentions email but more importantly > > it has a link to a podcast with Don. I didn't know this podcast existed > so > > I still need to listen to it.? I can see why you might think the report > > submission may have been done by using a telnet connection to a SRI host > > that had email. > > > > > > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > > > barbara > > >? ? On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via > > Internet-history wrote: > > > > > >? Hi Geoff - thanks for that bit of history and kudos! > > > > > > I think there's an Internet connection in your experience.? I'm not > sure > > > what, legally, "wireless email" means.? But I suspect that email was > > > being sent and received, wirelessly, well before even 1982, if only to > > > and from the SRI Packet Radio van that could occasionally be seen then > > > roaming around the Bay Area. > > > > > > Of course, technically, that probably involved a Telnet connection, > > > wirelessly, to some PDP-10 running an email program.? But, legally, it > > > might meet the court accepted definition of "wireless email".? I > > > learned from the lawyers that much of litigation involves arguing about > > > the meaning of words and phrases. > > > > > > So, perhaps someone could have looked for mouldering Packet Radio (aka > > > PR) hardware and software, and demonstrated wireless email circa 1978 > > > over one or more PRNETs. > > > > > > Sadly, although I was pretty sure that interesting "prior art" would be > > > found in the PR environment, we had little success 7 years ago while > > > trying to find anything that might show exactly how PR equipment > > > "downloaded instructions". > > > > > > There's remarkably little readily discoverable material about lots of > > > the computer and network systems of the 70s/80s, especially internal > > > details of operation, tools, procedures, etc.? Plenty of stuff on > > > Routing, but little on other mechanisms, or other types of networks of > > > that era, at least that the lawyers and I could find.? IMHO, that's a > > > huge gap even in Internet History, since the Internet did not evolve in > > > a vacuum, was itself composed of more than the ARPANET, and was > > > surrounded by competitors (remember multiprotocol routers). > > > > > > /Jack > > > > > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > > >> Jack, you're a Most Eloquent purveyor of history and that WHY explain > > >> is exactly what yours truly was hoping for... Thank You for the > > >> elucidation! :D > > >> > > >> along the lines vis-a-vis: > > >> > > >>? ? So, that's a bit about the "Why", for history to ponder.? The > > >>? ? experience got me wondering about the "patent history" of The > > >>? ? Internet.? Clearly there was a lot of innovation in those days. > > >>? ? My recollection is that very little was patented, even if only to > > >>? ? make sure no one else could.? Maybe someone will document the > > >>? ? patent-related aspects of Internet History someday. > > >> > > >> please excuse/pardon this immodesty: yours truly had a kinda similar > > >> "lawyered" experience with respect to WHO was the purported > > >> "inventor"/originator of wireless email in a patent litigation case > > >> and the "challenge" of finding/presenting any extant legally > > >> submissive "artifactual proof" to that effect -- for which John > > >> Markoff at the New York Times wrote about in this 2006 article: > > >> > > >> In Silicon Valley, a Man Without a Patent > > >> > > > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > > >> > > >> for which some links of "proof" exist -- for some stuff mentioned in > > >> the above NYT article -- on my website https://iconia.com/ under > > >> "wireless email" (in case any historians are duly interested)... > > >> > > >> geoff > > >> > > >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > >> > wrote: > > >> > > >>? ? Geoff, > > >> > > >>? ? Dave's IEEE paper does an excellent job of the > > >>? ? Who/What/When/Where.? He's right that it was about 7 years ago. > > >>? ? Time flies... but I guess it's still "recent" when viewed as part > > >>? ? of Internet History. > > >> > > >>? ? For the curious, I can add a bit more about the Why. > > >> > > >>? ? Sometime in 2013, I got an email out of the blue from Charlie > > >>? ? Neuhauser, someone I didn't recognize or remember at all, asking > > >>? ? if I was the "Jack Haverty" who authored IEN 158 - documenting the > > >>? ? XNET protocol in 1980.? Figuring that the statute of limitations > > >>? ? must have expired after 30+ years, I cautiously said yes.? Over > > >>? ? the next few days, he hooked me up with the lawyers who were > > >>? ? involved in a patent dispute - one that had been going on for > > >>? ? several decades by then.? In fact, the patent involved had been > > >>? ? issued, ran its 17 year lifetime, and expired, but there was still > > >>? ? litigation in process about whether or not the patent was valid, > > >>? ? and 17 years of violations were alleged cause for compensation in > > >>? ? the many millions.? For the next few years I was involved in the > > >>? ? battles, working with the lawyers scattered all over the country. > > >>? ? I never met any of them.? All our work was done by email and > > >>? ? telephone.? No Zoom then or we probably would have used it. > > >> > > >>? ? The core issue in the patent battle concerned "downloading > > >>? ? instructions", mechanisms such as would be involved in patching or > > >>? ? issuing new software releases to remote equipment.? XNET seemed > > >>? ? to them to possibly have something to do with that, hence the > > >>? ? interest.? The goal was to find hard evidence that such procedures > > >>? ? were being done by 1980, which would prove that prior art > > >>? ? existed.? Hard evidence literally means "hard" - opinions help, > > >>? ? but physical equipment and running code is much more impressive in > > >>? ? a courtroom. > > >> > > >>? ? They hadn't found any XNET artifacts, and I couldn't point them to > > >>? ? any surviving implementations.? But I pointed out that my XNET > > >>? ? document simply captured the technology that we "stole" from the > > >>? ? ARPANET IMP experience, and that the IMPs routinely "downloaded > > >>? ? code" from their neighbors and the NOC all during the life of the > > >>? ? ARPANET. > > >> > > >>? ? Since the IMPs had existed since the early 70s, that really > > >>? ? sparked their interest, and a search (worldwide) ensued to find > > >>? ? old IMPs, in the hope that just maybe one of them still had the > > >>? ? IMP software in its magnetic-core memory.? A few IMPs were > > >>? ? located, but none were functional.? The one in the museum at UCLA > > >>? ? seemed promising, but the owners were reluctant to even hook it up > > >>? ? to power after sitting idle for so many years, expecting it might > > >>? ? go up in smoke. > > >> > > >>? ? Then I learned from the BBN alumni mailing list that an ancient > > >>? ? IMP listing had been found in a basement.? The story from that > > >>? ? point is pretty well described in Dave's paper. > > >> > > >>? ? Personally, it was an interesting experience.? I worked > > >>? ? extensively with one lawyer in San Diego.? I taught him how > > >>? ? computers and networks actually work; he taught me a lot about the > > >>? ? legal system regarding patents.? IMHO, they are equally > > >>? ? convoluted and complex when viewed from the other's perspective. > > >> > > >>? ? I also learned a lot about the IMP code, which I had never even > > >>? ? looked at while I was at BBN.? One task I took on was to > > >>? ? exhaustively analyze the parts of the IMP code that implemented > > >>? ? the "download new instructions" functionality, writing up an > > >>? ? instruction-by-instruction description of how the code > > >>? ? accomplished that by interacting with a neighboring IMP.? It was > > >>? ? a very clever design, and extremely tight code, even including > > >>? ? self-modifying instructions.? Not easy to figure out (or explain > > >>? ? in language amenable to a non-technical judge or jury).? So there > > >>? ? was great interest in being able to demonstrate the code in action > > >>? ? using real software from the 70s and hardware simulators. > > >>? ? Tangible evidence is much better than even expert opinions. > > >> > > >>? ? The whole legal project came to a sudden end just a few months > > >>? ? prior to the first court date.? ? I was looking forward to going > > >>? ? to Delaware (legal action was filed in Federal court in Delaware), > > >>? ? and finally meeting some of the people.? But the parties settled > > >>? ? suddenly, the case was dropped, and AFAIK the patent question was > > >>? ? never resolved. > > >> > > >>? ? So, that's a bit about the "Why", for history to ponder.? ? The > > >>? ? experience got me wondering about the "patent history" of The > > >>? ? Internet.? Clearly there was a lot of innovation in those days. > > >>? ? My recollection is that very little was patented, even if only to > > >>? ? make sure no one else could.? Maybe someone will document the > > >>? ? patent-related aspects of Internet History someday. > > >> > > >>? ? /Jack Haverty > > >> > > >> > > >> > > >>? ? On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > > >>>? ? jack, you've raised my curiosity with respect to: > > >>> > > >>>? ? ? ? ... There > > >>>? ? ? ? *is* ARPANET IMP software which was recently restored and a > > small > > >>>? ? ? ? ARPANET was run using simulated IMP hardware. > > >>> > > >>>? ? Who/What/When/Where/Why? > > >>> > > >>>? ? geoff > > >>> > > >>>? ? On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history > > >>>? ? > >>>? ? > wrote: > > >>> > > >>>? ? ? ? Lukasz, > > >>> > > >>>? ? ? ? I think that the earliest implementations of TTL called it > > >>>? ? ? ? "Time", but > > >>>? ? ? ? I'm not aware that anyone actually used time per se in > > >>>? ? ? ? gateways, at > > >>>? ? ? ? least in the early days (1977-1982 or so). > > >>> > > >>>? ? ? ? TCP implementations didn't do anything with TTL other than > > >>>? ? ? ? set it on > > >>>? ? ? ? outgoing datagrams, and at least in my implementation (TCP > > >>>? ? ? ? for Unix), it > > >>>? ? ? ? was just set to some arbitrary value.? Until we had some data > > >>>? ? ? ? from > > >>>? ? ? ? experimentation it was hard to evaluate ideas about what > > >>>? ? ? ? routers, hosts, > > >>>? ? ? ? et al should actually do.? The early TCPs did use time in > > >>>? ? ? ? handling > > >>>? ? ? ? retransmission timers, and there was work a bit later to > > >>>? ? ? ? incorporate > > >>>? ? ? ? time more powerfully into TCP behavior, e.g., Van Jacobson's > > >>>? ? ? ? work. > > >>> > > >>>? ? ? ? The early gateways, IIRC, used the terminology "time", but in > > >>>? ? ? ? practice > > >>>? ? ? ? used just hop counts, since time measurements were difficult > to > > >>>? ? ? ? implement.? The exception to that may be Dave Mills' > > >>>? ? ? ? Fuzzballs, since > > >>>? ? ? ? Dave was the implementor most interested in time and making > > >>>? ? ? ? precise > > >>>? ? ? ? measurements of network behavior.? I *think* Dave may have > > >>>? ? ? ? used time > > >>>? ? ? ? values and delay-based routing amongst his "fuzzies". > > >>> > > >>>? ? ? ? The BBN doc you're seeking might have been one of many that > > >>>? ? ? ? discussed > > >>>? ? ? ? the ARPANET internal mechanisms, e.g., ones with titles like > > >>>? ? ? ? "Routing > > >>>? ? ? ? Algorithm Improvements".? The ARPANET internal mechanisms did > > >>>? ? ? ? use time. > > >>>? ? ? ? It was fairly simple in the IMPs, since the delay introduced > > >>>? ? ? ? by the > > >>>? ? ? ? synchronous communications lines could be easily predicted, > > >>>? ? ? ? and the > > >>>? ? ? ? other major component of delay was the time spent in queues, > > >>>? ? ? ? which could > > >>>? ? ? ? be measured fairly easily. > > >>> > > >>>? ? ? ? I even found one BBN ARPANET Project QTR from circa 1975 that > > >>>? ? ? ? discussed > > >>>? ? ? ? the merits of the new-fangled TCP proposal that some > > >>>? ? ? ? professor had > > >>>? ? ? ? published -- and seemed to conclude it couldn't possibly > work. > > >>> > > >>>? ? ? ? My involvement in implementations of TCPs and gateways lasted > > >>>? ? ? ? through > > >>>? ? ? ? about mid-1983, so I don't know much of the detail of > > subsequent > > >>>? ? ? ? implementations.? For the various BBN gateway/router > > >>>? ? ? ? equipment, Bob > > >>>? ? ? ? Hinden would probably be a good source.? The other major > > >>>? ? ? ? early player > > >>>? ? ? ? was MIT and spinoffs (Proteon), which perhaps Noel Chiappa > will > > >>>? ? ? ? remember.? There's also at least one paper on the Fuzzballs > > >>>? ? ? ? which may > > >>>? ? ? ? have some details. > > >>> > > >>>? ? ? ? One thing I'd advise being careful of is the various > > >>>? ? ? ? "specifications" in > > >>>? ? ? ? RFCs.? Much of the wording in those was intentionally > > >>>? ? ? ? non-prescriptive > > >>>? ? ? ? (use of "should" or "may" instead of "must"), to provide as > > much > > >>>? ? ? ? latitude as possible for experimentation with new ideas, > > >>>? ? ? ? especially > > >>>? ? ? ? within an AS.? The Internet was an Experiment. > > >>> > > >>>? ? ? ? Also, there was no consistent enforcement mechanism to assure > > >>>? ? ? ? that > > >>>? ? ? ? implementations actually even conformed to the "must" > > >>>? ? ? ? elements.? So > > >>>? ? ? ? Reality could be very different from Specification. > > >>> > > >>>? ? ? ? I don't know of any gateway implementations that have > > >>>? ? ? ? survived.? There > > >>>? ? ? ? *is* ARPANET IMP software which was recently restored and a > > small > > >>>? ? ? ? ARPANET was run using simulated IMP hardware.? I still have > > >>>? ? ? ? a ~1979 > > >>>? ? ? ? listing of the TCP I wrote for Unix, but haven't scanned it > > >>>? ? ? ? into digital > > >>>? ? ? ? form yet. > > >>> > > >>>? ? ? ? Jack > > >>> > > >>>? ? ? ? On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > > >>>? ? ? ? > Jack, > > >>>? ? ? ? > > > >>>? ? ? ? > I was reading a lot of old BBN PDFs thanks to all good > souls > > on > > >>>? ? ? ? > this list that post nice URLs from time to time. > > >>>? ? ? ? > > > >>>? ? ? ? > I remember reading in at least one of them, that apparently > > >>>? ? ? ? first > > >>>? ? ? ? > TCP/IP implementations were indeed using TTL as literally > > >>>? ? ? ? ?time?, > > >>>? ? ? ? > not hop count. I believe there somewhere there between PDP > > docs > > >>>? ? ? ? > and ARPANET docs I?ve read something to the effect ?and > > >>>? ? ? ? from this > > >>>? ? ? ? > time we changed from measuring time to simply count routing > > >>>? ? ? ? hops?. > > >>>? ? ? ? > Of course, right now google-fu is failing me. > > >>>? ? ? ? > > > >>>? ? ? ? > Quoting RFC 1009 that was already brought up, there?s quite > > >>>? ? ? ? > direct ?definition? of the field: > > >>>? ? ? ? > > > >>>? ? ? ? > "4.8.? Time-To-Live > > >>>? ? ? ? > > > >>>? ? ? ? >? The Time-to-Live (TTL) field of the IP header is defined > > >>>? ? ? ? to be a > > >>>? ? ? ? >? timer limiting the lifetime of a datagram in the > > >>>? ? ? ? Internet.? It is > > >>>? ? ? ? >? an 8-bit field and the units are seconds.? This would > > >>>? ? ? ? imply that > > >>>? ? ? ? >? for a maximum TTL of 255 a datagram would time-out after > > >>>? ? ? ? about 4 > > >>>? ? ? ? >? and a quarter minutes.? Another aspect of the definition > > >>>? ? ? ? requires > > >>>? ? ? ? >? each gateway (or other module) that handles a datagram to > > >>>? ? ? ? >? decrement the TTL by at least one, even if the elapsed > > >>>? ? ? ? time was > > >>>? ? ? ? >? much less than a second.? Since this is very often the > > >>>? ? ? ? case, the > > >>>? ? ? ? >? TTL effectively becomes a hop count limit on how far a > > >>>? ? ? ? datagram > > >>>? ? ? ? >? can propagate through the Internet." > > >>>? ? ? ? > > > >>>? ? ? ? > Were there any implementations that survived somewhere and > > >>>? ? ? ? actually > > >>>? ? ? ? > did exactly that - counted actual time/processing delay, > > >>>? ? ? ? not hops? > > >>>? ? ? ? > And if it took 2s to process packet, did they really > > >>>? ? ? ? decrement TTL > > >>>? ? ? ? > by two? > > >>>? ? ? ? > > > >>>? ? ? ? > Thanks for any pointers, > > >>> > > >>>? ? ? ? -- > > >>>? ? ? ? Internet-history mailing list > > >>>? ? ? ? Internet-history at elists.isoc.org > > >>>? ? ? ? > > >>>? ? ? ? https://elists.isoc.org/mailman/listinfo/internet-history > > >>> > > >>> > > >>> > > >>>? ? -- > > >>>? ? Geoff.Goodfellow at iconia.com > > >>>? ? living as The Truth is True > > >>> > > >>> > > >>> > > >> > > >> > > >> -- > > >> Geoff.Goodfellow at iconia.com > > >> living as The Truth is True > > >> > > >> > > >> > > > > -- > > 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. > > > ------------------------------ > > Subject: Digest Footer > > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > > ------------------------------ > > End of Internet-history Digest, Vol 12, Issue 36 > ************************************************ > -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From b_a_denny at yahoo.com Mon Sep 7 19:54:03 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Tue, 8 Sep 2020 02:54:03 +0000 (UTC) Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <4dc61360-d5d1-5b1d-27b9-37a958f68f13@3 kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> Message-ID: <1141252064.1197160.1599533643198@mail.yahoo.com> Hi Jack, This might not have been clear. I worked for BBN on the packet radio project before SRI. As you mentioned the packet radio work was in Div4 at BBN. I decided to move to California and took a job at SRI.? Besides ARPA, SRI had contracts with other military organizations for the networking research . The Army (CECOM) funded a lot of the work.? I think a couple projects I worked on had funding from the Navy and the Air Force (Rome Labs? ) but I could be wrong where the dollars actually came from.? Unfortunately I don't remember any contract numbers right now. Much of the information on what was done is in the monthly, quarterly and final reports delivered to the contracting organization. I think there were only a handful of conference papers and a few talks here and there. ?I have tried to use the DTIC site to find information on the SAC Strategic C3 Experiments (Mobile IP work) and I did find it hard to locate what I was looking for. I have no idea how SRI handled the deliverables once a project was over. I did find documentation on the Port Expander awhile ago but it wasn't very detailed. If you would like a copy, I will see if I can find it again.? I think it helps to know the project name when searching for information.? barbara? On Monday, September 7, 2020, 11:00:48 AM PDT, Jack Haverty via Internet-history wrote: Hi Barbara, Packet Radio artifacts of any kind were elusive (at least in 2013 when we searched), except for a few conference papers.? Specifically, we were looking for things like QTRs or other project reports that SRI presumably submitted to ARPA, analogous to the BBN QTRs.?? We found a lot of the BBN reports online at DTIC, but little from SRI.? I'm not sure, but the BBN QTRs may have been found by the search engine because I had the BBN/ARPA contract numbers involved, but I didn't know the appropriate contract numbers for the SRI (or any other) contracts.?? Not much detail about Fuzzballs, or Port Expanders, or other such boxes that were prolific in the early days of the Internet.? Google wasn't much help, but that may be from lack of knowledge in how to best use the search mechanisms. IMHO, there wasn't as much collaboration between the ARPANET and Packet Radio as there was with the Internet/Gateway work at BBN. BBN had internal structure that to some extent influenced the "technology transfer" between projects.? In particular there were two "divisions", Div4 and Div6, that both did similar computer and network research.? Div6 was where the ARPANET project began and evolved to an operational service over the ten years preceding the Internet, so there was a lot of operational experience and war wounds there.?? Div4 was where the Packet Radio work was done, along with lots of other things, such as TENEX.?? Both were very competent, but had different experiences. Although the technical staffs of the two divisions got along pretty well, pragmatic details limited collaboration.? We were physically located in separate buildings, so hallway encounters and casual interactions were less likely.? Interesting "teaching events" that occurred in the ARPANET propagated quickly through Div6 where the NOC was literally just down the hallway, less so to Div4.?? Cross-charging (charging your time to the other Division's project) was possible but discouraged. The "Gateway Project" began in Div4, where Ginny Strazisar implemented the first gateway;? I don't know if that was a separate project/contract, or just a part of the Packet Radio contract at the time.?? Some few years later, as it became desirable for the Internet to stabilize and become an operational service, ARPA moved the gateway work from Div4 to Div6, folding it into the "Internet Project" contract that was my responsibility at the time (it included various TCP implementations, SATNET, WBNET, Remote Site Maintenance, etc.). That was the point where we started injecting "ARPANET DNA" into the Internet/gateways, blatantly adopting ARPANET techniques as the most obvious (to us in Div6) way to get the Internet to be as managed as the ARPANET. I know little about the internal mechanisms of the Packet Radio environment.?? But it did not move to Div6 (which became BBN Communications Corp at some point) at least during my involvement (roughly 1978-1990). So I suspect that the Packet Radio system did not reuse much of the IMP ideas/techniques, especially the ones that were rather mundane and not well documented or publicized (such as the "reload from neighbor" idea).? The Packet Radio QTRs, if they survive, would probably answer that question. I've often wondered, from a historical perspective now, to what extent things like internal corporate structure and organizational decisions influenced the design and implementation of the Internet. /Jack On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: >? Because of BBN's involvement, I am thinking Packet Radio might have reused many of? the same ideas as the IMPs for loading new software from another node. Do you know this was not the case?? I never needed to look at that part of the code.? > I remember using XNET for examination of the Packet Radio station. Given your recent email it sounds like you looked for old Packet Radio station software and couldn't find it. Is this correct?? > I don't think Rockwell released their Packet Radio software in the late 70s/early 80s. I would have to contact Rockwell if I thought bugs required a change to a packet radio, versus the Packet Radio station, when I worked at BBN. I know several years later SRI did get some of their code? because I implemented one of the new routing algorithms ( I am pretty sure it was called threshold distance vector routing if anyone is interested). BTW, I think the software may have only been tested in a simulator due to delays in the delivery of the LPR (Low Cost Packet Radio). This was during the SURAN program.? > The first demo of Packet Radio and ARPANET in 1976 involved submitting the status report.? Don Nielson would probably remember if that was done through anything like email. Below is a link to an article that discusses this event. The text from the article mentions email but more importantly it has a link to a podcast with Don. I didn't know this podcast existed so I still need to listen to it.? I can see why you might think the report submission may have been done by using a telnet connection to a SRI host that had email.? > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > barbara? >? ? On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via Internet-history wrote:? >? >? Hi Geoff - thanks for that bit of history and kudos!? > > I think there's an Internet connection in your experience.? I'm not sure > what, legally, "wireless email" means.? But I suspect that email was > being sent and received, wirelessly, well before even 1982, if only to > and from the SRI Packet Radio van that could occasionally be seen then > roaming around the Bay Area. > > Of course, technically, that probably involved a Telnet connection, > wirelessly, to some PDP-10 running an email program.?? But, legally, it > might meet the court accepted definition of "wireless email". ? I > learned from the lawyers that much of litigation involves arguing about > the meaning of words and phrases. > > So, perhaps someone could have looked for mouldering Packet Radio (aka > PR) hardware and software, and demonstrated wireless email circa 1978 > over one or more PRNETs. > > Sadly, although I was pretty sure that interesting "prior art" would be > found in the PR environment, we had little success 7 years ago while > trying to find anything that might show exactly how PR equipment > "downloaded instructions".?? > > There's remarkably little readily discoverable material about lots of > the computer and network systems of the 70s/80s, especially internal > details of operation, tools, procedures, etc.?? Plenty of stuff on > Routing, but little on other mechanisms, or other types of networks of > that era, at least that the lawyers and I could find.?? IMHO, that's a > huge gap even in Internet History, since the Internet did not evolve in > a vacuum, was itself composed of more than the ARPANET, and was > surrounded by competitors (remember multiprotocol routers). > > /Jack > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: >> Jack, you're a Most Eloquent purveyor of history and that WHY explain >> is exactly what yours truly was hoping for... Thank You for the >> elucidation! :D >> >> along the lines vis-a-vis: >> >> ? ? So, that's a bit about the "Why", for history to ponder.? The >> ? ? experience got me wondering about the "patent history" of The >> ? ? Internet.? Clearly there was a lot of innovation in those days.? >> ? ? My recollection is that very little was patented, even if only to >> ? ? make sure no one else could.? Maybe someone will document the >> ? ? patent-related aspects of Internet History someday. >> >> please excuse/pardon this immodesty: yours truly had a kinda similar >> "lawyered" experience with respect to WHO was the purported >> "inventor"/originator of wireless email in a patent litigation case >> and the "challenge" of finding/presenting any extant legally >> submissive "artifactual?proof" to that effect -- for which John >> Markoff at the New York Times wrote about in this 2006 article: >> >> In Silicon Valley, a Man Without a Patent >> https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html >> >> for which some links of "proof" exist -- for some stuff mentioned in >> the above NYT article -- on my website?https://iconia.com/?under >> "wireless email" (in case any historians are duly interested)...? >> >> geoff >> >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > > wrote: >> >> ? ? Geoff, >> >> ? ? Dave's IEEE paper does an excellent job of the >> ? ? Who/What/When/Where.? He's right that it was about 7 years ago.?? >> ? ? Time flies... but I guess it's still "recent" when viewed as part >> ? ? of Internet History. >> >> ? ? For the curious, I can add a bit more about the Why. >> >> ? ? Sometime in 2013, I got an email out of the blue from Charlie >> ? ? Neuhauser, someone I didn't recognize or remember at all, asking >> ? ? if I was the "Jack Haverty" who authored IEN 158 - documenting the >> ? ? XNET protocol in 1980.?? Figuring that the statute of limitations >> ? ? must have expired after 30+ years, I cautiously said yes.? Over >> ? ? the next few days, he hooked me up with the lawyers who were >> ? ? involved in a patent dispute - one that had been going on for >> ? ? several decades by then.? In fact, the patent involved had been >> ? ? issued, ran its 17 year lifetime, and expired, but there was still >> ? ? litigation in process about whether or not the patent was valid, >> ? ? and 17 years of violations were alleged cause for compensation in >> ? ? the many millions. ? For the next few years I was involved in the >> ? ? battles, working with the lawyers scattered all over the country.? >> ? ? I never met any of them.? All our work was done by email and >> ? ? telephone.?? No Zoom then or we probably would have used it. >> >> ? ? The core issue in the patent battle concerned "downloading >> ? ? instructions", mechanisms such as would be involved in patching or >> ? ? issuing new software releases to remote equipment.?? XNET seemed >> ? ? to them to possibly have something to do with that, hence the >> ? ? interest.? The goal was to find hard evidence that such procedures >> ? ? were being done by 1980, which would prove that prior art >> ? ? existed.? Hard evidence literally means "hard" - opinions help, >> ? ? but physical equipment and running code is much more impressive in >> ? ? a courtroom. >> >> ? ? They hadn't found any XNET artifacts, and I couldn't point them to >> ? ? any surviving implementations.?? But I pointed out that my XNET >> ? ? document simply captured the technology that we "stole" from the >> ? ? ARPANET IMP experience, and that the IMPs routinely "downloaded >> ? ? code" from their neighbors and the NOC all during the life of the >> ? ? ARPANET. >> >> ? ? Since the IMPs had existed since the early 70s, that really >> ? ? sparked their interest, and a search (worldwide) ensued to find >> ? ? old IMPs, in the hope that just maybe one of them still had the >> ? ? IMP software in its magnetic-core memory.? A few IMPs were >> ? ? located, but none were functional.? The one in the museum at UCLA >> ? ? seemed promising, but the owners were reluctant to even hook it up >> ? ? to power after sitting idle for so many years, expecting it might >> ? ? go up in smoke. >> >> ? ? Then I learned from the BBN alumni mailing list that an ancient >> ? ? IMP listing had been found in a basement.?? The story from that >> ? ? point is pretty well described in Dave's paper. >> >> ? ? Personally, it was an interesting experience.? I worked >> ? ? extensively with one lawyer in San Diego.? I taught him how >> ? ? computers and networks actually work; he taught me a lot about the >> ? ? legal system regarding patents.?? IMHO, they are equally >> ? ? convoluted and complex when viewed from the other's perspective. >> >> ? ? I also learned a lot about the IMP code, which I had never even >> ? ? looked at while I was at BBN.? One task I took on was to >> ? ? exhaustively analyze the parts of the IMP code that implemented >> ? ? the "download new instructions" functionality, writing up an >> ? ? instruction-by-instruction description of how the code >> ? ? accomplished that by interacting with a neighboring IMP.?? It was >> ? ? a very clever design, and extremely tight code, even including >> ? ? self-modifying instructions.?? Not easy to figure out (or explain >> ? ? in language amenable to a non-technical judge or jury).? So there >> ? ? was great interest in being able to demonstrate the code in action >> ? ? using real software from the 70s and hardware simulators.?? >> ? ? Tangible evidence is much better than even expert opinions. >> >> ? ? The whole legal project came to a sudden end just a few months >> ? ? prior to the first court date.??? I was looking forward to going >> ? ? to Delaware (legal action was filed in Federal court in Delaware), >> ? ? and finally meeting some of the people.?? But the parties settled >> ? ? suddenly, the case was dropped, and AFAIK the patent question was >> ? ? never resolved.?? >> >> ? ? So, that's a bit about the "Why", for history to ponder.??? The >> ? ? experience got me wondering about the "patent history" of The >> ? ? Internet.?? Clearly there was a lot of innovation in those days.?? >> ? ? My recollection is that very little was patented, even if only to >> ? ? make sure no one else could.?? Maybe someone will document the >> ? ? patent-related aspects of Internet History someday. >> >> ? ? /Jack Haverty >> >> >> >> ? ? On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: >>> ? ? jack, you've raised my curiosity with respect to: >>> >>> ? ? ? ? ... There >>> ? ? ? ? *is* ARPANET IMP software which was recently restored and a small >>> ? ? ? ? ARPANET was run using simulated IMP hardware. >>> >>> ? ? Who/What/When/Where/Why? >>> >>> ? ? geoff >>> >>> ? ? On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history >>> ? ? >> ? ? > wrote: >>> >>> ? ? ? ? Lukasz, >>> >>> ? ? ? ? I think that the earliest implementations of TTL called it >>> ? ? ? ? "Time", but >>> ? ? ? ? I'm not aware that anyone actually used time per se in >>> ? ? ? ? gateways, at >>> ? ? ? ? least in the early days (1977-1982 or so).? >>> >>> ? ? ? ? TCP implementations didn't do anything with TTL other than >>> ? ? ? ? set it on >>> ? ? ? ? outgoing datagrams, and at least in my implementation (TCP >>> ? ? ? ? for Unix), it >>> ? ? ? ? was just set to some arbitrary value.? Until we had some data >>> ? ? ? ? from >>> ? ? ? ? experimentation it was hard to evaluate ideas about what >>> ? ? ? ? routers, hosts, >>> ? ? ? ? et al should actually do.?? The early TCPs did use time in >>> ? ? ? ? handling >>> ? ? ? ? retransmission timers, and there was work a bit later to >>> ? ? ? ? incorporate >>> ? ? ? ? time more powerfully into TCP behavior, e.g., Van Jacobson's >>> ? ? ? ? work. >>> >>> ? ? ? ? The early gateways, IIRC, used the terminology "time", but in >>> ? ? ? ? practice >>> ? ? ? ? used just hop counts, since time measurements were difficult to >>> ? ? ? ? implement.?? The exception to that may be Dave Mills' >>> ? ? ? ? Fuzzballs, since >>> ? ? ? ? Dave was the implementor most interested in time and making >>> ? ? ? ? precise >>> ? ? ? ? measurements of network behavior.?? I *think* Dave may have >>> ? ? ? ? used time >>> ? ? ? ? values and delay-based routing amongst his "fuzzies". >>> >>> ? ? ? ? The BBN doc you're seeking might have been one of many that >>> ? ? ? ? discussed >>> ? ? ? ? the ARPANET internal mechanisms, e.g., ones with titles like >>> ? ? ? ? "Routing >>> ? ? ? ? Algorithm Improvements".? The ARPANET internal mechanisms did >>> ? ? ? ? use time.? >>> ? ? ? ? It was fairly simple in the IMPs, since the delay introduced >>> ? ? ? ? by the >>> ? ? ? ? synchronous communications lines could be easily predicted, >>> ? ? ? ? and the >>> ? ? ? ? other major component of delay was the time spent in queues, >>> ? ? ? ? which could >>> ? ? ? ? be measured fairly easily.?? >>> >>> ? ? ? ? I even found one BBN ARPANET Project QTR from circa 1975 that >>> ? ? ? ? discussed >>> ? ? ? ? the merits of the new-fangled TCP proposal that some >>> ? ? ? ? professor had >>> ? ? ? ? published -- and seemed to conclude it couldn't possibly work. >>> >>> ? ? ? ? My involvement in implementations of TCPs and gateways lasted >>> ? ? ? ? through >>> ? ? ? ? about mid-1983, so I don't know much of the detail of subsequent >>> ? ? ? ? implementations.? For the various BBN gateway/router >>> ? ? ? ? equipment, Bob >>> ? ? ? ? Hinden would probably be a good source.? The other major >>> ? ? ? ? early player >>> ? ? ? ? was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will >>> ? ? ? ? remember.?? There's also at least one paper on the Fuzzballs >>> ? ? ? ? which may >>> ? ? ? ? have some details. >>> >>> ? ? ? ? One thing I'd advise being careful of is the various >>> ? ? ? ? "specifications" in >>> ? ? ? ? RFCs.? Much of the wording in those was intentionally >>> ? ? ? ? non-prescriptive >>> ? ? ? ? (use of "should" or "may" instead of "must"), to provide as much >>> ? ? ? ? latitude as possible for experimentation with new ideas, >>> ? ? ? ? especially >>> ? ? ? ? within an AS.?? The Internet was an Experiment. >>> >>> ? ? ? ? Also, there was no consistent enforcement mechanism to assure >>> ? ? ? ? that >>> ? ? ? ? implementations actually even conformed to the "must" >>> ? ? ? ? elements.?? So >>> ? ? ? ? Reality could be very different from Specification. >>> >>> ? ? ? ? I don't know of any gateway implementations that have >>> ? ? ? ? survived.?? There >>> ? ? ? ? *is* ARPANET IMP software which was recently restored and a small >>> ? ? ? ? ARPANET was run using simulated IMP hardware.?? I still have >>> ? ? ? ? a ~1979 >>> ? ? ? ? listing of the TCP I wrote for Unix, but haven't scanned it >>> ? ? ? ? into digital >>> ? ? ? ? form yet. >>> >>> ? ? ? ? Jack >>> >>> ? ? ? ? On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: >>> ? ? ? ? > Jack, >>> ? ? ? ? > >>> ? ? ? ? > I was reading a lot of old BBN PDFs thanks to all good souls on >>> ? ? ? ? > this list that post nice URLs from time to time. >>> ? ? ? ? > >>> ? ? ? ? > I remember reading in at least one of them, that apparently >>> ? ? ? ? first >>> ? ? ? ? > TCP/IP implementations were indeed using TTL as literally >>> ? ? ? ? ?time?, >>> ? ? ? ? > not hop count. I believe there somewhere there between PDP docs >>> ? ? ? ? > and ARPANET docs I?ve read something to the effect ?and >>> ? ? ? ? from this >>> ? ? ? ? > time we changed from measuring time to simply count routing >>> ? ? ? ? hops?. >>> ? ? ? ? > Of course, right now google-fu is failing me. >>> ? ? ? ? > >>> ? ? ? ? > Quoting RFC 1009 that was already brought up, there?s quite >>> ? ? ? ? > direct ?definition? of the field: >>> ? ? ? ? > >>> ? ? ? ? > "4.8.? Time-To-Live >>> ? ? ? ? > >>> ? ? ? ? >? The Time-to-Live (TTL) field of the IP header is defined >>> ? ? ? ? to be a >>> ? ? ? ? >? timer limiting the lifetime of a datagram in the >>> ? ? ? ? Internet.? It is >>> ? ? ? ? >? an 8-bit field and the units are seconds.? This would >>> ? ? ? ? imply that >>> ? ? ? ? >? for a maximum TTL of 255 a datagram would time-out after >>> ? ? ? ? about 4 >>> ? ? ? ? >? and a quarter minutes.? Another aspect of the definition >>> ? ? ? ? requires >>> ? ? ? ? >? each gateway (or other module) that handles a datagram to >>> ? ? ? ? >? decrement the TTL by at least one, even if the elapsed >>> ? ? ? ? time was >>> ? ? ? ? >? much less than a second.? Since this is very often the >>> ? ? ? ? case, the >>> ? ? ? ? >? TTL effectively becomes a hop count limit on how far a >>> ? ? ? ? datagram >>> ? ? ? ? >? can propagate through the Internet." >>> ? ? ? ? > >>> ? ? ? ? > Were there any implementations that survived somewhere and >>> ? ? ? ? actually >>> ? ? ? ? > did exactly that - counted actual time/processing delay, >>> ? ? ? ? not hops? >>> ? ? ? ? > And if it took 2s to process packet, did they really >>> ? ? ? ? decrement TTL >>> ? ? ? ? > by two? >>> ? ? ? ? > >>> ? ? ? ? > Thanks for any pointers, >>> >>> ? ? ? ? -- >>> ? ? ? ? Internet-history mailing list >>> ? ? ? ? Internet-history at elists.isoc.org >>> ? ? ? ? >>> ? ? ? ? https://elists.isoc.org/mailman/listinfo/internet-history >>> >>> >>> >>> ? ? -- >>> ? ? Geoff.Goodfellow at iconia.com >>> ? ? living as The Truth is True >>> >>> >>> >> >> >> -- >> Geoff.Goodfellow at iconia.com >> living as The Truth is True >> >> >> -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From lars at nocrew.org Mon Sep 7 23:15:51 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 08 Sep 2020 06:15:51 +0000 Subject: [ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ] In-Reply-To: (the keyboard of geoff goodfellow via Internet-history's message of "Mon, 7 Sep 2020 10:12:33 -1000") References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5F557104.16505.7DB7EB0@bernie.fantasyfarm.com> <1461413346.4001546.1599490865162@mail.yahoo.com> <867424403.4037955.1599496184673@mail.yahoo.com> <0db30f58-3a3a-75ad-6a35-4bfbc15c99b4@3kitty.org> <3fed5cdc-d4ea-46f3-5457-3da8fe42161b@3kitty.org> Message-ID: <7wft7sg5ew.fsf@junk.nocrew.org> Geoff Goodfellow wrote: > jack, there was a program on Tenex IIRC called HOSTAT that > when invoked established a connection to your SURVEY server at MIT-DM > and then downloaded and printed out your latest results in a friendly > fashion. Maybe a port of Mark Crispin's ITS program: title HOSTAT Host status slurper/printer ; Mark Crispin, AI, May 1977 Host number 106 is hard coded. From geoff at iconia.com Mon Sep 7 23:28:56 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Mon, 7 Sep 2020 20:28:56 -1000 Subject: [ih] informative ARPANET Datacomputer details brief Message-ID: https://en.wikipedia.org/wiki/Datacomputer -- Geoff.Goodfellow at iconia.com living as The Truth is True From vgcerf at gmail.com Tue Sep 8 02:49:17 2020 From: vgcerf at gmail.com (vinton cerf) Date: Tue, 8 Sep 2020 05:49:17 -0400 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: <1141252064.1197160.1599533643198@mail.yahoo.com> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <5ccdff66-b07c-9eaf-b8a6-50c6e431a685@3kitty.org> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> <1141252064.1197160.1599533643198@mail.yahoo.com> Message-ID: i wonder whether CHM has cataloged what it has been given in searchable form? i also wonder whether dense crowds of wifi users creates a big desensing risk? v On Mon, Sep 7, 2020 at 10:55 PM Barbara Denny via Internet-history < internet-history at elists.isoc.org> wrote: > Hi Jack, > This might not have been clear. I worked for BBN on the packet radio > project before SRI. As you mentioned the packet radio work was in Div4 at > BBN. I decided to move to California and took a job at SRI. > Besides ARPA, SRI had contracts with other military organizations for the > networking research . The Army (CECOM) funded a lot of the work. I think a > couple projects I worked on had funding from the Navy and the Air Force > (Rome Labs? ) but I could be wrong where the dollars actually came from. > > Unfortunately I don't remember any contract numbers right now. Much of the > information on what was done is in the monthly, quarterly and final reports > delivered to the contracting organization. I think there were only a > handful of conference papers and a few talks here and there. > I have tried to use the DTIC site to find information on the SAC > Strategic C3 Experiments (Mobile IP work) and I did find it hard to locate > what I was looking for. I have no idea how SRI handled the deliverables > once a project was over. I did find documentation on the Port Expander > awhile ago but it wasn't very detailed. If you would like a copy, I will > see if I can find it again. I think it helps to know the project name when > searching for information. > barbara > > On Monday, September 7, 2020, 11:00:48 AM PDT, Jack Haverty via > Internet-history wrote: > > Hi Barbara, > > Packet Radio artifacts of any kind were elusive (at least in 2013 when > we searched), except for a few conference papers. Specifically, we were > looking for things like QTRs or other project reports that SRI > presumably submitted to ARPA, analogous to the BBN QTRs. We found a > lot of the BBN reports online at DTIC, but little from SRI. I'm not > sure, but the BBN QTRs may have been found by the search engine because > I had the BBN/ARPA contract numbers involved, but I didn't know the > appropriate contract numbers for the SRI (or any other) contracts. > > Not much detail about Fuzzballs, or Port Expanders, or other such boxes > that were prolific in the early days of the Internet. Google wasn't > much help, but that may be from lack of knowledge in how to best use the > search mechanisms. > > IMHO, there wasn't as much collaboration between the ARPANET and Packet > Radio as there was with the Internet/Gateway work at BBN. > > BBN had internal structure that to some extent influenced the > "technology transfer" between projects. In particular there were two > "divisions", Div4 and Div6, that both did similar computer and network > research. Div6 was where the ARPANET project began and evolved to an > operational service over the ten years preceding the Internet, so there > was a lot of operational experience and war wounds there. Div4 was > where the Packet Radio work was done, along with lots of other things, > such as TENEX. Both were very competent, but had different experiences. > > Although the technical staffs of the two divisions got along pretty > well, pragmatic details limited collaboration. We were physically > located in separate buildings, so hallway encounters and casual > interactions were less likely. Interesting "teaching events" that > occurred in the ARPANET propagated quickly through Div6 where the NOC > was literally just down the hallway, less so to Div4. Cross-charging > (charging your time to the other Division's project) was possible but > discouraged. > > The "Gateway Project" began in Div4, where Ginny Strazisar implemented > the first gateway; I don't know if that was a separate > project/contract, or just a part of the Packet Radio contract at the > time. Some few years later, as it became desirable for the Internet to > stabilize and become an operational service, ARPA moved the gateway work > from Div4 to Div6, folding it into the "Internet Project" contract that > was my responsibility at the time (it included various TCP > implementations, SATNET, WBNET, Remote Site Maintenance, etc.). > > That was the point where we started injecting "ARPANET DNA" into the > Internet/gateways, blatantly adopting ARPANET techniques as the most > obvious (to us in Div6) way to get the Internet to be as managed as the > ARPANET. > > I know little about the internal mechanisms of the Packet Radio > environment. But it did not move to Div6 (which became BBN > Communications Corp at some point) at least during my involvement > (roughly 1978-1990). > > So I suspect that the Packet Radio system did not reuse much of the IMP > ideas/techniques, especially the ones that were rather mundane and not > well documented or publicized (such as the "reload from neighbor" > idea). The Packet Radio QTRs, if they survive, would probably answer > that question. > > I've often wondered, from a historical perspective now, to what extent > things like internal corporate structure and organizational decisions > influenced the design and implementation of the Internet. > > /Jack > > > On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: > > Because of BBN's involvement, I am thinking Packet Radio might have > reused many of the same ideas as the IMPs for loading new software from > another node. Do you know this was not the case? I never needed to look at > that part of the code. > > I remember using XNET for examination of the Packet Radio station. Given > your recent email it sounds like you looked for old Packet Radio station > software and couldn't find it. Is this correct? > > I don't think Rockwell released their Packet Radio software in the late > 70s/early 80s. I would have to contact Rockwell if I thought bugs required > a change to a packet radio, versus the Packet Radio station, when I worked > at BBN. I know several years later SRI did get some of their code because > I implemented one of the new routing algorithms ( I am pretty sure it was > called threshold distance vector routing if anyone is interested). BTW, I > think the software may have only been tested in a simulator due to delays > in the delivery of the LPR (Low Cost Packet Radio). This was during the > SURAN program. > > The first demo of Packet Radio and ARPANET in 1976 involved submitting > the status report. Don Nielson would probably remember if that was done > through anything like email. Below is a link to an article that discusses > this event. The text from the article mentions email but more importantly > it has a link to a podcast with Don. I didn't know this podcast existed so > I still need to listen to it. I can see why you might think the report > submission may have been done by using a telnet connection to a SRI host > that had email. > > > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > > barbara > > On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via > Internet-history wrote: > > > > Hi Geoff - thanks for that bit of history and kudos! > > > > I think there's an Internet connection in your experience. I'm not sure > > what, legally, "wireless email" means. But I suspect that email was > > being sent and received, wirelessly, well before even 1982, if only to > > and from the SRI Packet Radio van that could occasionally be seen then > > roaming around the Bay Area. > > > > Of course, technically, that probably involved a Telnet connection, > > wirelessly, to some PDP-10 running an email program. But, legally, it > > might meet the court accepted definition of "wireless email". I > > learned from the lawyers that much of litigation involves arguing about > > the meaning of words and phrases. > > > > So, perhaps someone could have looked for mouldering Packet Radio (aka > > PR) hardware and software, and demonstrated wireless email circa 1978 > > over one or more PRNETs. > > > > Sadly, although I was pretty sure that interesting "prior art" would be > > found in the PR environment, we had little success 7 years ago while > > trying to find anything that might show exactly how PR equipment > > "downloaded instructions". > > > > There's remarkably little readily discoverable material about lots of > > the computer and network systems of the 70s/80s, especially internal > > details of operation, tools, procedures, etc. Plenty of stuff on > > Routing, but little on other mechanisms, or other types of networks of > > that era, at least that the lawyers and I could find. IMHO, that's a > > huge gap even in Internet History, since the Internet did not evolve in > > a vacuum, was itself composed of more than the ARPANET, and was > > surrounded by competitors (remember multiprotocol routers). > > > > /Jack > > > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > >> Jack, you're a Most Eloquent purveyor of history and that WHY explain > >> is exactly what yours truly was hoping for... Thank You for the > >> elucidation! :D > >> > >> along the lines vis-a-vis: > >> > >> So, that's a bit about the "Why", for history to ponder. The > >> experience got me wondering about the "patent history" of The > >> Internet. Clearly there was a lot of innovation in those days. > >> My recollection is that very little was patented, even if only to > >> make sure no one else could. Maybe someone will document the > >> patent-related aspects of Internet History someday. > >> > >> please excuse/pardon this immodesty: yours truly had a kinda similar > >> "lawyered" experience with respect to WHO was the purported > >> "inventor"/originator of wireless email in a patent litigation case > >> and the "challenge" of finding/presenting any extant legally > >> submissive "artifactual proof" to that effect -- for which John > >> Markoff at the New York Times wrote about in this 2006 article: > >> > >> In Silicon Valley, a Man Without a Patent > >> > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > >> > >> for which some links of "proof" exist -- for some stuff mentioned in > >> the above NYT article -- on my website https://iconia.com/ under > >> "wireless email" (in case any historians are duly interested)... > >> > >> geoff > >> > >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty >> > wrote: > >> > >> Geoff, > >> > >> Dave's IEEE paper does an excellent job of the > >> Who/What/When/Where. He's right that it was about 7 years ago. > >> Time flies... but I guess it's still "recent" when viewed as part > >> of Internet History. > >> > >> For the curious, I can add a bit more about the Why. > >> > >> Sometime in 2013, I got an email out of the blue from Charlie > >> Neuhauser, someone I didn't recognize or remember at all, asking > >> if I was the "Jack Haverty" who authored IEN 158 - documenting the > >> XNET protocol in 1980. Figuring that the statute of limitations > >> must have expired after 30+ years, I cautiously said yes. Over > >> the next few days, he hooked me up with the lawyers who were > >> involved in a patent dispute - one that had been going on for > >> several decades by then. In fact, the patent involved had been > >> issued, ran its 17 year lifetime, and expired, but there was still > >> litigation in process about whether or not the patent was valid, > >> and 17 years of violations were alleged cause for compensation in > >> the many millions. For the next few years I was involved in the > >> battles, working with the lawyers scattered all over the country. > >> I never met any of them. All our work was done by email and > >> telephone. No Zoom then or we probably would have used it. > >> > >> The core issue in the patent battle concerned "downloading > >> instructions", mechanisms such as would be involved in patching or > >> issuing new software releases to remote equipment. XNET seemed > >> to them to possibly have something to do with that, hence the > >> interest. The goal was to find hard evidence that such procedures > >> were being done by 1980, which would prove that prior art > >> existed. Hard evidence literally means "hard" - opinions help, > >> but physical equipment and running code is much more impressive in > >> a courtroom. > >> > >> They hadn't found any XNET artifacts, and I couldn't point them to > >> any surviving implementations. But I pointed out that my XNET > >> document simply captured the technology that we "stole" from the > >> ARPANET IMP experience, and that the IMPs routinely "downloaded > >> code" from their neighbors and the NOC all during the life of the > >> ARPANET. > >> > >> Since the IMPs had existed since the early 70s, that really > >> sparked their interest, and a search (worldwide) ensued to find > >> old IMPs, in the hope that just maybe one of them still had the > >> IMP software in its magnetic-core memory. A few IMPs were > >> located, but none were functional. The one in the museum at UCLA > >> seemed promising, but the owners were reluctant to even hook it up > >> to power after sitting idle for so many years, expecting it might > >> go up in smoke. > >> > >> Then I learned from the BBN alumni mailing list that an ancient > >> IMP listing had been found in a basement. The story from that > >> point is pretty well described in Dave's paper. > >> > >> Personally, it was an interesting experience. I worked > >> extensively with one lawyer in San Diego. I taught him how > >> computers and networks actually work; he taught me a lot about the > >> legal system regarding patents. IMHO, they are equally > >> convoluted and complex when viewed from the other's perspective. > >> > >> I also learned a lot about the IMP code, which I had never even > >> looked at while I was at BBN. One task I took on was to > >> exhaustively analyze the parts of the IMP code that implemented > >> the "download new instructions" functionality, writing up an > >> instruction-by-instruction description of how the code > >> accomplished that by interacting with a neighboring IMP. It was > >> a very clever design, and extremely tight code, even including > >> self-modifying instructions. Not easy to figure out (or explain > >> in language amenable to a non-technical judge or jury). So there > >> was great interest in being able to demonstrate the code in action > >> using real software from the 70s and hardware simulators. > >> Tangible evidence is much better than even expert opinions. > >> > >> The whole legal project came to a sudden end just a few months > >> prior to the first court date. I was looking forward to going > >> to Delaware (legal action was filed in Federal court in Delaware), > >> and finally meeting some of the people. But the parties settled > >> suddenly, the case was dropped, and AFAIK the patent question was > >> never resolved. > >> > >> So, that's a bit about the "Why", for history to ponder. The > >> experience got me wondering about the "patent history" of The > >> Internet. Clearly there was a lot of innovation in those days. > >> My recollection is that very little was patented, even if only to > >> make sure no one else could. Maybe someone will document the > >> patent-related aspects of Internet History someday. > >> > >> /Jack Haverty > >> > >> > >> > >> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > >>> jack, you've raised my curiosity with respect to: > >>> > >>> ... There > >>> *is* ARPANET IMP software which was recently restored and a > small > >>> ARPANET was run using simulated IMP hardware. > >>> > >>> Who/What/When/Where/Why? > >>> > >>> geoff > >>> > >>> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history > >>> >>> > wrote: > >>> > >>> Lukasz, > >>> > >>> I think that the earliest implementations of TTL called it > >>> "Time", but > >>> I'm not aware that anyone actually used time per se in > >>> gateways, at > >>> least in the early days (1977-1982 or so). > >>> > >>> TCP implementations didn't do anything with TTL other than > >>> set it on > >>> outgoing datagrams, and at least in my implementation (TCP > >>> for Unix), it > >>> was just set to some arbitrary value. Until we had some data > >>> from > >>> experimentation it was hard to evaluate ideas about what > >>> routers, hosts, > >>> et al should actually do. The early TCPs did use time in > >>> handling > >>> retransmission timers, and there was work a bit later to > >>> incorporate > >>> time more powerfully into TCP behavior, e.g., Van Jacobson's > >>> work. > >>> > >>> The early gateways, IIRC, used the terminology "time", but in > >>> practice > >>> used just hop counts, since time measurements were difficult to > >>> implement. The exception to that may be Dave Mills' > >>> Fuzzballs, since > >>> Dave was the implementor most interested in time and making > >>> precise > >>> measurements of network behavior. I *think* Dave may have > >>> used time > >>> values and delay-based routing amongst his "fuzzies". > >>> > >>> The BBN doc you're seeking might have been one of many that > >>> discussed > >>> the ARPANET internal mechanisms, e.g., ones with titles like > >>> "Routing > >>> Algorithm Improvements". The ARPANET internal mechanisms did > >>> use time. > >>> It was fairly simple in the IMPs, since the delay introduced > >>> by the > >>> synchronous communications lines could be easily predicted, > >>> and the > >>> other major component of delay was the time spent in queues, > >>> which could > >>> be measured fairly easily. > >>> > >>> I even found one BBN ARPANET Project QTR from circa 1975 that > >>> discussed > >>> the merits of the new-fangled TCP proposal that some > >>> professor had > >>> published -- and seemed to conclude it couldn't possibly work. > >>> > >>> My involvement in implementations of TCPs and gateways lasted > >>> through > >>> about mid-1983, so I don't know much of the detail of > subsequent > >>> implementations. For the various BBN gateway/router > >>> equipment, Bob > >>> Hinden would probably be a good source. The other major > >>> early player > >>> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will > >>> remember. There's also at least one paper on the Fuzzballs > >>> which may > >>> have some details. > >>> > >>> One thing I'd advise being careful of is the various > >>> "specifications" in > >>> RFCs. Much of the wording in those was intentionally > >>> non-prescriptive > >>> (use of "should" or "may" instead of "must"), to provide as > much > >>> latitude as possible for experimentation with new ideas, > >>> especially > >>> within an AS. The Internet was an Experiment. > >>> > >>> Also, there was no consistent enforcement mechanism to assure > >>> that > >>> implementations actually even conformed to the "must" > >>> elements. So > >>> Reality could be very different from Specification. > >>> > >>> I don't know of any gateway implementations that have > >>> survived. There > >>> *is* ARPANET IMP software which was recently restored and a > small > >>> ARPANET was run using simulated IMP hardware. I still have > >>> a ~1979 > >>> listing of the TCP I wrote for Unix, but haven't scanned it > >>> into digital > >>> form yet. > >>> > >>> Jack > >>> > >>> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > >>> > Jack, > >>> > > >>> > I was reading a lot of old BBN PDFs thanks to all good souls > on > >>> > this list that post nice URLs from time to time. > >>> > > >>> > I remember reading in at least one of them, that apparently > >>> first > >>> > TCP/IP implementations were indeed using TTL as literally > >>> ?time?, > >>> > not hop count. I believe there somewhere there between PDP > docs > >>> > and ARPANET docs I?ve read something to the effect ?and > >>> from this > >>> > time we changed from measuring time to simply count routing > >>> hops?. > >>> > Of course, right now google-fu is failing me. > >>> > > >>> > Quoting RFC 1009 that was already brought up, there?s quite > >>> > direct ?definition? of the field: > >>> > > >>> > "4.8. Time-To-Live > >>> > > >>> > The Time-to-Live (TTL) field of the IP header is defined > >>> to be a > >>> > timer limiting the lifetime of a datagram in the > >>> Internet. It is > >>> > an 8-bit field and the units are seconds. This would > >>> imply that > >>> > for a maximum TTL of 255 a datagram would time-out after > >>> about 4 > >>> > and a quarter minutes. Another aspect of the definition > >>> requires > >>> > each gateway (or other module) that handles a datagram to > >>> > decrement the TTL by at least one, even if the elapsed > >>> time was > >>> > much less than a second. Since this is very often the > >>> case, the > >>> > TTL effectively becomes a hop count limit on how far a > >>> datagram > >>> > can propagate through the Internet." > >>> > > >>> > Were there any implementations that survived somewhere and > >>> actually > >>> > did exactly that - counted actual time/processing delay, > >>> not hops? > >>> > And if it took 2s to process packet, did they really > >>> decrement TTL > >>> > by two? > >>> > > >>> > Thanks for any pointers, > >>> > >>> -- > >>> Internet-history mailing list > >>> Internet-history at elists.isoc.org > >>> > >>> https://elists.isoc.org/mailman/listinfo/internet-history > >>> > >>> > >>> > >>> -- > >>> Geoff.Goodfellow at iconia.com > >>> living as The Truth is True > >>> > >>> > >>> > >> > >> > >> -- > >> Geoff.Goodfellow at iconia.com > >> living as The Truth is True > >> > >> > >> > > -- > 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 dave.walden.family at gmail.com Tue Sep 8 04:21:08 2020 From: dave.walden.family at gmail.com (David Walden) Date: Tue, 08 Sep 2020 07:21:08 -0400 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) Message-ID: <3i86ovregcpwpjp0bqr77e1d.1599564068555@email.android.com> Searching for "packet radio project" at the CHM gives 1800 results, the first page of results being SRI reports. On September 8, 2020, at 5:49 AM, vinton cerf via Internet-history wrote: i wonder whether CHM has cataloged what it has been given in searchable form? i also wonder whether dense crowds of wifi users creates a big desensing risk? v On Mon, Sep 7, 2020 at 10:55 PM Barbara Denny via Internet-history < internet-history at elists.isoc.org> wrote: > Hi Jack, > This might not have been clear. I worked for BBN on the packet radio > project before SRI. As you mentioned the packet radio work was in Div4 at > BBN. I decided to move to California and took a job at SRI. > Besides ARPA, SRI had contracts with other military organizations for the > networking research . The Army (CECOM) funded a lot of the work. I think a > couple projects I worked on had funding from the Navy and the Air Force > (Rome Labs? ) but I could be wrong where the dollars actually came from. > > Unfortunately I don't remember any contract numbers right now. Much of the > information on what was done is in the monthly, quarterly and final reports > delivered to the contracting organization. I think there were only a > handful of conference papers and a few talks here and there. > I have tried to use the DTIC site to find information on the SAC > Strategic C3 Experiments (Mobile IP work) and I did find it hard to locate > what I was looking for. I have no idea how SRI handled the deliverables > once a project was over. I did find documentation on the Port Expander > awhile ago but it wasn't very detailed. If you would like a copy, I will > see if I can find it again. I think it helps to know the project name when > searching for information. > barbara > > On Monday, September 7, 2020, 11:00:48 AM PDT, Jack Haverty via > Internet-history wrote: > > Hi Barbara, > > Packet Radio artifacts of any kind were elusive (at least in 2013 when > we searched), except for a few conference papers. Specifically, we were > looking for things like QTRs or other project reports that SRI > presumably submitted to ARPA, analogous to the BBN QTRs. We found a > lot of the BBN reports online at DTIC, but little from SRI. I'm not > sure, but the BBN QTRs may have been found by the search engine because > I had the BBN/ARPA contract numbers involved, but I didn't know the > appropriate contract numbers for the SRI (or any other) contracts. > > Not much detail about Fuzzballs, or Port Expanders, or other such boxes > that were prolific in the early days of the Internet. Google wasn't > much help, but that may be from lack of knowledge in how to best use the > search mechanisms. > > IMHO, there wasn't as much collaboration between the ARPANET and Packet > Radio as there was with the Internet/Gateway work at BBN. > > BBN had internal structure that to some extent influenced the > "technology transfer" between projects. In particular there were two > "divisions", Div4 and Div6, that both did similar computer and network > research. Div6 was where the ARPANET project began and evolved to an > operational service over the ten years preceding the Internet, so there > was a lot of operational experience and war wounds there. Div4 was > where the Packet Radio work was done, along with lots of other things, > such as TENEX. Both were very competent, but had different experiences. > > Although the technical staffs of the two divisions got along pretty > well, pragmatic details limited collaboration. We were physically > located in separate buildings, so hallway encounters and casual > interactions were less likely. Interesting "teaching events" that > occurred in the ARPANET propagated quickly through Div6 where the NOC > was literally just down the hallway, less so to Div4. Cross-charging > (charging your time to the other Division's project) was possible but > discouraged. > > The "Gateway Project" began in Div4, where Ginny Strazisar implemented > the first gateway; I don't know if that was a separate > project/contract, or just a part of the Packet Radio contract at the > time. Some few years later, as it became desirable for the Internet to > stabilize and become an operational service, ARPA moved the gateway work > from Div4 to Div6, folding it into the "Internet Project" contract that > was my responsibility at the time (it included various TCP > implementations, SATNET, WBNET, Remote Site Maintenance, etc.). > > That was the point where we started injecting "ARPANET DNA" into the > Internet/gateways, blatantly adopting ARPANET techniques as the most > obvious (to us in Div6) way to get the Internet to be as managed as the > ARPANET. > > I know little about the internal mechanisms of the Packet Radio > environment. But it did not move to Div6 (which became BBN > Communications Corp at some point) at least during my involvement > (roughly 1978-1990). > > So I suspect that the Packet Radio system did not reuse much of the IMP > ideas/techniques, especially the ones that were rather mundane and not > well documented or publicized (such as the "reload from neighbor" > idea). The Packet Radio QTRs, if they survive, would probably answer > that question. > > I've often wondered, from a historical perspective now, to what extent > things like internal corporate structure and organizational decisions > influenced the design and implementation of the Internet. > > /Jack > > > On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: > > Because of BBN's involvement, I am thinking Packet Radio might have > reused many of the same ideas as the IMPs for loading new software from > another node. Do you know this was not the case? I never needed to look at > that part of the code. > > I remember using XNET for examination of the Packet Radio station. Given > your recent email it sounds like you looked for old Packet Radio station > software and couldn't find it. Is this correct? > > I don't think Rockwell released their Packet Radio software in the late > 70s/early 80s. I would have to contact Rockwell if I thought bugs required > a change to a packet radio, versus the Packet Radio station, when I worked > at BBN. I know several years later SRI did get some of their code because > I implemented one of the new routing algorithms ( I am pretty sure it was > called threshold distance vector routing if anyone is interested). BTW, I > think the software may have only been tested in a simulator due to delays > in the delivery of the LPR (Low Cost Packet Radio). This was during the > SURAN program. > > The first demo of Packet Radio and ARPANET in 1976 involved submitting > the status report. Don Nielson would probably remember if that was done > through anything like email. Below is a link to an article that discusses > this event. The text from the article mentions email but more importantly > it has a link to a podcast with Don. I didn't know this podcast existed so > I still need to listen to it. I can see why you might think the report > submission may have been done by using a telnet connection to a SRI host > that had email. > > > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > > barbara > > On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via > Internet-history wrote: > > > > Hi Geoff - thanks for that bit of history and kudos! > > > > I think there's an Internet connection in your experience. I'm not sure > > what, legally, "wireless email" means. But I suspect that email was > > being sent and received, wirelessly, well before even 1982, if only to > > and from the SRI Packet Radio van that could occasionally be seen then > > roaming around the Bay Area. > > > > Of course, technically, that probably involved a Telnet connection, > > wirelessly, to some PDP-10 running an email program. But, legally, it > > might meet the court accepted definition of "wireless email". I > > learned from the lawyers that much of litigation involves arguing about > > the meaning of words and phrases. > > > > So, perhaps someone could have looked for mouldering Packet Radio (aka > > PR) hardware and software, and demonstrated wireless email circa 1978 > > over one or more PRNETs. > > > > Sadly, although I was pretty sure that interesting "prior art" would be > > found in the PR environment, we had little success 7 years ago while > > trying to find anything that might show exactly how PR equipment > > "downloaded instructions". > > > > There's remarkably little readily discoverable material about lots of > > the computer and network systems of the 70s/80s, especially internal > > details of operation, tools, procedures, etc. Plenty of stuff on > > Routing, but little on other mechanisms, or other types of networks of > > that era, at least that the lawyers and I could find. IMHO, that's a > > huge gap even in Internet History, since the Internet did not evolve in > > a vacuum, was itself composed of more than the ARPANET, and was > > surrounded by competitors (remember multiprotocol routers). > > > > /Jack > > > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > >> Jack, you're a Most Eloquent purveyor of history and that WHY explain > >> is exactly what yours truly was hoping for... Thank You for the > >> elucidation! :D > >> > >> along the lines vis-a-vis: > >> > >> So, that's a bit about the "Why", for history to ponder. The > >> experience got me wondering about the "patent history" of The > >> Internet. Clearly there was a lot of innovation in those days. > >> My recollection is that very little was patented, even if only to > >> make sure no one else could. Maybe someone will document the > >> patent-related aspects of Internet History someday. > >> > >> please excuse/pardon this immodesty: yours truly had a kinda similar > >> "lawyered" experience with respect to WHO was the purported > >> "inventor"/originator of wireless email in a patent litigation case > >> and the "challenge" of finding/presenting any extant legally > >> submissive "artifactual proof" to that effect -- for which John > >> Markoff at the New York Times wrote about in this 2006 article: > >> > >> In Silicon Valley, a Man Without a Patent > >> > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > >> > >> for which some links of "proof" exist -- for some stuff mentioned in > >> the above NYT article -- on my website https://iconia.com/ under > >> "wireless email" (in case any historians are duly interested)... > >> > >> geoff > >> > >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty >> > wrote: > >> > >> Geoff, > >> > >> Dave's IEEE paper does an excellent job of the > >> Who/What/When/Where. He's right that it was about 7 years ago. > >> Time flies... but I guess it's still "recent" when viewed as part > >> of Internet History. > >> > >> For the curious, I can add a bit more about the Why. > >> > >> Sometime in 2013, I got an email out of the blue from Charlie > >> Neuhauser, someone I didn't recognize or remember at all, asking > >> if I was the "Jack Haverty" who authored IEN 158 - documenting the > >> XNET protocol in 1980. Figuring that the statute of limitations > >> must have expired after 30+ years, I cautiously said yes. Over > >> the next few days, he hooked me up with the lawyers who were > >> involved in a patent dispute - one that had been going on for > >> several decades by then. In fact, the patent involved had been > >> issued, ran its 17 year lifetime, and expired, but there was still > >> litigation in process about whether or not the patent was valid, > >> and 17 years of violations were alleged cause for compensation in > >> the many millions. For the next few years I was involved in the > >> battles, working with the lawyers scattered all over the country. > >> I never met any of them. All our work was done by email and > >> telephone. No Zoom then or we probably would have used it. > >> > >> The core issue in the patent battle concerned "downloading > >> instructions", mechanisms such as would be involved in patching or > >> issuing new software releases to remote equipment. XNET seemed > >> to them to possibly have something to do with that, hence the > >> interest. The goal was to find hard evidence that such procedures > >> were being done by 1980, which would prove that prior art > >> existed. Hard evidence literally means "hard" - opinions help, > >> but physical equipment and running code is much more impressive in > >> a courtroom. > >> > >> They hadn't found any XNET artifacts, and I couldn't point them to > >> any surviving implementations. But I pointed out that my XNET > >> document simply captured the technology that we "stole" from the > >> ARPANET IMP experience, and that the IMPs routinely "downloaded > >> code" from their neighbors and the NOC all during the life of the > >> ARPANET. > >> > >> Since the IMPs had existed since the early 70s, that really > >> sparked their interest, and a search (worldwide) ensued to find > >> old IMPs, in the hope that just maybe one of them still had the > >> IMP software in its magnetic-core memory. A few IMPs were > >> located, but none were functional. The one in the museum at UCLA > >> seemed promising, but the owners were reluctant to even hook it up > >> to power after sitting idle for so many years, expecting it might > >> go up in smoke. > >> > >> Then I learned from the BBN alumni mailing list that an ancient > >> IMP listing had been found in a basement. The story from that > >> point is pretty well described in Dave's paper. > >> > >> Personally, it was an interesting experience. I worked > >> extensively with one lawyer in San Diego. I taught him how > >> computers and networks actually work; he taught me a lot about the > >> legal system regarding patents. IMHO, they are equally > >> convoluted and complex when viewed from the other's perspective. > >> > >> I also learned a lot about the IMP code, which I had never even > >> looked at while I was at BBN. One task I took on was to > >> exhaustively analyze the parts of the IMP code that implemented > >> the "download new instructions" functionality, writing up an > >> instruction-by-instruction description of how the code > >> accomplished that by interacting with a neighboring IMP. It was > >> a very clever design, and extremely tight code, even including > >> self-modifying instructions. Not easy to figure out (or explain > >> in language amenable to a non-technical judge or jury). So there > >> was great interest in being able to demonstrate the code in action > >> using real software from the 70s and hardware simulators. > >> Tangible evidence is much better than even expert opinions. > >> > >> The whole legal project came to a sudden end just a few months > >> prior to the first court date. I was looking forward to going > >> to Delaware (legal action was filed in Federal court in Delaware), > >> and finally meeting some of the people. But the parties settled > >> suddenly, the case was dropped, and AFAIK the patent question was > >> never resolved. > >> > >> So, that's a bit about the "Why", for history to ponder. The > >> experience got me wondering about the "patent history" of The > >> Internet. Clearly there was a lot of innovation in those days. > >> My recollection is that very little was patented, even if only to > >> make sure no one else could. Maybe someone will document the > >> patent-related aspects of Internet History someday. > >> > >> /Jack Haverty > >> > >> > >> > >> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > >>> jack, you've raised my curiosity with respect to: > >>> > >>> ... There > >>> *is* ARPANET IMP software which was recently restored and a > small > >>> ARPANET was run using simulated IMP hardware. > >>> > >>> Who/What/When/Where/Why? > >>> > >>> geoff > >>> > >>> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history > >>> >>> > wrote: > >>> > >>> Lukasz, > >>> > >>> I think that the earliest implementations of TTL called it > >>> "Time", but > >>> I'm not aware that anyone actually used time per se in > >>> gateways, at > >>> least in the early days (1977-1982 or so). > >>> > >>> TCP implementations didn't do anything with TTL other than > >>> set it on > >>> outgoing datagrams, and at least in my implementation (TCP > >>> for Unix), it > >>> was just set to some arbitrary value. Until we had some data > >>> from > >>> experimentation it was hard to evaluate ideas about what > >>> routers, hosts, > >>> et al should actually do. The early TCPs did use time in > >>> handling > >>> retransmission timers, and there was work a bit later to > >>> incorporate > >>> time more powerfully into TCP behavior, e.g., Van Jacobson's > >>> work. > >>> > >>> The early gateways, IIRC, used the terminology "time", but in > >>> practice > >>> used just hop counts, since time measurements were difficult to > >>> implement. The exception to that may be Dave Mills' > >>> Fuzzballs, since > >>> Dave was the implementor most interested in time and making > >>> precise > >>> measurements of network behavior. I *think* Dave may have > >>> used time > >>> values and delay-based routing amongst his "fuzzies". > >>> > >>> The BBN doc you're seeking might have been one of many that > >>> discussed > >>> the ARPANET internal mechanisms, e.g., ones with titles like > >>> "Routing > >>> Algorithm Improvements". The ARPANET internal mechanisms did > >>> use time. > >>> It was fairly simple in the IMPs, since the delay introduced > >>> by the > >>> synchronous communications lines could be easily predicted, > >>> and the > >>> other major component of delay was the time spent in queues, > >>> which could > >>> be measured fairly easily. > >>> > >>> I even found one BBN ARPANET Project QTR from circa 1975 that > >>> discussed > >>> the merits of the new-fangled TCP proposal that some > >>> professor had > >>> published -- and seemed to conclude it couldn't possibly work. > >>> > >>> My involvement in implementations of TCPs and gateways lasted > >>> through > >>> about mid-1983, so I don't know much of the detail of > subsequent > >>> implementations. For the various BBN gateway/router > >>> equipment, Bob > >>> Hinden would probably be a good source. The other major > >>> early player > >>> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will > >>> remember. There's also at least one paper on the Fuzzballs > >>> which may > >>> have some details. > >>> > >>> One thing I'd advise being careful of is the various > >>> "specifications" in > >>> RFCs. Much of the wording in those was intentionally > >>> non-prescriptive > >>> (use of "should" or "may" instead of "must"), to provide as > much > >>> latitude as possible for experimentation with new ideas, > >>> especially > >>> within an AS. The Internet was an Experiment. > >>> > >>> Also, there was no consistent enforcement mechanism to assure > >>> that > >>> implementations actually even conformed to the "must" > >>> elements. So > >>> Reality could be very different from Specification. > >>> > >>> I don't know of any gateway implementations that have > >>> survived. There > >>> *is* ARPANET IMP software which was recently restored and a > small > >>> ARPANET was run using simulated IMP hardware. I still have > >>> a ~1979 > >>> listing of the TCP I wrote for Unix, but haven't scanned it > >>> into digital > >>> form yet. > >>> > >>> Jack > >>> > >>> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > >>> > Jack, > >>> > > >>> > I was reading a lot of old BBN PDFs thanks to all good souls > on > >>> > this list that post nice URLs from time to time. > >>> > > >>> > I remember reading in at least one of them, that apparently > >>> first > >>> > TCP/IP implementations were indeed using TTL as literally > >>> ?time?, > >>> > not hop count. I believe there somewhere there between PDP > docs > >>> > and ARPANET docs I?ve read something to the effect ?and > >>> from this > >>> > time we changed from measuring time to simply count routing > >>> hops?. > >>> > Of course, right now google-fu is failing me. > >>> > > >>> > Quoting RFC 1009 that was already brought up, there?s quite > >>> > direct ?definition? of the field: > >>> > > >>> > "4.8. Time-To-Live > >>> > > >>> > The Time-to-Live (TTL) field of the IP header is defined > >>> to be a > >>> > timer limiting the lifetime of a datagram in the > >>> Internet. It is > >>> > an 8-bit field and the units are seconds. This would > >>> imply that > >>> > for a maximum TTL of 255 a datagram would time-out after > >>> about 4 > >>> > and a quarter minutes. Another aspect of the definition > >>> requires > >>> > each gateway (or other module) that handles a datagram to > >>> > decrement the TTL by at least one, even if the elapsed > >>> time was > >>> > much less than a second. Since this is very often the > >>> case, the > >>> > TTL effectively becomes a hop count limit on how far a > >>> datagram > >>> > can propagate through the Internet." > >>> > > >>> > Were there any implementations that survived somewhere and > >>> actually > >>> > did exactly that - counted actual time/processing delay, > >>> not hops? > >>> > And if it took 2s to process packet, did they really > >>> decrement TTL > >>> > by two? > >>> > > >>> > Thanks for any pointers, > >>> > >>> -- > >>> Internet-history mailing list > >>> Internet-history at elists.isoc.org > >>> > >>> https://elists.isoc.org/mailman/listinfo/internet-history > >>> > >>> > >>> > >>> -- > >>> Geoff.Goodfellow at iconia.com > >>> living as The Truth is True > >>> > >>> > >>> > >> > >> > >> -- > >> Geoff.Goodfellow at iconia.com > >> living as The Truth is True > >> > >> > >> > > -- > 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 stewart at serissa.com Tue Sep 8 09:29:11 2020 From: stewart at serissa.com (Lawrence Stewart) Date: Tue, 8 Sep 2020 12:29:11 -0400 Subject: [ih] Packet Radio Software In-Reply-To: References: Message-ID: I was peripherally involved in the PRNet activities in the Bay Area and went to a few quarterly meetings at SRI. (I built an 1822 interface for the Alto and we used it to encapsulate PUP packets for transit over PRNet, linking two Xerox sites in Palo Alto*) The radios and radio software was built by Rockwell (nee Collins Radio) and my youthful read on the vibes at meetings was that the SRI/Arpa people did not think much of the software development practices. One story I heard was that Rockwell management insisted on very tight control of the top secret source code. This meant that the master copy was to be kept on punch cards in the manager?s office. So it seems unlikely to me that the radios would be reloading their software from neighbors, at least until after other folks were able to make modifications. * http://www.watersprings.org/pub/rfc/ien/ien78.pdf -L From dan at lynch.com Tue Sep 8 11:14:23 2020 From: dan at lynch.com (Dan Lynch) Date: Tue, 8 Sep 2020 11:14:23 -0700 Subject: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) In-Reply-To: <7c403414-efea-6aea-6d23-831d9534f79a@3kitty.org> References: <7c403414-efea-6aea-6d23-831d9534f79a@3kitty.org> Message-ID: <4D9AB8F5-3FEA-4D61-8392-59A3AB976519@lynch.com> Jack, I testing the list right now. But I do not recall how the ACE coaster came into existence! Glad it still lives. Dan Cell 650-776-7313 > On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history wrote: > > ?Thanks Dan! > > There's so much of the history that didn't get recorded in RFCs and > such, and mail list archives from that era are rare. We weren't very > good about documenting things, especially the "why" of how decisions > were made. > > There's plenty of room for more participation! Perhaps you can provide > the story behind this artifact of the early Internet? > > ACE Coaster > > That coaster has been sitting on my desk for close to 40 years. The > lettering is fading, after too many attacks by marauding coffee mugs > over the decades, and a few trips to the floor courtesy of a roaming cat. > > The story of ACE, and Interop which followed, is an important part of > Internet history. There tends to be a focus on protocols and > algorithms, but innovations like Interop were, IMHO, equally important > to the success of the Internet by making it accessible to the masses and > emphasizing the importance of working systems. > > Perhaps more important. Tell us the story. > > /Jack > > >> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >> Forgot to copy the fantastic list! >> >> Dan >> >> Cell 650-776-7313 >> >> Begin forwarded message: >> >>> From: Dan Lynch >>> Date: September 5, 2020 at 11:42:36 AM PDT >>> To: Joseph Touch >>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) >>> >>> ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >>> >>> Dan >>> >>> Cell 650-776-7313 >>> >>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >>>> >>>> ?HI, all, >>>> >>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>>>> >>>>>>> From: Joseph Touch >>>>>> FYI - we moved the archives here. >>>>> I've just noticed that the archives are now only accessible to list members? >>>> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >>>> >>>> Please let me know if you continue to find otherwise. >>>> >>>> Joe (as list admin) >>>> -- >>>> 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 dan at lynch.com Tue Sep 8 11:52:23 2020 From: dan at lynch.com (Dan Lynch) Date: Tue, 8 Sep 2020 11:52:23 -0700 Subject: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) In-Reply-To: <7c403414-efea-6aea-6d23-831d9534f79a@3kitty.org> References: <7c403414-efea-6aea-6d23-831d9534f79a@3kitty.org> Message-ID: SoJack, you are asking me to recount how Interop came to be. I shall do that as quickly as I can here. In the early 80s I was at ISI in charge of the computer facility. After a year or so there came to be a term New Computing Environment to describe the advent of personal computers and the death of timesharing! I think Keith Uncapher coined the term, tho maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward a few years and I was back in Silicon Valley looking to start a company like my pals at Stanford had been doing. I looked around and noticed that the Internet was gaining traction but the nascent companies had not quite got it right. So I convinced Barry Leiner who was a program manager there in 85/86 to let me convene a 3 day workshop on TCP/IP protocols to explain them to the hundred or so implementation teams out there. I got the actual protocol designers to come to Monterrey California for 3 days. There was no company name then. I had no idea where this was going then. Needless to say the event was a success. The researchers learned of real life problems the early vendors we?re experiencing and the vendors learned a lot more about the Internet and what worked and what still needed further steps. I now had a business of teaching (through others) the vendors and advanced customers how the Internet works. I needed a name. I took the old name above and called it Advanced Computing Environment. A few years in to this the world really wanted to see working systems and I decided to try a trade show, with one critical addition: the systems had to be connected to an actual working Internet! And while I was on the phone with one of my brilliant tutor people from BBN, Craig Partridge, as were were concluding the call he blurted out ?I?ll see you at Interop ?. I hung up the phone and called my lawyer to register the name immediately! I had been calling it The TCP/IP Interoperability Conference and Exhibition! Ah, simplicity. That was in September of 1988. It had 50 vendors and 5000 attendees. In 1990 it had grown to 200 vendors and 30,000 attendees. Clearly this Internet stuff was catching on, eh? So I sold the company and stayed on for 5 more years as the PR guy and growing it into Europe and Asia. 30 years later it still exists in about 10 locations I. The world. Not quite the same, but still stressing interoperability. Thanks for asking, Jack. Dan Cell 650-776-7313 > On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history wrote: > > ?Thanks Dan! > > There's so much of the history that didn't get recorded in RFCs and > such, and mail list archives from that era are rare. We weren't very > good about documenting things, especially the "why" of how decisions > were made. > > There's plenty of room for more participation! Perhaps you can provide > the story behind this artifact of the early Internet? > > ACE Coaster > > That coaster has been sitting on my desk for close to 40 years. The > lettering is fading, after too many attacks by marauding coffee mugs > over the decades, and a few trips to the floor courtesy of a roaming cat. > > The story of ACE, and Interop which followed, is an important part of > Internet history. There tends to be a focus on protocols and > algorithms, but innovations like Interop were, IMHO, equally important > to the success of the Internet by making it accessible to the masses and > emphasizing the importance of working systems. > > Perhaps more important. Tell us the story. > > /Jack > > >> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >> Forgot to copy the fantastic list! >> >> Dan >> >> Cell 650-776-7313 >> >> Begin forwarded message: >> >>> From: Dan Lynch >>> Date: September 5, 2020 at 11:42:36 AM PDT >>> To: Joseph Touch >>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) >>> >>> ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >>> >>> Dan >>> >>> Cell 650-776-7313 >>> >>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >>>> >>>> ?HI, all, >>>> >>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>>>> >>>>>>> From: Joseph Touch >>>>>> FYI - we moved the archives here. >>>>> I've just noticed that the archives are now only accessible to list members? >>>> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >>>> >>>> Please let me know if you continue to find otherwise. >>>> >>>> Joe (as list admin) >>>> -- >>>> 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 craig at tereschau.net Tue Sep 8 13:13:50 2020 From: craig at tereschau.net (Craig Partridge) Date: Tue, 8 Sep 2020 14:13:50 -0600 Subject: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) In-Reply-To: References: <7c403414-efea-6aea-6d23-831d9534f79a@3kitty.org> Message-ID: Dan was kind enough to mention me, which makes it a little harder to send this note but I'll do it anyway. I think Dan underplays how radical Interop was. Vendors had to connect their equipment to the show network. There was a team of Internet wizards who helped setup the show network for each show. (I recall stories of laying things out on netting in a warehouse so that it could easily be transferred to the show floor). But it meant products actually worked. And then there was the education component, which as Dan tells, started things. Dan took the view that he tried to hire the top instructors in the field and compensate them properly. At a time when competitors were paying 10% of the gross or $2K, whichever was *less*, Dan paid $2K or 10% of the gross, whichever was *more*. That meant Interop's courses, instead of being taught by a grad student or a professor trying out a new course idea, were taught by folks like Doug Comer and Scott Bradner and Radia Perlman, teaching their areas of expertise. As a result, the educational program was immense -- many thousands of students. And because the instructors were already in town, Dan could recruit us to come do a panel session for the main program as well. The panels were often also huge. (I still remember a session I led that included Dave Clark and a couple of other key folks -- the room was packed -- probably 5,000 people -- and was so jammed that someone stepped on the tablecloth for the projector, dumping all our slides [this was pre-Powerpoint real-time projection] on the floor! So I had to talk w/o slides while the other speakers ran to the back to reinsert their slides!). Attending Interop was a full week affair -- you got trained and then went to the showfloor and conference sessions, while grabbing a handful of the old Doubletree cookies (twice the size they are today) during the breaks. The transitions in size were wild. We went from Monterrey, to the Santa Clara TechMart, to the San Jose Convention center to the Moscone Center in SF in rapid succession. Craig On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history < internet-history at elists.isoc.org> wrote: > SoJack, you are asking me to recount how Interop came to be. I shall do > that as quickly as I can here. > > In the early 80s I was at ISI in charge of the computer facility. After a > year or so there came to be a term New Computing Environment to describe > the advent of personal computers and the death of timesharing! I think > Keith Uncapher coined the term, tho maybe Bob Kahn and Vint Cerf had a hand > in it. Anyway fast forward a few years and I was back in Silicon Valley > looking to start a company like my pals at Stanford had been doing. I > looked around and noticed that the Internet was gaining traction but the > nascent companies had not quite got it right. So I convinced Barry Leiner > who was a program manager there in 85/86 to let me convene a 3 day workshop > on TCP/IP protocols to explain them to the hundred or so implementation > teams out there. I got the actual protocol designers to come to Monterrey > California for 3 days. There was no company name then. I had no idea where > this was going then. Needless to say the event was a success. The > researchers learned of real life problems the early vendors we?re > experiencing and the vendors learned a lot more about the Internet and what > worked and what still needed further steps. > > I now had a business of teaching (through others) the vendors and advanced > customers how the Internet works. I needed a name. I took the old name > above and called it Advanced Computing Environment. > > A few years in to this the world really wanted to see working systems and > I decided to try a trade show, with one critical addition: the systems had > to be connected to an actual working Internet! And while I was on the > phone with one of my brilliant tutor people from BBN, Craig Partridge, as > were were concluding the call he blurted out ?I?ll see you at Interop ?. I > hung up the phone and called my lawyer to register the name immediately! I > had been calling it The TCP/IP Interoperability Conference and Exhibition! > Ah, simplicity. > > That was in September of 1988. It had 50 vendors and 5000 attendees. In > 1990 it had grown to 200 vendors and 30,000 attendees. Clearly this > Internet stuff was catching on, eh? > > So I sold the company and stayed on for 5 more years as the PR guy and > growing it into Europe and Asia. > > 30 years later it still exists in about 10 locations I. The world. Not > quite the same, but still stressing interoperability. > > Thanks for asking, Jack. > > > > Dan > > Cell 650-776-7313 > > > On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > ?Thanks Dan! > > > > There's so much of the history that didn't get recorded in RFCs and > > such, and mail list archives from that era are rare. We weren't very > > good about documenting things, especially the "why" of how decisions > > were made. > > > > There's plenty of room for more participation! Perhaps you can provide > > the story behind this artifact of the early Internet? > > > > ACE Coaster > > > > That coaster has been sitting on my desk for close to 40 years. The > > lettering is fading, after too many attacks by marauding coffee mugs > > over the decades, and a few trips to the floor courtesy of a roaming > cat. > > > > The story of ACE, and Interop which followed, is an important part of > > Internet history. There tends to be a focus on protocols and > > algorithms, but innovations like Interop were, IMHO, equally important > > to the success of the Internet by making it accessible to the masses and > > emphasizing the importance of working systems. > > > > Perhaps more important. Tell us the story. > > > > /Jack > > > > > >> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: > >> Forgot to copy the fantastic list! > >> > >> Dan > >> > >> Cell 650-776-7313 > >> > >> Begin forwarded message: > >> > >>> From: Dan Lynch > >>> Date: September 5, 2020 at 11:42:36 AM PDT > >>> To: Joseph Touch > >>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) > >>> > >>> ?Great! These discussions are amazing, considering that they are > being done by the actual inventors of much of the Internet some 3 or 4 > decades later. We were young then, eh? Of course they must be open to the > world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve > forgotten just now. > >>> > >>> Dan > >>> > >>> Cell 650-776-7313 > >>> > >>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history < > internet-history at elists.isoc.org> wrote: > >>>> > >>>> ?HI, all, > >>>> > >>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history < > internet-history at elists.isoc.org> wrote: > >>>>>>> > >>>>>>> From: Joseph Touch > >>>>>> FYI - we moved the archives here. > >>>>> I've just noticed that the archives are now only accessible to list > members? > >>>> They should have been open. If anything changed recently, this is the > first I heard. Either way, the setting has been updated to allow public > access. > >>>> > >>>> Please let me know if you continue to find otherwise. > >>>> > >>>> Joe (as list admin) > >>>> -- > >>>> 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 > -- ***** Craig Partridge's email account for professional society activities and mailing lists. From dhc at dcrocker.net Tue Sep 8 13:29:49 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 8 Sep 2020 13:29:49 -0700 Subject: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) In-Reply-To: References: <7c403414-efea-6aea-6d23-831d9534f79a@3kitty.org> Message-ID: On 9/8/2020 1:13 PM, Craig Partridge via Internet-history wrote: > And then there was the education component, which as Dan tells, started > things. Craig described the tutorials component. The other remarkable bit of culture was that the regular program of sessions, associated with the industry event, were required to have serious technical and opertional content. There were special tracks for vendor marketing, but the main program did not allow vendor hype and if anyone snuck some in, they did not get a second chance.? The program was tightly managed and often included seeking out particular presenters, rather than waiting for vendors or others to offer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dan at lynch.com Tue Sep 8 14:48:00 2020 From: dan at lynch.com (Dan Lynch) Date: Tue, 8 Sep 2020 14:48:00 -0700 Subject: [ih] Fwd: Fwd: List archives (Was: Exterior Gateway Protocol) References: Message-ID: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> Craig, I think you did not copy the list. And while I?m at it, a small edit. I paid the tutors 15% , a full 50% more than the competition. I also charged everybody 50% more than the competition because I felt it was worth it! I even charged the vendors 50% more than the competition. I turned out that I was right. Dan Cell 650-776-7313 Begin forwarded message: > From: Craig Partridge > Date: September 8, 2020 at 1:14:05 PM PDT > To: Dan Lynch > Cc: Craig Partridge via Internet-history > Subject: Re: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) > > ? > Dan was kind enough to mention me, which makes it a little harder to send this note but I'll do it anyway. > > I think Dan underplays how radical Interop was. Vendors had to connect their equipment to the show network. There was a team of Internet wizards who helped setup the show network for each show. (I recall stories of laying things out on netting in a warehouse so that it could easily be transferred to the show floor). But it meant products actually worked. > > And then there was the education component, which as Dan tells, started things. Dan took the view that he tried to hire the top instructors in the field and compensate them properly. At a time when competitors were paying 10% of the gross or $2K, whichever was less, Dan paid $2K or 10% of the gross, whichever was more. That meant Interop's courses, instead of being taught by a grad student or a professor trying out a new course idea, were taught by folks like Doug Comer and Scott Bradner and Radia Perlman, teaching their areas of expertise. As a result, the educational program was immense -- many thousands of students. And because the instructors were already in town, Dan could recruit us to come do a panel session for the main program as well. The panels were often also huge. (I still remember a session I led that included Dave Clark and a couple of other key folks -- the room was packed -- probably 5,000 people -- and was so jammed that someone stepped on the tablecloth for the projector, dumping all our slides [this was pre-Powerpoint real-time projection] on the floor! So I had to talk w/o slides while the other speakers ran to the back to reinsert their slides!). > > Attending Interop was a full week affair -- you got trained and then went to the showfloor and conference sessions, while grabbing a handful of the old Doubletree cookies (twice the size they are today) during the breaks. > > The transitions in size were wild. We went from Monterrey, to the Santa Clara TechMart, to the San Jose Convention center to the Moscone Center in SF in rapid succession. > > Craig > >> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history wrote: >> SoJack, you are asking me to recount how Interop came to be. I shall do that as quickly as I can here. >> >> In the early 80s I was at ISI in charge of the computer facility. After a year or so there came to be a term New Computing Environment to describe the advent of personal computers and the death of timesharing! I think Keith Uncapher coined the term, tho maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward a few years and I was back in Silicon Valley looking to start a company like my pals at Stanford had been doing. I looked around and noticed that the Internet was gaining traction but the nascent companies had not quite got it right. So I convinced Barry Leiner who was a program manager there in 85/86 to let me convene a 3 day workshop on TCP/IP protocols to explain them to the hundred or so implementation teams out there. I got the actual protocol designers to come to Monterrey California for 3 days. There was no company name then. I had no idea where this was going then. Needless to say the event was a success. The researchers learned of real life problems the early vendors we?re experiencing and the vendors learned a lot more about the Internet and what worked and what still needed further steps. >> >> I now had a business of teaching (through others) the vendors and advanced customers how the Internet works. I needed a name. I took the old name above and called it Advanced Computing Environment. >> >> A few years in to this the world really wanted to see working systems and I decided to try a trade show, with one critical addition: the systems had to be connected to an actual working Internet! And while I was on the phone with one of my brilliant tutor people from BBN, Craig Partridge, as were were concluding the call he blurted out ?I?ll see you at Interop ?. I hung up the phone and called my lawyer to register the name immediately! I had been calling it The TCP/IP Interoperability Conference and Exhibition! Ah, simplicity. >> >> That was in September of 1988. It had 50 vendors and 5000 attendees. In 1990 it had grown to 200 vendors and 30,000 attendees. Clearly this Internet stuff was catching on, eh? >> >> So I sold the company and stayed on for 5 more years as the PR guy and growing it into Europe and Asia. >> >> 30 years later it still exists in about 10 locations I. The world. Not quite the same, but still stressing interoperability. >> >> Thanks for asking, Jack. >> >> >> >> Dan >> >> Cell 650-776-7313 >> >> > On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history wrote: >> > >> > ?Thanks Dan! >> > >> > There's so much of the history that didn't get recorded in RFCs and >> > such, and mail list archives from that era are rare. We weren't very >> > good about documenting things, especially the "why" of how decisions >> > were made. >> > >> > There's plenty of room for more participation! Perhaps you can provide >> > the story behind this artifact of the early Internet? >> > >> > ACE Coaster >> > >> > That coaster has been sitting on my desk for close to 40 years. The >> > lettering is fading, after too many attacks by marauding coffee mugs >> > over the decades, and a few trips to the floor courtesy of a roaming cat. >> > >> > The story of ACE, and Interop which followed, is an important part of >> > Internet history. There tends to be a focus on protocols and >> > algorithms, but innovations like Interop were, IMHO, equally important >> > to the success of the Internet by making it accessible to the masses and >> > emphasizing the importance of working systems. >> > >> > Perhaps more important. Tell us the story. >> > >> > /Jack >> > >> > >> >> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >> >> Forgot to copy the fantastic list! >> >> >> >> Dan >> >> >> >> Cell 650-776-7313 >> >> >> >> Begin forwarded message: >> >> >> >>> From: Dan Lynch >> >>> Date: September 5, 2020 at 11:42:36 AM PDT >> >>> To: Joseph Touch >> >>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) >> >>> >> >>> ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >> >>> >> >>> Dan >> >>> >> >>> Cell 650-776-7313 >> >>> >> >>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >> >>>> >> >>>> ?HI, all, >> >>>> >> >>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >> >>>>>>> >> >>>>>>> From: Joseph Touch >> >>>>>> FYI - we moved the archives here. >> >>>>> I've just noticed that the archives are now only accessible to list members? >> >>>> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >> >>>> >> >>>> Please let me know if you continue to find otherwise. >> >>>> >> >>>> Joe (as list admin) >> >>>> -- >> >>>> 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 > > > -- > ***** > Craig Partridge's email account for professional society activities and mailing lists. From b_a_denny at yahoo.com Tue Sep 8 16:29:59 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Tue, 8 Sep 2020 23:29:59 +0000 (UTC) Subject: [ih] Packet Radio Software In-Reply-To: References: Message-ID: <1220703022.30538.1599607799133@mail.yahoo.com> Hi Thanks for the ien78 reference! It brings back memories, especially looking at the pictures. I will take a more detailed look soon.? BTW, in doing some quick wikipedia lookups regarding packet radio I noticed what may be a mistake.? I have heard of the EPR, VPR, IPR, and the LPR as names for the different?Packet Radio hardware.? A Wikipedia entry for prnet mentioned a UPR.? I have never heard of it before. Anyone out there know about this one?? Given that same article doesn't mention the VPR? I wonder if an error got propagated somehow.? barbara? On Tuesday, September 8, 2020, 09:29:38 AM PDT, Lawrence Stewart via Internet-history wrote: I was peripherally involved in the PRNet activities in the Bay Area and went to a few quarterly meetings at SRI.? (I built an 1822 interface for the Alto and we used it to encapsulate PUP packets for transit over PRNet, linking two Xerox sites in Palo Alto*) The radios and radio software was built by Rockwell (nee Collins Radio) and my youthful read on the vibes at meetings was that the SRI/Arpa people did not think much of the software development practices.? One story I heard was that Rockwell management insisted on very tight control of the top secret source code.? This meant that the master copy was to be kept on punch cards in the manager?s office. So it seems unlikely to me that the radios would be reloading their software from neighbors, at least until after other folks were able to make modifications. * http://www.watersprings.org/pub/rfc/ien/ien78.pdf -L -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From vint at google.com Wed Sep 9 03:21:34 2020 From: vint at google.com (Vint Cerf) Date: Wed, 9 Sep 2020 06:21:34 -0400 Subject: [ih] Packet Radio Software In-Reply-To: <1220703022.30538.1599607799133@mail.yahoo.com> References: <1220703022.30538.1599607799133@mail.yahoo.com> Message-ID: "upgraded packet radio" v On Tue, Sep 8, 2020 at 7:31 PM Barbara Denny via Internet-history < internet-history at elists.isoc.org> wrote: > Hi > Thanks for the ien78 reference! It brings back memories, especially > looking at the pictures. I will take a more detailed look soon. > BTW, in doing some quick wikipedia lookups regarding packet radio I > noticed what may be a mistake. I have heard of the EPR, VPR, IPR, and the > LPR as names for the different Packet Radio hardware. A Wikipedia entry > for prnet mentioned a UPR. I have never heard of it before. Anyone out > there know about this one? Given that same article doesn't mention the > VPR I wonder if an error got propagated somehow. > barbara > On Tuesday, September 8, 2020, 09:29:38 AM PDT, Lawrence Stewart via > Internet-history wrote: > > I was peripherally involved in the PRNet activities in the Bay Area and > went to a few quarterly meetings at SRI. (I built an 1822 interface for > the Alto and we used it to encapsulate PUP packets for transit over PRNet, > linking two Xerox sites in Palo Alto*) > > The radios and radio software was built by Rockwell (nee Collins Radio) > and my youthful read on the vibes at meetings was that the SRI/Arpa people > did not think much of the software development practices. One story I > heard was that Rockwell management insisted on very tight control of the > top secret source code. This meant that the master copy was to be kept on > punch cards in the manager?s office. > > So it seems unlikely to me that the radios would be reloading their > software from neighbors, at least until after other folks were able to make > modifications. > > * http://www.watersprings.org/pub/rfc/ien/ien78.pdf < > http://www.watersprings.org/pub/rfc/ien/ien78.pdf> > > -L > > -- > 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 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From touch at strayalpha.com Wed Sep 9 11:18:32 2020 From: touch at strayalpha.com (Joseph Touch) Date: Wed, 9 Sep 2020 11:18:32 -0700 Subject: [ih] List archives (Was: Exterior Gateway Protocol) In-Reply-To: <7EEA9E47-847C-4758-B0C7-A3A8ACE6E7D2@strayalpha.com> References: <20200905145836.5A15918C09A@mercury.lcs.mit.edu> <74D55C16-5AAE-4803-96D0-4847DB73F240@strayalpha.com> <7EEA9E47-847C-4758-B0C7-A3A8ACE6E7D2@strayalpha.com> Message-ID: <296E8454-53A7-4257-A37C-C5185768A7CB@strayalpha.com> Hi, all, The bug appears to have been fixed. The archives are now open to the public and appear to be accessible. Please let me know if you find otherwise. Joe (as list admin) > On Sep 6, 2020, at 12:34 PM, Joseph Touch wrote: > > Hi, all, > > Unfortunately there is a bug in the Mailman at ISOC. When I set the list archives to be open to the public, they become inaccessible to everyone now (404 link error). > > I?ve set the archive back to ?list members only? and will ask the ISOC support staff to look into the issue. Until it is fixed, it will remain as currently set. > > I?ve also heard from some of you that you might not be receiving posts. Please check your filters and try a few short tests; I have received all posts to the list without gaps, so I?m not clear that this issue is on the server side yet. > > Joe (as list admin) > >> On Sep 5, 2020, at 8:05 AM, Joseph Touch wrote: >> >> HI, all, >> >>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>> >>>> From: Joseph Touch >>> >>>> FYI - we moved the archives here. >>> >>> I've just noticed that the archives are now only accessible to list members? >> >> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >> >> Please let me know if you continue to find otherwise. >> >> Joe (as list admin) > From jack at 3kitty.org Wed Sep 9 14:40:47 2020 From: jack at 3kitty.org (Jack Haverty) Date: Wed, 9 Sep 2020 14:40:47 -0700 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> <1141252064.1197160.1599533643198@mail.yahoo.com> Message-ID: <01374e4b-5660-a87c-e7de-51ad86ce403d@3kitty.org> Radio technology has gotten a lot better over the last 40 years; my experience is that desensing isn't as much of an issue now.?? Also, signal strength decreases rapidly with distance, so socially-distanced cellphone users shouldn't have a problem, except perhaps if they try to use a phone on each ear.? /j On 9/8/20 2:49 AM, vinton cerf wrote: > i wonder whether CHM has cataloged what it has been given in > searchable form? > > i also wonder?whether dense crowds of wifi users creates a big > desensing?risk? > > v > > > On Mon, Sep 7, 2020 at 10:55 PM Barbara Denny via Internet-history > > wrote: > > ?Hi Jack, > This might not have been clear. I worked for BBN on the packet > radio project before SRI. As you mentioned the packet radio work > was in Div4 at BBN. I decided to move to California and took a job > at SRI.? > Besides ARPA, SRI had contracts with other military organizations > for the networking research . The Army (CECOM) funded a lot of the > work.? I think a couple projects I worked on had funding from the > Navy and the Air Force (Rome Labs? ) but I could be wrong where > the dollars actually came from.? > > Unfortunately I don't remember any contract numbers right now. > Much of the information on what was done is in the monthly, > quarterly and final reports delivered to the contracting > organization. I think there were only a handful of conference > papers and a few talks here and there. > ?I have tried to use the DTIC site to find information on the SAC > Strategic C3 Experiments (Mobile IP work) and I did find it hard > to locate what I was looking for. I have no idea how SRI handled > the deliverables once a project was over. I did find documentation > on the Port Expander awhile ago but it wasn't very detailed. If > you would like a copy, I will see if I can find it again.? I think > it helps to know the project name when searching for information.? > barbara? > > ? ? On Monday, September 7, 2020, 11:00:48 AM PDT, Jack Haverty > via Internet-history > wrote:? > > ?Hi Barbara, > > Packet Radio artifacts of any kind were elusive (at least in 2013 when > we searched), except for a few conference papers.? Specifically, > we were > looking for things like QTRs or other project reports that SRI > presumably submitted to ARPA, analogous to the BBN QTRs.?? We found a > lot of the BBN reports online at DTIC, but little from SRI.? I'm not > sure, but the BBN QTRs may have been found by the search engine > because > I had the BBN/ARPA contract numbers involved, but I didn't know the > appropriate contract numbers for the SRI (or any other) contracts.?? > > Not much detail about Fuzzballs, or Port Expanders, or other such > boxes > that were prolific in the early days of the Internet.? Google wasn't > much help, but that may be from lack of knowledge in how to best > use the > search mechanisms. > > IMHO, there wasn't as much collaboration between the ARPANET and > Packet > Radio as there was with the Internet/Gateway work at BBN. > > BBN had internal structure that to some extent influenced the > "technology transfer" between projects.? In particular there were two > "divisions", Div4 and Div6, that both did similar computer and network > research.? Div6 was where the ARPANET project began and evolved to an > operational service over the ten years preceding the Internet, so > there > was a lot of operational experience and war wounds there.?? Div4 was > where the Packet Radio work was done, along with lots of other things, > such as TENEX.?? Both were very competent, but had different > experiences. > > Although the technical staffs of the two divisions got along pretty > well, pragmatic details limited collaboration.? We were physically > located in separate buildings, so hallway encounters and casual > interactions were less likely.? Interesting "teaching events" that > occurred in the ARPANET propagated quickly through Div6 where the NOC > was literally just down the hallway, less so to Div4.?? Cross-charging > (charging your time to the other Division's project) was possible but > discouraged. > > The "Gateway Project" began in Div4, where Ginny Strazisar implemented > the first gateway;? I don't know if that was a separate > project/contract, or just a part of the Packet Radio contract at the > time.?? Some few years later, as it became desirable for the > Internet to > stabilize and become an operational service, ARPA moved the > gateway work > from Div4 to Div6, folding it into the "Internet Project" contract > that > was my responsibility at the time (it included various TCP > implementations, SATNET, WBNET, Remote Site Maintenance, etc.). > > That was the point where we started injecting "ARPANET DNA" into the > Internet/gateways, blatantly adopting ARPANET techniques as the most > obvious (to us in Div6) way to get the Internet to be as managed > as the > ARPANET. > > I know little about the internal mechanisms of the Packet Radio > environment.?? But it did not move to Div6 (which became BBN > Communications Corp at some point) at least during my involvement > (roughly 1978-1990). > > So I suspect that the Packet Radio system did not reuse much of > the IMP > ideas/techniques, especially the ones that were rather mundane and not > well documented or publicized (such as the "reload from neighbor" > idea).? The Packet Radio QTRs, if they survive, would probably answer > that question. > > I've often wondered, from a historical perspective now, to what extent > things like internal corporate structure and organizational decisions > influenced the design and implementation of the Internet. > > /Jack > > > On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: > >? Because of BBN's involvement, I am thinking Packet Radio might > have reused many of? the same ideas as the IMPs for loading new > software from another node. Do you know this was not the case?? I > never needed to look at that part of the code.? > > I remember using XNET for examination of the Packet Radio > station. Given your recent email it sounds like you looked for old > Packet Radio station software and couldn't find it. Is this correct?? > > I don't think Rockwell released their Packet Radio software in > the late 70s/early 80s. I would have to contact Rockwell if I > thought bugs required a change to a packet radio, versus the > Packet Radio station, when I worked at BBN. I know several years > later SRI did get some of their code? because I implemented one of > the new routing algorithms ( I am pretty sure it was called > threshold distance vector routing if anyone is interested). BTW, I > think the software may have only been tested in a simulator due to > delays in the delivery of the LPR (Low Cost Packet Radio). This > was during the SURAN program.? > > The first demo of Packet Radio and ARPANET in 1976 involved > submitting the status report.? Don Nielson would probably remember > if that was done through anything like email. Below is a link to > an article that discusses this event. The text from the article > mentions email but more importantly it has a link to a podcast > with Don. I didn't know this podcast existed so I still need to > listen to it.? I can see why you might think the report submission > may have been done by using a telnet connection to a SRI host that > had email.? > > > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > > barbara? > >? ? On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty > via Internet-history > wrote:? > >? > >? Hi Geoff - thanks for that bit of history and kudos!? > > > > I think there's an Internet connection in your experience.? I'm > not sure > > what, legally, "wireless email" means.? But I suspect that email was > > being sent and received, wirelessly, well before even 1982, if > only to > > and from the SRI Packet Radio van that could occasionally be > seen then > > roaming around the Bay Area. > > > > Of course, technically, that probably involved a Telnet connection, > > wirelessly, to some PDP-10 running an email program.?? But, > legally, it > > might meet the court accepted definition of "wireless email". ? I > > learned from the lawyers that much of litigation involves > arguing about > > the meaning of words and phrases. > > > > So, perhaps someone could have looked for mouldering Packet > Radio (aka > > PR) hardware and software, and demonstrated wireless email circa > 1978 > > over one or more PRNETs. > > > > Sadly, although I was pretty sure that interesting "prior art" > would be > > found in the PR environment, we had little success 7 years ago while > > trying to find anything that might show exactly how PR equipment > > "downloaded instructions".?? > > > > There's remarkably little readily discoverable material about > lots of > > the computer and network systems of the 70s/80s, especially internal > > details of operation, tools, procedures, etc.?? Plenty of stuff on > > Routing, but little on other mechanisms, or other types of > networks of > > that era, at least that the lawyers and I could find.?? IMHO, > that's a > > huge gap even in Internet History, since the Internet did not > evolve in > > a vacuum, was itself composed of more than the ARPANET, and was > > surrounded by competitors (remember multiprotocol routers). > > > > /Jack > > > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > >> Jack, you're a Most Eloquent purveyor of history and that WHY > explain > >> is exactly what yours truly was hoping for... Thank You for the > >> elucidation! :D > >> > >> along the lines vis-a-vis: > >> > >> ? ? So, that's a bit about the "Why", for history to ponder.? The > >> ? ? experience got me wondering about the "patent history" of The > >> ? ? Internet.? Clearly there was a lot of innovation in those > days.? > >> ? ? My recollection is that very little was patented, even if > only to > >> ? ? make sure no one else could.? Maybe someone will document the > >> ? ? patent-related aspects of Internet History someday. > >> > >> please excuse/pardon this immodesty: yours truly had a kinda > similar > >> "lawyered" experience with respect to WHO was the purported > >> "inventor"/originator of wireless email in a patent litigation case > >> and the "challenge" of finding/presenting any extant legally > >> submissive "artifactual?proof" to that effect -- for which John > >> Markoff at the New York Times wrote about in this 2006 article: > >> > >> In Silicon Valley, a Man Without a Patent > >> > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > >> > >> for which some links of "proof" exist -- for some stuff > mentioned in > >> the above NYT article -- on my website?https://iconia.com/?under > >> "wireless email" (in case any historians are duly interested)...? > >> > >> geoff > >> > >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > >> >> wrote: > >> > >> ? ? Geoff, > >> > >> ? ? Dave's IEEE paper does an excellent job of the > >> ? ? Who/What/When/Where.? He's right that it was about 7 years > ago.?? > >> ? ? Time flies... but I guess it's still "recent" when viewed > as part > >> ? ? of Internet History. > >> > >> ? ? For the curious, I can add a bit more about the Why. > >> > >> ? ? Sometime in 2013, I got an email out of the blue from Charlie > >> ? ? Neuhauser, someone I didn't recognize or remember at all, > asking > >> ? ? if I was the "Jack Haverty" who authored IEN 158 - > documenting the > >> ? ? XNET protocol in 1980.?? Figuring that the statute of > limitations > >> ? ? must have expired after 30+ years, I cautiously said yes.? Over > >> ? ? the next few days, he hooked me up with the lawyers who were > >> ? ? involved in a patent dispute - one that had been going on for > >> ? ? several decades by then.? In fact, the patent involved had been > >> ? ? issued, ran its 17 year lifetime, and expired, but there > was still > >> ? ? litigation in process about whether or not the patent was > valid, > >> ? ? and 17 years of violations were alleged cause for > compensation in > >> ? ? the many millions. ? For the next few years I was involved > in the > >> ? ? battles, working with the lawyers scattered all over the > country.? > >> ? ? I never met any of them.? All our work was done by email and > >> ? ? telephone.?? No Zoom then or we probably would have used it. > >> > >> ? ? The core issue in the patent battle concerned "downloading > >> ? ? instructions", mechanisms such as would be involved in > patching or > >> ? ? issuing new software releases to remote equipment.?? XNET > seemed > >> ? ? to them to possibly have something to do with that, hence the > >> ? ? interest.? The goal was to find hard evidence that such > procedures > >> ? ? were being done by 1980, which would prove that prior art > >> ? ? existed.? Hard evidence literally means "hard" - opinions help, > >> ? ? but physical equipment and running code is much more > impressive in > >> ? ? a courtroom. > >> > >> ? ? They hadn't found any XNET artifacts, and I couldn't point > them to > >> ? ? any surviving implementations.?? But I pointed out that my XNET > >> ? ? document simply captured the technology that we "stole" > from the > >> ? ? ARPANET IMP experience, and that the IMPs routinely "downloaded > >> ? ? code" from their neighbors and the NOC all during the life > of the > >> ? ? ARPANET. > >> > >> ? ? Since the IMPs had existed since the early 70s, that really > >> ? ? sparked their interest, and a search (worldwide) ensued to find > >> ? ? old IMPs, in the hope that just maybe one of them still had the > >> ? ? IMP software in its magnetic-core memory.? A few IMPs were > >> ? ? located, but none were functional.? The one in the museum > at UCLA > >> ? ? seemed promising, but the owners were reluctant to even > hook it up > >> ? ? to power after sitting idle for so many years, expecting it > might > >> ? ? go up in smoke. > >> > >> ? ? Then I learned from the BBN alumni mailing list that an ancient > >> ? ? IMP listing had been found in a basement.?? The story from that > >> ? ? point is pretty well described in Dave's paper. > >> > >> ? ? Personally, it was an interesting experience.? I worked > >> ? ? extensively with one lawyer in San Diego.? I taught him how > >> ? ? computers and networks actually work; he taught me a lot > about the > >> ? ? legal system regarding patents.?? IMHO, they are equally > >> ? ? convoluted and complex when viewed from the other's > perspective. > >> > >> ? ? I also learned a lot about the IMP code, which I had never even > >> ? ? looked at while I was at BBN.? One task I took on was to > >> ? ? exhaustively analyze the parts of the IMP code that implemented > >> ? ? the "download new instructions" functionality, writing up an > >> ? ? instruction-by-instruction description of how the code > >> ? ? accomplished that by interacting with a neighboring IMP.?? > It was > >> ? ? a very clever design, and extremely tight code, even including > >> ? ? self-modifying instructions.?? Not easy to figure out (or > explain > >> ? ? in language amenable to a non-technical judge or jury).? So > there > >> ? ? was great interest in being able to demonstrate the code in > action > >> ? ? using real software from the 70s and hardware simulators.?? > >> ? ? Tangible evidence is much better than even expert opinions. > >> > >> ? ? The whole legal project came to a sudden end just a few months > >> ? ? prior to the first court date.??? I was looking forward to > going > >> ? ? to Delaware (legal action was filed in Federal court in > Delaware), > >> ? ? and finally meeting some of the people.?? But the parties > settled > >> ? ? suddenly, the case was dropped, and AFAIK the patent > question was > >> ? ? never resolved.?? > >> > >> ? ? So, that's a bit about the "Why", for history to ponder.??? The > >> ? ? experience got me wondering about the "patent history" of The > >> ? ? Internet.?? Clearly there was a lot of innovation in those > days.?? > >> ? ? My recollection is that very little was patented, even if > only to > >> ? ? make sure no one else could.?? Maybe someone will document the > >> ? ? patent-related aspects of Internet History someday. > >> > >> ? ? /Jack Haverty > >> > >> > >> > >> ? ? On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > >>> ? ? jack, you've raised my curiosity with respect to: > >>> > >>> ? ? ? ? ... There > >>> ? ? ? ? *is* ARPANET IMP software which was recently restored > and a small > >>> ? ? ? ? ARPANET was run using simulated IMP hardware. > >>> > >>> ? ? Who/What/When/Where/Why? > >>> > >>> ? ? geoff > >>> > >>> ? ? On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via > Internet-history > >>> ? ? > >>> ? ? >> wrote: > >>> > >>> ? ? ? ? Lukasz, > >>> > >>> ? ? ? ? I think that the earliest implementations of TTL called it > >>> ? ? ? ? "Time", but > >>> ? ? ? ? I'm not aware that anyone actually used time per se in > >>> ? ? ? ? gateways, at > >>> ? ? ? ? least in the early days (1977-1982 or so).? > >>> > >>> ? ? ? ? TCP implementations didn't do anything with TTL other than > >>> ? ? ? ? set it on > >>> ? ? ? ? outgoing datagrams, and at least in my implementation (TCP > >>> ? ? ? ? for Unix), it > >>> ? ? ? ? was just set to some arbitrary value.? Until we had > some data > >>> ? ? ? ? from > >>> ? ? ? ? experimentation it was hard to evaluate ideas about what > >>> ? ? ? ? routers, hosts, > >>> ? ? ? ? et al should actually do.?? The early TCPs did use time in > >>> ? ? ? ? handling > >>> ? ? ? ? retransmission timers, and there was work a bit later to > >>> ? ? ? ? incorporate > >>> ? ? ? ? time more powerfully into TCP behavior, e.g., Van > Jacobson's > >>> ? ? ? ? work. > >>> > >>> ? ? ? ? The early gateways, IIRC, used the terminology "time", > but in > >>> ? ? ? ? practice > >>> ? ? ? ? used just hop counts, since time measurements were > difficult to > >>> ? ? ? ? implement.?? The exception to that may be Dave Mills' > >>> ? ? ? ? Fuzzballs, since > >>> ? ? ? ? Dave was the implementor most interested in time and > making > >>> ? ? ? ? precise > >>> ? ? ? ? measurements of network behavior.?? I *think* Dave may > have > >>> ? ? ? ? used time > >>> ? ? ? ? values and delay-based routing amongst his "fuzzies". > >>> > >>> ? ? ? ? The BBN doc you're seeking might have been one of many > that > >>> ? ? ? ? discussed > >>> ? ? ? ? the ARPANET internal mechanisms, e.g., ones with > titles like > >>> ? ? ? ? "Routing > >>> ? ? ? ? Algorithm Improvements".? The ARPANET internal > mechanisms did > >>> ? ? ? ? use time.? > >>> ? ? ? ? It was fairly simple in the IMPs, since the delay > introduced > >>> ? ? ? ? by the > >>> ? ? ? ? synchronous communications lines could be easily > predicted, > >>> ? ? ? ? and the > >>> ? ? ? ? other major component of delay was the time spent in > queues, > >>> ? ? ? ? which could > >>> ? ? ? ? be measured fairly easily.?? > >>> > >>> ? ? ? ? I even found one BBN ARPANET Project QTR from circa > 1975 that > >>> ? ? ? ? discussed > >>> ? ? ? ? the merits of the new-fangled TCP proposal that some > >>> ? ? ? ? professor had > >>> ? ? ? ? published -- and seemed to conclude it couldn't > possibly work. > >>> > >>> ? ? ? ? My involvement in implementations of TCPs and gateways > lasted > >>> ? ? ? ? through > >>> ? ? ? ? about mid-1983, so I don't know much of the detail of > subsequent > >>> ? ? ? ? implementations.? For the various BBN gateway/router > >>> ? ? ? ? equipment, Bob > >>> ? ? ? ? Hinden would probably be a good source.? The other major > >>> ? ? ? ? early player > >>> ? ? ? ? was MIT and spinoffs (Proteon), which perhaps Noel > Chiappa will > >>> ? ? ? ? remember.?? There's also at least one paper on the > Fuzzballs > >>> ? ? ? ? which may > >>> ? ? ? ? have some details. > >>> > >>> ? ? ? ? One thing I'd advise being careful of is the various > >>> ? ? ? ? "specifications" in > >>> ? ? ? ? RFCs.? Much of the wording in those was intentionally > >>> ? ? ? ? non-prescriptive > >>> ? ? ? ? (use of "should" or "may" instead of "must"), to > provide as much > >>> ? ? ? ? latitude as possible for experimentation with new ideas, > >>> ? ? ? ? especially > >>> ? ? ? ? within an AS.?? The Internet was an Experiment. > >>> > >>> ? ? ? ? Also, there was no consistent enforcement mechanism to > assure > >>> ? ? ? ? that > >>> ? ? ? ? implementations actually even conformed to the "must" > >>> ? ? ? ? elements.?? So > >>> ? ? ? ? Reality could be very different from Specification. > >>> > >>> ? ? ? ? I don't know of any gateway implementations that have > >>> ? ? ? ? survived.?? There > >>> ? ? ? ? *is* ARPANET IMP software which was recently restored > and a small > >>> ? ? ? ? ARPANET was run using simulated IMP hardware.?? I > still have > >>> ? ? ? ? a ~1979 > >>> ? ? ? ? listing of the TCP I wrote for Unix, but haven't > scanned it > >>> ? ? ? ? into digital > >>> ? ? ? ? form yet. > >>> > >>> ? ? ? ? Jack > >>> > >>> ? ? ? ? On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > >>> ? ? ? ? > Jack, > >>> ? ? ? ? > > >>> ? ? ? ? > I was reading a lot of old BBN PDFs thanks to all > good souls on > >>> ? ? ? ? > this list that post nice URLs from time to time. > >>> ? ? ? ? > > >>> ? ? ? ? > I remember reading in at least one of them, that > apparently > >>> ? ? ? ? first > >>> ? ? ? ? > TCP/IP implementations were indeed using TTL as > literally > >>> ? ? ? ? ?time?, > >>> ? ? ? ? > not hop count. I believe there somewhere there > between PDP docs > >>> ? ? ? ? > and ARPANET docs I?ve read something to the effect ?and > >>> ? ? ? ? from this > >>> ? ? ? ? > time we changed from measuring time to simply count > routing > >>> ? ? ? ? hops?. > >>> ? ? ? ? > Of course, right now google-fu is failing me. > >>> ? ? ? ? > > >>> ? ? ? ? > Quoting RFC 1009 that was already brought up, > there?s quite > >>> ? ? ? ? > direct ?definition? of the field: > >>> ? ? ? ? > > >>> ? ? ? ? > "4.8.? Time-To-Live > >>> ? ? ? ? > > >>> ? ? ? ? >? The Time-to-Live (TTL) field of the IP header is > defined > >>> ? ? ? ? to be a > >>> ? ? ? ? >? timer limiting the lifetime of a datagram in the > >>> ? ? ? ? Internet.? It is > >>> ? ? ? ? >? an 8-bit field and the units are seconds.? This would > >>> ? ? ? ? imply that > >>> ? ? ? ? >? for a maximum TTL of 255 a datagram would time-out > after > >>> ? ? ? ? about 4 > >>> ? ? ? ? >? and a quarter minutes.? Another aspect of the > definition > >>> ? ? ? ? requires > >>> ? ? ? ? >? each gateway (or other module) that handles a > datagram to > >>> ? ? ? ? >? decrement the TTL by at least one, even if the elapsed > >>> ? ? ? ? time was > >>> ? ? ? ? >? much less than a second.? Since this is very often the > >>> ? ? ? ? case, the > >>> ? ? ? ? >? TTL effectively becomes a hop count limit on how far a > >>> ? ? ? ? datagram > >>> ? ? ? ? >? can propagate through the Internet." > >>> ? ? ? ? > > >>> ? ? ? ? > Were there any implementations that survived > somewhere and > >>> ? ? ? ? actually > >>> ? ? ? ? > did exactly that - counted actual time/processing delay, > >>> ? ? ? ? not hops? > >>> ? ? ? ? > And if it took 2s to process packet, did they really > >>> ? ? ? ? decrement TTL > >>> ? ? ? ? > by two? > >>> ? ? ? ? > > >>> ? ? ? ? > Thanks for any pointers, > >>> > >>> ? ? ? ? -- > >>> ? ? ? ? Internet-history mailing list > >>> ? ? ? ? Internet-history at elists.isoc.org > > >>> ? ? ? ? > > >>> ? ? ? ? https://elists.isoc.org/mailman/listinfo/internet-history > >>> > >>> > >>> > >>> ? ? -- > >>> ? ? Geoff.Goodfellow at iconia.com > > > > >>> ? ? living as The Truth is True > >>> > >>> > >>> > >> > >> > >> -- > >> Geoff.Goodfellow at iconia.com > > > > >> living as The Truth is True > >> > >> > >> > > -- > 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 bill.n1vux at gmail.com Wed Sep 9 15:21:24 2020 From: bill.n1vux at gmail.com (Bill Ricker) Date: Wed, 9 Sep 2020 18:21:24 -0400 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: <01374e4b-5660-a87c-e7de-51ad86ce403d@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> <1141252064.1197160.1599533643198@mail.yahoo.com> <01374e4b-5660-a87c-e7de-51ad86ce403d@3kitty.org> Message-ID: > On 9/8/20 2:49 AM, vinton cerf wrote: > > i also wonder whether dense crowds of wifi users creates a big > > desensing risk? > With both WiFi and Cellular technology, the transmitters are low power because they are designed for a dense network of near-by receivers - even in comparison to early cell phones (which could run 3W into the antenna at full power, which is a bit much for microwaves that close to the eyeballs, which is why i had an antenna on the roof of the truck). On Wed, Sep 9, 2020 at 5:41 PM Jack Haverty wrote: > Radio technology has gotten a lot better over the last 40 years; my > experience is that desensing isn't as much of an issue now. Absolutely. Technologies like direct-sequence spread spectrum (DSSS) allows (a) reliable synchronous reception of low power signals (b) sharing frequencies between users. This both allows the lower power that minimizes desense distance, and with synchronous decode, a weak or weakened signal is still decodable. Also, signal strength decreases rapidly with distance, Well Actually? The *power* (delivered per unit area) decreases rapidly with distance (R^-2) but detectable signal is *voltage* (per unit distance) which only decreases linearly with distance (R^-1), so one has to multiply distance x 100 to reduce received signal 1/100. (Optimizing Power vs Voltage is why TV receive antennae are 75 ohm, TV/Radio station transmitter anntennae are 33 ohms, and two-way radios' antennae, Ethernet coax (thick and thin), and test equipment are 50 ohms.) so socially-distanced > cellphone users shouldn't have a problem, except perhaps if they try to > use a phone on each ear. /j > A truly large crowd *will* saturate the network for cellular phone voice calling, but AFAIK it's the network capacity of the cell nodes, not desense in the handsets' receivers. (If the cell phone network is working *properly*, if there ever is desense at the handset, that should cause the partnered *node* to increase power, and NOT the handset, which only increases power if the *node* is receiving poorly, and will back down the power for user safety if it's plenty "loud" at the node. This is side-channel signal-strength feedback.) (Even on 2001-09-11, outside of lower Manhattan, when the cell voice network rapidly saturated as everyone called everyone else NxN repeatedly, the SMS/Text facilities were initially fine, took hours to saturate. I did get home before my message saying i was finally getting on the train, though.) Desense does still happen though in this marvellous 21st Century ... I have observed desense in **cheap** BlueTooth Speaker (which is DSSS or related). I can carry it while listening to podcast-player on the desktop into the kitchen, but acceptable safe levels of microwave leakage from the oven (i checked with an antique RadioShack? analog kitchen microwave safety tester!) will desense the BT speaker unless i shield it with a metal muffin pan. 73 de Bill n1vux From geoff at iconia.com Wed Sep 9 15:45:59 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Wed, 9 Sep 2020 12:45:59 -1000 Subject: [ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol]) In-Reply-To: <01374e4b-5660-a87c-e7de-51ad86ce403d@3kitty.org> References: <648ffab2-6b18-b939-c1fd-c9bd931e86f2@tnetconsulting.net> <4079ec9f-c73d-9719-5f9f-ca59d798d429@3kitty.org> <07f5a92e-1c38-ae65-a55b-cf3ca094a855@3kitty.org> <1779558001.912243.1599461078378@mail.yahoo.com> <1141252064.1197160.1599533643198@mail.yahoo.com> <01374e4b-5660-a87c-e7de-51ad86ce403d@3kitty.org> Message-ID: yours truly observed/experienced/had this exact "desensing issue" with/when 2 of the 100 "test" (pre-commercial and by hand constructed/"manufactured") DYNATAC handheld cellphone's on the ARTS (American Radio Telephone System) test system in the 80's that Motorola had constructed in the Washington D.C. & Baltimore MD area were used simultaneously in close proximity with one another... geoff On Wed, Sep 9, 2020 at 11:41 AM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > Radio technology has gotten a lot better over the last 40 years; my > experience is that desensing isn't as much of an issue now. Also, > signal strength decreases rapidly with distance, so socially-distanced > cellphone users shouldn't have a problem, except perhaps if they try to > use a phone on each ear. /j > > On 9/8/20 2:49 AM, vinton cerf wrote: > > i wonder whether CHM has cataloged what it has been given in > > searchable form? > > > > i also wonder whether dense crowds of wifi users creates a big > > desensing risk? > > > > v > > > > > > On Mon, Sep 7, 2020 at 10:55 PM Barbara Denny via Internet-history > > > > wrote: > > > > Hi Jack, > > This might not have been clear. I worked for BBN on the packet > > radio project before SRI. As you mentioned the packet radio work > > was in Div4 at BBN. I decided to move to California and took a job > > at SRI. > > Besides ARPA, SRI had contracts with other military organizations > > for the networking research . The Army (CECOM) funded a lot of the > > work. I think a couple projects I worked on had funding from the > > Navy and the Air Force (Rome Labs? ) but I could be wrong where > > the dollars actually came from. > > > > Unfortunately I don't remember any contract numbers right now. > > Much of the information on what was done is in the monthly, > > quarterly and final reports delivered to the contracting > > organization. I think there were only a handful of conference > > papers and a few talks here and there. > > I have tried to use the DTIC site to find information on the SAC > > Strategic C3 Experiments (Mobile IP work) and I did find it hard > > to locate what I was looking for. I have no idea how SRI handled > > the deliverables once a project was over. I did find documentation > > on the Port Expander awhile ago but it wasn't very detailed. If > > you would like a copy, I will see if I can find it again. I think > > it helps to know the project name when searching for information. > > barbara > > > > On Monday, September 7, 2020, 11:00:48 AM PDT, Jack Haverty > > via Internet-history > > wrote: > > > > Hi Barbara, > > > > Packet Radio artifacts of any kind were elusive (at least in 2013 > when > > we searched), except for a few conference papers. Specifically, > > we were > > looking for things like QTRs or other project reports that SRI > > presumably submitted to ARPA, analogous to the BBN QTRs. We found a > > lot of the BBN reports online at DTIC, but little from SRI. I'm not > > sure, but the BBN QTRs may have been found by the search engine > > because > > I had the BBN/ARPA contract numbers involved, but I didn't know the > > appropriate contract numbers for the SRI (or any other) contracts. > > > > Not much detail about Fuzzballs, or Port Expanders, or other such > > boxes > > that were prolific in the early days of the Internet. Google wasn't > > much help, but that may be from lack of knowledge in how to best > > use the > > search mechanisms. > > > > IMHO, there wasn't as much collaboration between the ARPANET and > > Packet > > Radio as there was with the Internet/Gateway work at BBN. > > > > BBN had internal structure that to some extent influenced the > > "technology transfer" between projects. In particular there were two > > "divisions", Div4 and Div6, that both did similar computer and > network > > research. Div6 was where the ARPANET project began and evolved to an > > operational service over the ten years preceding the Internet, so > > there > > was a lot of operational experience and war wounds there. Div4 was > > where the Packet Radio work was done, along with lots of other > things, > > such as TENEX. Both were very competent, but had different > > experiences. > > > > Although the technical staffs of the two divisions got along pretty > > well, pragmatic details limited collaboration. We were physically > > located in separate buildings, so hallway encounters and casual > > interactions were less likely. Interesting "teaching events" that > > occurred in the ARPANET propagated quickly through Div6 where the NOC > > was literally just down the hallway, less so to Div4. > Cross-charging > > (charging your time to the other Division's project) was possible but > > discouraged. > > > > The "Gateway Project" began in Div4, where Ginny Strazisar > implemented > > the first gateway; I don't know if that was a separate > > project/contract, or just a part of the Packet Radio contract at the > > time. Some few years later, as it became desirable for the > > Internet to > > stabilize and become an operational service, ARPA moved the > > gateway work > > from Div4 to Div6, folding it into the "Internet Project" contract > > that > > was my responsibility at the time (it included various TCP > > implementations, SATNET, WBNET, Remote Site Maintenance, etc.). > > > > That was the point where we started injecting "ARPANET DNA" into the > > Internet/gateways, blatantly adopting ARPANET techniques as the most > > obvious (to us in Div6) way to get the Internet to be as managed > > as the > > ARPANET. > > > > I know little about the internal mechanisms of the Packet Radio > > environment. But it did not move to Div6 (which became BBN > > Communications Corp at some point) at least during my involvement > > (roughly 1978-1990). > > > > So I suspect that the Packet Radio system did not reuse much of > > the IMP > > ideas/techniques, especially the ones that were rather mundane and > not > > well documented or publicized (such as the "reload from neighbor" > > idea). The Packet Radio QTRs, if they survive, would probably answer > > that question. > > > > I've often wondered, from a historical perspective now, to what > extent > > things like internal corporate structure and organizational decisions > > influenced the design and implementation of the Internet. > > > > /Jack > > > > > > On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote: > > > Because of BBN's involvement, I am thinking Packet Radio might > > have reused many of the same ideas as the IMPs for loading new > > software from another node. Do you know this was not the case? I > > never needed to look at that part of the code. > > > I remember using XNET for examination of the Packet Radio > > station. Given your recent email it sounds like you looked for old > > Packet Radio station software and couldn't find it. Is this correct? > > > I don't think Rockwell released their Packet Radio software in > > the late 70s/early 80s. I would have to contact Rockwell if I > > thought bugs required a change to a packet radio, versus the > > Packet Radio station, when I worked at BBN. I know several years > > later SRI did get some of their code because I implemented one of > > the new routing algorithms ( I am pretty sure it was called > > threshold distance vector routing if anyone is interested). BTW, I > > think the software may have only been tested in a simulator due to > > delays in the delivery of the LPR (Low Cost Packet Radio). This > > was during the SURAN program. > > > The first demo of Packet Radio and ARPANET in 1976 involved > > submitting the status report. Don Nielson would probably remember > > if that was done through anything like email. Below is a link to > > an article that discusses this event. The text from the article > > mentions email but more importantly it has a link to a podcast > > with Don. I didn't know this podcast existed so I still need to > > listen to it. I can see why you might think the report submission > > may have been done by using a telnet connection to a SRI host that > > had email. > > > > > > https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/ > > > barbara > > > On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty > > via Internet-history > > wrote: > > > > > > Hi Geoff - thanks for that bit of history and kudos! > > > > > > I think there's an Internet connection in your experience. I'm > > not sure > > > what, legally, "wireless email" means. But I suspect that email > was > > > being sent and received, wirelessly, well before even 1982, if > > only to > > > and from the SRI Packet Radio van that could occasionally be > > seen then > > > roaming around the Bay Area. > > > > > > Of course, technically, that probably involved a Telnet connection, > > > wirelessly, to some PDP-10 running an email program. But, > > legally, it > > > might meet the court accepted definition of "wireless email". I > > > learned from the lawyers that much of litigation involves > > arguing about > > > the meaning of words and phrases. > > > > > > So, perhaps someone could have looked for mouldering Packet > > Radio (aka > > > PR) hardware and software, and demonstrated wireless email circa > > 1978 > > > over one or more PRNETs. > > > > > > Sadly, although I was pretty sure that interesting "prior art" > > would be > > > found in the PR environment, we had little success 7 years ago > while > > > trying to find anything that might show exactly how PR equipment > > > "downloaded instructions". > > > > > > There's remarkably little readily discoverable material about > > lots of > > > the computer and network systems of the 70s/80s, especially > internal > > > details of operation, tools, procedures, etc. Plenty of stuff on > > > Routing, but little on other mechanisms, or other types of > > networks of > > > that era, at least that the lawyers and I could find. IMHO, > > that's a > > > huge gap even in Internet History, since the Internet did not > > evolve in > > > a vacuum, was itself composed of more than the ARPANET, and was > > > surrounded by competitors (remember multiprotocol routers). > > > > > > /Jack > > > > > > On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote: > > >> Jack, you're a Most Eloquent purveyor of history and that WHY > > explain > > >> is exactly what yours truly was hoping for... Thank You for the > > >> elucidation! :D > > >> > > >> along the lines vis-a-vis: > > >> > > >> So, that's a bit about the "Why", for history to ponder. The > > >> experience got me wondering about the "patent history" of The > > >> Internet. Clearly there was a lot of innovation in those > > days. > > >> My recollection is that very little was patented, even if > > only to > > >> make sure no one else could. Maybe someone will document the > > >> patent-related aspects of Internet History someday. > > >> > > >> please excuse/pardon this immodesty: yours truly had a kinda > > similar > > >> "lawyered" experience with respect to WHO was the purported > > >> "inventor"/originator of wireless email in a patent litigation > case > > >> and the "challenge" of finding/presenting any extant legally > > >> submissive "artifactual proof" to that effect -- for which John > > >> Markoff at the New York Times wrote about in this 2006 article: > > >> > > >> In Silicon Valley, a Man Without a Patent > > >> > > > https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html > > >> > > >> for which some links of "proof" exist -- for some stuff > > mentioned in > > >> the above NYT article -- on my website https://iconia.com/ under > > >> "wireless email" (in case any historians are duly interested)... > > >> > > >> geoff > > >> > > >> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty > > > >> >> wrote: > > >> > > >> Geoff, > > >> > > >> Dave's IEEE paper does an excellent job of the > > >> Who/What/When/Where. He's right that it was about 7 years > > ago. > > >> Time flies... but I guess it's still "recent" when viewed > > as part > > >> of Internet History. > > >> > > >> For the curious, I can add a bit more about the Why. > > >> > > >> Sometime in 2013, I got an email out of the blue from Charlie > > >> Neuhauser, someone I didn't recognize or remember at all, > > asking > > >> if I was the "Jack Haverty" who authored IEN 158 - > > documenting the > > >> XNET protocol in 1980. Figuring that the statute of > > limitations > > >> must have expired after 30+ years, I cautiously said yes. > Over > > >> the next few days, he hooked me up with the lawyers who were > > >> involved in a patent dispute - one that had been going on for > > >> several decades by then. In fact, the patent involved had > been > > >> issued, ran its 17 year lifetime, and expired, but there > > was still > > >> litigation in process about whether or not the patent was > > valid, > > >> and 17 years of violations were alleged cause for > > compensation in > > >> the many millions. For the next few years I was involved > > in the > > >> battles, working with the lawyers scattered all over the > > country. > > >> I never met any of them. All our work was done by email and > > >> telephone. No Zoom then or we probably would have used it. > > >> > > >> The core issue in the patent battle concerned "downloading > > >> instructions", mechanisms such as would be involved in > > patching or > > >> issuing new software releases to remote equipment. XNET > > seemed > > >> to them to possibly have something to do with that, hence the > > >> interest. The goal was to find hard evidence that such > > procedures > > >> were being done by 1980, which would prove that prior art > > >> existed. Hard evidence literally means "hard" - opinions > help, > > >> but physical equipment and running code is much more > > impressive in > > >> a courtroom. > > >> > > >> They hadn't found any XNET artifacts, and I couldn't point > > them to > > >> any surviving implementations. But I pointed out that my > XNET > > >> document simply captured the technology that we "stole" > > from the > > >> ARPANET IMP experience, and that the IMPs routinely > "downloaded > > >> code" from their neighbors and the NOC all during the life > > of the > > >> ARPANET. > > >> > > >> Since the IMPs had existed since the early 70s, that really > > >> sparked their interest, and a search (worldwide) ensued to > find > > >> old IMPs, in the hope that just maybe one of them still had > the > > >> IMP software in its magnetic-core memory. A few IMPs were > > >> located, but none were functional. The one in the museum > > at UCLA > > >> seemed promising, but the owners were reluctant to even > > hook it up > > >> to power after sitting idle for so many years, expecting it > > might > > >> go up in smoke. > > >> > > >> Then I learned from the BBN alumni mailing list that an > ancient > > >> IMP listing had been found in a basement. The story from > that > > >> point is pretty well described in Dave's paper. > > >> > > >> Personally, it was an interesting experience. I worked > > >> extensively with one lawyer in San Diego. I taught him how > > >> computers and networks actually work; he taught me a lot > > about the > > >> legal system regarding patents. IMHO, they are equally > > >> convoluted and complex when viewed from the other's > > perspective. > > >> > > >> I also learned a lot about the IMP code, which I had never > even > > >> looked at while I was at BBN. One task I took on was to > > >> exhaustively analyze the parts of the IMP code that > implemented > > >> the "download new instructions" functionality, writing up an > > >> instruction-by-instruction description of how the code > > >> accomplished that by interacting with a neighboring IMP. > > It was > > >> a very clever design, and extremely tight code, even including > > >> self-modifying instructions. Not easy to figure out (or > > explain > > >> in language amenable to a non-technical judge or jury). So > > there > > >> was great interest in being able to demonstrate the code in > > action > > >> using real software from the 70s and hardware simulators. > > >> Tangible evidence is much better than even expert opinions. > > >> > > >> The whole legal project came to a sudden end just a few months > > >> prior to the first court date. I was looking forward to > > going > > >> to Delaware (legal action was filed in Federal court in > > Delaware), > > >> and finally meeting some of the people. But the parties > > settled > > >> suddenly, the case was dropped, and AFAIK the patent > > question was > > >> never resolved. > > >> > > >> So, that's a bit about the "Why", for history to ponder. > The > > >> experience got me wondering about the "patent history" of The > > >> Internet. Clearly there was a lot of innovation in those > > days. > > >> My recollection is that very little was patented, even if > > only to > > >> make sure no one else could. Maybe someone will document the > > >> patent-related aspects of Internet History someday. > > >> > > >> /Jack Haverty > > >> > > >> > > >> > > >> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote: > > >>> jack, you've raised my curiosity with respect to: > > >>> > > >>> ... There > > >>> *is* ARPANET IMP software which was recently restored > > and a small > > >>> ARPANET was run using simulated IMP hardware. > > >>> > > >>> Who/What/When/Where/Why? > > >>> > > >>> geoff > > >>> > > >>> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via > > Internet-history > > >>> > > > >>> > >> wrote: > > >>> > > >>> Lukasz, > > >>> > > >>> I think that the earliest implementations of TTL called > it > > >>> "Time", but > > >>> I'm not aware that anyone actually used time per se in > > >>> gateways, at > > >>> least in the early days (1977-1982 or so). > > >>> > > >>> TCP implementations didn't do anything with TTL other > than > > >>> set it on > > >>> outgoing datagrams, and at least in my implementation > (TCP > > >>> for Unix), it > > >>> was just set to some arbitrary value. Until we had > > some data > > >>> from > > >>> experimentation it was hard to evaluate ideas about what > > >>> routers, hosts, > > >>> et al should actually do. The early TCPs did use time > in > > >>> handling > > >>> retransmission timers, and there was work a bit later to > > >>> incorporate > > >>> time more powerfully into TCP behavior, e.g., Van > > Jacobson's > > >>> work. > > >>> > > >>> The early gateways, IIRC, used the terminology "time", > > but in > > >>> practice > > >>> used just hop counts, since time measurements were > > difficult to > > >>> implement. The exception to that may be Dave Mills' > > >>> Fuzzballs, since > > >>> Dave was the implementor most interested in time and > > making > > >>> precise > > >>> measurements of network behavior. I *think* Dave may > > have > > >>> used time > > >>> values and delay-based routing amongst his "fuzzies". > > >>> > > >>> The BBN doc you're seeking might have been one of many > > that > > >>> discussed > > >>> the ARPANET internal mechanisms, e.g., ones with > > titles like > > >>> "Routing > > >>> Algorithm Improvements". The ARPANET internal > > mechanisms did > > >>> use time. > > >>> It was fairly simple in the IMPs, since the delay > > introduced > > >>> by the > > >>> synchronous communications lines could be easily > > predicted, > > >>> and the > > >>> other major component of delay was the time spent in > > queues, > > >>> which could > > >>> be measured fairly easily. > > >>> > > >>> I even found one BBN ARPANET Project QTR from circa > > 1975 that > > >>> discussed > > >>> the merits of the new-fangled TCP proposal that some > > >>> professor had > > >>> published -- and seemed to conclude it couldn't > > possibly work. > > >>> > > >>> My involvement in implementations of TCPs and gateways > > lasted > > >>> through > > >>> about mid-1983, so I don't know much of the detail of > > subsequent > > >>> implementations. For the various BBN gateway/router > > >>> equipment, Bob > > >>> Hinden would probably be a good source. The other major > > >>> early player > > >>> was MIT and spinoffs (Proteon), which perhaps Noel > > Chiappa will > > >>> remember. There's also at least one paper on the > > Fuzzballs > > >>> which may > > >>> have some details. > > >>> > > >>> One thing I'd advise being careful of is the various > > >>> "specifications" in > > >>> RFCs. Much of the wording in those was intentionally > > >>> non-prescriptive > > >>> (use of "should" or "may" instead of "must"), to > > provide as much > > >>> latitude as possible for experimentation with new ideas, > > >>> especially > > >>> within an AS. The Internet was an Experiment. > > >>> > > >>> Also, there was no consistent enforcement mechanism to > > assure > > >>> that > > >>> implementations actually even conformed to the "must" > > >>> elements. So > > >>> Reality could be very different from Specification. > > >>> > > >>> I don't know of any gateway implementations that have > > >>> survived. There > > >>> *is* ARPANET IMP software which was recently restored > > and a small > > >>> ARPANET was run using simulated IMP hardware. I > > still have > > >>> a ~1979 > > >>> listing of the TCP I wrote for Unix, but haven't > > scanned it > > >>> into digital > > >>> form yet. > > >>> > > >>> Jack > > >>> > > >>> On 9/5/20 7:38 PM, ?ukasz Bromirski wrote: > > >>> > Jack, > > >>> > > > >>> > I was reading a lot of old BBN PDFs thanks to all > > good souls on > > >>> > this list that post nice URLs from time to time. > > >>> > > > >>> > I remember reading in at least one of them, that > > apparently > > >>> first > > >>> > TCP/IP implementations were indeed using TTL as > > literally > > >>> ?time?, > > >>> > not hop count. I believe there somewhere there > > between PDP docs > > >>> > and ARPANET docs I?ve read something to the effect ?and > > >>> from this > > >>> > time we changed from measuring time to simply count > > routing > > >>> hops?. > > >>> > Of course, right now google-fu is failing me. > > >>> > > > >>> > Quoting RFC 1009 that was already brought up, > > there?s quite > > >>> > direct ?definition? of the field: > > >>> > > > >>> > "4.8. Time-To-Live > > >>> > > > >>> > The Time-to-Live (TTL) field of the IP header is > > defined > > >>> to be a > > >>> > timer limiting the lifetime of a datagram in the > > >>> Internet. It is > > >>> > an 8-bit field and the units are seconds. This would > > >>> imply that > > >>> > for a maximum TTL of 255 a datagram would time-out > > after > > >>> about 4 > > >>> > and a quarter minutes. Another aspect of the > > definition > > >>> requires > > >>> > each gateway (or other module) that handles a > > datagram to > > >>> > decrement the TTL by at least one, even if the elapsed > > >>> time was > > >>> > much less than a second. Since this is very often the > > >>> case, the > > >>> > TTL effectively becomes a hop count limit on how far a > > >>> datagram > > >>> > can propagate through the Internet." > > >>> > > > >>> > Were there any implementations that survived > > somewhere and > > >>> actually > > >>> > did exactly that - counted actual time/processing > delay, > > >>> not hops? > > >>> > And if it took 2s to process packet, did they really > > >>> decrement TTL > > >>> > by two? > > >>> > > > >>> > Thanks for any pointers, > > >>> > > >>> -- > > >>> Internet-history mailing list > > >>> Internet-history at elists.isoc.org > > > > >>> > > > > >>> > https://elists.isoc.org/mailman/listinfo/internet-history > > >>> > > >>> > > >>> > > >>> -- > > >>> Geoff.Goodfellow at iconia.com > > > > > > > > >>> living as The Truth is True > > >>> > > >>> > > >>> > > >> > > >> > > >> -- > > >> Geoff.Goodfellow at iconia.com > > > > > > > > >> living as The Truth is True > > >> > > >> > > >> > > > > -- > > 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 > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From jack at 3kitty.org Wed Sep 9 21:22:13 2020 From: jack at 3kitty.org (Jack Haverty) Date: Wed, 9 Sep 2020 21:22:13 -0700 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> Message-ID: <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen or so people) meeting that Dan called, I think to mostly bounce off ideas about a training/conference company.?? Again IIRC this happened somewhat before the first actual conference in Monterey, where Dan subsequently stole the Internet using chocolate-chip cookies as bribes.?? Vint never served such cookies! From my retro-perspective, it was an interesting progression of events.?? The ARPA "Internet Project" had started in the late 70s with a somewhat disjoint set of network-building projects, and had congealed into a network community, with quarterly meetings.? At first, the "TCP Working Group" and the "Internet Working Group" met separately.? Quickly we noticed that the TCP group kept coming up with changes to the IP header, while the IP group saw things that needed to be in the TCP header, and everyone in one group wanted to participate in the other, so "layering" was cast aside and the Internet Project as a single group was born. Over a year or two of such quarterly meetings, the size of the membership kept growing, and people had to plead with Vint for a "ticket" to attend.?? It had become difficult to find a willing host that had a venue big enough to handle the crowd for plenary and breakout sessions.?? I hosted one at BBN, and learned that it is a very bad idea to host a large meeting in a newly renovated building with lots of free rooms and space, but without first testing to make sure the brand-new sparkling bathrooms actually worked. The logistics of the quarterly meetings were becoming a serious problem.?? Then Dan stepped in. Instead of a meeting where ARPA and some benefactor host venue paid the costs and necessarily severely limited attendance, Dan rented (I assume it wasn't free!) a hotel, opened up a "ticket booth" to the masses, charged attendees a fee that didn't raise too many bean-counters' alarms, and added a show floor for vendors too, for an appropriate fee of course.?? He also recruited many of the people who used to just attend the quarterly Internet project meetings to provide the entertainment for all the attendees, and called it training and program presentations. Not a bad solution to the problem, eh??? I recall at first there was just a room with some tables and a handful of vendors showing their wares.? That turned pretty quickly into a trade show floor in Santa Clara, expanding into Moscone, and before long heading to Vegas when Moscone was just too small. All of this had the overriding mandate that there would be a strong technical focus, a live network, and vendors had to connect their stuff to it.? For a few years, I was on the Interop "Program Committee", which met around a big table to decide which papers would be put into the program.? It was common to look at a paper, see who was the author, and if there was even a hint of "marketing" present, it quickly went to the reject pile.?? Sometimes all it took was a look at the authors' titles. I remember a meeting where Dan took a few of us to Moscone, to meet with the powers-that-be about possibly holding Interop there.? They were cordial, but IMHO clearly thought this event-they-never-heard-of didn't belong in Moscone.? A year later, after blowing out Santa Clara, they were much more receptive.? Doing the "MazeWar" throughout the Interop show floor was ... interesting.? I checked in to my hotel room on Sunday at noon, and didn't get back until Tuesday night.?? After a few years in Moscone, it had become too small for Interop, so it was off to Vegas. Fun times.? Interop was, IMHO, critical to getting the Internet out into the real world.? Nobody else showed products actually working, and that matters to the people who approve the POs. But it's a good thing Dan didn't have more of the used-car-salesman genes.? Otherwise we would have all left Interop each year with a new vehicle.? Internet-ready, of course. You were wrong, Dan. IMHO, you could have gotten more than 50%.... /Jack Haverty On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: > Craig, I think you did not copy the list. And while I?m at it, a small edit. I paid the tutors 15% , a full 50% more than the competition. I also charged everybody 50% more than the competition because I felt it was worth it! I even charged the vendors 50% more than the competition. I turned out that I was right. > > Dan > > Cell 650-776-7313 > > Begin forwarded message: > >> From: Craig Partridge >> Date: September 8, 2020 at 1:14:05 PM PDT >> To: Dan Lynch >> Cc: Craig Partridge via Internet-history >> Subject: Re: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) >> >> ? >> Dan was kind enough to mention me, which makes it a little harder to send this note but I'll do it anyway. >> >> I think Dan underplays how radical Interop was. Vendors had to connect their equipment to the show network. There was a team of Internet wizards who helped setup the show network for each show. (I recall stories of laying things out on netting in a warehouse so that it could easily be transferred to the show floor). But it meant products actually worked. >> >> And then there was the education component, which as Dan tells, started things. Dan took the view that he tried to hire the top instructors in the field and compensate them properly. At a time when competitors were paying 10% of the gross or $2K, whichever was less, Dan paid $2K or 10% of the gross, whichever was more. That meant Interop's courses, instead of being taught by a grad student or a professor trying out a new course idea, were taught by folks like Doug Comer and Scott Bradner and Radia Perlman, teaching their areas of expertise. As a result, the educational program was immense -- many thousands of students. And because the instructors were already in town, Dan could recruit us to come do a panel session for the main program as well. The panels were often also huge. (I still remember a session I led that included Dave Clark and a couple of other key folks -- the room was packed -- probably 5,000 people -- and was so jammed that someone stepped on the tablecloth for the projector, dumping all our slides [this was pre-Powerpoint real-time projection] on the floor! So I had to talk w/o slides while the other speakers ran to the back to reinsert their slides!). >> >> Attending Interop was a full week affair -- you got trained and then went to the showfloor and conference sessions, while grabbing a handful of the old Doubletree cookies (twice the size they are today) during the breaks. >> >> The transitions in size were wild. We went from Monterrey, to the Santa Clara TechMart, to the San Jose Convention center to the Moscone Center in SF in rapid succession. >> >> Craig >> >>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history wrote: >>> SoJack, you are asking me to recount how Interop came to be. I shall do that as quickly as I can here. >>> >>> In the early 80s I was at ISI in charge of the computer facility. After a year or so there came to be a term New Computing Environment to describe the advent of personal computers and the death of timesharing! I think Keith Uncapher coined the term, tho maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward a few years and I was back in Silicon Valley looking to start a company like my pals at Stanford had been doing. I looked around and noticed that the Internet was gaining traction but the nascent companies had not quite got it right. So I convinced Barry Leiner who was a program manager there in 85/86 to let me convene a 3 day workshop on TCP/IP protocols to explain them to the hundred or so implementation teams out there. I got the actual protocol designers to come to Monterrey California for 3 days. There was no company name then. I had no idea where this was going then. Needless to say the event was a success. The researchers learned of real life problems the early vendors we?re experiencing and the vendors learned a lot more about the Internet and what worked and what still needed further steps. >>> >>> I now had a business of teaching (through others) the vendors and advanced customers how the Internet works. I needed a name. I took the old name above and called it Advanced Computing Environment. >>> >>> A few years in to this the world really wanted to see working systems and I decided to try a trade show, with one critical addition: the systems had to be connected to an actual working Internet! And while I was on the phone with one of my brilliant tutor people from BBN, Craig Partridge, as were were concluding the call he blurted out ?I?ll see you at Interop ?. I hung up the phone and called my lawyer to register the name immediately! I had been calling it The TCP/IP Interoperability Conference and Exhibition! Ah, simplicity. >>> >>> That was in September of 1988. It had 50 vendors and 5000 attendees. In 1990 it had grown to 200 vendors and 30,000 attendees. Clearly this Internet stuff was catching on, eh? >>> >>> So I sold the company and stayed on for 5 more years as the PR guy and growing it into Europe and Asia. >>> >>> 30 years later it still exists in about 10 locations I. The world. Not quite the same, but still stressing interoperability. >>> >>> Thanks for asking, Jack. >>> >>> >>> >>> Dan >>> >>> Cell 650-776-7313 >>> >>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history wrote: >>>> >>>> ?Thanks Dan! >>>> >>>> There's so much of the history that didn't get recorded in RFCs and >>>> such, and mail list archives from that era are rare. We weren't very >>>> good about documenting things, especially the "why" of how decisions >>>> were made. >>>> >>>> There's plenty of room for more participation! Perhaps you can provide >>>> the story behind this artifact of the early Internet? >>>> >>>> ACE Coaster >>>> >>>> That coaster has been sitting on my desk for close to 40 years. The >>>> lettering is fading, after too many attacks by marauding coffee mugs >>>> over the decades, and a few trips to the floor courtesy of a roaming cat. >>>> >>>> The story of ACE, and Interop which followed, is an important part of >>>> Internet history. There tends to be a focus on protocols and >>>> algorithms, but innovations like Interop were, IMHO, equally important >>>> to the success of the Internet by making it accessible to the masses and >>>> emphasizing the importance of working systems. >>>> >>>> Perhaps more important. Tell us the story. >>>> >>>> /Jack >>>> >>>> >>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >>>>> Forgot to copy the fantastic list! >>>>> >>>>> Dan >>>>> >>>>> Cell 650-776-7313 >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Dan Lynch >>>>>> Date: September 5, 2020 at 11:42:36 AM PDT >>>>>> To: Joseph Touch >>>>>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) >>>>>> >>>>>> ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >>>>>> >>>>>> Dan >>>>>> >>>>>> Cell 650-776-7313 >>>>>> >>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >>>>>>> >>>>>>> ?HI, all, >>>>>>> >>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>>>>>>> >>>>>>>>>> From: Joseph Touch >>>>>>>>> FYI - we moved the archives here. >>>>>>>> I've just noticed that the archives are now only accessible to list members? >>>>>>> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >>>>>>> >>>>>>> Please let me know if you continue to find otherwise. >>>>>>> >>>>>>> Joe (as list admin) >>>>>>> -- >>>>>>> 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 >> >> -- >> ***** >> Craig Partridge's email account for professional society activities and mailing lists. From vgcerf at gmail.com Thu Sep 10 02:55:21 2020 From: vgcerf at gmail.com (vinton cerf) Date: Thu, 10 Sep 2020 05:55:21 -0400 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> Message-ID: On Thu, Sep 10, 2020 at 12:22 AM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen or so > people) meeting that Dan called, I think to mostly bounce off ideas > about a training/conference company. Again IIRC this happened somewhat > before the first actual conference in Monterey, where Dan subsequently > stole the Internet using chocolate-chip cookies as bribes. Vint never > served such cookies! > no, but I did offer champagne for winners of the TCP/IP Hackathons. > > From my retro-perspective, it was an interesting progression of events. > > The ARPA "Internet Project" had started in the late 70s with a somewhat > no, it started in 1973. > disjoint set of network-building projects, and had congealed into a > network community, with quarterly meetings. > > At first, the "TCP Working Group" and the "Internet Working Group" met > separately. Quickly we noticed that the TCP group kept coming up with > changes to the IP header, while the IP group saw things that needed to > be in the TCP header, and everyone in one group wanted to participate in > the other, so "layering" was cast aside and the Internet Project as a > single group was born. > > Over a year or two of such quarterly meetings, the size of the > membership kept growing, and people had to plead with Vint for a > "ticket" to attend. > > It had become difficult to find a willing host that had a venue big > enough to handle the crowd for plenary and breakout sessions. I hosted > one at BBN, and learned that it is a very bad idea to host a large > meeting in a newly renovated building with lots of free rooms and space, > but without first testing to make sure the brand-new sparkling bathrooms > actually worked. > > The logistics of the quarterly meetings were becoming a serious > problem. Then Dan stepped in. > > Instead of a meeting where ARPA and some benefactor host venue paid the > costs and necessarily severely limited attendance, Dan rented (I assume > it wasn't free!) a hotel, opened up a "ticket booth" to the masses, > This is only half correct. Dan indeed opened Internet up to the public but as I recall, the Internet research program continued in parallel. The Internet Configuration Control Board (1979) morphed into the Internet Advisory Board in 1984 with 10 Task Forces after Barry Leiner took over the program management of the Internet Project at DARPA. In 1986, IAB become the Internet Activities Board under Dennis Perry's program management at DARPA. see https://www.iab.org/about/history/ IAB and IETF and IRTF continue as does INTEROP after its sale by Dan Lynch to Masayoshi Son (when?) charged attendees a fee that didn't raise too many bean-counters' > alarms, and added a show floor for vendors too, for an appropriate fee > of course. He also recruited many of the people who used to just > attend the quarterly Internet project meetings to provide the > entertainment for all the attendees, and called it training and program > presentations. > > Not a bad solution to the problem, eh? > > I recall at first there was just a room with some tables and a handful > of vendors showing their wares. That turned pretty quickly into a trade > show floor in Santa Clara, expanding into Moscone, and before long > heading to Vegas when Moscone was just too small. > > All of this had the overriding mandate that there would be a strong > technical focus, a live network, and vendors had to connect their stuff > to it. For a few years, I was on the Interop "Program Committee", which > met around a big table to decide which papers would be put into the > program. It was common to look at a paper, see who was the author, and > if there was even a hint of "marketing" present, it quickly went to the > reject pile. Sometimes all it took was a look at the authors' titles. > > I remember a meeting where Dan took a few of us to Moscone, to meet with > the powers-that-be about possibly holding Interop there. They were > cordial, but IMHO clearly thought this event-they-never-heard-of didn't > belong in Moscone. A year later, after blowing out Santa Clara, they > were much more receptive. Doing the "MazeWar" throughout the Interop > show floor was ... interesting. I checked in to my hotel room on Sunday > at noon, and didn't get back until Tuesday night. After a few years in > Moscone, it had become too small for Interop, so it was off to Vegas. > > Fun times. Interop was, IMHO, critical to getting the Internet out into > the real world. Nobody else showed products actually working, and that > matters to the people who approve the POs. > > But it's a good thing Dan didn't have more of the used-car-salesman > genes. Otherwise we would have all left Interop each year with a new > vehicle. Internet-ready, of course. > > You were wrong, Dan. IMHO, you could have gotten more than 50%.... > > /Jack Haverty > > > > > On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: > > Craig, I think you did not copy the list. And while I?m at it, a small > edit. I paid the tutors 15% , a full 50% more than the competition. I also > charged everybody 50% more than the competition because I felt it was worth > it! I even charged the vendors 50% more than the competition. I turned out > that I was right. > > > > Dan > > > > Cell 650-776-7313 > > > > Begin forwarded message: > > > >> From: Craig Partridge > >> Date: September 8, 2020 at 1:14:05 PM PDT > >> To: Dan Lynch > >> Cc: Craig Partridge via Internet-history < > internet-history at elists.isoc.org> > >> Subject: Re: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) > >> > >> ? > >> Dan was kind enough to mention me, which makes it a little harder to > send this note but I'll do it anyway. > >> > >> I think Dan underplays how radical Interop was. Vendors had to connect > their equipment to the show network. There was a team of Internet wizards > who helped setup the show network for each show. (I recall stories of > laying things out on netting in a warehouse so that it could easily be > transferred to the show floor). But it meant products actually worked. > >> > >> And then there was the education component, which as Dan tells, started > things. Dan took the view that he tried to hire the top instructors in the > field and compensate them properly. At a time when competitors were paying > 10% of the gross or $2K, whichever was less, Dan paid $2K or 10% of the > gross, whichever was more. That meant Interop's courses, instead of being > taught by a grad student or a professor trying out a new course idea, were > taught by folks like Doug Comer and Scott Bradner and Radia Perlman, > teaching their areas of expertise. As a result, the educational program > was immense -- many thousands of students. And because the instructors > were already in town, Dan could recruit us to come do a panel session for > the main program as well. The panels were often also huge. (I still > remember a session I led that included Dave Clark and a couple of other key > folks -- the room was packed -- probably 5,000 people -- and was so jammed > that someone stepped on the tablecloth for the projector, dumping all our > slides [this was pre-Powerpoint real-time projection] on the floor! So I > had to talk w/o slides while the other speakers ran to the back to reinsert > their slides!). > >> > >> Attending Interop was a full week affair -- you got trained and then > went to the showfloor and conference sessions, while grabbing a handful of > the old Doubletree cookies (twice the size they are today) during the > breaks. > >> > >> The transitions in size were wild. We went from Monterrey, to the > Santa Clara TechMart, to the San Jose Convention center to the Moscone > Center in SF in rapid succession. > >> > >> Craig > >> > >>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history < > internet-history at elists.isoc.org> wrote: > >>> SoJack, you are asking me to recount how Interop came to be. I shall > do that as quickly as I can here. > >>> > >>> In the early 80s I was at ISI in charge of the computer facility. > After a year or so there came to be a term New Computing Environment to > describe the advent of personal computers and the death of timesharing! I > think Keith Uncapher coined the term, tho maybe Bob Kahn and Vint Cerf had > a hand in it. Anyway fast forward a few years and I was back in Silicon > Valley looking to start a company like my pals at Stanford had been doing. > I looked around and noticed that the Internet was gaining traction but the > nascent companies had not quite got it right. So I convinced Barry Leiner > who was a program manager there in 85/86 to let me convene a 3 day workshop > on TCP/IP protocols to explain them to the hundred or so implementation > teams out there. I got the actual protocol designers to come to Monterrey > California for 3 days. There was no company name then. I had no idea where > this was going then. Needless to say the event was a success. The > researchers learned of real life problems the early vendors we?re > experiencing and the vendors learned a lot more about the Internet and what > worked and what still needed further steps. > >>> > >>> I now had a business of teaching (through others) the vendors and > advanced customers how the Internet works. I needed a name. I took the old > name above and called it Advanced Computing Environment. > >>> > >>> A few years in to this the world really wanted to see working systems > and I decided to try a trade show, with one critical addition: the systems > had to be connected to an actual working Internet! And while I was on the > phone with one of my brilliant tutor people from BBN, Craig Partridge, as > were were concluding the call he blurted out ?I?ll see you at Interop ?. I > hung up the phone and called my lawyer to register the name immediately! I > had been calling it The TCP/IP Interoperability Conference and Exhibition! > Ah, simplicity. > >>> > >>> That was in September of 1988. It had 50 vendors and 5000 attendees. > In 1990 it had grown to 200 vendors and 30,000 attendees. Clearly this > Internet stuff was catching on, eh? > >>> > >>> So I sold the company and stayed on for 5 more years as the PR guy and > growing it into Europe and Asia. > >>> > >>> 30 years later it still exists in about 10 locations I. The world. Not > quite the same, but still stressing interoperability. > >>> > >>> Thanks for asking, Jack. > >>> > >>> > >>> > >>> Dan > >>> > >>> Cell 650-776-7313 > >>> > >>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > >>>> > >>>> ?Thanks Dan! > >>>> > >>>> There's so much of the history that didn't get recorded in RFCs and > >>>> such, and mail list archives from that era are rare. We weren't very > >>>> good about documenting things, especially the "why" of how decisions > >>>> were made. > >>>> > >>>> There's plenty of room for more participation! Perhaps you can > provide > >>>> the story behind this artifact of the early Internet? > >>>> > >>>> ACE Coaster > >>>> > >>>> That coaster has been sitting on my desk for close to 40 years. The > >>>> lettering is fading, after too many attacks by marauding coffee mugs > >>>> over the decades, and a few trips to the floor courtesy of a roaming > cat. > >>>> > >>>> The story of ACE, and Interop which followed, is an important part of > >>>> Internet history. There tends to be a focus on protocols and > >>>> algorithms, but innovations like Interop were, IMHO, equally important > >>>> to the success of the Internet by making it accessible to the masses > and > >>>> emphasizing the importance of working systems. > >>>> > >>>> Perhaps more important. Tell us the story. > >>>> > >>>> /Jack > >>>> > >>>> > >>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: > >>>>> Forgot to copy the fantastic list! > >>>>> > >>>>> Dan > >>>>> > >>>>> Cell 650-776-7313 > >>>>> > >>>>> Begin forwarded message: > >>>>> > >>>>>> From: Dan Lynch > >>>>>> Date: September 5, 2020 at 11:42:36 AM PDT > >>>>>> To: Joseph Touch > >>>>>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) > >>>>>> > >>>>>> ?Great! These discussions are amazing, considering that they are > being done by the actual inventors of much of the Internet some 3 or 4 > decades later. We were young then, eh? Of course they must be open to the > world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve > forgotten just now. > >>>>>> > >>>>>> Dan > >>>>>> > >>>>>> Cell 650-776-7313 > >>>>>> > >>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history < > internet-history at elists.isoc.org> wrote: > >>>>>>> > >>>>>>> ?HI, all, > >>>>>>> > >>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history < > internet-history at elists.isoc.org> wrote: > >>>>>>>>>> > >>>>>>>>>> From: Joseph Touch > >>>>>>>>> FYI - we moved the archives here. > >>>>>>>> I've just noticed that the archives are now only accessible to > list members? > >>>>>>> They should have been open. If anything changed recently, this is > the first I heard. Either way, the setting has been updated to allow public > access. > >>>>>>> > >>>>>>> Please let me know if you continue to find otherwise. > >>>>>>> > >>>>>>> Joe (as list admin) > >>>>>>> -- > >>>>>>> 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 > >> > >> -- > >> ***** > >> 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 dan at lynch.com Thu Sep 10 09:10:00 2020 From: dan at lynch.com (Dan Lynch) Date: Thu, 10 Sep 2020 09:10:00 -0700 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> References: <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> Message-ID: <2799C189-23F2-43BA-BE17-8745B01149AF@lynch.com> Jack, you have a remarkable memory. A few edits. The chocolate chip cookies at the Doubletree Hotel in Monterey were definitely addictive. I was lucky when we moved to Santa Clara and there was a Doubletree Hotel there. Because I was a computer center guy I knew what the buyers wanted to see and hear. No marketing hype, just technical details, or speeds and feeds as it was called in those days. Price, performance and delivery was all we wanted to see. I remember that for a few years Interop facilitated the IETF meetings because it was easy for us (it was our business) and it built an affinity with the brain trust of the evolving Internet. Somehow NSF or DARPA insisted on paying us for that activity. It was $50k. It certainly cost us more than that to do the work, but we didn?t care. After a while I got the letter from some bureaucrat saying they wanted to audit the contract. Yikes. I had done audit before and they are costly to do. I quickly figured out that I could just give back the $50k and there would be no audit! Much cheaper! Oh, Vint, I sold Interop to Ziff-Davis Publishing. A few years later they sold it to SoftBank for a 3-400% profit. Fun times for many. Dan Cell 650-776-7313 > On Sep 9, 2020, at 9:22 PM, Jack Haverty via Internet-history wrote: > > ?That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen or so > people) meeting that Dan called, I think to mostly bounce off ideas > about a training/conference company. Again IIRC this happened somewhat > before the first actual conference in Monterey, where Dan subsequently > stole the Internet using chocolate-chip cookies as bribes. Vint never > served such cookies! > > From my retro-perspective, it was an interesting progression of events. > > The ARPA "Internet Project" had started in the late 70s with a somewhat > disjoint set of network-building projects, and had congealed into a > network community, with quarterly meetings. > > At first, the "TCP Working Group" and the "Internet Working Group" met > separately. Quickly we noticed that the TCP group kept coming up with > changes to the IP header, while the IP group saw things that needed to > be in the TCP header, and everyone in one group wanted to participate in > the other, so "layering" was cast aside and the Internet Project as a > single group was born. > > Over a year or two of such quarterly meetings, the size of the > membership kept growing, and people had to plead with Vint for a > "ticket" to attend. > > It had become difficult to find a willing host that had a venue big > enough to handle the crowd for plenary and breakout sessions. I hosted > one at BBN, and learned that it is a very bad idea to host a large > meeting in a newly renovated building with lots of free rooms and space, > but without first testing to make sure the brand-new sparkling bathrooms > actually worked. > > The logistics of the quarterly meetings were becoming a serious > problem. Then Dan stepped in. > > Instead of a meeting where ARPA and some benefactor host venue paid the > costs and necessarily severely limited attendance, Dan rented (I assume > it wasn't free!) a hotel, opened up a "ticket booth" to the masses, > charged attendees a fee that didn't raise too many bean-counters' > alarms, and added a show floor for vendors too, for an appropriate fee > of course. He also recruited many of the people who used to just > attend the quarterly Internet project meetings to provide the > entertainment for all the attendees, and called it training and program > presentations. > > Not a bad solution to the problem, eh? > > I recall at first there was just a room with some tables and a handful > of vendors showing their wares. That turned pretty quickly into a trade > show floor in Santa Clara, expanding into Moscone, and before long > heading to Vegas when Moscone was just too small. > > All of this had the overriding mandate that there would be a strong > technical focus, a live network, and vendors had to connect their stuff > to it. For a few years, I was on the Interop "Program Committee", which > met around a big table to decide which papers would be put into the > program. It was common to look at a paper, see who was the author, and > if there was even a hint of "marketing" present, it quickly went to the > reject pile. Sometimes all it took was a look at the authors' titles. > > I remember a meeting where Dan took a few of us to Moscone, to meet with > the powers-that-be about possibly holding Interop there. They were > cordial, but IMHO clearly thought this event-they-never-heard-of didn't > belong in Moscone. A year later, after blowing out Santa Clara, they > were much more receptive. Doing the "MazeWar" throughout the Interop > show floor was ... interesting. I checked in to my hotel room on Sunday > at noon, and didn't get back until Tuesday night. After a few years in > Moscone, it had become too small for Interop, so it was off to Vegas. > > Fun times. Interop was, IMHO, critical to getting the Internet out into > the real world. Nobody else showed products actually working, and that > matters to the people who approve the POs. > > But it's a good thing Dan didn't have more of the used-car-salesman > genes. Otherwise we would have all left Interop each year with a new > vehicle. Internet-ready, of course. > > You were wrong, Dan. IMHO, you could have gotten more than 50%.... > > /Jack Haverty > > > > >> On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: >> Craig, I think you did not copy the list. And while I?m at it, a small edit. I paid the tutors 15% , a full 50% more than the competition. I also charged everybody 50% more than the competition because I felt it was worth it! I even charged the vendors 50% more than the competition. I turned out that I was right. >> >> Dan >> >> Cell 650-776-7313 >> >> Begin forwarded message: >> >>> From: Craig Partridge >>> Date: September 8, 2020 at 1:14:05 PM PDT >>> To: Dan Lynch >>> Cc: Craig Partridge via Internet-history >>> Subject: Re: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) >>> >>> ? >>> Dan was kind enough to mention me, which makes it a little harder to send this note but I'll do it anyway. >>> >>> I think Dan underplays how radical Interop was. Vendors had to connect their equipment to the show network. There was a team of Internet wizards who helped setup the show network for each show. (I recall stories of laying things out on netting in a warehouse so that it could easily be transferred to the show floor). But it meant products actually worked. >>> >>> And then there was the education component, which as Dan tells, started things. Dan took the view that he tried to hire the top instructors in the field and compensate them properly. At a time when competitors were paying 10% of the gross or $2K, whichever was less, Dan paid $2K or 10% of the gross, whichever was more. That meant Interop's courses, instead of being taught by a grad student or a professor trying out a new course idea, were taught by folks like Doug Comer and Scott Bradner and Radia Perlman, teaching their areas of expertise. As a result, the educational program was immense -- many thousands of students. And because the instructors were already in town, Dan could recruit us to come do a panel session for the main program as well. The panels were often also huge. (I still remember a session I led that included Dave Clark and a couple of other key folks -- the room was packed -- probably 5,000 people -- and was so jammed that someone stepped on the tablecloth for the projector, dumping all our slides [this was pre-Powerpoint real-time projection] on the floor! So I had to talk w/o slides while the other speakers ran to the back to reinsert their slides!). >>> >>> Attending Interop was a full week affair -- you got trained and then went to the showfloor and conference sessions, while grabbing a handful of the old Doubletree cookies (twice the size they are today) during the breaks. >>> >>> The transitions in size were wild. We went from Monterrey, to the Santa Clara TechMart, to the San Jose Convention center to the Moscone Center in SF in rapid succession. >>> >>> Craig >>> >>>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history wrote: >>>> SoJack, you are asking me to recount how Interop came to be. I shall do that as quickly as I can here. >>>> >>>> In the early 80s I was at ISI in charge of the computer facility. After a year or so there came to be a term New Computing Environment to describe the advent of personal computers and the death of timesharing! I think Keith Uncapher coined the term, tho maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward a few years and I was back in Silicon Valley looking to start a company like my pals at Stanford had been doing. I looked around and noticed that the Internet was gaining traction but the nascent companies had not quite got it right. So I convinced Barry Leiner who was a program manager there in 85/86 to let me convene a 3 day workshop on TCP/IP protocols to explain them to the hundred or so implementation teams out there. I got the actual protocol designers to come to Monterrey California for 3 days. There was no company name then. I had no idea where this was going then. Needless to say the event was a success. The researchers learned of real life problems the early vendors we?re experiencing and the vendors learned a lot more about the Internet and what worked and what still needed further steps. >>>> >>>> I now had a business of teaching (through others) the vendors and advanced customers how the Internet works. I needed a name. I took the old name above and called it Advanced Computing Environment. >>>> >>>> A few years in to this the world really wanted to see working systems and I decided to try a trade show, with one critical addition: the systems had to be connected to an actual working Internet! And while I was on the phone with one of my brilliant tutor people from BBN, Craig Partridge, as were were concluding the call he blurted out ?I?ll see you at Interop ?. I hung up the phone and called my lawyer to register the name immediately! I had been calling it The TCP/IP Interoperability Conference and Exhibition! Ah, simplicity. >>>> >>>> That was in September of 1988. It had 50 vendors and 5000 attendees. In 1990 it had grown to 200 vendors and 30,000 attendees. Clearly this Internet stuff was catching on, eh? >>>> >>>> So I sold the company and stayed on for 5 more years as the PR guy and growing it into Europe and Asia. >>>> >>>> 30 years later it still exists in about 10 locations I. The world. Not quite the same, but still stressing interoperability. >>>> >>>> Thanks for asking, Jack. >>>> >>>> >>>> >>>> Dan >>>> >>>> Cell 650-776-7313 >>>> >>>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history wrote: >>>>> >>>>> ?Thanks Dan! >>>>> >>>>> There's so much of the history that didn't get recorded in RFCs and >>>>> such, and mail list archives from that era are rare. We weren't very >>>>> good about documenting things, especially the "why" of how decisions >>>>> were made. >>>>> >>>>> There's plenty of room for more participation! Perhaps you can provide >>>>> the story behind this artifact of the early Internet? >>>>> >>>>> ACE Coaster >>>>> >>>>> That coaster has been sitting on my desk for close to 40 years. The >>>>> lettering is fading, after too many attacks by marauding coffee mugs >>>>> over the decades, and a few trips to the floor courtesy of a roaming cat. >>>>> >>>>> The story of ACE, and Interop which followed, is an important part of >>>>> Internet history. There tends to be a focus on protocols and >>>>> algorithms, but innovations like Interop were, IMHO, equally important >>>>> to the success of the Internet by making it accessible to the masses and >>>>> emphasizing the importance of working systems. >>>>> >>>>> Perhaps more important. Tell us the story. >>>>> >>>>> /Jack >>>>> >>>>> >>>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >>>>>> Forgot to copy the fantastic list! >>>>>> >>>>>> Dan >>>>>> >>>>>> Cell 650-776-7313 >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Dan Lynch >>>>>>> Date: September 5, 2020 at 11:42:36 AM PDT >>>>>>> To: Joseph Touch >>>>>>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) >>>>>>> >>>>>>> ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> Cell 650-776-7313 >>>>>>> >>>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >>>>>>>> >>>>>>>> ?HI, all, >>>>>>>> >>>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>>>>>>>> >>>>>>>>>>> From: Joseph Touch >>>>>>>>>> FYI - we moved the archives here. >>>>>>>>> I've just noticed that the archives are now only accessible to list members? >>>>>>>> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >>>>>>>> >>>>>>>> Please let me know if you continue to find otherwise. >>>>>>>> >>>>>>>> Joe (as list admin) >>>>>>>> -- >>>>>>>> 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 >>> >>> -- >>> ***** >>> 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 Thu Sep 10 11:11:21 2020 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 10 Sep 2020 11:11:21 -0700 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> Message-ID: <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> Hi Vint, I concur that the genesis of TCP was in 1973, and spawned a collection of separate projects, e.g., Packet Radio, Atlantic Satellite, etc.? which along with the ARPANET were forming the core of what we now call Internet. What I was remembering is that the moniker "Internet Project" didn't become permanent until the later 70s, with "internet" replacing the earlier term "catenet", as described in 1978 in: http://catenet.org/index.php/IEN_48_-_THE_CATENET_MODEL_FOR_INTERNETWORKING I recall some meeting, probably 1978/9, where there was a discussion of what to call our new conglomeration of networks.? The term "catenet" was proposed, but the general feeling was that it would cause people to envision herds of cats, and the term "internet" achieved the "rough consensus" stage as the best candidate for a name.? We already had running code! The ICCB/IAB was also a key element of history, especially as the creator of the IETF and IRTF.? Somewhere I have my notes of the ICCB (or was it IAB by then...?) meeting where that happened. Pandemics provide rare opportunities to dig through old boxes in the basement... /Jack On 9/10/20 2:55 AM, vinton cerf wrote: > > > On Thu, Sep 10, 2020 at 12:22 AM Jack Haverty via Internet-history > > wrote: > > That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen > or so > people) meeting that Dan called, I think to mostly bounce off ideas > about a training/conference company.?? Again IIRC this happened > somewhat > before the first actual conference in Monterey, where Dan subsequently > stole the Internet using chocolate-chip cookies as bribes.?? Vint > never > served such cookies! > > no, but I did offer champagne for winners of the TCP/IP Hackathons.? > > > >From my retro-perspective, it was an interesting progression of > events.?? > > The ARPA "Internet Project" had started in the late 70s with a > somewhat > > no, it started in 1973.? > > disjoint set of network-building projects, and had congealed into a > network community, with quarterly meetings.? > > At first, the "TCP Working Group" and the "Internet Working Group" met > separately.? Quickly we noticed that the TCP group kept coming up with > changes to the IP header, while the IP group saw things that needed to > be in the TCP header, and everyone in one group wanted to > participate in > the other, so "layering" was cast aside and the Internet Project as a > single group was born. > > Over a year or two of such quarterly meetings, the size of the > membership kept growing, and people had to plead with Vint for a > "ticket" to attend.?? > > It had become difficult to find a willing host that had a venue big > enough to handle the crowd for plenary and breakout sessions.?? I > hosted > one at BBN, and learned that it is a very bad idea to host a large > meeting in a newly renovated building with lots of free rooms and > space, > but without first testing to make sure the brand-new sparkling > bathrooms > actually worked. > > The logistics of the quarterly meetings were becoming a serious > problem.?? Then Dan stepped in. > > Instead of a meeting where ARPA and some benefactor host venue > paid the > costs and necessarily severely limited attendance, Dan rented (I > assume > it wasn't free!) a hotel, opened up a "ticket booth" to the masses, > > This is only half correct. Dan indeed opened Internet up to the public > but as I recall, the Internet research program continued in parallel. > The Internet Configuration Control Board (1979) morphed into the > Internet Advisory Board in 1984 with 10 Task Forces after Barry Leiner > took over > the ?program management of the Internet Project at DARPA. In 1986, IAB? > become the Internet Activities Board under Dennis Perry's program > management > at DARPA. see?https://www.iab.org/about/history/IAB and IETF and IRTF > continue as > does INTEROP after its sale by Dan Lynch to Masayoshi Son (when?) > > charged attendees a fee that didn't raise too many bean-counters' > alarms, and added a show floor for vendors too, for an appropriate fee > of course.?? He also recruited many of the people who used to just > attend the quarterly Internet project meetings to provide the > entertainment for all the attendees, and called it training and > program > presentations. > > Not a bad solution to the problem, eh??? > > I recall at first there was just a room with some tables and a handful > of vendors showing their wares.? That turned pretty quickly into a > trade > show floor in Santa Clara, expanding into Moscone, and before long > heading to Vegas when Moscone was just too small. > > All of this had the overriding mandate that there would be a strong > technical focus, a live network, and vendors had to connect their > stuff > to it.? For a few years, I was on the Interop "Program Committee", > which > met around a big table to decide which papers would be put into the > program.? It was common to look at a paper, see who was the > author, and > if there was even a hint of "marketing" present, it quickly went > to the > reject pile.?? Sometimes all it took was a look at the authors' > titles. > > I remember a meeting where Dan took a few of us to Moscone, to > meet with > the powers-that-be about possibly holding Interop there.? They were > cordial, but IMHO clearly thought this event-they-never-heard-of > didn't > belong in Moscone.? A year later, after blowing out Santa Clara, they > were much more receptive.? Doing the "MazeWar" throughout the Interop > show floor was ... interesting.? I checked in to my hotel room on > Sunday > at noon, and didn't get back until Tuesday night.?? After a few > years in > Moscone, it had become too small for Interop, so it was off to Vegas. > > Fun times.? Interop was, IMHO, critical to getting the Internet > out into > the real world.? Nobody else showed products actually working, and > that > matters to the people who approve the POs. > > But it's a good thing Dan didn't have more of the used-car-salesman > genes.? Otherwise we would have all left Interop each year with a new > vehicle.? Internet-ready, of course. > > You were wrong, Dan. IMHO, you could have gotten more than 50%.... > > /Jack Haverty > > > > > On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: > > Craig, I think you did not copy the list.? And while I?m at it, > a small edit.? I paid the tutors 15% , a full 50% more than the > competition. I also charged everybody 50% more than the > competition because I felt it was worth it!? I even charged the > vendors 50% more than the competition. I turned out that I was right. > > > > Dan > > > > Cell 650-776-7313 > > > > Begin forwarded message: > > > >> From: Craig Partridge > > >> Date: September 8, 2020 at 1:14:05 PM PDT > >> To: Dan Lynch > > >> Cc: Craig Partridge via Internet-history > > > >> Subject: Re:? [ih] Fwd: List archives (Was: Exterior Gateway > Protocol) > >> > >> ? > >> Dan was kind enough to mention me, which makes it a little > harder to send this note but I'll do it anyway. > >> > >> I think Dan underplays how radical Interop was.? Vendors had to > connect their equipment to the show network.? There was a team of > Internet wizards who helped setup the show network for each show.? > (I recall stories of laying things out on netting in a warehouse > so that it could easily be transferred to the show floor).? But it > meant products actually worked. > >> > >> And then there was the education component, which as Dan tells, > started things.? Dan took the view that he tried to hire the top > instructors in the field and compensate them properly. At a time > when competitors were paying 10% of the gross or $2K, whichever > was less, Dan paid $2K or 10% of the gross, whichever was more.? > That meant Interop's courses, instead of being taught by a grad > student or a professor trying out a new course idea, were taught > by folks like Doug Comer and Scott Bradner and Radia Perlman, > teaching their areas of expertise.? As a result, the educational > program was immense -- many thousands of students.? And because > the instructors were already in town, Dan could recruit us to come > do a panel session for the main program as well.? The panels were > often also huge.? (I still remember a session I led that included > Dave Clark and a couple of other key folks -- the room was packed > -- probably 5,000 people -- and was so jammed that someone stepped > on the tablecloth for the projector, dumping all our slides [this > was pre-Powerpoint real-time projection] on the floor!? So I had > to talk w/o slides while the other speakers ran to the back to > reinsert their slides!). > >> > >> Attending Interop was a full week affair -- you got trained and > then went to the showfloor and conference sessions, while grabbing > a handful of the old Doubletree cookies (twice the size they are > today) during the breaks. > >> > >> The transitions in size were wild.? We went from Monterrey, to > the Santa Clara TechMart, to the San Jose Convention center to the > Moscone Center in SF in rapid succession. > >> > >> Craig > >> > >>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history > > wrote: > >>> SoJack, you are asking me to recount how Interop came to be. I > shall do that as quickly as I can here. > >>> > >>> In the early 80s I was at ISI in charge of the computer > facility. After a year or so there came to be a term New Computing > Environment to describe the advent of personal computers and the > death of timesharing!? I think Keith Uncapher coined the term, tho > maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward > a few years and I was back in Silicon Valley looking to start a > company like my pals at Stanford had been doing. I looked around > and noticed that the Internet was gaining traction but the nascent > companies had not quite got it right. So I convinced Barry Leiner > who was a program manager there in 85/86 to let me convene a 3 day > workshop on TCP/IP protocols to explain them to the hundred or so > implementation teams out there. I got the actual protocol > designers to come to Monterrey California for 3 days. There was no > company name then. I had no idea where this was going then. > Needless to say the event was a success. The researchers learned > of real life problems the early vendors we?re experiencing and the > vendors learned a lot more about the Internet and what worked and > what still needed further steps. > >>> > >>> I now had a business of teaching (through others) the vendors > and advanced customers how the Internet works. I needed a name. I > took the old name above and called it Advanced Computing Environment. > >>> > >>> A few years in to this the world really wanted to see working > systems and I decided to try a trade show, with one critical > addition: the systems had to be connected to an actual working > Internet!? And while I was on the phone with one of my brilliant > tutor people from BBN, Craig Partridge, as were were concluding > the call he blurted out ?I?ll see you at Interop ?. I hung up the > phone and called my lawyer to register the name immediately!? I > had been calling it The TCP/IP Interoperability Conference and > Exhibition!? Ah, simplicity. > >>> > >>> That was in September of 1988. It had 50 vendors and 5000 > attendees. In 1990 it had grown to 200 vendors and 30,000 > attendees. Clearly this Internet stuff was catching on, eh?? > >>> > >>> So I sold the company and stayed on for 5 more years as the PR > guy and growing it into Europe and Asia. > >>> > >>> 30 years later it still exists in about 10 locations I. The > world. Not quite the same, but still stressing interoperability. > >>> > >>> Thanks for asking, Jack. > >>> > >>> > >>> > >>> Dan > >>> > >>> Cell 650-776-7313 > >>> > >>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history > > wrote: > >>>> > >>>> ?Thanks Dan! > >>>> > >>>> There's so much of the history that didn't get recorded in > RFCs and > >>>> such, and mail list archives from that era are rare.? We > weren't very > >>>> good about documenting things, especially the "why" of how > decisions > >>>> were made. > >>>> > >>>> There's plenty of room for more participation!? ?Perhaps you > can provide > >>>> the story behind this artifact of the early Internet? > >>>> > >>>> ACE Coaster > >>>> > >>>> That coaster has been sitting on my desk for close to 40 > years.? The > >>>> lettering is fading, after too many attacks by marauding > coffee mugs > >>>> over the decades, and a few trips to the floor courtesy of a > roaming cat. > >>>> > >>>> The story of ACE, and Interop which followed, is an important > part of > >>>> Internet history.? There tends to be a focus on protocols and > >>>> algorithms, but innovations like Interop were, IMHO, equally > important > >>>> to the success of the Internet by making it accessible to the > masses and > >>>> emphasizing the importance of working systems. > >>>> > >>>> Perhaps more important.? ?Tell us the story. > >>>> > >>>> /Jack > >>>> > >>>> > >>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: > >>>>> Forgot to copy the fantastic list! > >>>>> > >>>>> Dan > >>>>> > >>>>> Cell 650-776-7313 > >>>>> > >>>>> Begin forwarded message: > >>>>> > >>>>>> From: Dan Lynch > > >>>>>> Date: September 5, 2020 at 11:42:36 AM PDT > >>>>>> To: Joseph Touch > > >>>>>> Subject: Re:? [ih] List archives (Was: Exterior Gateway > Protocol) > >>>>>> > >>>>>> ?Great!? These discussions are amazing, considering that > they are being done by the actual inventors of much of the > Internet some 3 or 4 decades later. We were young then, eh?? Of > course they must be open to the world. Thank you Noel, Miles, > Brian, Tony, Vint, Jack, and others I?ve forgotten just now. > >>>>>> > >>>>>> Dan > >>>>>> > >>>>>> Cell 650-776-7313 > >>>>>> > >>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via > Internet-history > wrote: > >>>>>>> > >>>>>>> ?HI, all, > >>>>>>> > >>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via > Internet-history > wrote: > >>>>>>>>>> > >>>>>>>>>> From: Joseph Touch > >>>>>>>>> FYI - we moved the archives here. > >>>>>>>> I've just noticed that the archives are now only > accessible to list members? > >>>>>>> They should have been open. If anything changed recently, > this is the first I heard. Either way, the setting has been > updated to allow public access. > >>>>>>> > >>>>>>> Please let me know if you continue to find otherwise. > >>>>>>> > >>>>>>> Joe (as list admin) > >>>>>>> -- > >>>>>>> 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 > >> > >> -- > >> ***** > >> 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 b_a_denny at yahoo.com Thu Sep 10 11:27:16 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Thu, 10 Sep 2020 18:27:16 +0000 (UTC) Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> Message-ID: <1565057141.824958.1599762436842@mail.yahoo.com> Could that meeting have been at SRI? I have a memory of listening to a discussion regarding the creation of the IETF and the IRTF.? I could be wrong about this maybe being the meeting where it happened but I thought it might help you if you look through your notes.? barbara? On Thursday, September 10, 2020, 11:11:55 AM PDT, Jack Haverty via Internet-history wrote: Hi Vint, I concur that the genesis of TCP was in 1973, and spawned a collection of separate projects, e.g., Packet Radio, Atlantic Satellite, etc.? which along with the ARPANET were forming the core of what we now call Internet. What I was remembering is that the moniker "Internet Project" didn't become permanent until the later 70s, with "internet" replacing the earlier term "catenet", as described in 1978 in: http://catenet.org/index.php/IEN_48_-_THE_CATENET_MODEL_FOR_INTERNETWORKING I recall some meeting, probably 1978/9, where there was a discussion of what to call our new conglomeration of networks.? The term "catenet" was proposed, but the general feeling was that it would cause people to envision herds of cats, and the term "internet" achieved the "rough consensus" stage as the best candidate for a name.? We already had running code! The ICCB/IAB was also a key element of history, especially as the creator of the IETF and IRTF.? Somewhere I have my notes of the ICCB (or was it IAB by then...?) meeting where that happened. Pandemics provide rare opportunities to dig through old boxes in the basement... /Jack On 9/10/20 2:55 AM, vinton cerf wrote: > > > On Thu, Sep 10, 2020 at 12:22 AM Jack Haverty via Internet-history > > wrote: > >? ? That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen >? ? or so >? ? people) meeting that Dan called, I think to mostly bounce off ideas >? ? about a training/conference company.?? Again IIRC this happened >? ? somewhat >? ? before the first actual conference in Monterey, where Dan subsequently >? ? stole the Internet using chocolate-chip cookies as bribes.?? Vint >? ? never >? ? served such cookies! > > no, but I did offer champagne for winners of the TCP/IP Hackathons.? > > >? ? >From my retro-perspective, it was an interesting progression of >? ? events.?? > >? ? The ARPA "Internet Project" had started in the late 70s with a >? ? somewhat > > no, it started in 1973.? > >? ? disjoint set of network-building projects, and had congealed into a >? ? network community, with quarterly meetings.? > >? ? At first, the "TCP Working Group" and the "Internet Working Group" met >? ? separately.? Quickly we noticed that the TCP group kept coming up with >? ? changes to the IP header, while the IP group saw things that needed to >? ? be in the TCP header, and everyone in one group wanted to >? ? participate in >? ? the other, so "layering" was cast aside and the Internet Project as a >? ? single group was born. > >? ? Over a year or two of such quarterly meetings, the size of the >? ? membership kept growing, and people had to plead with Vint for a >? ? "ticket" to attend.?? > >? ? It had become difficult to find a willing host that had a venue big >? ? enough to handle the crowd for plenary and breakout sessions.?? I >? ? hosted >? ? one at BBN, and learned that it is a very bad idea to host a large >? ? meeting in a newly renovated building with lots of free rooms and >? ? space, >? ? but without first testing to make sure the brand-new sparkling >? ? bathrooms >? ? actually worked. > >? ? The logistics of the quarterly meetings were becoming a serious >? ? problem.?? Then Dan stepped in. > >? ? Instead of a meeting where ARPA and some benefactor host venue >? ? paid the >? ? costs and necessarily severely limited attendance, Dan rented (I >? ? assume >? ? it wasn't free!) a hotel, opened up a "ticket booth" to the masses, > > This is only half correct. Dan indeed opened Internet up to the public > but as I recall, the Internet research program continued in parallel. > The Internet Configuration Control Board (1979) morphed into the > Internet Advisory Board in 1984 with 10 Task Forces after Barry Leiner > took over > the ?program management of the Internet Project at DARPA. In 1986, IAB? > become the Internet Activities Board under Dennis Perry's program > management > at DARPA. see?https://www.iab.org/about/history/IAB and IETF and IRTF > continue as > does INTEROP after its sale by Dan Lynch to Masayoshi Son (when?) > >? ? charged attendees a fee that didn't raise too many bean-counters' >? ? alarms, and added a show floor for vendors too, for an appropriate fee >? ? of course.?? He also recruited many of the people who used to just >? ? attend the quarterly Internet project meetings to provide the >? ? entertainment for all the attendees, and called it training and >? ? program >? ? presentations. > >? ? Not a bad solution to the problem, eh??? > >? ? I recall at first there was just a room with some tables and a handful >? ? of vendors showing their wares.? That turned pretty quickly into a >? ? trade >? ? show floor in Santa Clara, expanding into Moscone, and before long >? ? heading to Vegas when Moscone was just too small. > >? ? All of this had the overriding mandate that there would be a strong >? ? technical focus, a live network, and vendors had to connect their >? ? stuff >? ? to it.? For a few years, I was on the Interop "Program Committee", >? ? which >? ? met around a big table to decide which papers would be put into the >? ? program.? It was common to look at a paper, see who was the >? ? author, and >? ? if there was even a hint of "marketing" present, it quickly went >? ? to the >? ? reject pile.?? Sometimes all it took was a look at the authors' >? ? titles. > >? ? I remember a meeting where Dan took a few of us to Moscone, to >? ? meet with >? ? the powers-that-be about possibly holding Interop there.? They were >? ? cordial, but IMHO clearly thought this event-they-never-heard-of >? ? didn't >? ? belong in Moscone.? A year later, after blowing out Santa Clara, they >? ? were much more receptive.? Doing the "MazeWar" throughout the Interop >? ? show floor was ... interesting.? I checked in to my hotel room on >? ? Sunday >? ? at noon, and didn't get back until Tuesday night.?? After a few >? ? years in >? ? Moscone, it had become too small for Interop, so it was off to Vegas. > >? ? Fun times.? Interop was, IMHO, critical to getting the Internet >? ? out into >? ? the real world.? Nobody else showed products actually working, and >? ? that >? ? matters to the people who approve the POs. > >? ? But it's a good thing Dan didn't have more of the used-car-salesman >? ? genes.? Otherwise we would have all left Interop each year with a new >? ? vehicle.? Internet-ready, of course. > >? ? You were wrong, Dan. IMHO, you could have gotten more than 50%.... > >? ? /Jack Haverty > > > > >? ? On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: >? ? > Craig, I think you did not copy the list.? And while I?m at it, >? ? a small edit.? I paid the tutors 15% , a full 50% more than the >? ? competition. I also charged everybody 50% more than the >? ? competition because I felt it was worth it!? I even charged the >? ? vendors 50% more than the competition. I turned out that I was right. >? ? > >? ? > Dan >? ? > >? ? > Cell 650-776-7313 >? ? > >? ? > Begin forwarded message: >? ? > >? ? >> From: Craig Partridge ? ? > >? ? >> Date: September 8, 2020 at 1:14:05 PM PDT >? ? >> To: Dan Lynch > >? ? >> Cc: Craig Partridge via Internet-history >? ? ? ? > >? ? >> Subject: Re:? [ih] Fwd: List archives (Was: Exterior Gateway >? ? Protocol) >? ? >> >? ? >> ? >? ? >> Dan was kind enough to mention me, which makes it a little >? ? harder to send this note but I'll do it anyway. >? ? >> >? ? >> I think Dan underplays how radical Interop was.? Vendors had to >? ? connect their equipment to the show network.? There was a team of >? ? Internet wizards who helped setup the show network for each show.? >? ? (I recall stories of laying things out on netting in a warehouse >? ? so that it could easily be transferred to the show floor).? But it >? ? meant products actually worked. >? ? >> >? ? >> And then there was the education component, which as Dan tells, >? ? started things.? Dan took the view that he tried to hire the top >? ? instructors in the field and compensate them properly. At a time >? ? when competitors were paying 10% of the gross or $2K, whichever >? ? was less, Dan paid $2K or 10% of the gross, whichever was more.? >? ? That meant Interop's courses, instead of being taught by a grad >? ? student or a professor trying out a new course idea, were taught >? ? by folks like Doug Comer and Scott Bradner and Radia Perlman, >? ? teaching their areas of expertise.? As a result, the educational >? ? program was immense -- many thousands of students.? And because >? ? the instructors were already in town, Dan could recruit us to come >? ? do a panel session for the main program as well.? The panels were >? ? often also huge.? (I still remember a session I led that included >? ? Dave Clark and a couple of other key folks -- the room was packed >? ? -- probably 5,000 people -- and was so jammed that someone stepped >? ? on the tablecloth for the projector, dumping all our slides [this >? ? was pre-Powerpoint real-time projection] on the floor!? So I had >? ? to talk w/o slides while the other speakers ran to the back to >? ? reinsert their slides!). >? ? >> >? ? >> Attending Interop was a full week affair -- you got trained and >? ? then went to the showfloor and conference sessions, while grabbing >? ? a handful of the old Doubletree cookies (twice the size they are >? ? today) during the breaks. >? ? >> >? ? >> The transitions in size were wild.? We went from Monterrey, to >? ? the Santa Clara TechMart, to the San Jose Convention center to the >? ? Moscone Center in SF in rapid succession. >? ? >> >? ? >> Craig >? ? >> >? ? >>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history >? ? ? ? > wrote: >? ? >>> SoJack, you are asking me to recount how Interop came to be. I >? ? shall do that as quickly as I can here. >? ? >>> >? ? >>> In the early 80s I was at ISI in charge of the computer >? ? facility. After a year or so there came to be a term New Computing >? ? Environment to describe the advent of personal computers and the >? ? death of timesharing!? I think Keith Uncapher coined the term, tho >? ? maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward >? ? a few years and I was back in Silicon Valley looking to start a >? ? company like my pals at Stanford had been doing. I looked around >? ? and noticed that the Internet was gaining traction but the nascent >? ? companies had not quite got it right. So I convinced Barry Leiner >? ? who was a program manager there in 85/86 to let me convene a 3 day >? ? workshop on TCP/IP protocols to explain them to the hundred or so >? ? implementation teams out there. I got the actual protocol >? ? designers to come to Monterrey California for 3 days. There was no >? ? company name then. I had no idea where this was going then. >? ? Needless to say the event was a success. The researchers learned >? ? of real life problems the early vendors we?re experiencing and the >? ? vendors learned a lot more about the Internet and what worked and >? ? what still needed further steps. >? ? >>> >? ? >>> I now had a business of teaching (through others) the vendors >? ? and advanced customers how the Internet works. I needed a name. I >? ? took the old name above and called it Advanced Computing Environment. >? ? >>> >? ? >>> A few years in to this the world really wanted to see working >? ? systems and I decided to try a trade show, with one critical >? ? addition: the systems had to be connected to an actual working >? ? Internet!? And while I was on the phone with one of my brilliant >? ? tutor people from BBN, Craig Partridge, as were were concluding >? ? the call he blurted out ?I?ll see you at Interop ?. I hung up the >? ? phone and called my lawyer to register the name immediately!? I >? ? had been calling it The TCP/IP Interoperability Conference and >? ? Exhibition!? Ah, simplicity. >? ? >>> >? ? >>> That was in September of 1988. It had 50 vendors and 5000 >? ? attendees. In 1990 it had grown to 200 vendors and 30,000 >? ? attendees. Clearly this Internet stuff was catching on, eh?? >? ? >>> >? ? >>> So I sold the company and stayed on for 5 more years as the PR >? ? guy and growing it into Europe and Asia. >? ? >>> >? ? >>> 30 years later it still exists in about 10 locations I. The >? ? world. Not quite the same, but still stressing interoperability. >? ? >>> >? ? >>> Thanks for asking, Jack. >? ? >>> >? ? >>> >? ? >>> >? ? >>> Dan >? ? >>> >? ? >>> Cell 650-776-7313 >? ? >>> >? ? >>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history >? ? ? ? > wrote: >? ? >>>> >? ? >>>> ?Thanks Dan! >? ? >>>> >? ? >>>> There's so much of the history that didn't get recorded in >? ? RFCs and >? ? >>>> such, and mail list archives from that era are rare.? We >? ? weren't very >? ? >>>> good about documenting things, especially the "why" of how >? ? decisions >? ? >>>> were made. >? ? >>>> >? ? >>>> There's plenty of room for more participation!? ?Perhaps you >? ? can provide >? ? >>>> the story behind this artifact of the early Internet? >? ? >>>> >? ? >>>> ACE Coaster >? ? >>>> >? ? >>>> That coaster has been sitting on my desk for close to 40 >? ? years.? The >? ? >>>> lettering is fading, after too many attacks by marauding >? ? coffee mugs >? ? >>>> over the decades, and a few trips to the floor courtesy of a >? ? roaming cat. >? ? >>>> >? ? >>>> The story of ACE, and Interop which followed, is an important >? ? part of >? ? >>>> Internet history.? There tends to be a focus on protocols and >? ? >>>> algorithms, but innovations like Interop were, IMHO, equally >? ? important >? ? >>>> to the success of the Internet by making it accessible to the >? ? masses and >? ? >>>> emphasizing the importance of working systems. >? ? >>>> >? ? >>>> Perhaps more important.? ?Tell us the story. >? ? >>>> >? ? >>>> /Jack >? ? >>>> >? ? >>>> >? ? >>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >? ? >>>>> Forgot to copy the fantastic list! >? ? >>>>> >? ? >>>>> Dan >? ? >>>>> >? ? >>>>> Cell 650-776-7313 >? ? >>>>> >? ? >>>>> Begin forwarded message: >? ? >>>>> >? ? >>>>>> From: Dan Lynch > >? ? >>>>>> Date: September 5, 2020 at 11:42:36 AM PDT >? ? >>>>>> To: Joseph Touch ? ? > >? ? >>>>>> Subject: Re:? [ih] List archives (Was: Exterior Gateway >? ? Protocol) >? ? >>>>>> >? ? >>>>>> ?Great!? These discussions are amazing, considering that >? ? they are being done by the actual inventors of much of the >? ? Internet some 3 or 4 decades later. We were young then, eh?? Of >? ? course they must be open to the world. Thank you Noel, Miles, >? ? Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >? ? >>>>>> >? ? >>>>>> Dan >? ? >>>>>> >? ? >>>>>> Cell 650-776-7313 >? ? >>>>>> >? ? >>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via >? ? Internet-history ? ? > wrote: >? ? >>>>>>> >? ? >>>>>>> ?HI, all, >? ? >>>>>>> >? ? >>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via >? ? Internet-history ? ? > wrote: >? ? >>>>>>>>>> >? ? >>>>>>>>>> From: Joseph Touch >? ? >>>>>>>>> FYI - we moved the archives here. >? ? >>>>>>>> I've just noticed that the archives are now only >? ? accessible to list members? >? ? >>>>>>> They should have been open. If anything changed recently, >? ? this is the first I heard. Either way, the setting has been >? ? updated to allow public access. >? ? >>>>>>> >? ? >>>>>>> Please let me know if you continue to find otherwise. >? ? >>>>>>> >? ? >>>>>>> Joe (as list admin) >? ? >>>>>>> -- >? ? >>>>>>> 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 >? ? >> >? ? >> -- >? ? >> ***** >? ? >> 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 Thu Sep 10 11:30:32 2020 From: vint at google.com (Vint Cerf) Date: Thu, 10 Sep 2020 14:30:32 -0400 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <2799C189-23F2-43BA-BE17-8745B01149AF@lynch.com> References: <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <2799C189-23F2-43BA-BE17-8745B01149AF@lynch.com> Message-ID: thanks dan, i had forgotten the ziff-davis step v On Thu, Sep 10, 2020 at 12:10 PM Dan Lynch via Internet-history < internet-history at elists.isoc.org> wrote: > Jack, you have a remarkable memory. A few edits. > > The chocolate chip cookies at the Doubletree Hotel in Monterey were > definitely addictive. I was lucky when we moved to Santa Clara and there > was a Doubletree Hotel there. > > Because I was a computer center guy I knew what the buyers wanted to see > and hear. No marketing hype, just technical details, or speeds and feeds as > it was called in those days. Price, performance and delivery was all we > wanted to see. > > I remember that for a few years Interop facilitated the IETF meetings > because it was easy for us (it was our business) and it built an affinity > with the brain trust of the evolving Internet. Somehow NSF or DARPA > insisted on paying us for that activity. It was $50k. It certainly cost us > more than that to do the work, but we didn?t care. After a while I got the > letter from some bureaucrat saying they wanted to audit the contract. > Yikes. I had done audit before and they are costly to do. I quickly figured > out that I could just give back the $50k and there would be no audit! Much > cheaper! > > Oh, Vint, I sold Interop to Ziff-Davis Publishing. A few years later they > sold it to SoftBank for a 3-400% profit. > > Fun times for many. > > Dan > > Cell 650-776-7313 <(650)%20776-7313> > > > On Sep 9, 2020, at 9:22 PM, Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > ?That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen or so > > people) meeting that Dan called, I think to mostly bounce off ideas > > about a training/conference company. Again IIRC this happened somewhat > > before the first actual conference in Monterey, where Dan subsequently > > stole the Internet using chocolate-chip cookies as bribes. Vint never > > served such cookies! > > > > From my retro-perspective, it was an interesting progression of events. > > > > The ARPA "Internet Project" had started in the late 70s with a somewhat > > disjoint set of network-building projects, and had congealed into a > > network community, with quarterly meetings. > > > > At first, the "TCP Working Group" and the "Internet Working Group" met > > separately. Quickly we noticed that the TCP group kept coming up with > > changes to the IP header, while the IP group saw things that needed to > > be in the TCP header, and everyone in one group wanted to participate in > > the other, so "layering" was cast aside and the Internet Project as a > > single group was born. > > > > Over a year or two of such quarterly meetings, the size of the > > membership kept growing, and people had to plead with Vint for a > > "ticket" to attend. > > > > It had become difficult to find a willing host that had a venue big > > enough to handle the crowd for plenary and breakout sessions. I hosted > > one at BBN, and learned that it is a very bad idea to host a large > > meeting in a newly renovated building with lots of free rooms and space, > > but without first testing to make sure the brand-new sparkling bathrooms > > actually worked. > > > > The logistics of the quarterly meetings were becoming a serious > > problem. Then Dan stepped in. > > > > Instead of a meeting where ARPA and some benefactor host venue paid the > > costs and necessarily severely limited attendance, Dan rented (I assume > > it wasn't free!) a hotel, opened up a "ticket booth" to the masses, > > charged attendees a fee that didn't raise too many bean-counters' > > alarms, and added a show floor for vendors too, for an appropriate fee > > of course. He also recruited many of the people who used to just > > attend the quarterly Internet project meetings to provide the > > entertainment for all the attendees, and called it training and program > > presentations. > > > > Not a bad solution to the problem, eh? > > > > I recall at first there was just a room with some tables and a handful > > of vendors showing their wares. That turned pretty quickly into a trade > > show floor in Santa Clara, expanding into Moscone, and before long > > heading to Vegas when Moscone was just too small. > > > > All of this had the overriding mandate that there would be a strong > > technical focus, a live network, and vendors had to connect their stuff > > to it. For a few years, I was on the Interop "Program Committee", which > > met around a big table to decide which papers would be put into the > > program. It was common to look at a paper, see who was the author, and > > if there was even a hint of "marketing" present, it quickly went to the > > reject pile. Sometimes all it took was a look at the authors' titles. > > > > I remember a meeting where Dan took a few of us to Moscone, to meet with > > the powers-that-be about possibly holding Interop there. They were > > cordial, but IMHO clearly thought this event-they-never-heard-of didn't > > belong in Moscone. A year later, after blowing out Santa Clara, they > > were much more receptive. Doing the "MazeWar" throughout the Interop > > show floor was ... interesting. I checked in to my hotel room on Sunday > > at noon, and didn't get back until Tuesday night. After a few years in > > Moscone, it had become too small for Interop, so it was off to Vegas. > > > > Fun times. Interop was, IMHO, critical to getting the Internet out into > > the real world. Nobody else showed products actually working, and that > > matters to the people who approve the POs. > > > > But it's a good thing Dan didn't have more of the used-car-salesman > > genes. Otherwise we would have all left Interop each year with a new > > vehicle. Internet-ready, of course. > > > > You were wrong, Dan. IMHO, you could have gotten more than 50%.... > > > > /Jack Haverty > > > > > > > > > >> On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: > >> Craig, I think you did not copy the list. And while I?m at it, a small > edit. I paid the tutors 15% , a full 50% more than the competition. I also > charged everybody 50% more than the competition because I felt it was worth > it! I even charged the vendors 50% more than the competition. I turned out > that I was right. > >> > >> Dan > >> > >> Cell 650-776-7313 <(650)%20776-7313> > >> > >> Begin forwarded message: > >> > >>> From: Craig Partridge > >>> Date: September 8, 2020 at 1:14:05 PM PDT > >>> To: Dan Lynch > >>> Cc: Craig Partridge via Internet-history < > internet-history at elists.isoc.org> > >>> Subject: Re: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) > >>> > >>> ? > >>> Dan was kind enough to mention me, which makes it a little harder to > send this note but I'll do it anyway. > >>> > >>> I think Dan underplays how radical Interop was. Vendors had to > connect their equipment to the show network. There was a team of Internet > wizards who helped setup the show network for each show. (I recall stories > of laying things out on netting in a warehouse so that it could easily be > transferred to the show floor). But it meant products actually worked. > >>> > >>> And then there was the education component, which as Dan tells, > started things. Dan took the view that he tried to hire the top > instructors in the field and compensate them properly. At a time when > competitors were paying 10% of the gross or $2K, whichever was less, Dan > paid $2K or 10% of the gross, whichever was more. That meant Interop's > courses, instead of being taught by a grad student or a professor trying > out a new course idea, were taught by folks like Doug Comer and Scott > Bradner and Radia Perlman, teaching their areas of expertise. As a result, > the educational program was immense -- many thousands of students. And > because the instructors were already in town, Dan could recruit us to come > do a panel session for the main program as well. The panels were often > also huge. (I still remember a session I led that included Dave Clark and > a couple of other key folks -- the room was packed -- probably 5,000 people > -- and was so jammed that someone stepped on the tablecloth for the > projector, dumping all our slides [this was pre-Powerpoint real-time > projection] on the floor! So I had to talk w/o slides while the other > speakers ran to the back to reinsert their slides!). > >>> > >>> Attending Interop was a full week affair -- you got trained and then > went to the showfloor and conference sessions, while grabbing a handful of > the old Doubletree cookies (twice the size they are today) during the > breaks. > >>> > >>> The transitions in size were wild. We went from Monterrey, to the > Santa Clara TechMart, to the San Jose Convention center to the Moscone > Center in SF in rapid succession. > >>> > >>> Craig > >>> > >>>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history < > internet-history at elists.isoc.org> wrote: > >>>> SoJack, you are asking me to recount how Interop came to be. I shall > do that as quickly as I can here. > >>>> > >>>> In the early 80s I was at ISI in charge of the computer facility. > After a year or so there came to be a term New Computing Environment to > describe the advent of personal computers and the death of timesharing! I > think Keith Uncapher coined the term, tho maybe Bob Kahn and Vint Cerf had > a hand in it. Anyway fast forward a few years and I was back in Silicon > Valley looking to start a company like my pals at Stanford had been doing. > I looked around and noticed that the Internet was gaining traction but the > nascent companies had not quite got it right. So I convinced Barry Leiner > who was a program manager there in 85/86 to let me convene a 3 day workshop > on TCP/IP protocols to explain them to the hundred or so implementation > teams out there. I got the actual protocol designers to come to Monterrey > California for 3 days. There was no company name then. I had no idea where > this was going then. Needless to say the event was a success. The > researchers learned of real life problems the early vendors we?re > experiencing and the vendors learned a lot more about the Internet and what > worked and what still needed further steps. > >>>> > >>>> I now had a business of teaching (through others) the vendors and > advanced customers how the Internet works. I needed a name. I took the old > name above and called it Advanced Computing Environment. > >>>> > >>>> A few years in to this the world really wanted to see working systems > and I decided to try a trade show, with one critical addition: the systems > had to be connected to an actual working Internet! And while I was on the > phone with one of my brilliant tutor people from BBN, Craig Partridge, as > were were concluding the call he blurted out ?I?ll see you at Interop ?. I > hung up the phone and called my lawyer to register the name immediately! I > had been calling it The TCP/IP Interoperability Conference and Exhibition! > Ah, simplicity. > >>>> > >>>> That was in September of 1988. It had 50 vendors and 5000 attendees. > In 1990 it had grown to 200 vendors and 30,000 attendees. Clearly this > Internet stuff was catching on, eh? > >>>> > >>>> So I sold the company and stayed on for 5 more years as the PR guy > and growing it into Europe and Asia. > >>>> > >>>> 30 years later it still exists in about 10 locations I. The world. > Not quite the same, but still stressing interoperability. > >>>> > >>>> Thanks for asking, Jack. > >>>> > >>>> > >>>> > >>>> Dan > >>>> > >>>> Cell 650-776-7313 <(650)%20776-7313> > >>>> > >>>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > >>>>> > >>>>> ?Thanks Dan! > >>>>> > >>>>> There's so much of the history that didn't get recorded in RFCs and > >>>>> such, and mail list archives from that era are rare. We weren't very > >>>>> good about documenting things, especially the "why" of how decisions > >>>>> were made. > >>>>> > >>>>> There's plenty of room for more participation! Perhaps you can > provide > >>>>> the story behind this artifact of the early Internet? > >>>>> > >>>>> ACE Coaster > >>>>> > >>>>> That coaster has been sitting on my desk for close to 40 years. The > >>>>> lettering is fading, after too many attacks by marauding coffee mugs > >>>>> over the decades, and a few trips to the floor courtesy of a roaming > cat. > >>>>> > >>>>> The story of ACE, and Interop which followed, is an important part of > >>>>> Internet history. There tends to be a focus on protocols and > >>>>> algorithms, but innovations like Interop were, IMHO, equally > important > >>>>> to the success of the Internet by making it accessible to the masses > and > >>>>> emphasizing the importance of working systems. > >>>>> > >>>>> Perhaps more important. Tell us the story. > >>>>> > >>>>> /Jack > >>>>> > >>>>> > >>>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: > >>>>>> Forgot to copy the fantastic list! > >>>>>> > >>>>>> Dan > >>>>>> > >>>>>> Cell 650-776-7313 <(650)%20776-7313> > >>>>>> > >>>>>> Begin forwarded message: > >>>>>> > >>>>>>> From: Dan Lynch > >>>>>>> Date: September 5, 2020 at 11:42:36 AM PDT > >>>>>>> To: Joseph Touch > >>>>>>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) > >>>>>>> > >>>>>>> ?Great! These discussions are amazing, considering that they are > being done by the actual inventors of much of the Internet some 3 or 4 > decades later. We were young then, eh? Of course they must be open to the > world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve > forgotten just now. > >>>>>>> > >>>>>>> Dan > >>>>>>> > >>>>>>> Cell 650-776-7313 <(650)%20776-7313> > >>>>>>> > >>>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history < > internet-history at elists.isoc.org> wrote: > >>>>>>>> > >>>>>>>> ?HI, all, > >>>>>>>> > >>>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history < > internet-history at elists.isoc.org> wrote: > >>>>>>>>>>> > >>>>>>>>>>> From: Joseph Touch > >>>>>>>>>> FYI - we moved the archives here. > >>>>>>>>> I've just noticed that the archives are now only accessible to > list members? > >>>>>>>> They should have been open. If anything changed recently, this is > the first I heard. Either way, the setting has been updated to allow public > access. > >>>>>>>> > >>>>>>>> Please let me know if you continue to find otherwise. > >>>>>>>> > >>>>>>>> Joe (as list admin) > >>>>>>>> -- > >>>>>>>> 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 > >>> > >>> -- > >>> ***** > >>> 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 > -- Please send any postal/overnight deliveries to: Vint Cerf 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From vint at google.com Thu Sep 10 11:32:09 2020 From: vint at google.com (Vint Cerf) Date: Thu, 10 Sep 2020 14:32:09 -0400 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> Message-ID: 1. original project name: internetting 2. rfc 675 first use of "internet" 3. catenet used only once in ien #48 v On Thu, Sep 10, 2020 at 2:11 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > Hi Vint, > > I concur that the genesis of TCP was in 1973, and spawned a collection > of separate projects, e.g., Packet Radio, Atlantic Satellite, etc. > which along with the ARPANET were forming the core of what we now call > Internet. > > What I was remembering is that the moniker "Internet Project" didn't > become permanent until the later 70s, with "internet" replacing the > earlier term "catenet", as described in 1978 in: > > http://catenet.org/index.php/IEN_48_-_THE_CATENET_MODEL_FOR_INTERNETWORKING > > I recall some meeting, probably 1978/9, where there was a discussion of > what to call our new conglomeration of networks. The term "catenet" was > proposed, but the general feeling was that it would cause people to > envision herds of cats, and the term "internet" achieved the "rough > consensus" stage as the best candidate for a name. We already had > running code! > > The ICCB/IAB was also a key element of history, especially as the > creator of the IETF and IRTF. Somewhere I have my notes of the ICCB (or > was it IAB by then...?) meeting where that happened. > > Pandemics provide rare opportunities to dig through old boxes in the > basement... > > /Jack > > On 9/10/20 2:55 AM, vinton cerf wrote: > > > > > > On Thu, Sep 10, 2020 at 12:22 AM Jack Haverty via Internet-history > > > > wrote: > > > > That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen > > or so > > people) meeting that Dan called, I think to mostly bounce off ideas > > about a training/conference company. Again IIRC this happened > > somewhat > > before the first actual conference in Monterey, where Dan > subsequently > > stole the Internet using chocolate-chip cookies as bribes. Vint > > never > > served such cookies! > > > > no, but I did offer champagne for winners of the TCP/IP Hackathons. > > > > > > >From my retro-perspective, it was an interesting progression of > > events. > > > > The ARPA "Internet Project" had started in the late 70s with a > > somewhat > > > > no, it started in 1973. > > > > disjoint set of network-building projects, and had congealed into a > > network community, with quarterly meetings. > > > > At first, the "TCP Working Group" and the "Internet Working Group" > met > > separately. Quickly we noticed that the TCP group kept coming up > with > > changes to the IP header, while the IP group saw things that needed > to > > be in the TCP header, and everyone in one group wanted to > > participate in > > the other, so "layering" was cast aside and the Internet Project as a > > single group was born. > > > > Over a year or two of such quarterly meetings, the size of the > > membership kept growing, and people had to plead with Vint for a > > "ticket" to attend. > > > > It had become difficult to find a willing host that had a venue big > > enough to handle the crowd for plenary and breakout sessions. I > > hosted > > one at BBN, and learned that it is a very bad idea to host a large > > meeting in a newly renovated building with lots of free rooms and > > space, > > but without first testing to make sure the brand-new sparkling > > bathrooms > > actually worked. > > > > The logistics of the quarterly meetings were becoming a serious > > problem. Then Dan stepped in. > > > > Instead of a meeting where ARPA and some benefactor host venue > > paid the > > costs and necessarily severely limited attendance, Dan rented (I > > assume > > it wasn't free!) a hotel, opened up a "ticket booth" to the masses, > > > > This is only half correct. Dan indeed opened Internet up to the public > > but as I recall, the Internet research program continued in parallel. > > The Internet Configuration Control Board (1979) morphed into the > > Internet Advisory Board in 1984 with 10 Task Forces after Barry Leiner > > took over > > the program management of the Internet Project at DARPA. In 1986, IAB > > become the Internet Activities Board under Dennis Perry's program > > management > > at DARPA. see https://www.iab.org/about/history/IAB and IETF and IRTF > > continue as > > does INTEROP after its sale by Dan Lynch to Masayoshi Son (when?) > > > > charged attendees a fee that didn't raise too many bean-counters' > > alarms, and added a show floor for vendors too, for an appropriate > fee > > of course. He also recruited many of the people who used to just > > attend the quarterly Internet project meetings to provide the > > entertainment for all the attendees, and called it training and > > program > > presentations. > > > > Not a bad solution to the problem, eh? > > > > I recall at first there was just a room with some tables and a > handful > > of vendors showing their wares. That turned pretty quickly into a > > trade > > show floor in Santa Clara, expanding into Moscone, and before long > > heading to Vegas when Moscone was just too small. > > > > All of this had the overriding mandate that there would be a strong > > technical focus, a live network, and vendors had to connect their > > stuff > > to it. For a few years, I was on the Interop "Program Committee", > > which > > met around a big table to decide which papers would be put into the > > program. It was common to look at a paper, see who was the > > author, and > > if there was even a hint of "marketing" present, it quickly went > > to the > > reject pile. Sometimes all it took was a look at the authors' > > titles. > > > > I remember a meeting where Dan took a few of us to Moscone, to > > meet with > > the powers-that-be about possibly holding Interop there. They were > > cordial, but IMHO clearly thought this event-they-never-heard-of > > didn't > > belong in Moscone. A year later, after blowing out Santa Clara, they > > were much more receptive. Doing the "MazeWar" throughout the Interop > > show floor was ... interesting. I checked in to my hotel room on > > Sunday > > at noon, and didn't get back until Tuesday night. After a few > > years in > > Moscone, it had become too small for Interop, so it was off to Vegas. > > > > Fun times. Interop was, IMHO, critical to getting the Internet > > out into > > the real world. Nobody else showed products actually working, and > > that > > matters to the people who approve the POs. > > > > But it's a good thing Dan didn't have more of the used-car-salesman > > genes. Otherwise we would have all left Interop each year with a new > > vehicle. Internet-ready, of course. > > > > You were wrong, Dan. IMHO, you could have gotten more than 50%.... > > > > /Jack Haverty > > > > > > > > > > On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: > > > Craig, I think you did not copy the list. And while I?m at it, > > a small edit. I paid the tutors 15% , a full 50% more than the > > competition. I also charged everybody 50% more than the > > competition because I felt it was worth it! I even charged the > > vendors 50% more than the competition. I turned out that I was right. > > > > > > Dan > > > > > > Cell 650-776-7313 <(650)%20776-7313> > > > > > > Begin forwarded message: > > > > > >> From: Craig Partridge > > > > >> Date: September 8, 2020 at 1:14:05 PM PDT > > >> To: Dan Lynch > > > >> Cc: Craig Partridge via Internet-history > > > > > > >> Subject: Re: [ih] Fwd: List archives (Was: Exterior Gateway > > Protocol) > > >> > > >> ? > > >> Dan was kind enough to mention me, which makes it a little > > harder to send this note but I'll do it anyway. > > >> > > >> I think Dan underplays how radical Interop was. Vendors had to > > connect their equipment to the show network. There was a team of > > Internet wizards who helped setup the show network for each show. > > (I recall stories of laying things out on netting in a warehouse > > so that it could easily be transferred to the show floor). But it > > meant products actually worked. > > >> > > >> And then there was the education component, which as Dan tells, > > started things. Dan took the view that he tried to hire the top > > instructors in the field and compensate them properly. At a time > > when competitors were paying 10% of the gross or $2K, whichever > > was less, Dan paid $2K or 10% of the gross, whichever was more. > > That meant Interop's courses, instead of being taught by a grad > > student or a professor trying out a new course idea, were taught > > by folks like Doug Comer and Scott Bradner and Radia Perlman, > > teaching their areas of expertise. As a result, the educational > > program was immense -- many thousands of students. And because > > the instructors were already in town, Dan could recruit us to come > > do a panel session for the main program as well. The panels were > > often also huge. (I still remember a session I led that included > > Dave Clark and a couple of other key folks -- the room was packed > > -- probably 5,000 people -- and was so jammed that someone stepped > > on the tablecloth for the projector, dumping all our slides [this > > was pre-Powerpoint real-time projection] on the floor! So I had > > to talk w/o slides while the other speakers ran to the back to > > reinsert their slides!). > > >> > > >> Attending Interop was a full week affair -- you got trained and > > then went to the showfloor and conference sessions, while grabbing > > a handful of the old Doubletree cookies (twice the size they are > > today) during the breaks. > > >> > > >> The transitions in size were wild. We went from Monterrey, to > > the Santa Clara TechMart, to the San Jose Convention center to the > > Moscone Center in SF in rapid succession. > > >> > > >> Craig > > >> > > >>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history > > > > wrote: > > >>> SoJack, you are asking me to recount how Interop came to be. I > > shall do that as quickly as I can here. > > >>> > > >>> In the early 80s I was at ISI in charge of the computer > > facility. After a year or so there came to be a term New Computing > > Environment to describe the advent of personal computers and the > > death of timesharing! I think Keith Uncapher coined the term, tho > > maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward > > a few years and I was back in Silicon Valley looking to start a > > company like my pals at Stanford had been doing. I looked around > > and noticed that the Internet was gaining traction but the nascent > > companies had not quite got it right. So I convinced Barry Leiner > > who was a program manager there in 85/86 to let me convene a 3 day > > workshop on TCP/IP protocols to explain them to the hundred or so > > implementation teams out there. I got the actual protocol > > designers to come to Monterrey California for 3 days. There was no > > company name then. I had no idea where this was going then. > > Needless to say the event was a success. The researchers learned > > of real life problems the early vendors we?re experiencing and the > > vendors learned a lot more about the Internet and what worked and > > what still needed further steps. > > >>> > > >>> I now had a business of teaching (through others) the vendors > > and advanced customers how the Internet works. I needed a name. I > > took the old name above and called it Advanced Computing Environment. > > >>> > > >>> A few years in to this the world really wanted to see working > > systems and I decided to try a trade show, with one critical > > addition: the systems had to be connected to an actual working > > Internet! And while I was on the phone with one of my brilliant > > tutor people from BBN, Craig Partridge, as were were concluding > > the call he blurted out ?I?ll see you at Interop ?. I hung up the > > phone and called my lawyer to register the name immediately! I > > had been calling it The TCP/IP Interoperability Conference and > > Exhibition! Ah, simplicity. > > >>> > > >>> That was in September of 1988. It had 50 vendors and 5000 > > attendees. In 1990 it had grown to 200 vendors and 30,000 > > attendees. Clearly this Internet stuff was catching on, eh? > > >>> > > >>> So I sold the company and stayed on for 5 more years as the PR > > guy and growing it into Europe and Asia. > > >>> > > >>> 30 years later it still exists in about 10 locations I. The > > world. Not quite the same, but still stressing interoperability. > > >>> > > >>> Thanks for asking, Jack. > > >>> > > >>> > > >>> > > >>> Dan > > >>> > > >>> Cell 650-776-7313 <(650)%20776-7313> > > >>> > > >>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history > > > > wrote: > > >>>> > > >>>> ?Thanks Dan! > > >>>> > > >>>> There's so much of the history that didn't get recorded in > > RFCs and > > >>>> such, and mail list archives from that era are rare. We > > weren't very > > >>>> good about documenting things, especially the "why" of how > > decisions > > >>>> were made. > > >>>> > > >>>> There's plenty of room for more participation! Perhaps you > > can provide > > >>>> the story behind this artifact of the early Internet? > > >>>> > > >>>> ACE Coaster > > >>>> > > >>>> That coaster has been sitting on my desk for close to 40 > > years. The > > >>>> lettering is fading, after too many attacks by marauding > > coffee mugs > > >>>> over the decades, and a few trips to the floor courtesy of a > > roaming cat. > > >>>> > > >>>> The story of ACE, and Interop which followed, is an important > > part of > > >>>> Internet history. There tends to be a focus on protocols and > > >>>> algorithms, but innovations like Interop were, IMHO, equally > > important > > >>>> to the success of the Internet by making it accessible to the > > masses and > > >>>> emphasizing the importance of working systems. > > >>>> > > >>>> Perhaps more important. Tell us the story. > > >>>> > > >>>> /Jack > > >>>> > > >>>> > > >>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: > > >>>>> Forgot to copy the fantastic list! > > >>>>> > > >>>>> Dan > > >>>>> > > >>>>> Cell 650-776-7313 <(650)%20776-7313> > > >>>>> > > >>>>> Begin forwarded message: > > >>>>> > > >>>>>> From: Dan Lynch > > > >>>>>> Date: September 5, 2020 at 11:42:36 AM PDT > > >>>>>> To: Joseph Touch > > > > >>>>>> Subject: Re: [ih] List archives (Was: Exterior Gateway > > Protocol) > > >>>>>> > > >>>>>> ?Great! These discussions are amazing, considering that > > they are being done by the actual inventors of much of the > > Internet some 3 or 4 decades later. We were young then, eh? Of > > course they must be open to the world. Thank you Noel, Miles, > > Brian, Tony, Vint, Jack, and others I?ve forgotten just now. > > >>>>>> > > >>>>>> Dan > > >>>>>> > > >>>>>> Cell 650-776-7313 <(650)%20776-7313> > > >>>>>> > > >>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via > > Internet-history > > wrote: > > >>>>>>> > > >>>>>>> ?HI, all, > > >>>>>>> > > >>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via > > Internet-history > > wrote: > > >>>>>>>>>> > > >>>>>>>>>> From: Joseph Touch > > >>>>>>>>> FYI - we moved the archives here. > > >>>>>>>> I've just noticed that the archives are now only > > accessible to list members? > > >>>>>>> They should have been open. If anything changed recently, > > this is the first I heard. Either way, the setting has been > > updated to allow public access. > > >>>>>>> > > >>>>>>> Please let me know if you continue to find otherwise. > > >>>>>>> > > >>>>>>> Joe (as list admin) > > >>>>>>> -- > > >>>>>>> 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 > > >> > > >> -- > > >> ***** > > >> 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 > -- Please send any postal/overnight deliveries to: Vint Cerf 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From jack at 3kitty.org Thu Sep 10 12:04:38 2020 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 10 Sep 2020 12:04:38 -0700 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <2799C189-23F2-43BA-BE17-8745B01149AF@lynch.com> References: <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <2799C189-23F2-43BA-BE17-8745B01149AF@lynch.com> Message-ID: <093c9532-94d1-7074-133b-61e4f050fc67@3kitty.org> That's the key -- "knew what the buyers wanted"?? Interop was a crucial part of delivering information to those buyers who in a real sense bought the Internet, taking the ideas from research to scale. At about the same time (1989/90), I was involved in a consulting contract with a major investment house, who needed help in deciding how to use all the fancy new technology hitting the market.?? I recall going to meetings in the canyonlands of Wall Street, and seeing large trucks at the skyscrapers' loading docks, packed full of Sun workstations being delivered. The CTO had issued three identical contracts to three techie firms, with the vague deliverable of "build something that helps us in our business".? Hardware, software, AI, protocols, network-connected espresso machines, whatever they thought would help - the contractors got to decide, and should just assume that each user had a Sun workstation connected to Ethernet, running TCP. My consulting role was to help evaluate the resulting competitors' systems, and we had a meeting to sort out how to do that.?? I remember describing how we would look at CPU usage, memory, latency, efficiency, etc.? All of the things that matter. He listened attentively, then offered his own thoughts, asking if he was being too simplistic.? He was planning to take three floors of traders, and install each competitor's "helper system" on a separate floor.?? For a few weeks/months, they would all use the helper stuff, whatever it turned out to be, as part of their normal daily activities. At the end of those trials, he would simply see which floor had made the most money. ? Nothing else mattered. Oh yes, they did go to Interop, which was probably why they had all those Sun workstations, since they could see them working over the InteropNet.?? They had also adopted TCP as their solution, with a pile of Cisco routers set up in their IT lab for checkout before deployment to London and Tokyo.?? Satellite lines were ordered, and everything was dually redundant to maximize availability - Time=Money.?? An "intranet" was in the making; they saw it working at Interop. Interop was a key player in the "technology transfer" from the research/government/academic creche to the "real world".?? People adopted the Internet because they could see that it worked, and it helped them do whatever it was that they did. Fun times, /Jack On 9/10/20 9:10 AM, Dan Lynch wrote: > Jack, you have a remarkable memory. A few edits. > > The chocolate chip cookies at the Doubletree Hotel in Monterey were definitely addictive. I was lucky when we moved to Santa Clara and there was a Doubletree Hotel there. > > Because I was a computer center guy I knew what the buyers wanted to see and hear. No marketing hype, just technical details, or speeds and feeds as it was called in those days. Price, performance and delivery was all we wanted to see. > > I remember that for a few years Interop facilitated the IETF meetings because it was easy for us (it was our business) and it built an affinity with the brain trust of the evolving Internet. Somehow NSF or DARPA insisted on paying us for that activity. It was $50k. It certainly cost us more than that to do the work, but we didn?t care. After a while I got the letter from some bureaucrat saying they wanted to audit the contract. Yikes. I had done audit before and they are costly to do. I quickly figured out that I could just give back the $50k and there would be no audit! Much cheaper! > > Oh, Vint, I sold Interop to Ziff-Davis Publishing. A few years later they sold it to SoftBank for a 3-400% profit. > > Fun times for many. > > Dan > > Cell 650-776-7313 > >> On Sep 9, 2020, at 9:22 PM, Jack Haverty via Internet-history wrote: >> >> ?That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen or so >> people) meeting that Dan called, I think to mostly bounce off ideas >> about a training/conference company. Again IIRC this happened somewhat >> before the first actual conference in Monterey, where Dan subsequently >> stole the Internet using chocolate-chip cookies as bribes. Vint never >> served such cookies! >> >> From my retro-perspective, it was an interesting progression of events. >> >> The ARPA "Internet Project" had started in the late 70s with a somewhat >> disjoint set of network-building projects, and had congealed into a >> network community, with quarterly meetings. >> >> At first, the "TCP Working Group" and the "Internet Working Group" met >> separately. Quickly we noticed that the TCP group kept coming up with >> changes to the IP header, while the IP group saw things that needed to >> be in the TCP header, and everyone in one group wanted to participate in >> the other, so "layering" was cast aside and the Internet Project as a >> single group was born. >> >> Over a year or two of such quarterly meetings, the size of the >> membership kept growing, and people had to plead with Vint for a >> "ticket" to attend. >> >> It had become difficult to find a willing host that had a venue big >> enough to handle the crowd for plenary and breakout sessions. I hosted >> one at BBN, and learned that it is a very bad idea to host a large >> meeting in a newly renovated building with lots of free rooms and space, >> but without first testing to make sure the brand-new sparkling bathrooms >> actually worked. >> >> The logistics of the quarterly meetings were becoming a serious >> problem. Then Dan stepped in. >> >> Instead of a meeting where ARPA and some benefactor host venue paid the >> costs and necessarily severely limited attendance, Dan rented (I assume >> it wasn't free!) a hotel, opened up a "ticket booth" to the masses, >> charged attendees a fee that didn't raise too many bean-counters' >> alarms, and added a show floor for vendors too, for an appropriate fee >> of course. He also recruited many of the people who used to just >> attend the quarterly Internet project meetings to provide the >> entertainment for all the attendees, and called it training and program >> presentations. >> >> Not a bad solution to the problem, eh? >> >> I recall at first there was just a room with some tables and a handful >> of vendors showing their wares. That turned pretty quickly into a trade >> show floor in Santa Clara, expanding into Moscone, and before long >> heading to Vegas when Moscone was just too small. >> >> All of this had the overriding mandate that there would be a strong >> technical focus, a live network, and vendors had to connect their stuff >> to it. For a few years, I was on the Interop "Program Committee", which >> met around a big table to decide which papers would be put into the >> program. It was common to look at a paper, see who was the author, and >> if there was even a hint of "marketing" present, it quickly went to the >> reject pile. Sometimes all it took was a look at the authors' titles. >> >> I remember a meeting where Dan took a few of us to Moscone, to meet with >> the powers-that-be about possibly holding Interop there. They were >> cordial, but IMHO clearly thought this event-they-never-heard-of didn't >> belong in Moscone. A year later, after blowing out Santa Clara, they >> were much more receptive. Doing the "MazeWar" throughout the Interop >> show floor was ... interesting. I checked in to my hotel room on Sunday >> at noon, and didn't get back until Tuesday night. After a few years in >> Moscone, it had become too small for Interop, so it was off to Vegas. >> >> Fun times. Interop was, IMHO, critical to getting the Internet out into >> the real world. Nobody else showed products actually working, and that >> matters to the people who approve the POs. >> >> But it's a good thing Dan didn't have more of the used-car-salesman >> genes. Otherwise we would have all left Interop each year with a new >> vehicle. Internet-ready, of course. >> >> You were wrong, Dan. IMHO, you could have gotten more than 50%.... >> >> /Jack Haverty >> >> >> >> >>> On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: >>> Craig, I think you did not copy the list. And while I?m at it, a small edit. I paid the tutors 15% , a full 50% more than the competition. I also charged everybody 50% more than the competition because I felt it was worth it! I even charged the vendors 50% more than the competition. I turned out that I was right. >>> >>> Dan >>> >>> Cell 650-776-7313 >>> >>> Begin forwarded message: >>> >>>> From: Craig Partridge >>>> Date: September 8, 2020 at 1:14:05 PM PDT >>>> To: Dan Lynch >>>> Cc: Craig Partridge via Internet-history >>>> Subject: Re: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) >>>> >>>> ? >>>> Dan was kind enough to mention me, which makes it a little harder to send this note but I'll do it anyway. >>>> >>>> I think Dan underplays how radical Interop was. Vendors had to connect their equipment to the show network. There was a team of Internet wizards who helped setup the show network for each show. (I recall stories of laying things out on netting in a warehouse so that it could easily be transferred to the show floor). But it meant products actually worked. >>>> >>>> And then there was the education component, which as Dan tells, started things. Dan took the view that he tried to hire the top instructors in the field and compensate them properly. At a time when competitors were paying 10% of the gross or $2K, whichever was less, Dan paid $2K or 10% of the gross, whichever was more. That meant Interop's courses, instead of being taught by a grad student or a professor trying out a new course idea, were taught by folks like Doug Comer and Scott Bradner and Radia Perlman, teaching their areas of expertise. As a result, the educational program was immense -- many thousands of students. And because the instructors were already in town, Dan could recruit us to come do a panel session for the main program as well. The panels were often also huge. (I still remember a session I led that included Dave Clark and a couple of other key folks -- the room was packed -- probably 5,000 people -- and was so jammed that someone stepped on the tablecloth for the projector, dumping all our slides [this was pre-Powerpoint real-time projection] on the floor! So I had to talk w/o slides while the other speakers ran to the back to reinsert their slides!). >>>> >>>> Attending Interop was a full week affair -- you got trained and then went to the showfloor and conference sessions, while grabbing a handful of the old Doubletree cookies (twice the size they are today) during the breaks. >>>> >>>> The transitions in size were wild. We went from Monterrey, to the Santa Clara TechMart, to the San Jose Convention center to the Moscone Center in SF in rapid succession. >>>> >>>> Craig >>>> >>>>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history wrote: >>>>> SoJack, you are asking me to recount how Interop came to be. I shall do that as quickly as I can here. >>>>> >>>>> In the early 80s I was at ISI in charge of the computer facility. After a year or so there came to be a term New Computing Environment to describe the advent of personal computers and the death of timesharing! I think Keith Uncapher coined the term, tho maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward a few years and I was back in Silicon Valley looking to start a company like my pals at Stanford had been doing. I looked around and noticed that the Internet was gaining traction but the nascent companies had not quite got it right. So I convinced Barry Leiner who was a program manager there in 85/86 to let me convene a 3 day workshop on TCP/IP protocols to explain them to the hundred or so implementation teams out there. I got the actual protocol designers to come to Monterrey California for 3 days. There was no company name then. I had no idea where this was going then. Needless to say the event was a success. The researchers learned of real life problems the early vendors we?re experiencing and the vendors learned a lot more about the Internet and what worked and what still needed further steps. >>>>> >>>>> I now had a business of teaching (through others) the vendors and advanced customers how the Internet works. I needed a name. I took the old name above and called it Advanced Computing Environment. >>>>> >>>>> A few years in to this the world really wanted to see working systems and I decided to try a trade show, with one critical addition: the systems had to be connected to an actual working Internet! And while I was on the phone with one of my brilliant tutor people from BBN, Craig Partridge, as were were concluding the call he blurted out ?I?ll see you at Interop ?. I hung up the phone and called my lawyer to register the name immediately! I had been calling it The TCP/IP Interoperability Conference and Exhibition! Ah, simplicity. >>>>> >>>>> That was in September of 1988. It had 50 vendors and 5000 attendees. In 1990 it had grown to 200 vendors and 30,000 attendees. Clearly this Internet stuff was catching on, eh? >>>>> >>>>> So I sold the company and stayed on for 5 more years as the PR guy and growing it into Europe and Asia. >>>>> >>>>> 30 years later it still exists in about 10 locations I. The world. Not quite the same, but still stressing interoperability. >>>>> >>>>> Thanks for asking, Jack. >>>>> >>>>> >>>>> >>>>> Dan >>>>> >>>>> Cell 650-776-7313 >>>>> >>>>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history wrote: >>>>>> >>>>>> ?Thanks Dan! >>>>>> >>>>>> There's so much of the history that didn't get recorded in RFCs and >>>>>> such, and mail list archives from that era are rare. We weren't very >>>>>> good about documenting things, especially the "why" of how decisions >>>>>> were made. >>>>>> >>>>>> There's plenty of room for more participation! Perhaps you can provide >>>>>> the story behind this artifact of the early Internet? >>>>>> >>>>>> ACE Coaster >>>>>> >>>>>> That coaster has been sitting on my desk for close to 40 years. The >>>>>> lettering is fading, after too many attacks by marauding coffee mugs >>>>>> over the decades, and a few trips to the floor courtesy of a roaming cat. >>>>>> >>>>>> The story of ACE, and Interop which followed, is an important part of >>>>>> Internet history. There tends to be a focus on protocols and >>>>>> algorithms, but innovations like Interop were, IMHO, equally important >>>>>> to the success of the Internet by making it accessible to the masses and >>>>>> emphasizing the importance of working systems. >>>>>> >>>>>> Perhaps more important. Tell us the story. >>>>>> >>>>>> /Jack >>>>>> >>>>>> >>>>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >>>>>>> Forgot to copy the fantastic list! >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> Cell 650-776-7313 >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> From: Dan Lynch >>>>>>>> Date: September 5, 2020 at 11:42:36 AM PDT >>>>>>>> To: Joseph Touch >>>>>>>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) >>>>>>>> >>>>>>>> ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> Cell 650-776-7313 >>>>>>>> >>>>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >>>>>>>>> >>>>>>>>> ?HI, all, >>>>>>>>> >>>>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>>>>>>>>> >>>>>>>>>>>> From: Joseph Touch >>>>>>>>>>> FYI - we moved the archives here. >>>>>>>>>> I've just noticed that the archives are now only accessible to list members? >>>>>>>>> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >>>>>>>>> >>>>>>>>> Please let me know if you continue to find otherwise. >>>>>>>>> >>>>>>>>> Joe (as list admin) >>>>>>>>> -- >>>>>>>>> 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 >>>> -- >>>> ***** >>>> 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 Thu Sep 10 11:51:55 2020 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 10 Sep 2020 11:51:55 -0700 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <1565057141.824958.1599762436842@mail.yahoo.com> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> <1565057141.824958.1599762436842@mail.yahoo.com> Message-ID: <8d3a9ab5-a769-ab77-5bb1-597fa4fd3bfb@3kitty.org> I'll take a look, it easily could have been at SRI.? BTW, when I say "meeting" it wasn't necessarily some formal session.? We had lots of informal impromptu "meetings". ? I vaguely remember that there was some restaurant near SRI that was popular where people used to gather.? Something to do with a train station; the tracks were right next to the building.?? Also a pancake/breakfast venue -- maybe "Ken's". /Jack? On 9/10/20 11:27 AM, Barbara Denny via Internet-history wrote: > Could that meeting have been at SRI? I have a memory of listening to a discussion regarding the creation of the IETF and the IRTF.? I could be wrong about this maybe being the meeting where it happened but I thought it might help you if you look through your notes.? > barbara? > On Thursday, September 10, 2020, 11:11:55 AM PDT, Jack Haverty via Internet-history wrote: > > Hi Vint, > > I concur that the genesis of TCP was in 1973, and spawned a collection > of separate projects, e.g., Packet Radio, Atlantic Satellite, etc.? > which along with the ARPANET were forming the core of what we now call > Internet. > > What I was remembering is that the moniker "Internet Project" didn't > become permanent until the later 70s, with "internet" replacing the > earlier term "catenet", as described in 1978 in: > > http://catenet.org/index.php/IEN_48_-_THE_CATENET_MODEL_FOR_INTERNETWORKING > > I recall some meeting, probably 1978/9, where there was a discussion of > what to call our new conglomeration of networks.? The term "catenet" was > proposed, but the general feeling was that it would cause people to > envision herds of cats, and the term "internet" achieved the "rough > consensus" stage as the best candidate for a name.? We already had > running code! > > The ICCB/IAB was also a key element of history, especially as the > creator of the IETF and IRTF.? Somewhere I have my notes of the ICCB (or > was it IAB by then...?) meeting where that happened. > > Pandemics provide rare opportunities to dig through old boxes in the > basement... > > /Jack > > On 9/10/20 2:55 AM, vinton cerf wrote: >> >> On Thu, Sep 10, 2020 at 12:22 AM Jack Haverty via Internet-history >> > > wrote: >> >> ? ? That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen >> ? ? or so >> ? ? people) meeting that Dan called, I think to mostly bounce off ideas >> ? ? about a training/conference company.?? Again IIRC this happened >> ? ? somewhat >> ? ? before the first actual conference in Monterey, where Dan subsequently >> ? ? stole the Internet using chocolate-chip cookies as bribes.?? Vint >> ? ? never >> ? ? served such cookies! >> >> no, but I did offer champagne for winners of the TCP/IP Hackathons.? >> >> >> ? ? >From my retro-perspective, it was an interesting progression of >> ? ? events.?? >> >> ? ? The ARPA "Internet Project" had started in the late 70s with a >> ? ? somewhat >> >> no, it started in 1973.? >> >> ? ? disjoint set of network-building projects, and had congealed into a >> ? ? network community, with quarterly meetings.? >> >> ? ? At first, the "TCP Working Group" and the "Internet Working Group" met >> ? ? separately.? Quickly we noticed that the TCP group kept coming up with >> ? ? changes to the IP header, while the IP group saw things that needed to >> ? ? be in the TCP header, and everyone in one group wanted to >> ? ? participate in >> ? ? the other, so "layering" was cast aside and the Internet Project as a >> ? ? single group was born. >> >> ? ? Over a year or two of such quarterly meetings, the size of the >> ? ? membership kept growing, and people had to plead with Vint for a >> ? ? "ticket" to attend.?? >> >> ? ? It had become difficult to find a willing host that had a venue big >> ? ? enough to handle the crowd for plenary and breakout sessions.?? I >> ? ? hosted >> ? ? one at BBN, and learned that it is a very bad idea to host a large >> ? ? meeting in a newly renovated building with lots of free rooms and >> ? ? space, >> ? ? but without first testing to make sure the brand-new sparkling >> ? ? bathrooms >> ? ? actually worked. >> >> ? ? The logistics of the quarterly meetings were becoming a serious >> ? ? problem.?? Then Dan stepped in. >> >> ? ? Instead of a meeting where ARPA and some benefactor host venue >> ? ? paid the >> ? ? costs and necessarily severely limited attendance, Dan rented (I >> ? ? assume >> ? ? it wasn't free!) a hotel, opened up a "ticket booth" to the masses, >> >> This is only half correct. Dan indeed opened Internet up to the public >> but as I recall, the Internet research program continued in parallel. >> The Internet Configuration Control Board (1979) morphed into the >> Internet Advisory Board in 1984 with 10 Task Forces after Barry Leiner >> took over >> the ?program management of the Internet Project at DARPA. In 1986, IAB? >> become the Internet Activities Board under Dennis Perry's program >> management >> at DARPA. see?https://www.iab.org/about/history/IAB and IETF and IRTF >> continue as >> does INTEROP after its sale by Dan Lynch to Masayoshi Son (when?) >> >> ? ? charged attendees a fee that didn't raise too many bean-counters' >> ? ? alarms, and added a show floor for vendors too, for an appropriate fee >> ? ? of course.?? He also recruited many of the people who used to just >> ? ? attend the quarterly Internet project meetings to provide the >> ? ? entertainment for all the attendees, and called it training and >> ? ? program >> ? ? presentations. >> >> ? ? Not a bad solution to the problem, eh??? >> >> ? ? I recall at first there was just a room with some tables and a handful >> ? ? of vendors showing their wares.? That turned pretty quickly into a >> ? ? trade >> ? ? show floor in Santa Clara, expanding into Moscone, and before long >> ? ? heading to Vegas when Moscone was just too small. >> >> ? ? All of this had the overriding mandate that there would be a strong >> ? ? technical focus, a live network, and vendors had to connect their >> ? ? stuff >> ? ? to it.? For a few years, I was on the Interop "Program Committee", >> ? ? which >> ? ? met around a big table to decide which papers would be put into the >> ? ? program.? It was common to look at a paper, see who was the >> ? ? author, and >> ? ? if there was even a hint of "marketing" present, it quickly went >> ? ? to the >> ? ? reject pile.?? Sometimes all it took was a look at the authors' >> ? ? titles. >> >> ? ? I remember a meeting where Dan took a few of us to Moscone, to >> ? ? meet with >> ? ? the powers-that-be about possibly holding Interop there.? They were >> ? ? cordial, but IMHO clearly thought this event-they-never-heard-of >> ? ? didn't >> ? ? belong in Moscone.? A year later, after blowing out Santa Clara, they >> ? ? were much more receptive.? Doing the "MazeWar" throughout the Interop >> ? ? show floor was ... interesting.? I checked in to my hotel room on >> ? ? Sunday >> ? ? at noon, and didn't get back until Tuesday night.?? After a few >> ? ? years in >> ? ? Moscone, it had become too small for Interop, so it was off to Vegas. >> >> ? ? Fun times.? Interop was, IMHO, critical to getting the Internet >> ? ? out into >> ? ? the real world.? Nobody else showed products actually working, and >> ? ? that >> ? ? matters to the people who approve the POs. >> >> ? ? But it's a good thing Dan didn't have more of the used-car-salesman >> ? ? genes.? Otherwise we would have all left Interop each year with a new >> ? ? vehicle.? Internet-ready, of course. >> >> ? ? You were wrong, Dan. IMHO, you could have gotten more than 50%.... >> >> ? ? /Jack Haverty >> >> >> >> >> ? ? On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: >> ? ? > Craig, I think you did not copy the list.? And while I?m at it, >> ? ? a small edit.? I paid the tutors 15% , a full 50% more than the >> ? ? competition. I also charged everybody 50% more than the >> ? ? competition because I felt it was worth it!? I even charged the >> ? ? vendors 50% more than the competition. I turned out that I was right. >> ? ? > >> ? ? > Dan >> ? ? > >> ? ? > Cell 650-776-7313 >> ? ? > >> ? ? > Begin forwarded message: >> ? ? > >> ? ? >> From: Craig Partridge > ? ? > >> ? ? >> Date: September 8, 2020 at 1:14:05 PM PDT >> ? ? >> To: Dan Lynch > >> ? ? >> Cc: Craig Partridge via Internet-history >> ? ? > ? ? > >> ? ? >> Subject: Re:? [ih] Fwd: List archives (Was: Exterior Gateway >> ? ? Protocol) >> ? ? >> >> ? ? >> ? >> ? ? >> Dan was kind enough to mention me, which makes it a little >> ? ? harder to send this note but I'll do it anyway. >> ? ? >> >> ? ? >> I think Dan underplays how radical Interop was.? Vendors had to >> ? ? connect their equipment to the show network.? There was a team of >> ? ? Internet wizards who helped setup the show network for each show.? >> ? ? (I recall stories of laying things out on netting in a warehouse >> ? ? so that it could easily be transferred to the show floor).? But it >> ? ? meant products actually worked. >> ? ? >> >> ? ? >> And then there was the education component, which as Dan tells, >> ? ? started things.? Dan took the view that he tried to hire the top >> ? ? instructors in the field and compensate them properly. At a time >> ? ? when competitors were paying 10% of the gross or $2K, whichever >> ? ? was less, Dan paid $2K or 10% of the gross, whichever was more.? >> ? ? That meant Interop's courses, instead of being taught by a grad >> ? ? student or a professor trying out a new course idea, were taught >> ? ? by folks like Doug Comer and Scott Bradner and Radia Perlman, >> ? ? teaching their areas of expertise.? As a result, the educational >> ? ? program was immense -- many thousands of students.? And because >> ? ? the instructors were already in town, Dan could recruit us to come >> ? ? do a panel session for the main program as well.? The panels were >> ? ? often also huge.? (I still remember a session I led that included >> ? ? Dave Clark and a couple of other key folks -- the room was packed >> ? ? -- probably 5,000 people -- and was so jammed that someone stepped >> ? ? on the tablecloth for the projector, dumping all our slides [this >> ? ? was pre-Powerpoint real-time projection] on the floor!? So I had >> ? ? to talk w/o slides while the other speakers ran to the back to >> ? ? reinsert their slides!). >> ? ? >> >> ? ? >> Attending Interop was a full week affair -- you got trained and >> ? ? then went to the showfloor and conference sessions, while grabbing >> ? ? a handful of the old Doubletree cookies (twice the size they are >> ? ? today) during the breaks. >> ? ? >> >> ? ? >> The transitions in size were wild.? We went from Monterrey, to >> ? ? the Santa Clara TechMart, to the San Jose Convention center to the >> ? ? Moscone Center in SF in rapid succession. >> ? ? >> >> ? ? >> Craig >> ? ? >> >> ? ? >>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history >> ? ? > ? ? > wrote: >> ? ? >>> SoJack, you are asking me to recount how Interop came to be. I >> ? ? shall do that as quickly as I can here. >> ? ? >>> >> ? ? >>> In the early 80s I was at ISI in charge of the computer >> ? ? facility. After a year or so there came to be a term New Computing >> ? ? Environment to describe the advent of personal computers and the >> ? ? death of timesharing!? I think Keith Uncapher coined the term, tho >> ? ? maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward >> ? ? a few years and I was back in Silicon Valley looking to start a >> ? ? company like my pals at Stanford had been doing. I looked around >> ? ? and noticed that the Internet was gaining traction but the nascent >> ? ? companies had not quite got it right. So I convinced Barry Leiner >> ? ? who was a program manager there in 85/86 to let me convene a 3 day >> ? ? workshop on TCP/IP protocols to explain them to the hundred or so >> ? ? implementation teams out there. I got the actual protocol >> ? ? designers to come to Monterrey California for 3 days. There was no >> ? ? company name then. I had no idea where this was going then. >> ? ? Needless to say the event was a success. The researchers learned >> ? ? of real life problems the early vendors we?re experiencing and the >> ? ? vendors learned a lot more about the Internet and what worked and >> ? ? what still needed further steps. >> ? ? >>> >> ? ? >>> I now had a business of teaching (through others) the vendors >> ? ? and advanced customers how the Internet works. I needed a name. I >> ? ? took the old name above and called it Advanced Computing Environment. >> ? ? >>> >> ? ? >>> A few years in to this the world really wanted to see working >> ? ? systems and I decided to try a trade show, with one critical >> ? ? addition: the systems had to be connected to an actual working >> ? ? Internet!? And while I was on the phone with one of my brilliant >> ? ? tutor people from BBN, Craig Partridge, as were were concluding >> ? ? the call he blurted out ?I?ll see you at Interop ?. I hung up the >> ? ? phone and called my lawyer to register the name immediately!? I >> ? ? had been calling it The TCP/IP Interoperability Conference and >> ? ? Exhibition!? Ah, simplicity. >> ? ? >>> >> ? ? >>> That was in September of 1988. It had 50 vendors and 5000 >> ? ? attendees. In 1990 it had grown to 200 vendors and 30,000 >> ? ? attendees. Clearly this Internet stuff was catching on, eh?? >> ? ? >>> >> ? ? >>> So I sold the company and stayed on for 5 more years as the PR >> ? ? guy and growing it into Europe and Asia. >> ? ? >>> >> ? ? >>> 30 years later it still exists in about 10 locations I. The >> ? ? world. Not quite the same, but still stressing interoperability. >> ? ? >>> >> ? ? >>> Thanks for asking, Jack. >> ? ? >>> >> ? ? >>> >> ? ? >>> >> ? ? >>> Dan >> ? ? >>> >> ? ? >>> Cell 650-776-7313 >> ? ? >>> >> ? ? >>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history >> ? ? > ? ? > wrote: >> ? ? >>>> >> ? ? >>>> ?Thanks Dan! >> ? ? >>>> >> ? ? >>>> There's so much of the history that didn't get recorded in >> ? ? RFCs and >> ? ? >>>> such, and mail list archives from that era are rare.? We >> ? ? weren't very >> ? ? >>>> good about documenting things, especially the "why" of how >> ? ? decisions >> ? ? >>>> were made. >> ? ? >>>> >> ? ? >>>> There's plenty of room for more participation!? ?Perhaps you >> ? ? can provide >> ? ? >>>> the story behind this artifact of the early Internet? >> ? ? >>>> >> ? ? >>>> ACE Coaster >> ? ? >>>> >> ? ? >>>> That coaster has been sitting on my desk for close to 40 >> ? ? years.? The >> ? ? >>>> lettering is fading, after too many attacks by marauding >> ? ? coffee mugs >> ? ? >>>> over the decades, and a few trips to the floor courtesy of a >> ? ? roaming cat. >> ? ? >>>> >> ? ? >>>> The story of ACE, and Interop which followed, is an important >> ? ? part of >> ? ? >>>> Internet history.? There tends to be a focus on protocols and >> ? ? >>>> algorithms, but innovations like Interop were, IMHO, equally >> ? ? important >> ? ? >>>> to the success of the Internet by making it accessible to the >> ? ? masses and >> ? ? >>>> emphasizing the importance of working systems. >> ? ? >>>> >> ? ? >>>> Perhaps more important.? ?Tell us the story. >> ? ? >>>> >> ? ? >>>> /Jack >> ? ? >>>> >> ? ? >>>> >> ? ? >>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >> ? ? >>>>> Forgot to copy the fantastic list! >> ? ? >>>>> >> ? ? >>>>> Dan >> ? ? >>>>> >> ? ? >>>>> Cell 650-776-7313 >> ? ? >>>>> >> ? ? >>>>> Begin forwarded message: >> ? ? >>>>> >> ? ? >>>>>> From: Dan Lynch > >> ? ? >>>>>> Date: September 5, 2020 at 11:42:36 AM PDT >> ? ? >>>>>> To: Joseph Touch > ? ? > >> ? ? >>>>>> Subject: Re:? [ih] List archives (Was: Exterior Gateway >> ? ? Protocol) >> ? ? >>>>>> >> ? ? >>>>>> ?Great!? These discussions are amazing, considering that >> ? ? they are being done by the actual inventors of much of the >> ? ? Internet some 3 or 4 decades later. We were young then, eh?? Of >> ? ? course they must be open to the world. Thank you Noel, Miles, >> ? ? Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >> ? ? >>>>>> >> ? ? >>>>>> Dan >> ? ? >>>>>> >> ? ? >>>>>> Cell 650-776-7313 >> ? ? >>>>>> >> ? ? >>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via >> ? ? Internet-history > ? ? > wrote: >> ? ? >>>>>>> >> ? ? >>>>>>> ?HI, all, >> ? ? >>>>>>> >> ? ? >>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via >> ? ? Internet-history > ? ? > wrote: >> ? ? >>>>>>>>>> >> ? ? >>>>>>>>>> From: Joseph Touch >> ? ? >>>>>>>>> FYI - we moved the archives here. >> ? ? >>>>>>>> I've just noticed that the archives are now only >> ? ? accessible to list members? >> ? ? >>>>>>> They should have been open. If anything changed recently, >> ? ? this is the first I heard. Either way, the setting has been >> ? ? updated to allow public access. >> ? ? >>>>>>> >> ? ? >>>>>>> Please let me know if you continue to find otherwise. >> ? ? >>>>>>> >> ? ? >>>>>>> Joe (as list admin) >> ? ? >>>>>>> -- >> ? ? >>>>>>> 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 >> ? ? >> >> ? ? >> -- >> ? ? >> ***** >> ? ? >> 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 b_a_denny at yahoo.com Thu Sep 10 13:02:01 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Thu, 10 Sep 2020 20:02:01 +0000 (UTC) Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <8d3a9ab5-a769-ab77-5bb1-597fa4fd3bfb@3kitty.org> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> <1565057141.824958.1599762436842@mail.yahoo.com> <8d3a9ab5-a769-ab77-5bb1-597fa4fd3bfb@3kitty.org> Message-ID: <1898540920.884265.1599768121777@mail.yahoo.com> Late For the Train was the restaurant.? It had wonderful blintzes. I got introduced to it when I was still working at BBN. There was a packet radio meeting at SRI and the BBN contingent wanted to eat there. Unfortunately it closed years ago. barbara On Thursday, September 10, 2020, 12:52:26 PM PDT, Jack Haverty via Internet-history wrote: I'll take a look, it easily could have been at SRI.? BTW, when I say "meeting" it wasn't necessarily some formal session.? We had lots of informal impromptu "meetings". ? I vaguely remember that there was some restaurant near SRI that was popular where people used to gather.? Something to do with a train station; the tracks were right next to the building.?? Also a pancake/breakfast venue -- maybe "Ken's". /Jack? On 9/10/20 11:27 AM, Barbara Denny via Internet-history wrote: >? Could that meeting have been at SRI? I have a memory of listening to a discussion regarding the creation of the IETF and the IRTF.? I could be wrong about this maybe being the meeting where it happened but I thought it might help you if you look through your notes.? > barbara? >? ? On Thursday, September 10, 2020, 11:11:55 AM PDT, Jack Haverty via Internet-history wrote:? >? >? Hi Vint, > > I concur that the genesis of TCP was in 1973, and spawned a collection > of separate projects, e.g., Packet Radio, Atlantic Satellite, etc.? > which along with the ARPANET were forming the core of what we now call > Internet. > > What I was remembering is that the moniker "Internet Project" didn't > become permanent until the later 70s, with "internet" replacing the > earlier term "catenet", as described in 1978 in: > > http://catenet.org/index.php/IEN_48_-_THE_CATENET_MODEL_FOR_INTERNETWORKING > > I recall some meeting, probably 1978/9, where there was a discussion of > what to call our new conglomeration of networks.? The term "catenet" was > proposed, but the general feeling was that it would cause people to > envision herds of cats, and the term "internet" achieved the "rough > consensus" stage as the best candidate for a name.? We already had > running code! > > The ICCB/IAB was also a key element of history, especially as the > creator of the IETF and IRTF.? Somewhere I have my notes of the ICCB (or > was it IAB by then...?) meeting where that happened. > > Pandemics provide rare opportunities to dig through old boxes in the > basement... > > /Jack > > On 9/10/20 2:55 AM, vinton cerf wrote: >> >> On Thu, Sep 10, 2020 at 12:22 AM Jack Haverty via Internet-history >> > > wrote: >> >> ? ? That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen >> ? ? or so >> ? ? people) meeting that Dan called, I think to mostly bounce off ideas >> ? ? about a training/conference company.?? Again IIRC this happened >> ? ? somewhat >> ? ? before the first actual conference in Monterey, where Dan subsequently >> ? ? stole the Internet using chocolate-chip cookies as bribes.?? Vint >> ? ? never >> ? ? served such cookies! >> >> no, but I did offer champagne for winners of the TCP/IP Hackathons.? >> >> >> ? ? >From my retro-perspective, it was an interesting progression of >> ? ? events.?? >> >> ? ? The ARPA "Internet Project" had started in the late 70s with a >> ? ? somewhat >> >> no, it started in 1973.? >> >> ? ? disjoint set of network-building projects, and had congealed into a >> ? ? network community, with quarterly meetings.? >> >> ? ? At first, the "TCP Working Group" and the "Internet Working Group" met >> ? ? separately.? Quickly we noticed that the TCP group kept coming up with >> ? ? changes to the IP header, while the IP group saw things that needed to >> ? ? be in the TCP header, and everyone in one group wanted to >> ? ? participate in >> ? ? the other, so "layering" was cast aside and the Internet Project as a >> ? ? single group was born. >> >> ? ? Over a year or two of such quarterly meetings, the size of the >> ? ? membership kept growing, and people had to plead with Vint for a >> ? ? "ticket" to attend.?? >> >> ? ? It had become difficult to find a willing host that had a venue big >> ? ? enough to handle the crowd for plenary and breakout sessions.?? I >> ? ? hosted >> ? ? one at BBN, and learned that it is a very bad idea to host a large >> ? ? meeting in a newly renovated building with lots of free rooms and >> ? ? space, >> ? ? but without first testing to make sure the brand-new sparkling >> ? ? bathrooms >> ? ? actually worked. >> >> ? ? The logistics of the quarterly meetings were becoming a serious >> ? ? problem.?? Then Dan stepped in. >> >> ? ? Instead of a meeting where ARPA and some benefactor host venue >> ? ? paid the >> ? ? costs and necessarily severely limited attendance, Dan rented (I >> ? ? assume >> ? ? it wasn't free!) a hotel, opened up a "ticket booth" to the masses, >> >> This is only half correct. Dan indeed opened Internet up to the public >> but as I recall, the Internet research program continued in parallel. >> The Internet Configuration Control Board (1979) morphed into the >> Internet Advisory Board in 1984 with 10 Task Forces after Barry Leiner >> took over >> the ?program management of the Internet Project at DARPA. In 1986, IAB? >> become the Internet Activities Board under Dennis Perry's program >> management >> at DARPA. see?https://www.iab.org/about/history/IAB and IETF and IRTF >> continue as >> does INTEROP after its sale by Dan Lynch to Masayoshi Son (when?) >> >> ? ? charged attendees a fee that didn't raise too many bean-counters' >> ? ? alarms, and added a show floor for vendors too, for an appropriate fee >> ? ? of course.?? He also recruited many of the people who used to just >> ? ? attend the quarterly Internet project meetings to provide the >> ? ? entertainment for all the attendees, and called it training and >> ? ? program >> ? ? presentations. >> >> ? ? Not a bad solution to the problem, eh??? >> >> ? ? I recall at first there was just a room with some tables and a handful >> ? ? of vendors showing their wares.? That turned pretty quickly into a >> ? ? trade >> ? ? show floor in Santa Clara, expanding into Moscone, and before long >> ? ? heading to Vegas when Moscone was just too small. >> >> ? ? All of this had the overriding mandate that there would be a strong >> ? ? technical focus, a live network, and vendors had to connect their >> ? ? stuff >> ? ? to it.? For a few years, I was on the Interop "Program Committee", >> ? ? which >> ? ? met around a big table to decide which papers would be put into the >> ? ? program.? It was common to look at a paper, see who was the >> ? ? author, and >> ? ? if there was even a hint of "marketing" present, it quickly went >> ? ? to the >> ? ? reject pile.?? Sometimes all it took was a look at the authors' >> ? ? titles. >> >> ? ? I remember a meeting where Dan took a few of us to Moscone, to >> ? ? meet with >> ? ? the powers-that-be about possibly holding Interop there.? They were >> ? ? cordial, but IMHO clearly thought this event-they-never-heard-of >> ? ? didn't >> ? ? belong in Moscone.? A year later, after blowing out Santa Clara, they >> ? ? were much more receptive.? Doing the "MazeWar" throughout the Interop >> ? ? show floor was ... interesting.? I checked in to my hotel room on >> ? ? Sunday >> ? ? at noon, and didn't get back until Tuesday night.?? After a few >> ? ? years in >> ? ? Moscone, it had become too small for Interop, so it was off to Vegas. >> >> ? ? Fun times.? Interop was, IMHO, critical to getting the Internet >> ? ? out into >> ? ? the real world.? Nobody else showed products actually working, and >> ? ? that >> ? ? matters to the people who approve the POs. >> >> ? ? But it's a good thing Dan didn't have more of the used-car-salesman >> ? ? genes.? Otherwise we would have all left Interop each year with a new >> ? ? vehicle.? Internet-ready, of course. >> >> ? ? You were wrong, Dan. IMHO, you could have gotten more than 50%.... >> >> ? ? /Jack Haverty >> >> >> >> >> ? ? On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: >> ? ? > Craig, I think you did not copy the list.? And while I?m at it, >> ? ? a small edit.? I paid the tutors 15% , a full 50% more than the >> ? ? competition. I also charged everybody 50% more than the >> ? ? competition because I felt it was worth it!? I even charged the >> ? ? vendors 50% more than the competition. I turned out that I was right. >> ? ? > >> ? ? > Dan >> ? ? > >> ? ? > Cell 650-776-7313 >> ? ? > >> ? ? > Begin forwarded message: >> ? ? > >> ? ? >> From: Craig Partridge > ? ? > >> ? ? >> Date: September 8, 2020 at 1:14:05 PM PDT >> ? ? >> To: Dan Lynch > >> ? ? >> Cc: Craig Partridge via Internet-history >> ? ? > ? ? > >> ? ? >> Subject: Re:? [ih] Fwd: List archives (Was: Exterior Gateway >> ? ? Protocol) >> ? ? >> >> ? ? >> ? >> ? ? >> Dan was kind enough to mention me, which makes it a little >> ? ? harder to send this note but I'll do it anyway. >> ? ? >> >> ? ? >> I think Dan underplays how radical Interop was.? Vendors had to >> ? ? connect their equipment to the show network.? There was a team of >> ? ? Internet wizards who helped setup the show network for each show.? >> ? ? (I recall stories of laying things out on netting in a warehouse >> ? ? so that it could easily be transferred to the show floor).? But it >> ? ? meant products actually worked. >> ? ? >> >> ? ? >> And then there was the education component, which as Dan tells, >> ? ? started things.? Dan took the view that he tried to hire the top >> ? ? instructors in the field and compensate them properly. At a time >> ? ? when competitors were paying 10% of the gross or $2K, whichever >> ? ? was less, Dan paid $2K or 10% of the gross, whichever was more.? >> ? ? That meant Interop's courses, instead of being taught by a grad >> ? ? student or a professor trying out a new course idea, were taught >> ? ? by folks like Doug Comer and Scott Bradner and Radia Perlman, >> ? ? teaching their areas of expertise.? As a result, the educational >> ? ? program was immense -- many thousands of students.? And because >> ? ? the instructors were already in town, Dan could recruit us to come >> ? ? do a panel session for the main program as well.? The panels were >> ? ? often also huge.? (I still remember a session I led that included >> ? ? Dave Clark and a couple of other key folks -- the room was packed >> ? ? -- probably 5,000 people -- and was so jammed that someone stepped >> ? ? on the tablecloth for the projector, dumping all our slides [this >> ? ? was pre-Powerpoint real-time projection] on the floor!? So I had >> ? ? to talk w/o slides while the other speakers ran to the back to >> ? ? reinsert their slides!). >> ? ? >> >> ? ? >> Attending Interop was a full week affair -- you got trained and >> ? ? then went to the showfloor and conference sessions, while grabbing >> ? ? a handful of the old Doubletree cookies (twice the size they are >> ? ? today) during the breaks. >> ? ? >> >> ? ? >> The transitions in size were wild.? We went from Monterrey, to >> ? ? the Santa Clara TechMart, to the San Jose Convention center to the >> ? ? Moscone Center in SF in rapid succession. >> ? ? >> >> ? ? >> Craig >> ? ? >> >> ? ? >>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history >> ? ? > ? ? > wrote: >> ? ? >>> SoJack, you are asking me to recount how Interop came to be. I >> ? ? shall do that as quickly as I can here. >> ? ? >>> >> ? ? >>> In the early 80s I was at ISI in charge of the computer >> ? ? facility. After a year or so there came to be a term New Computing >> ? ? Environment to describe the advent of personal computers and the >> ? ? death of timesharing!? I think Keith Uncapher coined the term, tho >> ? ? maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward >> ? ? a few years and I was back in Silicon Valley looking to start a >> ? ? company like my pals at Stanford had been doing. I looked around >> ? ? and noticed that the Internet was gaining traction but the nascent >> ? ? companies had not quite got it right. So I convinced Barry Leiner >> ? ? who was a program manager there in 85/86 to let me convene a 3 day >> ? ? workshop on TCP/IP protocols to explain them to the hundred or so >> ? ? implementation teams out there. I got the actual protocol >> ? ? designers to come to Monterrey California for 3 days. There was no >> ? ? company name then. I had no idea where this was going then. >> ? ? Needless to say the event was a success. The researchers learned >> ? ? of real life problems the early vendors we?re experiencing and the >> ? ? vendors learned a lot more about the Internet and what worked and >> ? ? what still needed further steps. >> ? ? >>> >> ? ? >>> I now had a business of teaching (through others) the vendors >> ? ? and advanced customers how the Internet works. I needed a name. I >> ? ? took the old name above and called it Advanced Computing Environment. >> ? ? >>> >> ? ? >>> A few years in to this the world really wanted to see working >> ? ? systems and I decided to try a trade show, with one critical >> ? ? addition: the systems had to be connected to an actual working >> ? ? Internet!? And while I was on the phone with one of my brilliant >> ? ? tutor people from BBN, Craig Partridge, as were were concluding >> ? ? the call he blurted out ?I?ll see you at Interop ?. I hung up the >> ? ? phone and called my lawyer to register the name immediately!? I >> ? ? had been calling it The TCP/IP Interoperability Conference and >> ? ? Exhibition!? Ah, simplicity. >> ? ? >>> >> ? ? >>> That was in September of 1988. It had 50 vendors and 5000 >> ? ? attendees. In 1990 it had grown to 200 vendors and 30,000 >> ? ? attendees. Clearly this Internet stuff was catching on, eh?? >> ? ? >>> >> ? ? >>> So I sold the company and stayed on for 5 more years as the PR >> ? ? guy and growing it into Europe and Asia. >> ? ? >>> >> ? ? >>> 30 years later it still exists in about 10 locations I. The >> ? ? world. Not quite the same, but still stressing interoperability. >> ? ? >>> >> ? ? >>> Thanks for asking, Jack. >> ? ? >>> >> ? ? >>> >> ? ? >>> >> ? ? >>> Dan >> ? ? >>> >> ? ? >>> Cell 650-776-7313 >> ? ? >>> >> ? ? >>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history >> ? ? > ? ? > wrote: >> ? ? >>>> >> ? ? >>>> ?Thanks Dan! >> ? ? >>>> >> ? ? >>>> There's so much of the history that didn't get recorded in >> ? ? RFCs and >> ? ? >>>> such, and mail list archives from that era are rare.? We >> ? ? weren't very >> ? ? >>>> good about documenting things, especially the "why" of how >> ? ? decisions >> ? ? >>>> were made. >> ? ? >>>> >> ? ? >>>> There's plenty of room for more participation!? ?Perhaps you >> ? ? can provide >> ? ? >>>> the story behind this artifact of the early Internet? >> ? ? >>>> >> ? ? >>>> ACE Coaster >> ? ? >>>> >> ? ? >>>> That coaster has been sitting on my desk for close to 40 >> ? ? years.? The >> ? ? >>>> lettering is fading, after too many attacks by marauding >> ? ? coffee mugs >> ? ? >>>> over the decades, and a few trips to the floor courtesy of a >> ? ? roaming cat. >> ? ? >>>> >> ? ? >>>> The story of ACE, and Interop which followed, is an important >> ? ? part of >> ? ? >>>> Internet history.? There tends to be a focus on protocols and >> ? ? >>>> algorithms, but innovations like Interop were, IMHO, equally >> ? ? important >> ? ? >>>> to the success of the Internet by making it accessible to the >> ? ? masses and >> ? ? >>>> emphasizing the importance of working systems. >> ? ? >>>> >> ? ? >>>> Perhaps more important.? ?Tell us the story. >> ? ? >>>> >> ? ? >>>> /Jack >> ? ? >>>> >> ? ? >>>> >> ? ? >>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >> ? ? >>>>> Forgot to copy the fantastic list! >> ? ? >>>>> >> ? ? >>>>> Dan >> ? ? >>>>> >> ? ? >>>>> Cell 650-776-7313 >> ? ? >>>>> >> ? ? >>>>> Begin forwarded message: >> ? ? >>>>> >> ? ? >>>>>> From: Dan Lynch > >> ? ? >>>>>> Date: September 5, 2020 at 11:42:36 AM PDT >> ? ? >>>>>> To: Joseph Touch > ? ? > >> ? ? >>>>>> Subject: Re:? [ih] List archives (Was: Exterior Gateway >> ? ? Protocol) >> ? ? >>>>>> >> ? ? >>>>>> ?Great!? These discussions are amazing, considering that >> ? ? they are being done by the actual inventors of much of the >> ? ? Internet some 3 or 4 decades later. We were young then, eh?? Of >> ? ? course they must be open to the world. Thank you Noel, Miles, >> ? ? Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >> ? ? >>>>>> >> ? ? >>>>>> Dan >> ? ? >>>>>> >> ? ? >>>>>> Cell 650-776-7313 >> ? ? >>>>>> >> ? ? >>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via >> ? ? Internet-history > ? ? > wrote: >> ? ? >>>>>>> >> ? ? >>>>>>> ?HI, all, >> ? ? >>>>>>> >> ? ? >>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via >> ? ? Internet-history > ? ? > wrote: >> ? ? >>>>>>>>>> >> ? ? >>>>>>>>>> From: Joseph Touch >> ? ? >>>>>>>>> FYI - we moved the archives here. >> ? ? >>>>>>>> I've just noticed that the archives are now only >> ? ? accessible to list members? >> ? ? >>>>>>> They should have been open. If anything changed recently, >> ? ? this is the first I heard. Either way, the setting has been >> ? ? updated to allow public access. >> ? ? >>>>>>> >> ? ? >>>>>>> Please let me know if you continue to find otherwise. >> ? ? >>>>>>> >> ? ? >>>>>>> Joe (as list admin) >> ? ? >>>>>>> -- >> ? ? >>>>>>> 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 >> ? ? >> >> ? ? >> -- >> ? ? >> ***** >> ? ? >> 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 jack at 3kitty.org Thu Sep 10 13:41:30 2020 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 10 Sep 2020 13:41:30 -0700 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> Message-ID: Hmmmmm.? I don't recall ever hearing the specific term "Internetting Project".? Was that an internal name used within ARPA? My recollection is that at the time (mid/late-70s), there were a number of efforts to interconnect networks, e.g., outside of ARPA, but using similar terminology such as "internet".?? There were multiple "internets" being developed, in addition to the one at ARPA. For example, I found, only about 7 years ago, some mid-70s BBN QTRs about the ARPANET project, which included some description of how to create an internet by interconnecting multiple IMP subnets.?? It showed diagrams of packet formats to be used in the internal IMP-IMP interactions, e.g., specifying a different IMP network to which a packet should be directed.?? No TCP/IP involved.? I never encountered any evidence that anything like that was implemented, but someone was thinking about it as a way to interconnect networks.?? This may have been after ARPA handed over the ARPANET to DCA. CCITT was working on X.25, and creating X.75, to interconnect their networks.? It was a natural evolution of the PTT's prior interconnection of their telephone networks.?? Later, as DDN marched down the X.25 path, the subsequent government Internet might have ended up based on X.25/X.75.?? If it worked. The IBM world also did internetting.? I don't know much about it, something to do with SNA and LU6.2.?? I remember though that we sent salespeople out to sell IMP networks, with optional Gateways to hook up their anticipated LANs.? After a few encounters with some "IBM Shops", the harassed salespeople told us that there was no way to sell "Gateways" into that marketplace.?? IBM had some "Gateway" product, and it had a horrible reputation for being unreliable; no one would consider buying anything that involved a "Gateway".?? So we started calling the TCP/IP boxes "Routers". The meeting I recall involved seeking a name for ARPA's TCP-based internet and the aggregate of the various projects involved in building it.? The term "internet" had many different meanings to different people, but "catenet" was too obscure, and it was too big a mental leap to grok it as "concatenated networks".?? So "internet" became "ARPA Internet" to distinguish it from other internets of the day.? Somewhat later, I suspect after NSF became a player, it evolved into "The Internet". There were many other internets over the years, e.g., Netware, Apple, Microsoft, Banyan, Xerox, DEC, OSI et al had their own internetting solutions.?? TCP/IP by then owned "The Internet", but for a while we had to suffer with multiprotocol routers and overlapping competing Internets (I had to help run one such beast in the 90s) until all the other solutions withered away. All this is IIRC, of course.... /Jack On 9/10/20 11:32 AM, Vint Cerf wrote: > 1. original project name: internetting > 2. rfc 675 first use of "internet" > 3. catenet used only once in ien #48 > > v > > On Thu, Sep 10, 2020 at 2:11 PM Jack Haverty via Internet-history > > wrote: > > Hi Vint, > > I concur that the genesis of TCP was in 1973, and spawned a collection > of separate projects, e.g., Packet Radio, Atlantic Satellite, etc.? > which along with the ARPANET were forming the core of what we now call > Internet. > > What I was remembering is that the moniker "Internet Project" didn't > become permanent until the later 70s, with "internet" replacing the > earlier term "catenet", as described in 1978 in: > > http://catenet.org/index.php/IEN_48_-_THE_CATENET_MODEL_FOR_INTERNETWORKING > > I recall some meeting, probably 1978/9, where there was a > discussion of > what to call our new conglomeration of networks.? The term > "catenet" was > proposed, but the general feeling was that it would cause people to > envision herds of cats, and the term "internet" achieved the "rough > consensus" stage as the best candidate for a name.? We already had > running code! > > The ICCB/IAB was also a key element of history, especially as the > creator of the IETF and IRTF.? Somewhere I have my notes of the > ICCB (or > was it IAB by then...?) meeting where that happened. > > Pandemics provide rare opportunities to dig through old boxes in the > basement... > > /Jack > > On 9/10/20 2:55 AM, vinton cerf wrote: > > > > > > On Thu, Sep 10, 2020 at 12:22 AM Jack Haverty via Internet-history > > > > >> wrote: > > > >? ? ?That "ACE Coaster" was handed out (by Dan, IIRC) at a small > (dozen > >? ? ?or so > >? ? ?people) meeting that Dan called, I think to mostly bounce > off ideas > >? ? ?about a training/conference company.?? Again IIRC this happened > >? ? ?somewhat > >? ? ?before the first actual conference in Monterey, where Dan > subsequently > >? ? ?stole the Internet using chocolate-chip cookies as bribes.?? > Vint > >? ? ?never > >? ? ?served such cookies! > > > > no, but I did offer champagne for winners of the TCP/IP Hackathons.? > > > > > >? ? ?>From my retro-perspective, it was an interesting progression of > >? ? ?events.?? > > > >? ? ?The ARPA "Internet Project" had started in the late 70s with a > >? ? ?somewhat > > > > no, it started in 1973.? > > > >? ? ?disjoint set of network-building projects, and had congealed > into a > >? ? ?network community, with quarterly meetings.? > > > >? ? ?At first, the "TCP Working Group" and the "Internet Working > Group" met > >? ? ?separately.? Quickly we noticed that the TCP group kept > coming up with > >? ? ?changes to the IP header, while the IP group saw things that > needed to > >? ? ?be in the TCP header, and everyone in one group wanted to > >? ? ?participate in > >? ? ?the other, so "layering" was cast aside and the Internet > Project as a > >? ? ?single group was born. > > > >? ? ?Over a year or two of such quarterly meetings, the size of the > >? ? ?membership kept growing, and people had to plead with Vint for a > >? ? ?"ticket" to attend.?? > > > >? ? ?It had become difficult to find a willing host that had a > venue big > >? ? ?enough to handle the crowd for plenary and breakout > sessions.?? I > >? ? ?hosted > >? ? ?one at BBN, and learned that it is a very bad idea to host a > large > >? ? ?meeting in a newly renovated building with lots of free > rooms and > >? ? ?space, > >? ? ?but without first testing to make sure the brand-new sparkling > >? ? ?bathrooms > >? ? ?actually worked. > > > >? ? ?The logistics of the quarterly meetings were becoming a serious > >? ? ?problem.?? Then Dan stepped in. > > > >? ? ?Instead of a meeting where ARPA and some benefactor host venue > >? ? ?paid the > >? ? ?costs and necessarily severely limited attendance, Dan rented (I > >? ? ?assume > >? ? ?it wasn't free!) a hotel, opened up a "ticket booth" to the > masses, > > > > This is only half correct. Dan indeed opened Internet up to the > public > > but as I recall, the Internet research program continued in > parallel. > > The Internet Configuration Control Board (1979) morphed into the > > Internet Advisory Board in 1984 with 10 Task Forces after Barry > Leiner > > took over > > the ?program management of the Internet Project at DARPA. In > 1986, IAB? > > become the Internet Activities Board under Dennis Perry's program > > management > > at DARPA. see?https://www.iab.org/about/history/IAB and IETF and > IRTF > > continue as > > does INTEROP after its sale by Dan Lynch to Masayoshi Son (when?) > > > >? ? ?charged attendees a fee that didn't raise too many > bean-counters' > >? ? ?alarms, and added a show floor for vendors too, for an > appropriate fee > >? ? ?of course.?? He also recruited many of the people who used > to just > >? ? ?attend the quarterly Internet project meetings to provide the > >? ? ?entertainment for all the attendees, and called it training and > >? ? ?program > >? ? ?presentations. > > > >? ? ?Not a bad solution to the problem, eh??? > > > >? ? ?I recall at first there was just a room with some tables and > a handful > >? ? ?of vendors showing their wares.? That turned pretty quickly > into a > >? ? ?trade > >? ? ?show floor in Santa Clara, expanding into Moscone, and > before long > >? ? ?heading to Vegas when Moscone was just too small. > > > >? ? ?All of this had the overriding mandate that there would be a > strong > >? ? ?technical focus, a live network, and vendors had to connect > their > >? ? ?stuff > >? ? ?to it.? For a few years, I was on the Interop "Program > Committee", > >? ? ?which > >? ? ?met around a big table to decide which papers would be put > into the > >? ? ?program.? It was common to look at a paper, see who was the > >? ? ?author, and > >? ? ?if there was even a hint of "marketing" present, it quickly went > >? ? ?to the > >? ? ?reject pile.?? Sometimes all it took was a look at the authors' > >? ? ?titles. > > > >? ? ?I remember a meeting where Dan took a few of us to Moscone, to > >? ? ?meet with > >? ? ?the powers-that-be about possibly holding Interop there.? > They were > >? ? ?cordial, but IMHO clearly thought this event-they-never-heard-of > >? ? ?didn't > >? ? ?belong in Moscone.? A year later, after blowing out Santa > Clara, they > >? ? ?were much more receptive.? Doing the "MazeWar" throughout > the Interop > >? ? ?show floor was ... interesting.? I checked in to my hotel > room on > >? ? ?Sunday > >? ? ?at noon, and didn't get back until Tuesday night.?? After a few > >? ? ?years in > >? ? ?Moscone, it had become too small for Interop, so it was off > to Vegas. > > > >? ? ?Fun times.? Interop was, IMHO, critical to getting the Internet > >? ? ?out into > >? ? ?the real world.? Nobody else showed products actually > working, and > >? ? ?that > >? ? ?matters to the people who approve the POs. > > > >? ? ?But it's a good thing Dan didn't have more of the > used-car-salesman > >? ? ?genes.? Otherwise we would have all left Interop each year > with a new > >? ? ?vehicle.? Internet-ready, of course. > > > >? ? ?You were wrong, Dan. IMHO, you could have gotten more than > 50%.... > > > >? ? ?/Jack Haverty > > > > > > > > > >? ? ?On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: > >? ? ?> Craig, I think you did not copy the list.? And while I?m > at it, > >? ? ?a small edit.? I paid the tutors 15% , a full 50% more than the > >? ? ?competition. I also charged everybody 50% more than the > >? ? ?competition because I felt it was worth it!? I even charged the > >? ? ?vendors 50% more than the competition. I turned out that I > was right. > >? ? ?> > >? ? ?> Dan > >? ? ?> > >? ? ?> Cell 650-776-7313 > >? ? ?> > >? ? ?> Begin forwarded message: > >? ? ?> > >? ? ?>> From: Craig Partridge > >? ? ?>> > >? ? ?>> Date: September 8, 2020 at 1:14:05 PM PDT > >? ? ?>> To: Dan Lynch > >> > >? ? ?>> Cc: Craig Partridge via Internet-history > >? ? ? > >? ? ? >> > >? ? ?>> Subject: Re:? [ih] Fwd: List archives (Was: Exterior Gateway > >? ? ?Protocol) > >? ? ?>> > >? ? ?>> ? > >? ? ?>> Dan was kind enough to mention me, which makes it a little > >? ? ?harder to send this note but I'll do it anyway. > >? ? ?>> > >? ? ?>> I think Dan underplays how radical Interop was.? Vendors > had to > >? ? ?connect their equipment to the show network.? There was a > team of > >? ? ?Internet wizards who helped setup the show network for each > show.? > >? ? ?(I recall stories of laying things out on netting in a warehouse > >? ? ?so that it could easily be transferred to the show floor).? > But it > >? ? ?meant products actually worked. > >? ? ?>> > >? ? ?>> And then there was the education component, which as Dan > tells, > >? ? ?started things.? Dan took the view that he tried to hire the top > >? ? ?instructors in the field and compensate them properly. At a time > >? ? ?when competitors were paying 10% of the gross or $2K, whichever > >? ? ?was less, Dan paid $2K or 10% of the gross, whichever was more.? > >? ? ?That meant Interop's courses, instead of being taught by a grad > >? ? ?student or a professor trying out a new course idea, were taught > >? ? ?by folks like Doug Comer and Scott Bradner and Radia Perlman, > >? ? ?teaching their areas of expertise.? As a result, the educational > >? ? ?program was immense -- many thousands of students.? And because > >? ? ?the instructors were already in town, Dan could recruit us > to come > >? ? ?do a panel session for the main program as well.? The panels > were > >? ? ?often also huge.? (I still remember a session I led that > included > >? ? ?Dave Clark and a couple of other key folks -- the room was > packed > >? ? ?-- probably 5,000 people -- and was so jammed that someone > stepped > >? ? ?on the tablecloth for the projector, dumping all our slides > [this > >? ? ?was pre-Powerpoint real-time projection] on the floor!? So I had > >? ? ?to talk w/o slides while the other speakers ran to the back to > >? ? ?reinsert their slides!). > >? ? ?>> > >? ? ?>> Attending Interop was a full week affair -- you got > trained and > >? ? ?then went to the showfloor and conference sessions, while > grabbing > >? ? ?a handful of the old Doubletree cookies (twice the size they are > >? ? ?today) during the breaks. > >? ? ?>> > >? ? ?>> The transitions in size were wild.? We went from > Monterrey, to > >? ? ?the Santa Clara TechMart, to the San Jose Convention center > to the > >? ? ?Moscone Center in SF in rapid succession. > >? ? ?>> > >? ? ?>> Craig > >? ? ?>> > >? ? ?>>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via > Internet-history > >? ? ? > >? ? ? >> wrote: > >? ? ?>>> SoJack, you are asking me to recount how Interop came to > be. I > >? ? ?shall do that as quickly as I can here. > >? ? ?>>> > >? ? ?>>> In the early 80s I was at ISI in charge of the computer > >? ? ?facility. After a year or so there came to be a term New > Computing > >? ? ?Environment to describe the advent of personal computers and the > >? ? ?death of timesharing!? I think Keith Uncapher coined the > term, tho > >? ? ?maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast > forward > >? ? ?a few years and I was back in Silicon Valley looking to start a > >? ? ?company like my pals at Stanford had been doing. I looked around > >? ? ?and noticed that the Internet was gaining traction but the > nascent > >? ? ?companies had not quite got it right. So I convinced Barry > Leiner > >? ? ?who was a program manager there in 85/86 to let me convene a > 3 day > >? ? ?workshop on TCP/IP protocols to explain them to the hundred > or so > >? ? ?implementation teams out there. I got the actual protocol > >? ? ?designers to come to Monterrey California for 3 days. There > was no > >? ? ?company name then. I had no idea where this was going then. > >? ? ?Needless to say the event was a success. The researchers learned > >? ? ?of real life problems the early vendors we?re experiencing > and the > >? ? ?vendors learned a lot more about the Internet and what > worked and > >? ? ?what still needed further steps. > >? ? ?>>> > >? ? ?>>> I now had a business of teaching (through others) the > vendors > >? ? ?and advanced customers how the Internet works. I needed a > name. I > >? ? ?took the old name above and called it Advanced Computing > Environment. > >? ? ?>>> > >? ? ?>>> A few years in to this the world really wanted to see > working > >? ? ?systems and I decided to try a trade show, with one critical > >? ? ?addition: the systems had to be connected to an actual working > >? ? ?Internet!? And while I was on the phone with one of my brilliant > >? ? ?tutor people from BBN, Craig Partridge, as were were concluding > >? ? ?the call he blurted out ?I?ll see you at Interop ?. I hung > up the > >? ? ?phone and called my lawyer to register the name immediately!? I > >? ? ?had been calling it The TCP/IP Interoperability Conference and > >? ? ?Exhibition!? Ah, simplicity. > >? ? ?>>> > >? ? ?>>> That was in September of 1988. It had 50 vendors and 5000 > >? ? ?attendees. In 1990 it had grown to 200 vendors and 30,000 > >? ? ?attendees. Clearly this Internet stuff was catching on, eh?? > >? ? ?>>> > >? ? ?>>> So I sold the company and stayed on for 5 more years as > the PR > >? ? ?guy and growing it into Europe and Asia. > >? ? ?>>> > >? ? ?>>> 30 years later it still exists in about 10 locations I. The > >? ? ?world. Not quite the same, but still stressing interoperability. > >? ? ?>>> > >? ? ?>>> Thanks for asking, Jack. > >? ? ?>>> > >? ? ?>>> > >? ? ?>>> > >? ? ?>>> Dan > >? ? ?>>> > >? ? ?>>> Cell 650-776-7313 > >? ? ?>>> > >? ? ?>>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via > Internet-history > >? ? ? > >? ? ? >> wrote: > >? ? ?>>>> > >? ? ?>>>> ?Thanks Dan! > >? ? ?>>>> > >? ? ?>>>> There's so much of the history that didn't get recorded in > >? ? ?RFCs and > >? ? ?>>>> such, and mail list archives from that era are rare.? We > >? ? ?weren't very > >? ? ?>>>> good about documenting things, especially the "why" of how > >? ? ?decisions > >? ? ?>>>> were made. > >? ? ?>>>> > >? ? ?>>>> There's plenty of room for more participation!? > ?Perhaps you > >? ? ?can provide > >? ? ?>>>> the story behind this artifact of the early Internet? > >? ? ?>>>> > >? ? ?>>>> ACE Coaster > >? ? ?>>>> > >? ? ?>>>> That coaster has been sitting on my desk for close to 40 > >? ? ?years.? The > >? ? ?>>>> lettering is fading, after too many attacks by marauding > >? ? ?coffee mugs > >? ? ?>>>> over the decades, and a few trips to the floor courtesy > of a > >? ? ?roaming cat. > >? ? ?>>>> > >? ? ?>>>> The story of ACE, and Interop which followed, is an > important > >? ? ?part of > >? ? ?>>>> Internet history.? There tends to be a focus on > protocols and > >? ? ?>>>> algorithms, but innovations like Interop were, IMHO, > equally > >? ? ?important > >? ? ?>>>> to the success of the Internet by making it accessible > to the > >? ? ?masses and > >? ? ?>>>> emphasizing the importance of working systems. > >? ? ?>>>> > >? ? ?>>>> Perhaps more important.? ?Tell us the story. > >? ? ?>>>> > >? ? ?>>>> /Jack > >? ? ?>>>> > >? ? ?>>>> > >? ? ?>>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: > >? ? ?>>>>> Forgot to copy the fantastic list! > >? ? ?>>>>> > >? ? ?>>>>> Dan > >? ? ?>>>>> > >? ? ?>>>>> Cell 650-776-7313 > >? ? ?>>>>> > >? ? ?>>>>> Begin forwarded message: > >? ? ?>>>>> > >? ? ?>>>>>> From: Dan Lynch > >> > >? ? ?>>>>>> Date: September 5, 2020 at 11:42:36 AM PDT > >? ? ?>>>>>> To: Joseph Touch > >? ? ?>> > >? ? ?>>>>>> Subject: Re:? [ih] List archives (Was: Exterior Gateway > >? ? ?Protocol) > >? ? ?>>>>>> > >? ? ?>>>>>> ?Great!? These discussions are amazing, considering that > >? ? ?they are being done by the actual inventors of much of the > >? ? ?Internet some 3 or 4 decades later. We were young then, eh?? Of > >? ? ?course they must be open to the world. Thank you Noel, Miles, > >? ? ?Brian, Tony, Vint, Jack, and others I?ve forgotten just now. > >? ? ?>>>>>> > >? ? ?>>>>>> Dan > >? ? ?>>>>>> > >? ? ?>>>>>> Cell 650-776-7313 > >? ? ?>>>>>> > >? ? ?>>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via > >? ? ?Internet-history > >? ? ? >> wrote: > >? ? ?>>>>>>> > >? ? ?>>>>>>> ?HI, all, > >? ? ?>>>>>>> > >? ? ?>>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via > >? ? ?Internet-history > >? ? ? >> wrote: > >? ? ?>>>>>>>>>> > >? ? ?>>>>>>>>>> From: Joseph Touch > >? ? ?>>>>>>>>> FYI - we moved the archives here. > >? ? ?>>>>>>>> I've just noticed that the archives are now only > >? ? ?accessible to list members? > >? ? ?>>>>>>> They should have been open. If anything changed > recently, > >? ? ?this is the first I heard. Either way, the setting has been > >? ? ?updated to allow public access. > >? ? ?>>>>>>> > >? ? ?>>>>>>> Please let me know if you continue to find otherwise. > >? ? ?>>>>>>> > >? ? ?>>>>>>> Joe (as list admin) > >? ? ?>>>>>>> -- > >? ? ?>>>>>>> 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 > >? ? ?>> > >? ? ?>> -- > >? ? ?>> ***** > >? ? ?>> 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 > > > > -- > Please send any postal/overnight deliveries to: > Vint Cerf > 1435 Woodhurst Blvd? > McLean, VA 22102 > 703-448-0965 > > until further notice > > > From jack at 3kitty.org Thu Sep 10 13:45:30 2020 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 10 Sep 2020 13:45:30 -0700 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <1898540920.884265.1599768121777@mail.yahoo.com> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> <1565057141.824958.1599762436842@mail.yahoo.com> <8d3a9ab5-a769-ab77-5bb1-597fa4fd3bfb@3kitty.org> <1898540920.884265.1599768121777@mail.yahoo.com> Message-ID: <632f31be-f947-dad1-43cd-595824f4bc2c@3kitty.org> Yes! That was the place.? IMHO, much of Internet History happened in such places.? Sadly for historians, no one took minutes.?? Not even Jon.??? And the memories are fading.? /Jack On 9/10/20 1:02 PM, Barbara Denny via Internet-history wrote: > Late For the Train was the restaurant.? It had wonderful blintzes. I got introduced to it when I was still working at BBN. There was a packet radio meeting at SRI and the BBN contingent wanted to eat there. Unfortunately it closed years ago. > barbara > On Thursday, September 10, 2020, 12:52:26 PM PDT, Jack Haverty via Internet-history wrote: > > I'll take a look, it easily could have been at SRI.? BTW, when I say > "meeting" it wasn't necessarily some formal session.? We had lots of > informal impromptu "meetings". ? I vaguely remember that there was some > restaurant near SRI that was popular where people used to gather.? > Something to do with a train station; the tracks were right next to the > building.?? Also a pancake/breakfast venue -- maybe "Ken's". > > /Jack? > > On 9/10/20 11:27 AM, Barbara Denny via Internet-history wrote: >> ? Could that meeting have been at SRI? I have a memory of listening to a discussion regarding the creation of the IETF and the IRTF.? I could be wrong about this maybe being the meeting where it happened but I thought it might help you if you look through your notes.? >> barbara? >> ? ? On Thursday, September 10, 2020, 11:11:55 AM PDT, Jack Haverty via Internet-history wrote:? >> ? >> ? Hi Vint, >> >> I concur that the genesis of TCP was in 1973, and spawned a collection >> of separate projects, e.g., Packet Radio, Atlantic Satellite, etc.? >> which along with the ARPANET were forming the core of what we now call >> Internet. >> >> What I was remembering is that the moniker "Internet Project" didn't >> become permanent until the later 70s, with "internet" replacing the >> earlier term "catenet", as described in 1978 in: >> >> http://catenet.org/index.php/IEN_48_-_THE_CATENET_MODEL_FOR_INTERNETWORKING >> >> I recall some meeting, probably 1978/9, where there was a discussion of >> what to call our new conglomeration of networks.? The term "catenet" was >> proposed, but the general feeling was that it would cause people to >> envision herds of cats, and the term "internet" achieved the "rough >> consensus" stage as the best candidate for a name.? We already had >> running code! >> >> The ICCB/IAB was also a key element of history, especially as the >> creator of the IETF and IRTF.? Somewhere I have my notes of the ICCB (or >> was it IAB by then...?) meeting where that happened. >> >> Pandemics provide rare opportunities to dig through old boxes in the >> basement... >> >> /Jack >> >> On 9/10/20 2:55 AM, vinton cerf wrote: >>> On Thu, Sep 10, 2020 at 12:22 AM Jack Haverty via Internet-history >>> >> > wrote: >>> >>> ? ? That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen >>> ? ? or so >>> ? ? people) meeting that Dan called, I think to mostly bounce off ideas >>> ? ? about a training/conference company.?? Again IIRC this happened >>> ? ? somewhat >>> ? ? before the first actual conference in Monterey, where Dan subsequently >>> ? ? stole the Internet using chocolate-chip cookies as bribes.?? Vint >>> ? ? never >>> ? ? served such cookies! >>> >>> no, but I did offer champagne for winners of the TCP/IP Hackathons.? >>> >>> >>> ? ? >From my retro-perspective, it was an interesting progression of >>> ? ? events.?? >>> >>> ? ? The ARPA "Internet Project" had started in the late 70s with a >>> ? ? somewhat >>> >>> no, it started in 1973.? >>> >>> ? ? disjoint set of network-building projects, and had congealed into a >>> ? ? network community, with quarterly meetings.? >>> >>> ? ? At first, the "TCP Working Group" and the "Internet Working Group" met >>> ? ? separately.? Quickly we noticed that the TCP group kept coming up with >>> ? ? changes to the IP header, while the IP group saw things that needed to >>> ? ? be in the TCP header, and everyone in one group wanted to >>> ? ? participate in >>> ? ? the other, so "layering" was cast aside and the Internet Project as a >>> ? ? single group was born. >>> >>> ? ? Over a year or two of such quarterly meetings, the size of the >>> ? ? membership kept growing, and people had to plead with Vint for a >>> ? ? "ticket" to attend.?? >>> >>> ? ? It had become difficult to find a willing host that had a venue big >>> ? ? enough to handle the crowd for plenary and breakout sessions.?? I >>> ? ? hosted >>> ? ? one at BBN, and learned that it is a very bad idea to host a large >>> ? ? meeting in a newly renovated building with lots of free rooms and >>> ? ? space, >>> ? ? but without first testing to make sure the brand-new sparkling >>> ? ? bathrooms >>> ? ? actually worked. >>> >>> ? ? The logistics of the quarterly meetings were becoming a serious >>> ? ? problem.?? Then Dan stepped in. >>> >>> ? ? Instead of a meeting where ARPA and some benefactor host venue >>> ? ? paid the >>> ? ? costs and necessarily severely limited attendance, Dan rented (I >>> ? ? assume >>> ? ? it wasn't free!) a hotel, opened up a "ticket booth" to the masses, >>> >>> This is only half correct. Dan indeed opened Internet up to the public >>> but as I recall, the Internet research program continued in parallel. >>> The Internet Configuration Control Board (1979) morphed into the >>> Internet Advisory Board in 1984 with 10 Task Forces after Barry Leiner >>> took over >>> the ?program management of the Internet Project at DARPA. In 1986, IAB? >>> become the Internet Activities Board under Dennis Perry's program >>> management >>> at DARPA. see?https://www.iab.org/about/history/IAB and IETF and IRTF >>> continue as >>> does INTEROP after its sale by Dan Lynch to Masayoshi Son (when?) >>> >>> ? ? charged attendees a fee that didn't raise too many bean-counters' >>> ? ? alarms, and added a show floor for vendors too, for an appropriate fee >>> ? ? of course.?? He also recruited many of the people who used to just >>> ? ? attend the quarterly Internet project meetings to provide the >>> ? ? entertainment for all the attendees, and called it training and >>> ? ? program >>> ? ? presentations. >>> >>> ? ? Not a bad solution to the problem, eh??? >>> >>> ? ? I recall at first there was just a room with some tables and a handful >>> ? ? of vendors showing their wares.? That turned pretty quickly into a >>> ? ? trade >>> ? ? show floor in Santa Clara, expanding into Moscone, and before long >>> ? ? heading to Vegas when Moscone was just too small. >>> >>> ? ? All of this had the overriding mandate that there would be a strong >>> ? ? technical focus, a live network, and vendors had to connect their >>> ? ? stuff >>> ? ? to it.? For a few years, I was on the Interop "Program Committee", >>> ? ? which >>> ? ? met around a big table to decide which papers would be put into the >>> ? ? program.? It was common to look at a paper, see who was the >>> ? ? author, and >>> ? ? if there was even a hint of "marketing" present, it quickly went >>> ? ? to the >>> ? ? reject pile.?? Sometimes all it took was a look at the authors' >>> ? ? titles. >>> >>> ? ? I remember a meeting where Dan took a few of us to Moscone, to >>> ? ? meet with >>> ? ? the powers-that-be about possibly holding Interop there.? They were >>> ? ? cordial, but IMHO clearly thought this event-they-never-heard-of >>> ? ? didn't >>> ? ? belong in Moscone.? A year later, after blowing out Santa Clara, they >>> ? ? were much more receptive.? Doing the "MazeWar" throughout the Interop >>> ? ? show floor was ... interesting.? I checked in to my hotel room on >>> ? ? Sunday >>> ? ? at noon, and didn't get back until Tuesday night.?? After a few >>> ? ? years in >>> ? ? Moscone, it had become too small for Interop, so it was off to Vegas. >>> >>> ? ? Fun times.? Interop was, IMHO, critical to getting the Internet >>> ? ? out into >>> ? ? the real world.? Nobody else showed products actually working, and >>> ? ? that >>> ? ? matters to the people who approve the POs. >>> >>> ? ? But it's a good thing Dan didn't have more of the used-car-salesman >>> ? ? genes.? Otherwise we would have all left Interop each year with a new >>> ? ? vehicle.? Internet-ready, of course. >>> >>> ? ? You were wrong, Dan. IMHO, you could have gotten more than 50%.... >>> >>> ? ? /Jack Haverty >>> >>> >>> >>> >>> ? ? On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: >>> ? ? > Craig, I think you did not copy the list.? And while I?m at it, >>> ? ? a small edit.? I paid the tutors 15% , a full 50% more than the >>> ? ? competition. I also charged everybody 50% more than the >>> ? ? competition because I felt it was worth it!? I even charged the >>> ? ? vendors 50% more than the competition. I turned out that I was right. >>> ? ? > >>> ? ? > Dan >>> ? ? > >>> ? ? > Cell 650-776-7313 >>> ? ? > >>> ? ? > Begin forwarded message: >>> ? ? > >>> ? ? >> From: Craig Partridge >> ? ? > >>> ? ? >> Date: September 8, 2020 at 1:14:05 PM PDT >>> ? ? >> To: Dan Lynch > >>> ? ? >> Cc: Craig Partridge via Internet-history >>> ? ? >> ? ? > >>> ? ? >> Subject: Re:? [ih] Fwd: List archives (Was: Exterior Gateway >>> ? ? Protocol) >>> ? ? >> >>> ? ? >> ? >>> ? ? >> Dan was kind enough to mention me, which makes it a little >>> ? ? harder to send this note but I'll do it anyway. >>> ? ? >> >>> ? ? >> I think Dan underplays how radical Interop was.? Vendors had to >>> ? ? connect their equipment to the show network.? There was a team of >>> ? ? Internet wizards who helped setup the show network for each show.? >>> ? ? (I recall stories of laying things out on netting in a warehouse >>> ? ? so that it could easily be transferred to the show floor).? But it >>> ? ? meant products actually worked. >>> ? ? >> >>> ? ? >> And then there was the education component, which as Dan tells, >>> ? ? started things.? Dan took the view that he tried to hire the top >>> ? ? instructors in the field and compensate them properly. At a time >>> ? ? when competitors were paying 10% of the gross or $2K, whichever >>> ? ? was less, Dan paid $2K or 10% of the gross, whichever was more.? >>> ? ? That meant Interop's courses, instead of being taught by a grad >>> ? ? student or a professor trying out a new course idea, were taught >>> ? ? by folks like Doug Comer and Scott Bradner and Radia Perlman, >>> ? ? teaching their areas of expertise.? As a result, the educational >>> ? ? program was immense -- many thousands of students.? And because >>> ? ? the instructors were already in town, Dan could recruit us to come >>> ? ? do a panel session for the main program as well.? The panels were >>> ? ? often also huge.? (I still remember a session I led that included >>> ? ? Dave Clark and a couple of other key folks -- the room was packed >>> ? ? -- probably 5,000 people -- and was so jammed that someone stepped >>> ? ? on the tablecloth for the projector, dumping all our slides [this >>> ? ? was pre-Powerpoint real-time projection] on the floor!? So I had >>> ? ? to talk w/o slides while the other speakers ran to the back to >>> ? ? reinsert their slides!). >>> ? ? >> >>> ? ? >> Attending Interop was a full week affair -- you got trained and >>> ? ? then went to the showfloor and conference sessions, while grabbing >>> ? ? a handful of the old Doubletree cookies (twice the size they are >>> ? ? today) during the breaks. >>> ? ? >> >>> ? ? >> The transitions in size were wild.? We went from Monterrey, to >>> ? ? the Santa Clara TechMart, to the San Jose Convention center to the >>> ? ? Moscone Center in SF in rapid succession. >>> ? ? >> >>> ? ? >> Craig >>> ? ? >> >>> ? ? >>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history >>> ? ? >> ? ? > wrote: >>> ? ? >>> SoJack, you are asking me to recount how Interop came to be. I >>> ? ? shall do that as quickly as I can here. >>> ? ? >>> >>> ? ? >>> In the early 80s I was at ISI in charge of the computer >>> ? ? facility. After a year or so there came to be a term New Computing >>> ? ? Environment to describe the advent of personal computers and the >>> ? ? death of timesharing!? I think Keith Uncapher coined the term, tho >>> ? ? maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward >>> ? ? a few years and I was back in Silicon Valley looking to start a >>> ? ? company like my pals at Stanford had been doing. I looked around >>> ? ? and noticed that the Internet was gaining traction but the nascent >>> ? ? companies had not quite got it right. So I convinced Barry Leiner >>> ? ? who was a program manager there in 85/86 to let me convene a 3 day >>> ? ? workshop on TCP/IP protocols to explain them to the hundred or so >>> ? ? implementation teams out there. I got the actual protocol >>> ? ? designers to come to Monterrey California for 3 days. There was no >>> ? ? company name then. I had no idea where this was going then. >>> ? ? Needless to say the event was a success. The researchers learned >>> ? ? of real life problems the early vendors we?re experiencing and the >>> ? ? vendors learned a lot more about the Internet and what worked and >>> ? ? what still needed further steps. >>> ? ? >>> >>> ? ? >>> I now had a business of teaching (through others) the vendors >>> ? ? and advanced customers how the Internet works. I needed a name. I >>> ? ? took the old name above and called it Advanced Computing Environment. >>> ? ? >>> >>> ? ? >>> A few years in to this the world really wanted to see working >>> ? ? systems and I decided to try a trade show, with one critical >>> ? ? addition: the systems had to be connected to an actual working >>> ? ? Internet!? And while I was on the phone with one of my brilliant >>> ? ? tutor people from BBN, Craig Partridge, as were were concluding >>> ? ? the call he blurted out ?I?ll see you at Interop ?. I hung up the >>> ? ? phone and called my lawyer to register the name immediately!? I >>> ? ? had been calling it The TCP/IP Interoperability Conference and >>> ? ? Exhibition!? Ah, simplicity. >>> ? ? >>> >>> ? ? >>> That was in September of 1988. It had 50 vendors and 5000 >>> ? ? attendees. In 1990 it had grown to 200 vendors and 30,000 >>> ? ? attendees. Clearly this Internet stuff was catching on, eh?? >>> ? ? >>> >>> ? ? >>> So I sold the company and stayed on for 5 more years as the PR >>> ? ? guy and growing it into Europe and Asia. >>> ? ? >>> >>> ? ? >>> 30 years later it still exists in about 10 locations I. The >>> ? ? world. Not quite the same, but still stressing interoperability. >>> ? ? >>> >>> ? ? >>> Thanks for asking, Jack. >>> ? ? >>> >>> ? ? >>> >>> ? ? >>> >>> ? ? >>> Dan >>> ? ? >>> >>> ? ? >>> Cell 650-776-7313 >>> ? ? >>> >>> ? ? >>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history >>> ? ? >> ? ? > wrote: >>> ? ? >>>> >>> ? ? >>>> ?Thanks Dan! >>> ? ? >>>> >>> ? ? >>>> There's so much of the history that didn't get recorded in >>> ? ? RFCs and >>> ? ? >>>> such, and mail list archives from that era are rare.? We >>> ? ? weren't very >>> ? ? >>>> good about documenting things, especially the "why" of how >>> ? ? decisions >>> ? ? >>>> were made. >>> ? ? >>>> >>> ? ? >>>> There's plenty of room for more participation!? ?Perhaps you >>> ? ? can provide >>> ? ? >>>> the story behind this artifact of the early Internet? >>> ? ? >>>> >>> ? ? >>>> ACE Coaster >>> ? ? >>>> >>> ? ? >>>> That coaster has been sitting on my desk for close to 40 >>> ? ? years.? The >>> ? ? >>>> lettering is fading, after too many attacks by marauding >>> ? ? coffee mugs >>> ? ? >>>> over the decades, and a few trips to the floor courtesy of a >>> ? ? roaming cat. >>> ? ? >>>> >>> ? ? >>>> The story of ACE, and Interop which followed, is an important >>> ? ? part of >>> ? ? >>>> Internet history.? There tends to be a focus on protocols and >>> ? ? >>>> algorithms, but innovations like Interop were, IMHO, equally >>> ? ? important >>> ? ? >>>> to the success of the Internet by making it accessible to the >>> ? ? masses and >>> ? ? >>>> emphasizing the importance of working systems. >>> ? ? >>>> >>> ? ? >>>> Perhaps more important.? ?Tell us the story. >>> ? ? >>>> >>> ? ? >>>> /Jack >>> ? ? >>>> >>> ? ? >>>> >>> ? ? >>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >>> ? ? >>>>> Forgot to copy the fantastic list! >>> ? ? >>>>> >>> ? ? >>>>> Dan >>> ? ? >>>>> >>> ? ? >>>>> Cell 650-776-7313 >>> ? ? >>>>> >>> ? ? >>>>> Begin forwarded message: >>> ? ? >>>>> >>> ? ? >>>>>> From: Dan Lynch > >>> ? ? >>>>>> Date: September 5, 2020 at 11:42:36 AM PDT >>> ? ? >>>>>> To: Joseph Touch >> ? ? > >>> ? ? >>>>>> Subject: Re:? [ih] List archives (Was: Exterior Gateway >>> ? ? Protocol) >>> ? ? >>>>>> >>> ? ? >>>>>> ?Great!? These discussions are amazing, considering that >>> ? ? they are being done by the actual inventors of much of the >>> ? ? Internet some 3 or 4 decades later. We were young then, eh?? Of >>> ? ? course they must be open to the world. Thank you Noel, Miles, >>> ? ? Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >>> ? ? >>>>>> >>> ? ? >>>>>> Dan >>> ? ? >>>>>> >>> ? ? >>>>>> Cell 650-776-7313 >>> ? ? >>>>>> >>> ? ? >>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via >>> ? ? Internet-history >> ? ? > wrote: >>> ? ? >>>>>>> >>> ? ? >>>>>>> ?HI, all, >>> ? ? >>>>>>> >>> ? ? >>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via >>> ? ? Internet-history >> ? ? > wrote: >>> ? ? >>>>>>>>>> >>> ? ? >>>>>>>>>> From: Joseph Touch >>> ? ? >>>>>>>>> FYI - we moved the archives here. >>> ? ? >>>>>>>> I've just noticed that the archives are now only >>> ? ? accessible to list members? >>> ? ? >>>>>>> They should have been open. If anything changed recently, >>> ? ? this is the first I heard. Either way, the setting has been >>> ? ? updated to allow public access. >>> ? ? >>>>>>> >>> ? ? >>>>>>> Please let me know if you continue to find otherwise. >>> ? ? >>>>>>> >>> ? ? >>>>>>> Joe (as list admin) >>> ? ? >>>>>>> -- >>> ? ? >>>>>>> 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 >>> ? ? >> >>> ? ? >> -- >>> ? ? >> ***** >>> ? ? >> 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 Thu Sep 10 14:49:52 2020 From: vgcerf at gmail.com (vinton cerf) Date: Thu, 10 Sep 2020 17:49:52 -0400 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> Message-ID: the official DARPA project title was "internetting" in the literature, the more common term was "internetworking" Catenet was coined by Louis Pouzin ibm did not call their stuff internetting xerox parc and novell did refer I think to internetting - but when we referred to it, the word implied tcp/ip and the Internet vs internet was about the public versus private use of TCP/IP protocol suite. networking on the other hand was widespread and included things like BITNET, EARN, FIDONET, USENET (uucp) and so on. v On Thu, Sep 10, 2020 at 4:41 PM Jack Haverty wrote: > Hmmmmm. > > I don't recall ever hearing the specific term "Internetting Project". Was > that an internal name used within ARPA? > > My recollection is that at the time (mid/late-70s), there were a number of > efforts to interconnect networks, e.g., outside of ARPA, but using similar > terminology such as "internet". There were multiple "internets" being > developed, in addition to the one at ARPA. > > For example, I found, only about 7 years ago, some mid-70s BBN QTRs about > the ARPANET project, which included some description of how to create an > internet by interconnecting multiple IMP subnets. It showed diagrams of > packet formats to be used in the internal IMP-IMP interactions, e.g., > specifying a different IMP network to which a packet should be directed. > No TCP/IP involved. I never encountered any evidence that anything like > that was implemented, but someone was thinking about it as a way to > interconnect networks. This may have been after ARPA handed over the > ARPANET to DCA. > > CCITT was working on X.25, and creating X.75, to interconnect their > networks. It was a natural evolution of the PTT's prior interconnection of > their telephone networks. Later, as DDN marched down the X.25 path, the > subsequent government Internet might have ended up based on X.25/X.75. If > it worked. > > The IBM world also did internetting. I don't know much about it, > something to do with SNA and LU6.2. I remember though that we sent > salespeople out to sell IMP networks, with optional Gateways to hook up > their anticipated LANs. After a few encounters with some "IBM Shops", the > harassed salespeople told us that there was no way to sell "Gateways" into > that marketplace. IBM had some "Gateway" product, and it had a horrible > reputation for being unreliable; no one would consider buying anything that > involved a "Gateway". So we started calling the TCP/IP boxes "Routers". > > The meeting I recall involved seeking a name for ARPA's TCP-based internet > and the aggregate of the various projects involved in building it. The > term "internet" had many different meanings to different people, but > "catenet" was too obscure, and it was too big a mental leap to grok it as > "concatenated networks". So "internet" became "ARPA Internet" to > distinguish it from other internets of the day. Somewhat later, I suspect > after NSF became a player, it evolved into "The Internet". > > There were many other internets over the years, e.g., Netware, Apple, > Microsoft, Banyan, Xerox, DEC, OSI et al had their own internetting > solutions. TCP/IP by then owned "The Internet", but for a while we had to > suffer with multiprotocol routers and overlapping competing Internets (I > had to help run one such beast in the 90s) until all the other solutions > withered away. > > All this is IIRC, of course.... > /Jack > > > On 9/10/20 11:32 AM, Vint Cerf wrote: > > 1. original project name: internetting > 2. rfc 675 first use of "internet" > 3. catenet used only once in ien #48 > > v > > On Thu, Sep 10, 2020 at 2:11 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > >> Hi Vint, >> >> I concur that the genesis of TCP was in 1973, and spawned a collection >> of separate projects, e.g., Packet Radio, Atlantic Satellite, etc. >> which along with the ARPANET were forming the core of what we now call >> Internet. >> >> What I was remembering is that the moniker "Internet Project" didn't >> become permanent until the later 70s, with "internet" replacing the >> earlier term "catenet", as described in 1978 in: >> >> >> http://catenet.org/index.php/IEN_48_-_THE_CATENET_MODEL_FOR_INTERNETWORKING >> >> I recall some meeting, probably 1978/9, where there was a discussion of >> what to call our new conglomeration of networks. The term "catenet" was >> proposed, but the general feeling was that it would cause people to >> envision herds of cats, and the term "internet" achieved the "rough >> consensus" stage as the best candidate for a name. We already had >> running code! >> >> The ICCB/IAB was also a key element of history, especially as the >> creator of the IETF and IRTF. Somewhere I have my notes of the ICCB (or >> was it IAB by then...?) meeting where that happened. >> >> Pandemics provide rare opportunities to dig through old boxes in the >> basement... >> >> /Jack >> >> On 9/10/20 2:55 AM, vinton cerf wrote: >> > >> > >> > On Thu, Sep 10, 2020 at 12:22 AM Jack Haverty via Internet-history >> > > > > wrote: >> > >> > That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen >> > or so >> > people) meeting that Dan called, I think to mostly bounce off ideas >> > about a training/conference company. Again IIRC this happened >> > somewhat >> > before the first actual conference in Monterey, where Dan >> subsequently >> > stole the Internet using chocolate-chip cookies as bribes. Vint >> > never >> > served such cookies! >> > >> > no, but I did offer champagne for winners of the TCP/IP Hackathons. >> > >> > >> > >From my retro-perspective, it was an interesting progression of >> > events. >> > >> > The ARPA "Internet Project" had started in the late 70s with a >> > somewhat >> > >> > no, it started in 1973. >> > >> > disjoint set of network-building projects, and had congealed into a >> > network community, with quarterly meetings. >> > >> > At first, the "TCP Working Group" and the "Internet Working Group" >> met >> > separately. Quickly we noticed that the TCP group kept coming up >> with >> > changes to the IP header, while the IP group saw things that needed >> to >> > be in the TCP header, and everyone in one group wanted to >> > participate in >> > the other, so "layering" was cast aside and the Internet Project as >> a >> > single group was born. >> > >> > Over a year or two of such quarterly meetings, the size of the >> > membership kept growing, and people had to plead with Vint for a >> > "ticket" to attend. >> > >> > It had become difficult to find a willing host that had a venue big >> > enough to handle the crowd for plenary and breakout sessions. I >> > hosted >> > one at BBN, and learned that it is a very bad idea to host a large >> > meeting in a newly renovated building with lots of free rooms and >> > space, >> > but without first testing to make sure the brand-new sparkling >> > bathrooms >> > actually worked. >> > >> > The logistics of the quarterly meetings were becoming a serious >> > problem. Then Dan stepped in. >> > >> > Instead of a meeting where ARPA and some benefactor host venue >> > paid the >> > costs and necessarily severely limited attendance, Dan rented (I >> > assume >> > it wasn't free!) a hotel, opened up a "ticket booth" to the masses, >> > >> > This is only half correct. Dan indeed opened Internet up to the public >> > but as I recall, the Internet research program continued in parallel. >> > The Internet Configuration Control Board (1979) morphed into the >> > Internet Advisory Board in 1984 with 10 Task Forces after Barry Leiner >> > took over >> > the program management of the Internet Project at DARPA. In 1986, IAB >> > become the Internet Activities Board under Dennis Perry's program >> > management >> > at DARPA. see https://www.iab.org/about/history/IAB and IETF and IRTF >> > continue as >> > does INTEROP after its sale by Dan Lynch to Masayoshi Son (when?) >> > >> > charged attendees a fee that didn't raise too many bean-counters' >> > alarms, and added a show floor for vendors too, for an appropriate >> fee >> > of course. He also recruited many of the people who used to just >> > attend the quarterly Internet project meetings to provide the >> > entertainment for all the attendees, and called it training and >> > program >> > presentations. >> > >> > Not a bad solution to the problem, eh? >> > >> > I recall at first there was just a room with some tables and a >> handful >> > of vendors showing their wares. That turned pretty quickly into a >> > trade >> > show floor in Santa Clara, expanding into Moscone, and before long >> > heading to Vegas when Moscone was just too small. >> > >> > All of this had the overriding mandate that there would be a strong >> > technical focus, a live network, and vendors had to connect their >> > stuff >> > to it. For a few years, I was on the Interop "Program Committee", >> > which >> > met around a big table to decide which papers would be put into the >> > program. It was common to look at a paper, see who was the >> > author, and >> > if there was even a hint of "marketing" present, it quickly went >> > to the >> > reject pile. Sometimes all it took was a look at the authors' >> > titles. >> > >> > I remember a meeting where Dan took a few of us to Moscone, to >> > meet with >> > the powers-that-be about possibly holding Interop there. They were >> > cordial, but IMHO clearly thought this event-they-never-heard-of >> > didn't >> > belong in Moscone. A year later, after blowing out Santa Clara, >> they >> > were much more receptive. Doing the "MazeWar" throughout the >> Interop >> > show floor was ... interesting. I checked in to my hotel room on >> > Sunday >> > at noon, and didn't get back until Tuesday night. After a few >> > years in >> > Moscone, it had become too small for Interop, so it was off to >> Vegas. >> > >> > Fun times. Interop was, IMHO, critical to getting the Internet >> > out into >> > the real world. Nobody else showed products actually working, and >> > that >> > matters to the people who approve the POs. >> > >> > But it's a good thing Dan didn't have more of the used-car-salesman >> > genes. Otherwise we would have all left Interop each year with a >> new >> > vehicle. Internet-ready, of course. >> > >> > You were wrong, Dan. IMHO, you could have gotten more than 50%.... >> > >> > /Jack Haverty >> > >> > >> > >> > >> > On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: >> > > Craig, I think you did not copy the list. And while I?m at it, >> > a small edit. I paid the tutors 15% , a full 50% more than the >> > competition. I also charged everybody 50% more than the >> > competition because I felt it was worth it! I even charged the >> > vendors 50% more than the competition. I turned out that I was >> right. >> > > >> > > Dan >> > > >> > > Cell 650-776-7313 <(650)%20776-7313> >> > > >> > > Begin forwarded message: >> > > >> > >> From: Craig Partridge > > > >> > >> Date: September 8, 2020 at 1:14:05 PM PDT >> > >> To: Dan Lynch > >> > >> Cc: Craig Partridge via Internet-history >> > > > > >> > >> Subject: Re: [ih] Fwd: List archives (Was: Exterior Gateway >> > Protocol) >> > >> >> > >> ? >> > >> Dan was kind enough to mention me, which makes it a little >> > harder to send this note but I'll do it anyway. >> > >> >> > >> I think Dan underplays how radical Interop was. Vendors had to >> > connect their equipment to the show network. There was a team of >> > Internet wizards who helped setup the show network for each show. >> > (I recall stories of laying things out on netting in a warehouse >> > so that it could easily be transferred to the show floor). But it >> > meant products actually worked. >> > >> >> > >> And then there was the education component, which as Dan tells, >> > started things. Dan took the view that he tried to hire the top >> > instructors in the field and compensate them properly. At a time >> > when competitors were paying 10% of the gross or $2K, whichever >> > was less, Dan paid $2K or 10% of the gross, whichever was more. >> > That meant Interop's courses, instead of being taught by a grad >> > student or a professor trying out a new course idea, were taught >> > by folks like Doug Comer and Scott Bradner and Radia Perlman, >> > teaching their areas of expertise. As a result, the educational >> > program was immense -- many thousands of students. And because >> > the instructors were already in town, Dan could recruit us to come >> > do a panel session for the main program as well. The panels were >> > often also huge. (I still remember a session I led that included >> > Dave Clark and a couple of other key folks -- the room was packed >> > -- probably 5,000 people -- and was so jammed that someone stepped >> > on the tablecloth for the projector, dumping all our slides [this >> > was pre-Powerpoint real-time projection] on the floor! So I had >> > to talk w/o slides while the other speakers ran to the back to >> > reinsert their slides!). >> > >> >> > >> Attending Interop was a full week affair -- you got trained and >> > then went to the showfloor and conference sessions, while grabbing >> > a handful of the old Doubletree cookies (twice the size they are >> > today) during the breaks. >> > >> >> > >> The transitions in size were wild. We went from Monterrey, to >> > the Santa Clara TechMart, to the San Jose Convention center to the >> > Moscone Center in SF in rapid succession. >> > >> >> > >> Craig >> > >> >> > >>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history >> > > > > wrote: >> > >>> SoJack, you are asking me to recount how Interop came to be. I >> > shall do that as quickly as I can here. >> > >>> >> > >>> In the early 80s I was at ISI in charge of the computer >> > facility. After a year or so there came to be a term New Computing >> > Environment to describe the advent of personal computers and the >> > death of timesharing! I think Keith Uncapher coined the term, tho >> > maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward >> > a few years and I was back in Silicon Valley looking to start a >> > company like my pals at Stanford had been doing. I looked around >> > and noticed that the Internet was gaining traction but the nascent >> > companies had not quite got it right. So I convinced Barry Leiner >> > who was a program manager there in 85/86 to let me convene a 3 day >> > workshop on TCP/IP protocols to explain them to the hundred or so >> > implementation teams out there. I got the actual protocol >> > designers to come to Monterrey California for 3 days. There was no >> > company name then. I had no idea where this was going then. >> > Needless to say the event was a success. The researchers learned >> > of real life problems the early vendors we?re experiencing and the >> > vendors learned a lot more about the Internet and what worked and >> > what still needed further steps. >> > >>> >> > >>> I now had a business of teaching (through others) the vendors >> > and advanced customers how the Internet works. I needed a name. I >> > took the old name above and called it Advanced Computing >> Environment. >> > >>> >> > >>> A few years in to this the world really wanted to see working >> > systems and I decided to try a trade show, with one critical >> > addition: the systems had to be connected to an actual working >> > Internet! And while I was on the phone with one of my brilliant >> > tutor people from BBN, Craig Partridge, as were were concluding >> > the call he blurted out ?I?ll see you at Interop ?. I hung up the >> > phone and called my lawyer to register the name immediately! I >> > had been calling it The TCP/IP Interoperability Conference and >> > Exhibition! Ah, simplicity. >> > >>> >> > >>> That was in September of 1988. It had 50 vendors and 5000 >> > attendees. In 1990 it had grown to 200 vendors and 30,000 >> > attendees. Clearly this Internet stuff was catching on, eh? >> > >>> >> > >>> So I sold the company and stayed on for 5 more years as the PR >> > guy and growing it into Europe and Asia. >> > >>> >> > >>> 30 years later it still exists in about 10 locations I. The >> > world. Not quite the same, but still stressing interoperability. >> > >>> >> > >>> Thanks for asking, Jack. >> > >>> >> > >>> >> > >>> >> > >>> Dan >> > >>> >> > >>> Cell 650-776-7313 <(650)%20776-7313> >> > >>> >> > >>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history >> > > > > wrote: >> > >>>> >> > >>>> ?Thanks Dan! >> > >>>> >> > >>>> There's so much of the history that didn't get recorded in >> > RFCs and >> > >>>> such, and mail list archives from that era are rare. We >> > weren't very >> > >>>> good about documenting things, especially the "why" of how >> > decisions >> > >>>> were made. >> > >>>> >> > >>>> There's plenty of room for more participation! Perhaps you >> > can provide >> > >>>> the story behind this artifact of the early Internet? >> > >>>> >> > >>>> ACE Coaster >> > >>>> >> > >>>> That coaster has been sitting on my desk for close to 40 >> > years. The >> > >>>> lettering is fading, after too many attacks by marauding >> > coffee mugs >> > >>>> over the decades, and a few trips to the floor courtesy of a >> > roaming cat. >> > >>>> >> > >>>> The story of ACE, and Interop which followed, is an important >> > part of >> > >>>> Internet history. There tends to be a focus on protocols and >> > >>>> algorithms, but innovations like Interop were, IMHO, equally >> > important >> > >>>> to the success of the Internet by making it accessible to the >> > masses and >> > >>>> emphasizing the importance of working systems. >> > >>>> >> > >>>> Perhaps more important. Tell us the story. >> > >>>> >> > >>>> /Jack >> > >>>> >> > >>>> >> > >>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >> > >>>>> Forgot to copy the fantastic list! >> > >>>>> >> > >>>>> Dan >> > >>>>> >> > >>>>> Cell 650-776-7313 <(650)%20776-7313> >> > >>>>> >> > >>>>> Begin forwarded message: >> > >>>>> >> > >>>>>> From: Dan Lynch > >> > >>>>>> Date: September 5, 2020 at 11:42:36 AM PDT >> > >>>>>> To: Joseph Touch > > > >> > >>>>>> Subject: Re: [ih] List archives (Was: Exterior Gateway >> > Protocol) >> > >>>>>> >> > >>>>>> ?Great! These discussions are amazing, considering that >> > they are being done by the actual inventors of much of the >> > Internet some 3 or 4 decades later. We were young then, eh? Of >> > course they must be open to the world. Thank you Noel, Miles, >> > Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >> > >>>>>> >> > >>>>>> Dan >> > >>>>>> >> > >>>>>> Cell 650-776-7313 <(650)%20776-7313> >> > >>>>>> >> > >>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via >> > Internet-history > > > wrote: >> > >>>>>>> >> > >>>>>>> ?HI, all, >> > >>>>>>> >> > >>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via >> > Internet-history > > > wrote: >> > >>>>>>>>>> >> > >>>>>>>>>> From: Joseph Touch >> > >>>>>>>>> FYI - we moved the archives here. >> > >>>>>>>> I've just noticed that the archives are now only >> > accessible to list members? >> > >>>>>>> They should have been open. If anything changed recently, >> > this is the first I heard. Either way, the setting has been >> > updated to allow public access. >> > >>>>>>> >> > >>>>>>> Please let me know if you continue to find otherwise. >> > >>>>>>> >> > >>>>>>> Joe (as list admin) >> > >>>>>>> -- >> > >>>>>>> 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 >> > >> >> > >> -- >> > >> ***** >> > >> 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 >> > > > -- > Please send any postal/overnight deliveries to: > Vint Cerf > 1435 Woodhurst Blvd > McLean, VA 22102 > 703-448-0965 > > until further notice > > > > > From geoff at iconia.com Thu Sep 10 17:21:58 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Thu, 10 Sep 2020 14:21:58 -1000 Subject: [ih] NO "settlements" as part of Internet History (was: Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol))) In-Reply-To: References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> Message-ID: On Thu, Sep 10, 2020 at 10:42 AM *Jack Haverty via Internet-history > wrote* : > CCITT was working on X.25, and creating X.75, to interconnect their > networks. It was a natural evolution of the PTT's prior interconnection > of their telephone networks. Later, as DDN marched down the X.25 path, > the subsequent government Internet might have ended up based on > X.25/X.75. If it worked. > part and parcel of the X.25 and X.75 networking shibboleth was the notion of "settlements" -- just like with the PTT's interconnection of their telephone networks -- where The Fee for/of Transit was split along a "calls" participants/networks transited. IIRC, Advanced Network and Services (ANS) tried to "imprint" the settlements model on the fledgling Internet -- with them In The Middle collecting a fee for transit (for commercial traffic) between networks as well as for interconnection with The Budding commercial Internet upstarts (PSI, ALTERNET, etc.) the resulting in the founding of the CIX, viz.: *Data Network Raises Monopoly Fear* By JOHN MARKOFF The New York Times December 19, 1991 http://www.nytimes.com/1991 /12/19/business/data-network-raises-monopoly-fear.html Soon after President Bush signed legislation calling for the creation of a nationwide computer data "superhighway," a debate has erupted over whether the Government gave an unfair advantage to a joint venture of I.B.M. MCI that built and manages a key part of the network. The venture, known as Advanced Network and Services, manages a network called NSFnet, which connects hundreds of research centers and universities. NSFnet also manages links to dozens of other countries. All these networks are collectively known as Internet. Some private competitors say Advanced Network and Services uses its favored position to squeeze them out of the data-transmission market by establishing rules that make it difficult to connect to NSFnet. *Traffic Has Doubled* NSFnet was founded by the National Science Foundation, a Federal agency, and is composed of leased telephone lines that link special computers called routers, which transmit packages of data to three million users in 33 countries. Data traffic over the NSFnet backbone has doubled in the last year. The Government wants to develop a national data highway for electronic commerce, digital video transmissions to homes and vast electronic libraries that could be drawn on by the nation's schools. Advanced Network and Services, based in Elmsford, N.Y., was set up last year as a nonprofit corporation with $10 million from the International Business Machines Corporation and the MCI Communications Corporation. Earlier this year it set up a for-profit subsidiary, called ANS CO+RE (pronounced core), to sell computer network services. That led some competitors to complain that Advanced Network and Services would be able to compete unfairly because of its arrangement with the Government. *Fear Loss of Innovation* People involved in planning for a national data network say it is essential to provide for fair competition, which will lead rival companies to offer creative and entrepreneurial services in the hope of building market share. Without competiton, they say, the Government will have created a monopoly that has little incentive to innovate. "This is the first major communication business to be born under the deregulation era," said David Farber, a computer scientist at the University of Pennsylvania and a pioneer in data networking. "This hasn't happened since the growth of the telephone industry. You want it to be a business that doesn't repeat the errors of the past." In recent years, the National Science Foundation has tried to shift its operations and ownership of NSFnet to Advanced Network and Services. And it will try to establish competition through contracts for networks to compete with NSFnet next year. But there is no level playing field, complained William L. Schrader, president of Performance Systems International Inc., a Reston, Va., company that provides commercial data connections to Internet. He made public two letters between officials of Advanced Network and Services and the National Science Foundation that he said gave the company unfair control over access to the network. The result, he added, was that the Government turned over valuable public property to a private company. "It's like taking a Federal park and giving it to K Mart," Mr. Schrader said. "It's not right, and it isn't going to stand." Performance Systems and several other companies have set up an alternative to NSFnet, known as a CIX. Mr. Schrader said his company and the venture of I.B.M. and MCI were competing for the same customers but unlike his rival he lacked a Federal subsidy. He said he might ask the Internal Revenue Service to look at the business relationship between Advanced Network's nonprofit and for-profit operations. *'Very Competitive Environment'* Allan Weis, the president of Advanced Network, disputed that his company had an unfair advantage. "It's a very competitive environment right now," he said. At the National Science Foundation, Stephen Wolff, director of its networking division, said I.B.M. and MCI had overbuilt the network and were selling commercial service based on the excess capacity that was available. A number of organizations are working informally to settle the dispute. "I think it's a mess," said Mitchell D. Kapor, the founder of the Lotus Development Corporation and now head of the Electronic Frontier Foundation, a public-interest group focusing on public policy issues surrounding data networks. "Nobody should have an unfair advantage." -- Geoff.Goodfellow at iconia.com living as The Truth is True From dan at lynch.com Thu Sep 10 21:26:43 2020 From: dan at lynch.com (Dan Lynch) Date: Thu, 10 Sep 2020 21:26:43 -0700 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <093c9532-94d1-7074-133b-61e4f050fc67@3kitty.org> References: <093c9532-94d1-7074-133b-61e4f050fc67@3kitty.org> Message-ID: ?I know it works. I saw it at Interop.? That became our tag line in our early marketing of Interop. In the very first show in Santa Clara I saw three attendees (propeller heads) drag their boss (suit) over to a Sun booth and look at a demo and say ?see, it works, so will you sign the P.O.?? He said yes, and I knew I had a great business. You are right, Jack! Dan Cell 650-776-7313 > On Sep 10, 2020, at 12:04 PM, Jack Haverty wrote: > > ?That's the key -- "knew what the buyers wanted" Interop was a crucial > part of delivering information to those buyers who in a real sense > bought the Internet, taking the ideas from research to scale. > > At about the same time (1989/90), I was involved in a consulting > contract with a major investment house, who needed help in deciding how > to use all the fancy new technology hitting the market. I recall going > to meetings in the canyonlands of Wall Street, and seeing large trucks > at the skyscrapers' loading docks, packed full of Sun workstations being > delivered. > > The CTO had issued three identical contracts to three techie firms, with > the vague deliverable of "build something that helps us in our > business". Hardware, software, AI, protocols, network-connected > espresso machines, whatever they thought would help - the contractors > got to decide, and should just assume that each user had a Sun > workstation connected to Ethernet, running TCP. > > My consulting role was to help evaluate the resulting competitors' > systems, and we had a meeting to sort out how to do that. I remember > describing how we would look at CPU usage, memory, latency, efficiency, > etc. All of the things that matter. > > He listened attentively, then offered his own thoughts, asking if he was > being too simplistic. He was planning to take three floors of traders, > and install each competitor's "helper system" on a separate floor. For > a few weeks/months, they would all use the helper stuff, whatever it > turned out to be, as part of their normal daily activities. > > At the end of those trials, he would simply see which floor had made the > most money. Nothing else mattered. > > Oh yes, they did go to Interop, which was probably why they had all > those Sun workstations, since they could see them working over the > InteropNet. They had also adopted TCP as their solution, with a pile > of Cisco routers set up in their IT lab for checkout before deployment > to London and Tokyo. Satellite lines were ordered, and everything was > dually redundant to maximize availability - Time=Money. An "intranet" > was in the making; they saw it working at Interop. > > Interop was a key player in the "technology transfer" from the > research/government/academic creche to the "real world". People > adopted the Internet because they could see that it worked, and it > helped them do whatever it was that they did. > > Fun times, > /Jack > >> On 9/10/20 9:10 AM, Dan Lynch wrote: >> Jack, you have a remarkable memory. A few edits. >> >> The chocolate chip cookies at the Doubletree Hotel in Monterey were definitely addictive. I was lucky when we moved to Santa Clara and there was a Doubletree Hotel there. >> >> Because I was a computer center guy I knew what the buyers wanted to see and hear. No marketing hype, just technical details, or speeds and feeds as it was called in those days. Price, performance and delivery was all we wanted to see. >> >> I remember that for a few years Interop facilitated the IETF meetings because it was easy for us (it was our business) and it built an affinity with the brain trust of the evolving Internet. Somehow NSF or DARPA insisted on paying us for that activity. It was $50k. It certainly cost us more than that to do the work, but we didn?t care. After a while I got the letter from some bureaucrat saying they wanted to audit the contract. Yikes. I had done audit before and they are costly to do. I quickly figured out that I could just give back the $50k and there would be no audit! Much cheaper! >> >> Oh, Vint, I sold Interop to Ziff-Davis Publishing. A few years later they sold it to SoftBank for a 3-400% profit. >> >> Fun times for many. >> >> Dan >> >> Cell 650-776-7313 >> >>>> On Sep 9, 2020, at 9:22 PM, Jack Haverty via Internet-history wrote: >>> >>> ?That "ACE Coaster" was handed out (by Dan, IIRC) at a small (dozen or so >>> people) meeting that Dan called, I think to mostly bounce off ideas >>> about a training/conference company. Again IIRC this happened somewhat >>> before the first actual conference in Monterey, where Dan subsequently >>> stole the Internet using chocolate-chip cookies as bribes. Vint never >>> served such cookies! >>> >>> From my retro-perspective, it was an interesting progression of events. >>> >>> The ARPA "Internet Project" had started in the late 70s with a somewhat >>> disjoint set of network-building projects, and had congealed into a >>> network community, with quarterly meetings. >>> >>> At first, the "TCP Working Group" and the "Internet Working Group" met >>> separately. Quickly we noticed that the TCP group kept coming up with >>> changes to the IP header, while the IP group saw things that needed to >>> be in the TCP header, and everyone in one group wanted to participate in >>> the other, so "layering" was cast aside and the Internet Project as a >>> single group was born. >>> >>> Over a year or two of such quarterly meetings, the size of the >>> membership kept growing, and people had to plead with Vint for a >>> "ticket" to attend. >>> >>> It had become difficult to find a willing host that had a venue big >>> enough to handle the crowd for plenary and breakout sessions. I hosted >>> one at BBN, and learned that it is a very bad idea to host a large >>> meeting in a newly renovated building with lots of free rooms and space, >>> but without first testing to make sure the brand-new sparkling bathrooms >>> actually worked. >>> >>> The logistics of the quarterly meetings were becoming a serious >>> problem. Then Dan stepped in. >>> >>> Instead of a meeting where ARPA and some benefactor host venue paid the >>> costs and necessarily severely limited attendance, Dan rented (I assume >>> it wasn't free!) a hotel, opened up a "ticket booth" to the masses, >>> charged attendees a fee that didn't raise too many bean-counters' >>> alarms, and added a show floor for vendors too, for an appropriate fee >>> of course. He also recruited many of the people who used to just >>> attend the quarterly Internet project meetings to provide the >>> entertainment for all the attendees, and called it training and program >>> presentations. >>> >>> Not a bad solution to the problem, eh? >>> >>> I recall at first there was just a room with some tables and a handful >>> of vendors showing their wares. That turned pretty quickly into a trade >>> show floor in Santa Clara, expanding into Moscone, and before long >>> heading to Vegas when Moscone was just too small. >>> >>> All of this had the overriding mandate that there would be a strong >>> technical focus, a live network, and vendors had to connect their stuff >>> to it. For a few years, I was on the Interop "Program Committee", which >>> met around a big table to decide which papers would be put into the >>> program. It was common to look at a paper, see who was the author, and >>> if there was even a hint of "marketing" present, it quickly went to the >>> reject pile. Sometimes all it took was a look at the authors' titles. >>> >>> I remember a meeting where Dan took a few of us to Moscone, to meet with >>> the powers-that-be about possibly holding Interop there. They were >>> cordial, but IMHO clearly thought this event-they-never-heard-of didn't >>> belong in Moscone. A year later, after blowing out Santa Clara, they >>> were much more receptive. Doing the "MazeWar" throughout the Interop >>> show floor was ... interesting. I checked in to my hotel room on Sunday >>> at noon, and didn't get back until Tuesday night. After a few years in >>> Moscone, it had become too small for Interop, so it was off to Vegas. >>> >>> Fun times. Interop was, IMHO, critical to getting the Internet out into >>> the real world. Nobody else showed products actually working, and that >>> matters to the people who approve the POs. >>> >>> But it's a good thing Dan didn't have more of the used-car-salesman >>> genes. Otherwise we would have all left Interop each year with a new >>> vehicle. Internet-ready, of course. >>> >>> You were wrong, Dan. IMHO, you could have gotten more than 50%.... >>> >>> /Jack Haverty >>> >>> >>> >>> >>>> On 9/8/20 2:48 PM, Dan Lynch via Internet-history wrote: >>>> Craig, I think you did not copy the list. And while I?m at it, a small edit. I paid the tutors 15% , a full 50% more than the competition. I also charged everybody 50% more than the competition because I felt it was worth it! I even charged the vendors 50% more than the competition. I turned out that I was right. >>>> >>>> Dan >>>> >>>> Cell 650-776-7313 >>>> >>>> Begin forwarded message: >>>> >>>>> From: Craig Partridge >>>>> Date: September 8, 2020 at 1:14:05 PM PDT >>>>> To: Dan Lynch >>>>> Cc: Craig Partridge via Internet-history >>>>> Subject: Re: [ih] Fwd: List archives (Was: Exterior Gateway Protocol) >>>>> >>>>> ? >>>>> Dan was kind enough to mention me, which makes it a little harder to send this note but I'll do it anyway. >>>>> >>>>> I think Dan underplays how radical Interop was. Vendors had to connect their equipment to the show network. There was a team of Internet wizards who helped setup the show network for each show. (I recall stories of laying things out on netting in a warehouse so that it could easily be transferred to the show floor). But it meant products actually worked. >>>>> >>>>> And then there was the education component, which as Dan tells, started things. Dan took the view that he tried to hire the top instructors in the field and compensate them properly. At a time when competitors were paying 10% of the gross or $2K, whichever was less, Dan paid $2K or 10% of the gross, whichever was more. That meant Interop's courses, instead of being taught by a grad student or a professor trying out a new course idea, were taught by folks like Doug Comer and Scott Bradner and Radia Perlman, teaching their areas of expertise. As a result, the educational program was immense -- many thousands of students. And because the instructors were already in town, Dan could recruit us to come do a panel session for the main program as well. The panels were often also huge. (I still remember a session I led that included Dave Clark and a couple of other key folks -- the room was packed -- probably 5,000 people -- and was so jammed that someone stepped on the tablecloth for the projector, dumping all our slides [this was pre-Powerpoint real-time projection] on the floor! So I had to talk w/o slides while the other speakers ran to the back to reinsert their slides!). >>>>> >>>>> Attending Interop was a full week affair -- you got trained and then went to the showfloor and conference sessions, while grabbing a handful of the old Doubletree cookies (twice the size they are today) during the breaks. >>>>> >>>>> The transitions in size were wild. We went from Monterrey, to the Santa Clara TechMart, to the San Jose Convention center to the Moscone Center in SF in rapid succession. >>>>> >>>>> Craig >>>>> >>>>>> On Tue, Sep 8, 2020 at 12:52 PM Dan Lynch via Internet-history wrote: >>>>>> SoJack, you are asking me to recount how Interop came to be. I shall do that as quickly as I can here. >>>>>> >>>>>> In the early 80s I was at ISI in charge of the computer facility. After a year or so there came to be a term New Computing Environment to describe the advent of personal computers and the death of timesharing! I think Keith Uncapher coined the term, tho maybe Bob Kahn and Vint Cerf had a hand in it. Anyway fast forward a few years and I was back in Silicon Valley looking to start a company like my pals at Stanford had been doing. I looked around and noticed that the Internet was gaining traction but the nascent companies had not quite got it right. So I convinced Barry Leiner who was a program manager there in 85/86 to let me convene a 3 day workshop on TCP/IP protocols to explain them to the hundred or so implementation teams out there. I got the actual protocol designers to come to Monterrey California for 3 days. There was no company name then. I had no idea where this was going then. Needless to say the event was a success. The researchers learned of real life problems the early vendors we?re experiencing and the vendors learned a lot more about the Internet and what worked and what still needed further steps. >>>>>> >>>>>> I now had a business of teaching (through others) the vendors and advanced customers how the Internet works. I needed a name. I took the old name above and called it Advanced Computing Environment. >>>>>> >>>>>> A few years in to this the world really wanted to see working systems and I decided to try a trade show, with one critical addition: the systems had to be connected to an actual working Internet! And while I was on the phone with one of my brilliant tutor people from BBN, Craig Partridge, as were were concluding the call he blurted out ?I?ll see you at Interop ?. I hung up the phone and called my lawyer to register the name immediately! I had been calling it The TCP/IP Interoperability Conference and Exhibition! Ah, simplicity. >>>>>> >>>>>> That was in September of 1988. It had 50 vendors and 5000 attendees. In 1990 it had grown to 200 vendors and 30,000 attendees. Clearly this Internet stuff was catching on, eh? >>>>>> >>>>>> So I sold the company and stayed on for 5 more years as the PR guy and growing it into Europe and Asia. >>>>>> >>>>>> 30 years later it still exists in about 10 locations I. The world. Not quite the same, but still stressing interoperability. >>>>>> >>>>>> Thanks for asking, Jack. >>>>>> >>>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>> Cell 650-776-7313 >>>>>> >>>>>>> On Sep 5, 2020, at 1:28 PM, Jack Haverty via Internet-history wrote: >>>>>>> >>>>>>> ?Thanks Dan! >>>>>>> >>>>>>> There's so much of the history that didn't get recorded in RFCs and >>>>>>> such, and mail list archives from that era are rare. We weren't very >>>>>>> good about documenting things, especially the "why" of how decisions >>>>>>> were made. >>>>>>> >>>>>>> There's plenty of room for more participation! Perhaps you can provide >>>>>>> the story behind this artifact of the early Internet? >>>>>>> >>>>>>> ACE Coaster >>>>>>> >>>>>>> That coaster has been sitting on my desk for close to 40 years. The >>>>>>> lettering is fading, after too many attacks by marauding coffee mugs >>>>>>> over the decades, and a few trips to the floor courtesy of a roaming cat. >>>>>>> >>>>>>> The story of ACE, and Interop which followed, is an important part of >>>>>>> Internet history. There tends to be a focus on protocols and >>>>>>> algorithms, but innovations like Interop were, IMHO, equally important >>>>>>> to the success of the Internet by making it accessible to the masses and >>>>>>> emphasizing the importance of working systems. >>>>>>> >>>>>>> Perhaps more important. Tell us the story. >>>>>>> >>>>>>> /Jack >>>>>>> >>>>>>> >>>>>>>> On 9/5/20 12:10 PM, Dan Lynch via Internet-history wrote: >>>>>>>> Forgot to copy the fantastic list! >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> Cell 650-776-7313 >>>>>>>> >>>>>>>> Begin forwarded message: >>>>>>>> >>>>>>>>> From: Dan Lynch >>>>>>>>> Date: September 5, 2020 at 11:42:36 AM PDT >>>>>>>>> To: Joseph Touch >>>>>>>>> Subject: Re: [ih] List archives (Was: Exterior Gateway Protocol) >>>>>>>>> >>>>>>>>> ?Great! These discussions are amazing, considering that they are being done by the actual inventors of much of the Internet some 3 or 4 decades later. We were young then, eh? Of course they must be open to the world. Thank you Noel, Miles, Brian, Tony, Vint, Jack, and others I?ve forgotten just now. >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> Cell 650-776-7313 >>>>>>>>> >>>>>>>>>> On Sep 5, 2020, at 8:06 AM, Joseph Touch via Internet-history wrote: >>>>>>>>>> >>>>>>>>>> ?HI, all, >>>>>>>>>> >>>>>>>>>>>>> On Sep 5, 2020, at 7:58 AM, Noel Chiappa via Internet-history wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> From: Joseph Touch >>>>>>>>>>>> FYI - we moved the archives here. >>>>>>>>>>> I've just noticed that the archives are now only accessible to list members? >>>>>>>>>> They should have been open. If anything changed recently, this is the first I heard. Either way, the setting has been updated to allow public access. >>>>>>>>>> >>>>>>>>>> Please let me know if you continue to find otherwise. >>>>>>>>>> >>>>>>>>>> Joe (as list admin) >>>>>>>>>> -- >>>>>>>>>> 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 >>>>> -- >>>>> ***** >>>>> 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 b_a_denny at yahoo.com Fri Sep 11 16:00:53 2020 From: b_a_denny at yahoo.com (Barbara Denny) Date: Fri, 11 Sep 2020 23:00:53 +0000 (UTC) Subject: [ih] Packet Radio Software In-Reply-To: References: <1220703022.30538.1599607799133@mail.yahoo.com> Message-ID: <1757413748.1385481.1599865253391@mail.yahoo.com> It does look like the packet radios developed under the Packet Radio Program did not have over the air loading of software updates.? However there is a MILCOM 1990 paper entitled "Accomplishments of the DARPA SURAN Program" by David A. Beyer that mentions this capability (Dave provided the reference).? I also think I made use of this capability while preparing what may have been the last demo utilizing packet radios, in particular the LPRs. This demo was in Germany at the Warrior Prep Center.?? Radios were deployed in the field for this demo and one node was at Ramstein. I might be able to track down the date for this demo if anyone is interested. By the way, I believe the Packet Radio Program and SURAN Program had their own series of technical notes called PRTNs and SRNTNs.? SRNTNs definitely existed because there is a reference to a yet to be completed SRTN for the automatic over the air loading of software in Dave's paper.?? This might help people in searches for information. barbara On Wednesday, September 9, 2020, 3:21:48 AM PDT, Vint Cerf wrote: "upgraded packet radio" v On Tue, Sep 8, 2020 at 7:31 PM Barbara Denny via Internet-history wrote: ?Hi Thanks for the ien78 reference! It brings back memories, especially looking at the pictures. I will take a more detailed look soon.? BTW, in doing some quick wikipedia lookups regarding packet radio I noticed what may be a mistake.? I have heard of the EPR, VPR, IPR, and the LPR as names for the different?Packet Radio hardware.? A Wikipedia entry for prnet mentioned a UPR.? I have never heard of it before. Anyone out there know about this one?? Given that same article doesn't mention the VPR? I wonder if an error got propagated somehow.? barbara? ? ? On Tuesday, September 8, 2020, 09:29:38 AM PDT, Lawrence Stewart via Internet-history wrote:? ?I was peripherally involved in the PRNet activities in the Bay Area and went to a few quarterly meetings at SRI.? (I built an 1822 interface for the Alto and we used it to encapsulate PUP packets for transit over PRNet, linking two Xerox sites in Palo Alto*) The radios and radio software was built by Rockwell (nee Collins Radio) and my youthful read on the vibes at meetings was that the SRI/Arpa people did not think much of the software development practices.? One story I heard was that Rockwell management insisted on very tight control of the top secret source code.? This meant that the master copy was to be kept on punch cards in the manager?s office. So it seems unlikely to me that the radios would be reloading their software from neighbors, at least until after other folks were able to make modifications. * http://www.watersprings.org/pub/rfc/ien/ien78.pdf -L -- 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 Cerf1435 Woodhurst Blvd?McLean, VA 22102703-448-0965 until further notice From karl at cavebear.com Sat Sep 12 15:27:38 2020 From: karl at cavebear.com (Karl Auerbach) Date: Sat, 12 Sep 2020 15:27:38 -0700 Subject: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: <331a3ea9-ac1e-e4d1-93cb-58cde9c388a4@3kitty.org> References: <093c9532-94d1-7074-133b-61e4f050fc67@3kitty.org> <331a3ea9-ac1e-e4d1-93cb-58cde9c388a4@3kitty.org> Message-ID: <87310b35-e974-ee1c-ea30-8b5c78982cac@cavebear.com> For some reason my post never made it onto the internet history list itself.? Odd.? I hope it shows up eventually. Seventeen minutes for things to settle down after a route flap? You made a good prediction!? By today's standards that's a long time.? But its a whole lot better than the hours it often took in earlier days. (BTW, our internet architecture is lacking a layer, often called "association" or "session" that would lay on top of the transport and would allow fast application-level healing despite failures of transport connections and establishment of replacement connections (such as would be common in mobile situations.)? It turns out that such a layer would be extremely lightweight and not add a meaningful amount of overhead.? But because that was an ISO/OSI idea (but done badly) the Internet engineering community has not picked up on it. I worked at Wells Fargo for several years helping them to move into the "modern" age of computers and networks (circa 1982). And, like your experience, down time meant serious money.? It was amazing how much money sloshes through a large bank, especially around 3am when they have to meet their reserves requirements - it was a mad time of buying and selling huge blocks of money for to cover the reserve requirements for the next 24 hours.? If they missed, or if they couldn't get things to reconcile - then the regulations would shut the whole thing - the whole bank - down almost immediately. When I got into networking - around 1972 - I was working first on a project that closely resembled the movie "War Games" (but with real missile launches) and then I moved on to do secure network research for the US Joint Chiefs and later, for an unmentionable three-letter-agency just south of Baltimore.? So we were not only concerned with failure, we anticipated it in the most nuclear-blast-like of forms.? Our reliability and response time requirements were based, literally, on whether the US could make and deploy a timely "launch/not-launch" decision.? It was scary stuff. The Interop net was unique in many ways.? The time pressure to install was immense, the pressure to keep it alive was heavy, and something nobody ever mentions - we had to tear it down and get it onto trucks back home within a few hours.? We had to invent a lot of things - and Dan let us have the leeway to experiment, sometimes destructively or not strictly within the limits of "the rules", to get the net up.? (It also helped that we put our often large bar tab on Dan's hotel room bill.) Sometimes we got downright brutal.? For instance, just before opening of the first show in San Jose we had an utterly critical box that needed to be cabled up - but the access hole was too small.? So ten minutes before the doors opened Alex Latzko and I pulled out hammers and proceeded to pound the beejeebers out of the existing box's hole.? We metal fatigued the steel and got the cables in just as the doors opened.? It was ugly, and we destroyed the box, but it worked. We initially had a lot of trouble with the house electricians. At first they didn't mind us hanging our yellow hose Ethernet, but they felt that if it got in their way that they could simply cut it and splice it back together.? We later had troubles with telco people cutting and splicing our carefully balanced long DSL runs across the main rooms of convention centers.? It came to a head when union people insisted that we could not touch our own fiber optic plant.? I can't remember the details of how we resolved that in the short term - I had suggested arguing that fiber optics are light "pipes" and that the proper union would be the plumbers not the electrical workers.? In the long term we trained a lot of them about the right way to do things.? In New York we had to supplement that with thick wads of $20 and $50 bills. I am very concerned that today's networks are very difficult to diagnose and repair.?? My grandfather was a radio repair guy and my father had a business repairing TV's that nobody else could fix.? I kind of inherited those genes.?? One could tell a good TV guy just by looking at his toolkit.? For example, fixing one of those vacuum tube TV's required a lot of turning of coils and capacitors via screws on the back and looking how the picture changed.? A good TV guy had a little mirror that could be propped up in front of the TV so that the picture could be viewed while turning the screws.? The bad TV guy kept running between the front and the back. Our tools to detect problems and to make tests are primitive. Back in the mid 1990's I built a tool called "Dr. Watson, The Network Detective's Assistant" - it was the first internet butt-set designed to get a repair person up and running within a few seconds.? it worked well but I was not a good manager of my company and it died (parts of the tool were picked up by Fluke instruments.)? That tool was intended ultimately to be part of a much larger pathology-analysis system based on some of our medical systems. At Cisco I worked on a DARPA backed project to do "smart networks" - I was beginning to instrument routers so that they could detect when they began to wobble beyond limits established by models.? That detection would feed back into the models - often revealing incorrect configuration, a degradation, a failure, or, interestingly, a security penetration.? That work got short-circuited when I was elected to the ICANN board and that absorbed all of my time.? That work has never continued but it needs to be resurrected. I am extremely interested in adopting methods from biology into networking.? Living systems are amazingly robust.? The key is that they have, over time and evolution, acquired layers of responses to situations.? By comparison our computers and networking systems are extremely brittle and generally incorporate only one response to any situation.?? I really want to change that but to do so will require a massive change in our mental approach to networking as well as breaking some honored traditions, such as strict separation between layers of abstraction/protocols. With my lawyer hat on I keep wondering when the ax of liability is going to fall on network operators.? I gave a talk at NANOG last year about issues of carrier liability and how we ought to change our approach to engineering of the internet to make it more robust (based, somewhat, on lessons from biology. ;-) Here's the video/transcript of that talk: https://blog.iwl.com/blog/keynote-at-nanog-77-by-cto-karl-auerbach ??? ??? --karl-- From brian.e.carpenter at gmail.com Sat Sep 12 20:12:16 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 13 Sep 2020 15:12:16 +1200 Subject: [ih] NO "settlements" as part of Internet History In-Reply-To: References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> Message-ID: <442a4b6d-1384-dc66-0a28-c1406e4a611f@gmail.com> In my humble (non-American) opinion, some of the arguments made at that time were very self-serving. I think that Guy Almes and Steve Goldstein between them could explain better than me, but NSFnet always had an acceptable use policy that (since it was taxpayer-funded) only allowed "free" transit for traffic to or from a legitimate NSF user, i.e. one end or both ends of a flow had to be a research site. Clearly the taxpayer shouldn't pay for business-to-business traffic, and that fact was the business case for creating CIX. Neither NSFnet nor CIX was free of course; they just had very different funding sources. It was my understanding at the time that ANS CO+RE was created precisely to avoid cross-subsidy from NSF money. They did have the advantage of knowledge transfer. (All of this was of intense interest to us at CERN as we hosted a transatlantic link to NSFnet and we too had to ensure that the NSFnet AUP was respected. So we followed it pretty closely.) Of course the idea that there are no settlements in the Internet is a bit ridiculous. There are no settlements per "call" but connections to transit providers and/or IXPs cost money. Regards Brian Carpenter On 11-Sep-20 12:21, the keyboard of geoff goodfellow via Internet-history wrote: > On Thu, Sep 10, 2020 at 10:42 AM *Jack Haverty via Internet-history > > wrote* > : > >> CCITT was working on X.25, and creating X.75, to interconnect their >> networks. It was a natural evolution of the PTT's prior interconnection >> of their telephone networks. Later, as DDN marched down the X.25 path, >> the subsequent government Internet might have ended up based on >> X.25/X.75. If it worked. >> > > part and parcel of the X.25 and X.75 networking shibboleth was the notion > of "settlements" -- just like with the PTT's interconnection of their > telephone networks -- where The Fee for/of Transit was split along a > "calls" participants/networks transited. > > IIRC, Advanced Network and Services (ANS) tried to "imprint" the > settlements model on the fledgling Internet -- with them In The Middle > collecting a fee for transit (for commercial traffic) between networks as > well as for interconnection with The Budding commercial Internet upstarts > (PSI, ALTERNET, etc.) the resulting in the founding of the CIX, viz.: > > > *Data Network Raises Monopoly Fear* > By JOHN MARKOFF > The New York Times > December 19, 1991 > http://www.nytimes.com/1991 > /12/19/business/data-network-raises-monopoly-fear.html > > Soon after President Bush signed legislation calling for the creation of a > nationwide computer data "superhighway," a debate has erupted over whether > the Government gave an unfair advantage to a joint venture of I.B.M. MCI > that built and manages a key part of the network. > > The venture, known as Advanced Network and Services, manages a network > called NSFnet, which connects hundreds of research centers and > universities. NSFnet also manages links to dozens of other countries. All > these networks are collectively known as Internet. > > Some private competitors say Advanced Network and Services uses its favored > position to squeeze them out of the data-transmission market by > establishing rules that make it difficult to connect to NSFnet. > > *Traffic Has Doubled* > > NSFnet was founded by the National Science Foundation, a Federal agency, > and is composed of leased telephone lines that link special computers > called routers, which transmit packages of data to three million users in > 33 countries. Data traffic over the NSFnet backbone has doubled in the last > year. > > The Government wants to develop a national data highway for electronic > commerce, digital video transmissions to homes and vast electronic > libraries that could be drawn on by the nation's schools. > > Advanced Network and Services, based in Elmsford, N.Y., was set up last > year as a nonprofit corporation with $10 million from the International > Business Machines Corporation and the MCI Communications Corporation. > Earlier this year it set up a for-profit subsidiary, called ANS CO+RE > (pronounced core), to sell computer network services. That led some > competitors to complain that Advanced Network and Services would be able to > compete unfairly because of its arrangement with the Government. > > *Fear Loss of Innovation* > > People involved in planning for a national data network say it is essential > to provide for fair competition, which will lead rival companies to offer > creative and entrepreneurial services in the hope of building market share. > Without competiton, they say, the Government will have created a monopoly > that has little incentive to innovate. > > "This is the first major communication business to be born under the > deregulation era," said David Farber, a computer scientist at the > University of Pennsylvania and a pioneer in data networking. "This hasn't > happened since the growth of the telephone industry. You want it to be a > business that doesn't repeat the errors of the past." > > In recent years, the National Science Foundation has tried to shift its > operations and ownership of NSFnet to Advanced Network and Services. And it > will try to establish competition through contracts for networks to compete > with NSFnet next year. > > But there is no level playing field, complained William L. Schrader, > president of Performance Systems International Inc., a Reston, Va., company > that provides commercial data connections to Internet. He made public two > letters between officials of Advanced Network and Services and the National > Science Foundation that he said gave the company unfair control over access > to the network. The result, he added, was that the Government turned over > valuable public property to a private company. > > "It's like taking a Federal park and giving it to K Mart," Mr. Schrader > said. "It's not right, and it isn't going to stand." > > Performance Systems and several other companies have set up an alternative > to NSFnet, known as a CIX. Mr. Schrader said his company and the venture of > I.B.M. and MCI were competing for the same customers but unlike his rival > he lacked a Federal subsidy. He said he might ask the Internal Revenue > Service to look at the business relationship between Advanced Network's > nonprofit and for-profit operations. > > *'Very Competitive Environment'* > > Allan Weis, the president of Advanced Network, disputed that his company > had an unfair advantage. "It's a very competitive environment right now," > he said. > > At the National Science Foundation, Stephen Wolff, director of its > networking division, said I.B.M. and MCI had overbuilt the network and were > selling commercial service based on the excess capacity that was available. > > A number of organizations are working informally to settle the dispute. > > "I think it's a mess," said Mitchell D. Kapor, the founder of the Lotus > Development Corporation and now head of the Electronic Frontier Foundation, > a public-interest group focusing on public policy issues surrounding data > networks. "Nobody should have an unfair advantage." > > From touch at strayalpha.com Sat Sep 12 21:22:29 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 12 Sep 2020 21:22:29 -0700 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) Message-ID: Subject: Re: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) Date: Fri, 11 Sep 2020 14:56:57 -0700 From: Karl Auerbach To: Dan Lynch , Jack Haverty CC: internet-history at elists.isoc.org On 9/10/20 9:26 PM, Dan Lynch via Internet-history wrote: > ?I know it works. I saw it at Interop.? > > That became our tag line in our early marketing of Interop. Interop had two major parts, maybe three. - There was the "show net". - There were the vendors (who had to attach to the show net) - There were presentations/papers. The show was one of the critical drivers that forced vendors to have working products. Interop was a loud bell that rang once or twice a year. And lord help the vendor whose products were not ready when that bell tolled. (Another major driver of vendors was the now largely forgotten Air Force ULANA procurement.) There were a lot of companies who thought they were interoperable but discovered otherwise at the show. We were not shy about turning off vendors that were so non-interoperable that they were causing problems. The importance of Interop in forcing early Internet products to work together can not be overstated. For fifteen or so years I was part of the core volunteer "NOC Team" that designed, installed, and operated that net. It was not a small net - tens of thousands of hosts, lots of internal routing issues (we had massive redundancy), multiple external providers (hence a lot of BGP juggling), big DNS, heavy traffic loads, external attacks, etc Many of the early Interop show networks were designed at my house in Santa Cruz. (I also met my wife via the show net; she was working at Dan's ACE [Another Cute Employee] and charge of the volunteer core team.) Here's a video or us installing the '93 net (either San Francisco or DC) that Dan Lynch had made (by Linda Fefferman). (I spoke to her a few years back and she still had the raw betamax tapes from which this video was made.) https://youtu.be/SMkKIaHee4c Here's a few, very few, early photos: https://www.cavebear.com/archive/interop/ We had a class A /8 (45.x.x.x) to play around with. We subnetted it heavily. In the early days we also carried DECnet, Netware/IPX, as well as IPv4 (including IP multicast). We also did IPv6 fairly early. We (John Romkey, Simon Hackett, and I) showed the first two Internet Toasters (yes there were two) at the 1989 show in San Jose. Unfortunately on the first day we forgot to bring bread - so we had to toast and re-toast the same slice. In 1997 during one of the shows I called from the show floor over an early IP based phone into an NTIA conference call - for most of the participants that was the first IP based phone call they had ever heard. And during that same show I used a wi-fi and IP multicast battery powered camera (mounted on a hard hat) to broadcast interviews on the show floor - I kinda looked like a mad bomber, my wife called it the "husband cam" because she could see who I was looking at as I wandered the show floor.) We quickly developed a rib-and-spine approach for convention centers. In the San Jose and DC shows we used lots and lots of routers - Cisco, Wellfleet, and 3COM. Management of that was a pain, so we quickly developed two management networks - a so called "spy" net which used remote controlled optical mirrors so that we could create direct bi-directional ethernet paths onto any part of the show network. We used that for monitoring and getting to disconnected parts. We also had a separate management net that led us to the console ports of all the routers (and switches.) One of our important developments was the ability to pre-wire a convention center in a warehouse - by the time we were doing the Atlanta shows it took 45 fully loaded trucks to haul our gear from our warehouse to the convention center. Dave Bridgham and I considered bying a C 130 to get some of the gear around quickly. And we really stressed out the local Frys. We developed a rubber-bungee strap system so that we could dangle the booth drops from the convention center ceiling, but above the roofs of the trucks that drive around the show floor during setup. After the show the bungees would pull the drops back up out of the way of the trucks. We also learned how to co-exist on friendly terms with the local unions - many of workers were not then familiar with network tech and were more than willing to work with us to learn.) We also developed a portable fiber plant using a massive "pink" cable with some serious (and expensive) quick-connect plug/socket devices - we bought out the entire national supply of those (and discovered that we had depleted the US national military stockpile of 'em.) We also got really good at moving a /8 around the world - sometimes in a matter of days. During hook-up we would stress-out most providers BGP implementations due to the up/down cycles during hook-up. That's when many providers learned about route flapping and damping. Our core team evolved over the years - at the start it was small, with people like Simon Hackett (https://www.cavebear.com/archive/interop/Internode ); John Romkey, Dave Bridgham, Stev Knowles, Peter deVris (FTP software); Geoff Baehr (Sun); Stuart Vance (TGV); me (Epilogue Technology, Empirical Tools and Toys); etc. The first year or two was mostly yellow-hose ethernet. Then David Systems and Synoptics turned us onto 10-Base-T. Which we mis-wired with stranded-wire connectors and had to re-connect the entire show floor (by hand) overnight. Eventually we got good with fiber, managed by David Steele (who did some of the fiber plans for the 777 aircraft) and Merike Kaeo (Merike also handled our early FDDI deployment - during which we found flaws in the specifications and vendors were deploying fixes during the show.) And we got really good at both local routing and multi-homed external routing. Our three router goddesses were Cindi Jung (3COM), Robin Littlefield (Wellfleet), and Chris Pecina (Cisco?) We weren't beyond pulling a few legs. A surprising number of people (and tech journalists) believed this press release we issued: https://www.cavebear.com/archive/cavebear/catalogue/maypressrelease.html One year when we had something like 90 routers on the show floor we bought a bunch of spacey-looking TV dish antennae, put one on each router, and aimed them at a disco ball on the convention center ceiling - and told people that it was a low-earth orbit geosynchronous satellite. I gave the first "tour" of our show net at the first DC show to Jack Haverty and Vint Cerf. That tour evolved into a regular part of the show. (That may have been the year when we got snowed into the convention center.) Over the years our group grew - there are a few hundred members by now - and we got really good a "commando networking". We could wire up a big convention center (like Atlanta) plus hotels (in Atlanta we ran illicit cables through active train tunnels.) We got good at running laser aimed links between hotel room windows and remote rooftops. Much of what we learned made its way out to the ISP world. I developed test and diagnostic tools that found their way into products by Fluke and others. Other ideas vanished - like my demo of inserting words into VoIP calls or our demo of a RAID 5 array made of USB flash drives via iSCSI over wi-fi. --karl-- From touch at strayalpha.com Sat Sep 12 21:25:02 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 12 Sep 2020 21:25:02 -0700 Subject: [ih] Found the bug - a word to avoid.... Message-ID: Hi, all, So here?s what happened at least to Karl?s attempted post - and everyone (including me) in their attempt to repost. The word is ?h o o k u p? (without the spaces). You can say ?hook-up? or ?hook up?. But you can?t put the letters together without spaces or hyphens. Why? ? I have NO IDEA ? I?m going to claim this is a bug because it?s not on any of the pages I?ve configured. It?s not triggering the spam filter. It?s just a bug somewhere. I?ll report it, but in the meantime - - if you had a post fall on the floor, please check if you used that magic word. If so, please re-post with a hyphen or space Joe From geoff at iconia.com Sat Sep 12 21:33:37 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sat, 12 Sep 2020 18:33:37 -1000 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: References: Message-ID: your truly would summarily posit that if there is one "forbidden" word there are likely others...? WHO decides what they are and WHY is any mail sent with any of them just /dev/null'd? isn't one of The Central Tenets of email: messages are never "lost" and if an email cannot be delivered for whatever a reason, then the sender of said message is summarily notified via a "bounce" message of some sort? ERGO, it seems that the IH list apparatus or some part there of is in summary violation with This Central Email Tenet, no? geoff On Sat, Sep 12, 2020 at 6:25 PM Joseph Touch via Internet-history < internet-history at elists.isoc.org> wrote: > Hi, all, > > So here?s what happened at least to Karl?s attempted post - and everyone > (including me) in their attempt to repost. > > The word is ?h o o k u p? (without the spaces). > > You can say ?hook-up? or ?hook up?. But you can?t put the letters together > without spaces or hyphens. > > Why? > > ? I have NO IDEA ? > > I?m going to claim this is a bug because it?s not on any of the pages I?ve > configured. It?s not triggering the spam filter. It?s just a bug somewhere. > > I?ll report it, but in the meantime - > > - if you had a post fall on the floor, please check if you used > that magic word. If so, please re-post with a hyphen or space > > Joe > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From touch at strayalpha.com Sat Sep 12 21:37:59 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 12 Sep 2020 21:37:59 -0700 Subject: [ih] A note on mailing list problems In-Reply-To: References: Message-ID: Hi, all, Please note - I found this bug as follows: - I posted tests to the list and checked the archives - that included trying Karl?s post, which failed - so I did a binary search to find out WHERE his post failed - at which point I found the specific word involved This required no special access or privilege. I.e., consider this an invitation to debug things on your end in the future, esp. before posting for help from the ?list admin?. Joe From touch at strayalpha.com Sat Sep 12 21:43:51 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 12 Sep 2020 21:43:51 -0700 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: References: Message-ID: Geoff, It?s not spam (I turned spam rejection off during the test). I administer this list as supported at no cost by ISOC. I didn?t write Mailman and don?t know why it didn?t send a bounce message. If you find out, please do let us know and I?ll see what I can do to get it fixed. Joe > On Sep 12, 2020, at 9:33 PM, the keyboard of geoff goodfellow wrote: > > your truly would summarily posit that if there is one "forbidden" word there are likely others...? > > WHO decides what they are and WHY is any mail sent with any of them just /dev/null'd? > > isn't one of The Central Tenets of email: messages are never "lost" and if an email cannot be delivered for whatever a reason, then the sender of said message is summarily notified via a "bounce" message of some sort? > > ERGO, it seems that the IH list apparatus or some part there of is in summary violation with This Central Email Tenet, no? > > geoff > > On Sat, Sep 12, 2020 at 6:25 PM Joseph Touch via Internet-history > wrote: > Hi, all, > > So here?s what happened at least to Karl?s attempted post - and everyone (including me) in their attempt to repost. > > The word is ?h o o k u p? (without the spaces). > > You can say ?hook-up? or ?hook up?. But you can?t put the letters together without spaces or hyphens. > > Why? > > ? I have NO IDEA ? > > I?m going to claim this is a bug because it?s not on any of the pages I?ve configured. It?s not triggering the spam filter. It?s just a bug somewhere. > > I?ll report it, but in the meantime - > > - if you had a post fall on the floor, please check if you used that magic word. If so, please re-post with a hyphen or space > > Joe > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > From brian.e.carpenter at gmail.com Sat Sep 12 21:57:09 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 13 Sep 2020 16:57:09 +1200 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: References: Message-ID: I wonder if this message will make it: Quoting Wikipedia, "Scunthorpe (/?sk?n???rp/) is a large market and industrial town in the North Lincolnshire borough in Lincolnshire, England." In the early days of kiddie filters, that town could not be mentioned. Wikipedia has an article dedicated to the Scunthorpe problem. I think it's incomplete, because I definitely remember reading about it as a specific problem for the first efforts at content filtering in the UK. But it doesn't mention the H-word as a problem. I don't think any list server should be running snowflake filters. Regards Brian Carpenter On 13-Sep-20 16:33, the keyboard of geoff goodfellow via Internet-history wrote: > your truly would summarily posit that if there is one "forbidden" word > there are likely others...? > > WHO decides what they are and WHY is any mail sent with any of them just > /dev/null'd? > > isn't one of The Central Tenets of email: messages are never "lost" and if > an email cannot be delivered for whatever a reason, then the sender of said > message is summarily notified via a "bounce" message of some sort? > > ERGO, it seems that the IH list apparatus or some part there of is in > summary violation with This Central Email Tenet, no? > > geoff > > On Sat, Sep 12, 2020 at 6:25 PM Joseph Touch via Internet-history < > internet-history at elists.isoc.org> wrote: > >> Hi, all, >> >> So here?s what happened at least to Karl?s attempted post - and everyone >> (including me) in their attempt to repost. >> >> The word is ?h o o k u p? (without the spaces). >> >> You can say ?hook-up? or ?hook up?. But you can?t put the letters together >> without spaces or hyphens. >> >> Why? >> >> ? I have NO IDEA ? >> >> I?m going to claim this is a bug because it?s not on any of the pages I?ve >> configured. It?s not triggering the spam filter. It?s just a bug somewhere. >> >> I?ll report it, but in the meantime - >> >> - if you had a post fall on the floor, please check if you used >> that magic word. If so, please re-post with a hyphen or space >> >> Joe >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> >> > From casner at acm.org Sat Sep 12 21:58:04 2020 From: casner at acm.org (Stephen Casner) Date: Sat, 12 Sep 2020 21:58:04 -0700 (PDT) Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020, Joseph Touch via Internet-history wrote: > I administer this list as supported at no cost by ISOC. And we appreciate it. > I didn't write Mailman and don't know why it didn't send a bounce > message. Perhaps ISOC's Mailman was not where the problem occurred. -- Steve From touch at strayalpha.com Sat Sep 12 22:05:14 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 12 Sep 2020 22:05:14 -0700 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: References: Message-ID: <70CD2499-146C-40BC-997D-18CE75091E32@strayalpha.com> > On Sep 12, 2020, at 9:58 PM, Stephen Casner wrote: > > On Sat, 12 Sep 2020, Joseph Touch via Internet-history wrote: > >> I administer this list as supported at no cost by ISOC. > > And we appreciate it. > >> I didn't write Mailman and don't know why it didn't send a bounce >> message. > > Perhaps ISOC's Mailman was not where the problem occurred. If not, then why would it happen for me when sending a message with the single word ?hook-up? in it? (Without the hyphen)? I don?t use the same mail system on my end as either Karl or Geoff. Joe From touch at strayalpha.com Sat Sep 12 22:16:08 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 12 Sep 2020 22:16:08 -0700 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: References: Message-ID: Hi, all, > On Sep 12, 2020, at 9:57 PM, Brian E Carpenter wrote: > > I don't think any list server should be running snowflake filters. Although I agree, I also was not aware we were - until I just tested it (sorry Brian and Geoff, who were collateral damage in my test). There isn?t such a configuration in the Mailman system we?re running. It?s not triggered in the spam filters. Nobody informed me when we setup this list. I will contact ISOC to see what they?re doing, in addition to Mailman, to filter mail and let them know. Joe From geoff at iconia.com Sat Sep 12 22:24:17 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sat, 12 Sep 2020 19:24:17 -1000 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: <70CD2499-146C-40BC-997D-18CE75091E32@strayalpha.com> References: <70CD2499-146C-40BC-997D-18CE75091E32@strayalpha.com> Message-ID: joe, please de-confuse yours truly: not only did it happen to you, but it also happened to karl as well as yours truly when sending a message with the single word ?hook-up? in it? (Without the hyphen). in all three cases, an email sent to IH with the word ?hook-up? (Without the hyphen) did not go out to the list, but instead it went to /dev/null -- with NO notification to the sender (or anyone). isn't that consistency between us three and not just unique to you? with eternal gratitude for your being our list admin, geoff On Sat, Sep 12, 2020 at 7:05 PM Joseph Touch wrote: > > > > On Sep 12, 2020, at 9:58 PM, Stephen Casner wrote: > > > > On Sat, 12 Sep 2020, Joseph Touch via Internet-history wrote: > > > >> I administer this list as supported at no cost by ISOC. > > > > And we appreciate it. > > > >> I didn't write Mailman and don't know why it didn't send a bounce > >> message. > > > > Perhaps ISOC's Mailman was not where the problem occurred. > > If not, then why would it happen for me when sending a message with the > single word ?hook-up? in it? (Without the hyphen)? > > I don?t use the same mail system on my end as either Karl or Geoff. > > Joe > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From touch at strayalpha.com Sat Sep 12 22:28:00 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 12 Sep 2020 22:28:00 -0700 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: References: <70CD2499-146C-40BC-997D-18CE75091E32@strayalpha.com> Message-ID: > On Sep 12, 2020, at 10:24 PM, the keyboard of geoff goodfellow wrote: > > joe, please de-confuse yours truly: > > not only did it happen to you, but it also happened to karl as well as yours truly when sending a message with the single word ?hook-up? in it? (Without the hyphen). It?s, as Brian put it, a ?snowflake filter? at ISOC - one that is not part of the Mailman configuration, but it is part of the ISOC processing. > in all three cases, an email sent to IH with the word ?hook-up? (Without the hyphen) did not go out to the list, but instead it went to /dev/null -- with NO notification to the sender (or anyone). > > isn't that consistency between us three and not just unique to you? It is - I wasn?t saying it was unique to me; I was saying it was not. Joe > > with eternal gratitude for your being our list admin, > > geoff > > > > On Sat, Sep 12, 2020 at 7:05 PM Joseph Touch > wrote: > > > > On Sep 12, 2020, at 9:58 PM, Stephen Casner > wrote: > > > > On Sat, 12 Sep 2020, Joseph Touch via Internet-history wrote: > > > >> I administer this list as supported at no cost by ISOC. > > > > And we appreciate it. > > > >> I didn't write Mailman and don't know why it didn't send a bounce > >> message. > > > > Perhaps ISOC's Mailman was not where the problem occurred. > > If not, then why would it happen for me when sending a message with the single word ?hook-up? in it? (Without the hyphen)? > > I don?t use the same mail system on my end as either Karl or Geoff. > > Joe > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > From touch at strayalpha.com Sat Sep 12 22:28:18 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 12 Sep 2020 22:28:18 -0700 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: <70CD2499-146C-40BC-997D-18CE75091E32@strayalpha.com> References: <70CD2499-146C-40BC-997D-18CE75091E32@strayalpha.com> Message-ID: <91B5BED1-88BD-4819-9A29-52C3B3440DB3@strayalpha.com> > On Sep 12, 2020, at 10:05 PM, Joseph Touch via Internet-history wrote: > > > >> On Sep 12, 2020, at 9:58 PM, Stephen Casner wrote: >> >> On Sat, 12 Sep 2020, Joseph Touch via Internet-history wrote: >> >>> I administer this list as supported at no cost by ISOC. >> >> And we appreciate it. >> >>> I didn't write Mailman and don't know why it didn't send a bounce >>> message. >> >> Perhaps ISOC's Mailman was not where the problem occurred. > > If not, then why would it happen for me when sending a message with the single word ?hook-up? in it? (Without the hyphen)? > > I don?t use the same mail system on my end as either Karl or Geoff. To clarify - the issue is definitely at ISOC. It might not be inside the Mailman software; there appears to be (as Brian put it) a ?snowflake filter? running somewhere in their receive processing path. Again, I?ve contacted ISOC to find out. Joe From geoff at iconia.com Sat Sep 12 22:41:24 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sat, 12 Sep 2020 19:41:24 -1000 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: References: <70CD2499-146C-40BC-997D-18CE75091E32@strayalpha.com> Message-ID: thanks joe and here's what yours truly suspects is going on: ISOC's mail lists is running PostFix, viz.: host elists.isoc.org elists.isoc.org has address 4.31.198.48 elists.isoc.org has IPv6 address 2001:1900:3001:11::30 elists.isoc.org mail is handled by 10 elists.isoc.org. telnet elists.isoc.org. smtp Trying 2001:1900:3001:11::30... Connected to elists.isoc.org. Escape character is '^]'. 220 elists.isoc.org ESMTP *Postfix* quit 221 2.0.0 Bye Connection closed by foreign host. Postfix, like Sendmail (that yours truly runs), have Milters, viz.: Postfix before-queue Milter support ------------------------------ Introduction Postfix implements support for the Sendmail version 8 Milter (mail filter) protocol. This protocol is used by applications that run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT), SMTP commands (HELO, MAIL FROM, etc.) as well as mail content (headers and body). All this happens before mail is queued. The reason for adding Milter support to Postfix is that there exists a large collection of applications, not only to block unwanted mail, but also to verify authenticity (examples: OpenDKIM and DMARC ) or to digitally sign mail (example: OpenDKIM ). Having yet another Postfix-specific version of all that software is a poor use of human and system resources. The Milter protocol has evolved over time, and different Postfix versions implement different feature sets. See the workarounds and limitations sections at the end of this document for differences between Postfix and Sendmail implementations... [...] http://www.postfix.org/MILTER_README.html ERGO, it is further posited that the ISOC mail list MTA Postfix MTA is Very Likely employing a "snowflake" Milter of a sort that does not like certain words and one of those words is likely ?hook-up? (Without the hyphen). geoff (who is still immersed in system and networking "janitoring" email gizzards) On Sat, Sep 12, 2020 at 7:28 PM Joseph Touch wrote: > > > On Sep 12, 2020, at 10:24 PM, the keyboard of geoff goodfellow < > geoff at iconia.com> wrote: > > joe, please de-confuse yours truly: > > not only did it happen to you, but it also happened to karl as well as > yours truly when sending a message with the single word ?hook-up? in it? > (Without the hyphen). > > > It?s, as Brian put it, a ?snowflake filter? at ISOC - one that is not part > of the Mailman configuration, but it is part of the ISOC processing. > > in all three cases, an email sent to IH with the word ?hook-up? (Without > the hyphen) did not go out to the list, but instead it went to /dev/null -- > with NO notification to the sender (or anyone). > > isn't that consistency between us three and not just unique to you? > > > It is - I wasn?t saying it was unique to me; I was saying it was not. > > Joe > > > with eternal gratitude for your being our list admin, > > geoff > > > > On Sat, Sep 12, 2020 at 7:05 PM Joseph Touch wrote: > >> >> >> > On Sep 12, 2020, at 9:58 PM, Stephen Casner wrote: >> > >> > On Sat, 12 Sep 2020, Joseph Touch via Internet-history wrote: >> > >> >> I administer this list as supported at no cost by ISOC. >> > >> > And we appreciate it. >> > >> >> I didn't write Mailman and don't know why it didn't send a bounce >> >> message. >> > >> > Perhaps ISOC's Mailman was not where the problem occurred. >> >> If not, then why would it happen for me when sending a message with the >> single word ?hook-up? in it? (Without the hyphen)? >> >> I don?t use the same mail system on my end as either Karl or Geoff. >> >> Joe >> >> > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From gtaylor at tnetconsulting.net Sat Sep 12 23:19:52 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 13 Sep 2020 00:19:52 -0600 Subject: [ih] Found the bug - a word to avoid.... In-Reply-To: References: Message-ID: <11385cc3-9844-0dab-52a0-4c5374900e7f@spamtrap.tnetconsulting.net> On 9/12/20 10:33 PM, the keyboard of geoff goodfellow via Internet-history wrote: > your truly would summarily posit that if there is one "forbidden" > word there are likely others...? Agreed. > WHO decides what they are and WHY is any mail sent with any of them > just /dev/null'd? My bet is a former admin that was dealing with a spite of unwanted messages that had the trigger phrase(s) in them. > isn't one of The Central Tenets of email: messages are never "lost" > and if an email cannot be delivered for whatever a reason, then the > sender of said message is summarily notified via a "bounce" message > of some sort? Yes.* * I expect that SMTP successfully delivered the message from the sender's server to the receiver's server. So, SMTP didn't loose the email. I speculate that the problem is somewhere in the receiving MTA or the LDA that delivers the messages into Mailman. > ERGO, it seems that the IH list apparatus or some part there of is > in summary violation with This Central Email Tenet, no? Yes and no. See above for why. -- Grant. . . . unix || die From karl at cavebear.com Sun Sep 13 01:18:21 2020 From: karl at cavebear.com (Karl Auerbach) Date: Sun, 13 Sep 2020 01:18:21 -0700 Subject: [ih] End-to-end - Was: Re: Found the bug - a word to avoid.... In-Reply-To: References: Message-ID: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> My imaginary hat is being tipped in very real thanks and cheers to all the effort that went into figuring where a couple of my postings went. If we step back we might see this event as a kind of failure of the end-to-end principle - something in the middle decided to muck with the data moving between the endpoints (in this case the end-points being the members of this mailing list.) The notion of end-to-end clarity and transparency - the notion that data should flow, unvexed, unchanged - is valuable. I have considerable concern that the generation of people who see end-to-end as a valuable principal is aging away and being replaced by a new generation who perceive the Internet as a bag of their favorite applications.? Their concern is that those applications work; there is not a lot of honor or credit given to elegant underlying end-to-end plumbing.? That, in turn, opens the door to application layer proxies and gateways that generally appear transparent but that every now and then clamp down on some traffic or some users. A few years back I wrote a rather pessimistic piece, almost Blade Runner dark, about a view of the net of the future being shaped into a world of island networks connected by highly guarded bridges.? It's a future that I don't want, but I have yet to be convinced that that future is not possible or not likely. https://www.cavebear.com/cavebear-blog/internet_quo_vadis/ (It's not a short piece - it runs to a bit over 7200 words.) ??? ??? --karl-- From vint at google.com Sun Sep 13 04:56:08 2020 From: vint at google.com (Vint Cerf) Date: Sun, 13 Sep 2020 07:56:08 -0400 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: References: Message-ID: sounds to me like a history of Interop would be a big contribution to the record. v On Sun, Sep 13, 2020 at 12:22 AM Joseph Touch via Internet-history < internet-history at elists.isoc.org> wrote: > Subject: Re: [ih] Interop as part of Internet History (was Re: Fwd: Fwd: > List archives (Was: Exterior Gateway Protocol)) > Date: Fri, 11 Sep 2020 14:56:57 -0700 > From: Karl Auerbach > To: Dan Lynch , Jack Haverty < > jack at 3kitty.org> > CC: internet-history at elists.isoc.org internet-history at elists.isoc.org> > > On 9/10/20 9:26 PM, Dan Lynch via Internet-history wrote: > > ?I know it works. I saw it at Interop.? > > > > That became our tag line in our early marketing of Interop. > > Interop had two major parts, maybe three. > > - There was the "show net". > > - There were the vendors (who had to attach to the show net) > > - There were presentations/papers. > > The show was one of the critical drivers that forced vendors to have > working products. > > Interop was a loud bell that rang once or twice a year. And lord help the > vendor whose products were not ready when that bell tolled. > > (Another major driver of vendors was the now largely forgotten Air Force > ULANA procurement.) > > There were a lot of companies who thought they were interoperable but > discovered otherwise at the show. We were not shy about turning off vendors > that were so non-interoperable that they were causing problems. > > The importance of Interop in forcing early Internet products to work > together can not be overstated. > > For fifteen or so years I was part of the core volunteer "NOC Team" that > designed, installed, and operated that net. > > It was not a small net - tens of thousands of hosts, lots of internal > routing issues (we had massive redundancy), multiple external providers > (hence a lot of BGP juggling), big DNS, heavy traffic loads, external > attacks, etc > > Many of the early Interop show networks were designed at my house in Santa > Cruz. > > (I also met my wife via the show net; she was working at Dan's ACE > [Another Cute Employee] and charge of the volunteer core team.) > > Here's a video or us installing the '93 net (either San Francisco or DC) > that Dan Lynch had made (by Linda Fefferman). (I spoke to her a few years > back and she still had the raw betamax tapes from which this video was > made.) > > https://youtu.be/SMkKIaHee4c > > Here's a few, very few, early photos: > > https://www.cavebear.com/archive/interop/ < > https://www.cavebear.com/archive/interop/> > > We had a class A /8 (45.x.x.x) to play around with. We subnetted it > heavily. > > In the early days we also carried DECnet, Netware/IPX, as well as IPv4 > (including IP multicast). We also did IPv6 fairly early. > > We (John Romkey, Simon Hackett, and I) showed the first two Internet > Toasters (yes there were two) at the 1989 show in San Jose. Unfortunately > on the first day we forgot to bring bread - so we had to toast and re-toast > the same slice. > > In 1997 during one of the shows I called from the show floor over an early > IP based phone into an NTIA conference call - for most of the participants > that was the first IP based phone call they had ever heard. > > And during that same show I used a wi-fi and IP multicast battery powered > camera (mounted on a hard hat) to broadcast interviews on the show floor - > I kinda looked like a mad bomber, my wife called it the "husband cam" > because she could see who I was looking at as I wandered the show floor.) > > We quickly developed a rib-and-spine approach for convention centers. In > the San Jose and DC shows we used lots and lots of routers - Cisco, > Wellfleet, and 3COM. > > Management of that was a pain, so we quickly developed two management > networks - a so called "spy" net which used remote controlled optical > mirrors so that we could create direct bi-directional ethernet paths onto > any part of the show network. We used that for monitoring and getting to > disconnected parts. We also had a separate management net that led us to > the console ports of all the routers (and switches.) > > One of our important developments was the ability to pre-wire a convention > center in a warehouse - by the time we were doing the Atlanta shows it took > 45 fully loaded trucks to haul our gear from our warehouse to the > convention center. Dave Bridgham and I considered bying a C 130 to get some > of the gear around quickly. And we really stressed out the local Frys. > > We developed a rubber-bungee strap system so that we could dangle the > booth drops from the convention center ceiling, but above the roofs of the > trucks that drive around the show floor during setup. After the show the > bungees would pull the drops back up out of the way of the trucks. We also > learned how to co-exist on friendly terms with the local unions - many of > workers were not then familiar with network tech and were more than willing > to work with us to learn.) > > We also developed a portable fiber plant using a massive "pink" cable with > some serious (and expensive) quick-connect plug/socket devices - we bought > out the entire national supply of those (and discovered that we had > depleted the US national military stockpile of 'em.) > > We also got really good at moving a /8 around the world - sometimes in a > matter of days. During hook-up we would stress-out most providers BGP > implementations due to the up/down cycles during hook-up. That's when many > providers learned about route flapping and damping. > > Our core team evolved over the years - at the start it was small, with > people like Simon Hackett ( > https://www.cavebear.com/archive/interop/Internode < > https://www.cavebear.com/archive/interop/Internode>); John Romkey, Dave > Bridgham, Stev Knowles, Peter deVris (FTP software); Geoff Baehr (Sun); > Stuart Vance (TGV); me (Epilogue Technology, Empirical Tools and Toys); etc. > > The first year or two was mostly yellow-hose ethernet. > > Then David Systems and Synoptics turned us onto 10-Base-T. Which we > mis-wired with stranded-wire connectors and had to re-connect the entire > show floor (by hand) overnight. > > Eventually we got good with fiber, managed by David Steele (who did some > of the fiber plans for the 777 aircraft) and Merike Kaeo (Merike also > handled our early FDDI deployment - during which we found flaws in the > specifications and vendors were deploying fixes during the show.) And we > got really good at both local routing and multi-homed external routing. Our > three router goddesses were Cindi Jung (3COM), Robin Littlefield > (Wellfleet), and Chris Pecina (Cisco?) > > We weren't beyond pulling a few legs. A surprising number of people (and > tech journalists) believed this press release we issued: > > https://www.cavebear.com/archive/cavebear/catalogue/maypressrelease.html < > https://www.cavebear.com/archive/cavebear/catalogue/maypressrelease.html> > > One year when we had something like 90 routers on the show floor we bought > a bunch of spacey-looking TV dish antennae, put one on each router, and > aimed them at a disco ball on the convention center ceiling - and told > people that it was a low-earth orbit geosynchronous satellite. > > I gave the first "tour" of our show net at the first DC show to Jack > Haverty and Vint Cerf. That tour evolved into a regular part of the show. > (That may have been the year when we got snowed into the convention center.) > > Over the years our group grew - there are a few hundred members by now - > and we got really good a "commando networking". We could wire up a big > convention center (like Atlanta) plus hotels (in Atlanta we ran illicit > cables through active train tunnels.) We got good at running laser aimed > links between hotel room windows and remote rooftops. > > Much of what we learned made its way out to the ISP world. I developed > test and diagnostic tools that found their way into products by Fluke and > others. > > Other ideas vanished - like my demo of inserting words into VoIP calls or > our demo of a RAID 5 array made of USB flash drives via iSCSI over wi-fi. > > --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 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From vint at google.com Sun Sep 13 05:02:58 2020 From: vint at google.com (Vint Cerf) Date: Sun, 13 Sep 2020 08:02:58 -0400 Subject: [ih] NO "settlements" as part of Internet History In-Reply-To: <442a4b6d-1384-dc66-0a28-c1406e4a611f@gmail.com> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> <442a4b6d-1384-dc66-0a28-c1406e4a611f@gmail.com> Message-ID: Brian, in 1988 the then Federal Networking Council (or its predecessor, the FRICC) gave me permission to connect the commercial MCI Mail to the NSFNET backbone. This connection occurred in 1989, the same year that UUNET, PSINET and CERFNET came into operation and, I think, interconnected at the CIX. Other email services (Compuserve, OnTyme, Telemail) were also given permission to connect. In 1992 legislation was passed to allow this formally (Boucher Bill I thinik?). v On Sat, Sep 12, 2020 at 11:12 PM Brian E Carpenter via Internet-history < internet-history at elists.isoc.org> wrote: > In my humble (non-American) opinion, some of the arguments made at that > time were very self-serving. I think that Guy Almes and Steve Goldstein > between them could explain better than me, but NSFnet always had an > acceptable use policy that (since it was taxpayer-funded) only allowed > "free" transit for traffic to or from a legitimate NSF user, i.e. one end > or both ends of a flow had to be a research site. Clearly the taxpayer > shouldn't pay for business-to-business traffic, and that fact was the > business case for creating CIX. > > Neither NSFnet nor CIX was free of course; they just had very different > funding sources. It was my understanding at the time that ANS CO+RE was > created precisely to avoid cross-subsidy from NSF money. They did have > the advantage of knowledge transfer. > > (All of this was of intense interest to us at CERN as we hosted a > transatlantic link to NSFnet and we too had to ensure that the NSFnet > AUP was respected. So we followed it pretty closely.) > > Of course the idea that there are no settlements in the Internet is > a bit ridiculous. There are no settlements per "call" but connections > to transit providers and/or IXPs cost money. > > Regards > Brian Carpenter > > On 11-Sep-20 12:21, the keyboard of geoff goodfellow via Internet-history > wrote: > > On Thu, Sep 10, 2020 at 10:42 AM *Jack Haverty via Internet-history > > > > wrote* > > : > > > >> CCITT was working on X.25, and creating X.75, to interconnect their > >> networks. It was a natural evolution of the PTT's prior interconnection > >> of their telephone networks. Later, as DDN marched down the X.25 path, > >> the subsequent government Internet might have ended up based on > >> X.25/X.75. If it worked. > >> > > > > part and parcel of the X.25 and X.75 networking shibboleth was the notion > > of "settlements" -- just like with the PTT's interconnection of their > > telephone networks -- where The Fee for/of Transit was split along a > > "calls" participants/networks transited. > > > > IIRC, Advanced Network and Services (ANS) tried to "imprint" the > > settlements model on the fledgling Internet -- with them In The Middle > > collecting a fee for transit (for commercial traffic) between networks as > > well as for interconnection with The Budding commercial Internet upstarts > > (PSI, ALTERNET, etc.) the resulting in the founding of the CIX, viz.: > > > > > > *Data Network Raises Monopoly Fear* > > By JOHN MARKOFF > > The New York Times > > December 19, 1991 > > http://www.nytimes.com/1991 > > /12/19/business/data-network-raises-monopoly-fear.html > > > > Soon after President Bush signed legislation calling for the creation of > a > > nationwide computer data "superhighway," a debate has erupted over > whether > > the Government gave an unfair advantage to a joint venture of I.B.M. MCI > > that built and manages a key part of the network. > > > > The venture, known as Advanced Network and Services, manages a network > > called NSFnet, which connects hundreds of research centers and > > universities. NSFnet also manages links to dozens of other countries. All > > these networks are collectively known as Internet. > > > > Some private competitors say Advanced Network and Services uses its > favored > > position to squeeze them out of the data-transmission market by > > establishing rules that make it difficult to connect to NSFnet. > > > > *Traffic Has Doubled* > > > > NSFnet was founded by the National Science Foundation, a Federal agency, > > and is composed of leased telephone lines that link special computers > > called routers, which transmit packages of data to three million users in > > 33 countries. Data traffic over the NSFnet backbone has doubled in the > last > > year. > > > > The Government wants to develop a national data highway for electronic > > commerce, digital video transmissions to homes and vast electronic > > libraries that could be drawn on by the nation's schools. > > > > Advanced Network and Services, based in Elmsford, N.Y., was set up last > > year as a nonprofit corporation with $10 million from the International > > Business Machines Corporation and the MCI Communications Corporation. > > Earlier this year it set up a for-profit subsidiary, called ANS CO+RE > > (pronounced core), to sell computer network services. That led some > > competitors to complain that Advanced Network and Services would be able > to > > compete unfairly because of its arrangement with the Government. > > > > *Fear Loss of Innovation* > > > > People involved in planning for a national data network say it is > essential > > to provide for fair competition, which will lead rival companies to offer > > creative and entrepreneurial services in the hope of building market > share. > > Without competiton, they say, the Government will have created a monopoly > > that has little incentive to innovate. > > > > "This is the first major communication business to be born under the > > deregulation era," said David Farber, a computer scientist at the > > University of Pennsylvania and a pioneer in data networking. "This hasn't > > happened since the growth of the telephone industry. You want it to be a > > business that doesn't repeat the errors of the past." > > > > In recent years, the National Science Foundation has tried to shift its > > operations and ownership of NSFnet to Advanced Network and Services. And > it > > will try to establish competition through contracts for networks to > compete > > with NSFnet next year. > > > > But there is no level playing field, complained William L. Schrader, > > president of Performance Systems International Inc., a Reston, Va., > company > > that provides commercial data connections to Internet. He made public two > > letters between officials of Advanced Network and Services and the > National > > Science Foundation that he said gave the company unfair control over > access > > to the network. The result, he added, was that the Government turned over > > valuable public property to a private company. > > > > "It's like taking a Federal park and giving it to K Mart," Mr. Schrader > > said. "It's not right, and it isn't going to stand." > > > > Performance Systems and several other companies have set up an > alternative > > to NSFnet, known as a CIX. Mr. Schrader said his company and the venture > of > > I.B.M. and MCI were competing for the same customers but unlike his rival > > he lacked a Federal subsidy. He said he might ask the Internal Revenue > > Service to look at the business relationship between Advanced Network's > > nonprofit and for-profit operations. > > > > *'Very Competitive Environment'* > > > > Allan Weis, the president of Advanced Network, disputed that his company > > had an unfair advantage. "It's a very competitive environment right now," > > he said. > > > > At the National Science Foundation, Stephen Wolff, director of its > > networking division, said I.B.M. and MCI had overbuilt the network and > were > > selling commercial service based on the excess capacity that was > available. > > > > A number of organizations are working informally to settle the dispute. > > > > "I think it's a mess," said Mitchell D. Kapor, the founder of the Lotus > > Development Corporation and now head of the Electronic Frontier > Foundation, > > a public-interest group focusing on public policy issues surrounding data > > networks. "Nobody should have an unfair advantage." > > > > > -- > 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 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From dave.walden.family at gmail.com Sun Sep 13 05:08:49 2020 From: dave.walden.family at gmail.com (dave walden) Date: Sun, 13 Sep 2020 08:08:49 -0400 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History (was Re: Fwd: Fwd: List archives (Was: Exterior Gateway Protocol)) In-Reply-To: References: Message-ID: And the IEEE Annals of the History of Computing would surely like to see submission of a an anecdote (see https://annals-extras.org/anecdotes/? and https://annals-extras.org/anecdotes/writing/ ) or a longer piece submitted to the peer review process ( see https://www.computer.org/csdl/magazine/an? and https://www.computer.org/publications/author-resources/peer-review/magazines ). On 9/13/2020 7:56 AM, Vint Cerf via Internet-history wrote: > sounds to me like a history of Interop would be a big contribution to the > record. > > v > > > From touch at strayalpha.com Sun Sep 13 08:26:23 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sun, 13 Sep 2020 08:26:23 -0700 Subject: [ih] End-to-end - Was: Re: Found the bug - a word to avoid.... In-Reply-To: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> References: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> Message-ID: <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> FWIW: > On Sep 13, 2020, at 1:18 AM, Karl Auerbach via Internet-history wrote: > > If we step back we might see this event as a kind of failure of the end-to-end principle - something in the middle decided to muck with the data moving between the endpoints (in this case the end-points being the members of this mailing list.) I see a different failure - of the same principle. What happened here is a simple E2E problem - one where posters want to know if mail actually showed up on a list, which includes both being distributed to themselves and others as well as appearing in the archives. On the one hand, that E2E is the composition of a set of applications into a single service that was never implemented as E2E at the mail delivery layer. If it were, your mailer would have let you know that you didn?t receive a copy of the mail or that your post didn?t appear in the archive. So, at some level, one E2E failure happened in the design and implementation of ALL mail readers. However, understanding E2E means knowing what the ends are. The joke about HW/SW is ?hardware is that which can be kicked?. The way I taught it at USC, the ends are ?that which *I* can kick?, i.e., it?s a statement of relative views of the (recursive, IMO) layers of a network. So on the other hand, mail list posters can be considered an endpoint. If they had acted as endpoints, the NACK would have resulted in their retrying posts with varying content until they confirm success by receipt and in the archive. I.e., what I did, using the CS 100 method of binary search. Instead, they did something very un-E2E - they sought assistance from the management plane (me) and took issue with the lack of active feedback from various intermediate layers and hops (smtp, postfix, Mailman, etc.). Over the years, I thought we had learned not to expect active feedback when things fail, for several reasons: security (why ICMPs are blocked), stability (to avoid NACK storms), info theory (you can?t NACK what you didn?t expect), or even the Postel Principle (be liberal in what you [don?t] receive). So if there?s an observation to make here, it is that E2E failed, but not the way that it might first appear. Joe (wearing both list admin and contributor hats this time) From dhc at dcrocker.net Sun Sep 13 09:34:34 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Sun, 13 Sep 2020 09:34:34 -0700 Subject: [ih] There is no such thing as an "end-to-end failure" In-Reply-To: <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> References: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> Message-ID: <9057ad7d-9019-2ed7-2e70-111dcf72a2a9@dcrocker.net> The original term was "end-to-end arguments" which often is altered to "end-to-end principle", neither of which permit much meaning for a phrase like "end-to-end failure".? Similarly, the problematic term does not distinguish between design, implementation or operations errors. The original terms suggested a style of thinking about networked system design.? It's possible to think inadequately, of course, just as it's possible to have bugs when programming or to set the wrong configuration value.? The term "end-to-end failure" offers no insight into which of these is involved, nor how. The problematic term is often invoked by someone who has a clear meaning for its use.? And it is often heard by people who have a clear meaning for the term.? However their are two problems.? One is that the clear meanings well might be different and the other is that there is no clear documentation that can be referenced, analyzed, and repaired. Further... On 9/13/2020 8:26 AM, Joseph Touch via Internet-history wrote: > On the one hand, that E2E is the composition of a set of applications > into a single service that was never implemented as E2E at the mail > delivery layer. Oh?? Please clarify, with details. Here are some reasons for my surprise:? email infrastructure RFCs (object and transport) have tended to describe an end-to-end design. RFC 5598 documented the evolved state of affairs for recent history.? So if E2E was missing from that thinking, it will be helpful to understand this failure in detail. > If it were, your mailer would have let you know that you didn?t > receive a copy of the mail or that your post didn?t appear in the > archive. So, at some level, one E2E failure happened in the design and > implementation of ALL mail readers. The operational reality of modern Internet mail is that perhaps 95% of the traffic across the Internet is spam.? This has required quite a bit of mitigation, of course, where one of the resulting requirements is to permit essentially no automated feedback to the author or originating operator.? Sorry.? That's unfortunate, but it's not a 'failure'. To the extent that feedback is essential, please offer a design that is robust against abuse.? We do not currently have one. Return Receipt still works, but it's not quite what you are looking for, I suspect. > However, understanding E2E means knowing what the ends are. The importance of this observation cannot be overstated.? I used to think that MUAs were the endpoints -- and often, of course, they are. Then I met EDI over email. > So on the other hand, mail list posters can be considered an endpoint. If they had acted as endpoints, the NACK would have resulted in their retrying posts with varying content until they confirm success by receipt and in the archive. I.e., what I did, using the CS 100 method of binary search. Instead, they did something very un-E2E - they sought assistance from the management plane (me) and took issue with the lack of active feedback from various intermediate layers and hops (smtp, postfix, Mailman, etc.). There is a tendency to think that mailing list managers (MLM) are the same as mail transfer agents (MTA).? They aren't.? The latter are relays holding roughly the same architectural role as an IP router. However MLMs are actual email endpoints.? They take delivery of mail addressed to them and then generate and post a new message. The fact that an original author and final recipients perceive a 'direct' interaction is due to a layer /above/ normal email. And it is a poorly documented and inconsistently implemented and inconsistently operated layer. To the extent that someone wants to declare a failure at that level, they need to point to the documentation involved and clarify what, exactly has failed. Typically what has actually failed is that their entirely reasonable expectations, which were not documented anywhere, were not met. > Over the years, I thought we had learned not to expect active feedback when things fail, for several reasons: security (why ICMPs are blocked), stability (to avoid NACK storms), info theory (you can?t NACK what you didn?t expect), or even the Postel Principle (be liberal in what you [don?t] receive). I quite like this summary. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From touch at strayalpha.com Sun Sep 13 09:58:20 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sun, 13 Sep 2020 09:58:20 -0700 Subject: [ih] There is no such thing as an "end-to-end failure" In-Reply-To: <9057ad7d-9019-2ed7-2e70-111dcf72a2a9@dcrocker.net> References: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> <9057ad7d-9019-2ed7-2e70-111dcf72a2a9@dcrocker.net> Message-ID: <1265973D-39A1-4B6F-A2F4-137F7D8AB8CF@strayalpha.com> > On Sep 13, 2020, at 9:34 AM, Dave Crocker via Internet-history wrote: > ... > On 9/13/2020 8:26 AM, Joseph Touch via Internet-history wrote: >> On the one hand, that E2E is the composition of a set of applications into a single service that was never implemented as E2E at the mail delivery layer. > > Oh? Please clarify, with details. I did; E2E would mean the entire chain of ?send the mail to the server? and ?server sent the mail out to the list and to the archive?. My mail client never sends mail to your mail client. There are several steps involved there - SMTP and either IMAP or POP for unicast; SMTP to SMTP via Mailman to IMAP or POP for mailing lists. There is no single E2E signaling mechanism. >> If it were, your mailer would have let you know that you didn?t receive a copy of the mail or that your post didn?t appear in the archive. So, at some level, one E2E failure happened in the design and implementation of ALL mail readers. > > The operational reality of modern Internet mail is that perhaps 95% of the traffic across the Internet is spam. This has required quite a bit of mitigation, of course, where one of the resulting requirements is to permit essentially no automated feedback to the author or originating operator. Sorry. That's unfortunate, but it's not a 'failure'. That?s an eventuality an E2E system could have accounted for, e.g., via a timeout - as is done with TCP when a segment is silently dropped. > To the extent that feedback is essential, please offer a design that is robust against abuse. We do not currently have one. Return Receipt still works, but it's not quite what you are looking for, I suspect. For a system that involves email distribution, which is another step, the check would have to occur by trying to match list posts to sent mail, not merely expect return receipts. >> However, understanding E2E means knowing what the ends are. > > The importance of this observation cannot be overstated. I used to think that MUAs were the endpoints -- and often, of course, they are. > > Then I met EDI over email. > >> So on the other hand, mail list posters can be considered an endpoint. If they had acted as endpoints, the NACK would have resulted in their retrying posts with varying content until they confirm success by receipt and in the archive. I.e., what I did, using the CS 100 method of binary search. Instead, they did something very un-E2E - they sought assistance from the management plane (me) and took issue with the lack of active feedback from various intermediate layers and hops (smtp, postfix, Mailman, etc.). > > There is a tendency to think that mailing list managers (MLM) are the same as mail transfer agents (MTA). They aren't. The latter are relays holding roughly the same architectural role as an IP router. > > However MLMs are actual email endpoints. They take delivery of mail addressed to them and then generate and post a new message. > > The fact that an original author and final recipients perceive a 'direct' interaction is due to a layer /above/ normal email. And it is a poorly documented and inconsistently implemented and inconsistently operated layer. > > To the extent that someone wants to declare a failure at that level, they need to point to the documentation involved and clarify what, exactly has failed. > > Typically what has actually failed is that their entirely reasonable expectations, which were not documented anywhere, were not met. I agree; I?m claiming that expecting email to be E2E here is incorrect. It?s one hop in a chain for which there is no E2E system except the user to ensure oversight (at least at present). >> Over the years, I thought we had learned not to expect active feedback when things fail, for several reasons: security (why ICMPs are blocked), stability (to avoid NACK storms), info theory (you can?t NACK what you didn?t expect), or even the Postel Principle (be liberal in what you [don?t] receive). > > I quite like this summary. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From dhc at dcrocker.net Sun Sep 13 11:09:37 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Sun, 13 Sep 2020 11:09:37 -0700 Subject: [ih] There is no such thing as an "end-to-end failure" In-Reply-To: <1265973D-39A1-4B6F-A2F4-137F7D8AB8CF@strayalpha.com> References: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> <9057ad7d-9019-2ed7-2e70-111dcf72a2a9@dcrocker.net> <1265973D-39A1-4B6F-A2F4-137F7D8AB8CF@strayalpha.com> Message-ID: <1a4cd040-d9f3-5663-b6b7-983ce64f8301@dcrocker.net> Note that my primary comment was about terminology. I'm going to venture that this exchange demonstrates how unproductive -- or even counterproductive -- language like "end-to-end failure" is. It provides a simplistic, and frankly arrogant, term that is readily invoked, but has no precise technical meaning. (Much like 'security' or 'privacy'...) On 9/13/2020 9:58 AM, Joseph Touch via Internet-history wrote: >> On Sep 13, 2020, at 9:34 AM, Dave Crocker via Internet-history >> wrote: ... On 9/13/2020 8:26 AM, >> Joseph Touch via Internet-history wrote: >>> On the one hand, that E2E is the composition of a set of >>> applications into a single service that was never implemented as >>> E2E at the mail delivery layer. >> >> Oh? Please clarify, with details. > > I did; E2E would mean the entire chain of ?send the mail to the > server? and ?server sent the mail out to the list and to the > archive?. > > My mail client never sends mail to your mail client. There are > several steps involved there - SMTP and either IMAP or POP for > unicast; SMTP to SMTP via Mailman to IMAP or POP for mailing lists. > There is no single E2E signaling mechanism. In formal architectural parlance, a basic mailing list sequence MUA -> MSA -> MTA -> ... MTA -> MDA -> MLM -> -> MSA -> MTA -> ... MTA -> MDA -> MUA I say 'basic' because, of course, a message might go through multiple mailing lists. But for this basic sequence, since there are two MDA's noted, there are two mail deliveries. Hence my observation that mailing list activity is a logical layer above basic email. Hence "mail delivery" per se, is not the issue, absent clarification to the contrary. It's possible that the real desire here is for something that /is/ at the level of basic mail transport and that something really is desired at the time of normal mail delivery. In that case, it has nothing to do with mailing lists. If it /does/ have to do with mailing lists, then it has nothing to do with basic mail delivery, since that would be a layer violation. It's tempting to think that the issue might be to provide a mechanism invoked during 'final' delivery, to the 'ultimate' recipient. That would presume knowing when that occurs. cf, multiple mailing lists. >>> If it were, your mailer would have let you know that you didn?t >>> receive a copy of the mail My "mailer" would let me know I didn't receive some mail? Isn't that akin to proving a negative? I don't understand how my "mailer" can be expected to know about mail I didn't receive. > or that your post didn?t appear in the archive. So, at some level, > one E2E failure happened in the design and implementation of ALL mail > readers. Sorry, but I do not understand the control mechanisms you are postulating. They appear to involve quite a bit of mechanism that hasn't been discussed much, over the 45+ years of email, or implemented for Internet mail at all. So while there might be some interesting opportunities for enhancements, calling any of this a 'failure' is not helpful. >> The operational reality of modern Internet mail is that perhaps 95% >> of the traffic across the Internet is spam. This has required >> quite a bit of mitigation, of course, where one of the resulting >> requirements is to permit essentially no automated feedback to the >> author or originating operator. Sorry. That's unfortunate, but >> it's not a 'failure'. > > That?s an eventuality an E2E system could have accounted for, e.g., > via a timeout - as is done with TCP when a segment is silently > dropped. Rubbish. Such hand-waves about difficult operational challenges that develop over time, and at scale, are frequently made as convenient slams but they never have the theoretical, experimental or operational basis to be valid. The basic stance of such rubbish is that all eventualities must be anticipated before anything is put into the field. That was the OSI approach. Besides creating infinite delay, it doesn't work. Again, it's possible that there are useful enhancements to be made, but calling these sorts of issues 'failures' serves more to polarize discussion than to promote it. (Hence my stooping to 'rubbish'.) >> To the extent that feedback is essential, please offer a design >> that is robust against abuse. We do not currently have one. Return >> Receipt still works, but it's not quite what you are looking for, I >> suspect. > > For a system that involves email distribution, which is another step, > the check would have to occur by trying to match list posts to sent > mail, not merely expect return receipts. Sorry, but I don't know what "matching list posts to sent mail" is, since I consider "posts" to equate to "sent". Further, there is nothing that identifies mail that is sent as specifically going to a list. >> To the extent that someone wants to declare a failure at that >> level, they need to point to the documentation involved and clarify >> what, exactly has failed. >> >> Typically what has actually failed is that their entirely >> reasonable expectations, which were not documented anywhere, were >> not met. > > I agree; I?m claiming that expecting email to be E2E here is > incorrect. It?s one hop in a chain for which there is no E2E system > except the user to ensure oversight (at least at present). This demonstrates my original point about language even more strongly. It appears that we agree on an essential architectural issue, though it also seems clear to me that there is work to be done to establish enough shared detail for discussion to be productive. (And invoking 'failure' actually was counter-productive.) So here's my suggestion, by way of a recitation: The MUA-MTA model was developed around 1980 and was pretty much the only documented architectural model for mail for almost 30 years. At the time, it was, in fact, an end-to-end model, though it's primary utility was in clarifying the distinction between user-level email functions and transport-level functions. In the early 2000s, I noticed diligent, experienced email workers using wildly inconsistent references to email details and behaviors and decided that we needed a comprehensive email architecture document. I blithely figured that I had enough background in the topic for this to be a tractable task to take on. The task was to document the architecture of the /existing/ Internet Mail service, with no effort to propose changes. It took 5 years of extensive interaction with the email community. I constantly produced a draft that resolved all of the outstanding issues -- with 'rough consensus' sometimes producing a result that did not match my own views -- circulated the draft and would get still-more input that I couldn't legitimately ignore (no matter how much I wanted to.) It was, by far, the hardest design work I've ever had to do. Your certitude about what is needed for end-to-end mailing list behavior serves as self-nomination to produce something similar for mailing lists. I look forward to reviewing your first draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From geoff at iconia.com Sun Sep 13 11:44:03 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 13 Sep 2020 08:44:03 -1000 Subject: [ih] There is no such thing as an "end-to-end failure" In-Reply-To: <1a4cd040-d9f3-5663-b6b7-983ce64f8301@dcrocker.net> References: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> <9057ad7d-9019-2ed7-2e70-111dcf72a2a9@dcrocker.net> <1265973D-39A1-4B6F-A2F4-137F7D8AB8CF@strayalpha.com> <1a4cd040-d9f3-5663-b6b7-983ce64f8301@dcrocker.net> Message-ID: dave, where can the resultant document from/of your Labor Of Love mentioned below be found? On Sun, Sep 13, 2020 at 8:10 AM Dave Crocker via Internet-history < internet-history at elists.isoc.org> wrote: > [...] > In the early 2000s, I noticed diligent, experienced email workers using > wildly inconsistent references to email details and behaviors and > decided that we needed a comprehensive email architecture document. I > blithely figured that I had enough background in the topic for this to > be a tractable task to take on. > > The task was to document the architecture of the /existing/ Internet > Mail service, with no effort to propose changes. > > It took 5 years of extensive interaction with the email community. I > constantly produced a draft that resolved all of the outstanding issues > -- with 'rough consensus' sometimes producing a result that did not > match my own views -- circulated the draft and would get still-more > input that I couldn't legitimately ignore (no matter how much I wanted > to.) It was, by far, the hardest design work I've ever had to do. > [...] > -- Geoff.Goodfellow at iconia.com living as The Truth is True From dhc at dcrocker.net Sun Sep 13 11:59:44 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Sun, 13 Sep 2020 11:59:44 -0700 Subject: [ih] There is no such thing as an "end-to-end failure" In-Reply-To: References: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> <9057ad7d-9019-2ed7-2e70-111dcf72a2a9@dcrocker.net> <1265973D-39A1-4B6F-A2F4-137F7D8AB8CF@strayalpha.com> <1a4cd040-d9f3-5663-b6b7-983ce64f8301@dcrocker.net> Message-ID: <8b949241-f5f4-cfac-63ae-7d8df7e48edb@dcrocker.net> On 9/13/2020 11:44 AM, the keyboard of geoff goodfellow via Internet-history wrote: > dave, where can the resultant document from/of your Labor Of Love mentioned > below be found? It's the RFC 5598 I'd cited. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dave.walden.family at gmail.com Sun Sep 13 12:08:27 2020 From: dave.walden.family at gmail.com (dave walden) Date: Sun, 13 Sep 2020 15:08:27 -0400 Subject: [ih] There is no such thing as an "end-to-end failure" In-Reply-To: References: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> <9057ad7d-9019-2ed7-2e70-111dcf72a2a9@dcrocker.net> <1265973D-39A1-4B6F-A2F4-137F7D8AB8CF@strayalpha.com> <1a4cd040-d9f3-5663-b6b7-983ce64f8301@dcrocker.net> Message-ID: I am not following this discussion closely, so probably the following is not relevant, but it's title fits the thread: End-to-End Arguments in the Internet: Principles, Practices, and Theory vorgelegt von M a t t h i a s B ? r w o l f f https://d-nb.info/1010281003/34 From touch at strayalpha.com Sun Sep 13 12:28:27 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sun, 13 Sep 2020 12:28:27 -0700 Subject: [ih] There is no such thing as an "end-to-end failure" In-Reply-To: <1a4cd040-d9f3-5663-b6b7-983ce64f8301@dcrocker.net> References: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> <9057ad7d-9019-2ed7-2e70-111dcf72a2a9@dcrocker.net> <1265973D-39A1-4B6F-A2F4-137F7D8AB8CF@strayalpha.com> <1a4cd040-d9f3-5663-b6b7-983ce64f8301@dcrocker.net> Message-ID: > On Sep 13, 2020, at 11:09 AM, Dave Crocker wrote: > > Note that my primary comment was about terminology. > > I'm going to venture that this exchange demonstrates how unproductive -- > or even counterproductive -- language like "end-to-end failure" is. Agreed. My version is: from user sending a post to a list to user knowing the post arrives on that list Not all solutions to CS problems involve only computers. > ... > In formal architectural parlance, a basic mailing list sequence > > MUA -> MSA -> MTA -> ... MTA -> MDA -> MLM -> > > -> MSA -> MTA -> ... MTA -> MDA -> MUA You?ve omitted the users on both ends of that sequence, which *can* be part of the E2E chain too. > ... > It's tempting to think that the issue might be to provide a mechanism > invoked during 'final' delivery, to the 'ultimate' recipient. That > would presume knowing when that occurs. cf, multiple mailing lists. Humans do. >>>> If it were, your mailer would have let you know that you didn?t >>>> receive a copy of the mail > > My "mailer" would let me know I didn't receive some mail? Isn't that > akin to proving a negative? I don't understand how my "mailer" can be > expected to know about mail I didn't receive. A timeout. That?s the only way anyone (or thing) ever knows something is lost. >> or that your post didn?t appear in the archive. So, at some level, >> one E2E failure happened in the design and implementation of ALL mail >> readers. > > Sorry, but I do not understand the control mechanisms you are postulating. A mail reader COULD know when it?s posting to a list (we don?t currently encode that in either email addresses or the protocols to post to lists, but that could have been done). A mail reader could then correlate the sent mail to the receipt of matching post to that list, again if email had sufficient unique IDs that were retained through the entire chain from user to mailing list and back to that user. > They appear to involve quite a bit of mechanism that hasn't been > discussed much, over the 45+ years of email, or implemented for Internet > mail at all. Right - my (apparently too subtle) point is that this was a) not considered by email designers b) not performed by email list users c) but appears to be assumed of email list maintainers I don?t consider (a) the E2E failure; rather it is the combination of (a), (b), and (c). ... >>> The operational reality of modern Internet mail is that perhaps 95% >>> of the traffic across the Internet is spam. This has required >>> quite a bit of mitigation, of course, where one of the resulting >>> requirements is to permit essentially no automated feedback to the >>> author or originating operator. Sorry. That's unfortunate, but >>> it's not a 'failure'. >> That?s an eventuality an E2E system could have accounted for, e.g., >> via a timeout - as is done with TCP when a segment is silently >> dropped. > > Rubbish. Such hand-waves about difficult operational challenges that > develop over time, and at scale, are frequently made as convenient slams > but they never have the theoretical, experimental or operational basis > to be valid. > > The basic stance of such rubbish is that all eventualities must be > anticipated before anything is put into the field. That was the OSI > approach. Besides creating infinite delay, it doesn't work. One eventuality is that hop by hop mail delivery in a mail sequence does not confer E2E delivery guarantees. Any mail source could - and should - plan for that. That includes ?people? as that source. > >>> To the extent that feedback is essential, please offer a design >>> that is robust against abuse. We do not currently have one. Return >>> Receipt still works, but it's not quite what you are looking for, I >>> suspect. >> For a system that involves email distribution, which is another step, >> the check would have to occur by trying to match list posts to sent >> mail, not merely expect return receipts. > > Sorry, but I don't know what "matching list posts to sent mail" is, > since I consider "posts" to equate to "sent". If that were true, then Karl?s posts were all successful. They all got sent to ISOC and promptly dropped on the floor after being successfully received. > Further, there is nothing > that identifies mail that is sent as specifically going to a list. As per above, yes. That?s part of the ?failure? of the system overall to account for the E2E goal. > ... > Your certitude about what is needed for end-to-end mailing list behavior serves as self-nomination to produce something similar for mailing lists. I look forward to reviewing your first draft. Here?s the draft, in as much detail as is needed: - if you post to a list and don?t see it in the archive or get a copy, then debug it by varying what?s transmitted and who transmits it, i.e., at the endpoints Not all E2E problems should start by demanding visibility into the middle of a path. Joe From dhc at dcrocker.net Sun Sep 13 12:49:56 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Sun, 13 Sep 2020 12:49:56 -0700 Subject: [ih] There is no such thing as an "end-to-end failure" In-Reply-To: References: <93e6e8f1-d9e5-2c4d-d92b-44ae4e1b30e6@cavebear.com> <6F59658E-5AA3-4763-90E9-FBA7345FC6E0@strayalpha.com> <9057ad7d-9019-2ed7-2e70-111dcf72a2a9@dcrocker.net> <1265973D-39A1-4B6F-A2F4-137F7D8AB8CF@strayalpha.com> <1a4cd040-d9f3-5663-b6b7-983ce64f8301@dcrocker.net> Message-ID: <5df3c255-5f34-2931-f201-bf137e23fb88@dcrocker.net> On 9/13/2020 12:28 PM, Joseph Touch via Internet-history wrote: >> On Sep 13, 2020, at 11:09 AM, Dave Crocker wrote: >> Note that my primary comment was about terminology. >> >> I'm going to venture that this exchange demonstrates how unproductive -- >> or even counterproductive -- language like "end-to-end failure" is. > > Agreed. My version is: > > from user sending a post to a list > to user knowing the post arrives on that list MLMs vary on whether the author gets a copy of the message posted through the MLM. In fact it is a per-list configuration option for some MLM software. (I think that includes the IETF list manager.) >> In formal architectural parlance, a basic mailing list sequence >> >> MUA -> MSA -> MTA -> ... MTA -> MDA -> MLM -> >> >> -> MSA -> MTA -> ... MTA -> MDA -> MUA > > You?ve omitted the users on both ends of that sequence, which *can* be part of the E2E chain too. > >> ... >> It's tempting to think that the issue might be to provide a mechanism >> invoked during 'final' delivery, to the 'ultimate' recipient. That >> would presume knowing when that occurs. cf, multiple mailing lists. > > Humans do. Yeah, but that's largely irrelevant, in terms of operational realities. There is a widespread belief that it's good to give user's control. The belief typically does not distinguish between "available" and "required" and therefore misses the basic problem of user burden, attention, desire, etc. >>>>> If it were, your mailer would have let you know that you didn?t >>>>> receive a copy of the mail >> >> My "mailer" would let me know I didn't receive some mail? Isn't that >> akin to proving a negative? I don't understand how my "mailer" can be >> expected to know about mail I didn't receive. > > A timeout. That?s the only way anyone (or thing) ever knows something is lost. A timeout to what? From what to what? I have guesses what you might mean but this is your mechanism, not mine. And my guess is for something that doesn't work very well... >>> or that your post didn?t appear in the archive. So, at some level, >>> one E2E failure happened in the design and implementation of ALL mail >>> readers. >> >> Sorry, but I do not understand the control mechanisms you are postulating. > > A mail reader COULD know when it?s posting to a list (we don?t currently encode that in either email addresses or the protocols to post to lists, but that could have been done). > > A mail reader could then correlate the sent mail to the receipt of matching post to that list, again if email had sufficient unique IDs that were retained through the entire chain from user to mailing list and back to that user. The sent (outbox) MUA folder constitutes just such a list, and some MUAs do correlate received return receipts. But as I originally noted, that's a low-level email transport mechanism, not specific to mailing lists. >> They appear to involve quite a bit of mechanism that hasn't been >> discussed much, over the 45+ years of email, or implemented for Internet >> mail at all. > > Right - my (apparently too subtle) point is that this was > a) not considered by email designers > b) not performed by email list users > c) but appears to be assumed of email list maintainers > > I don?t consider (a) the E2E failure; rather it is the combination of (a), (b), and (c). You've left off: not required by users. New mechanism is expensive. Mechanism not demanded by the market -- or not appreciated by the market when the mechanism shows up -- is a lot of wasted time and money. That was the (apparently too subtle) point in referring to the 45+ year history of this service. >> The basic stance of such rubbish is that all eventualities must be >> anticipated before anything is put into the field. That was the OSI >> approach. Besides creating infinite delay, it doesn't work. > > One eventuality is that hop by hop mail delivery in a mail sequence does not confer E2E delivery guarantees. > > Any mail source could - and should - plan for that. That includes ?people? as that source. Yeah, but... I don't know what that means in its particulars. Or at least not what it means beyond what is already happening. >> Sorry, but I don't know what "matching list posts to sent mail" is, >> since I consider "posts" to equate to "sent". > > If that were true, then Karl?s posts were all successful. They all got sent to ISOC and promptly dropped on the floor after being successfully received. Some mail is worth ignoring. Some MLMs are clever. But seriously... Your "if that were true" doesn't seem to follow from what I wrote. Sorry, I just don't understand. >> Further, there is nothing >> that identifies mail that is sent as specifically going to a list. > > As per above, yes. That?s part of the ?failure? of the system overall to account for the E2E goal. Oh good. That gives you a design task, for a better mechanism. Note that the major challenge here won't be the technology but overcoming end user resistance. Well, ok. Some design approaches would be to create intractable technology designs... >> Your certitude about what is needed for end-to-end mailing list behavior serves as self-nomination to produce something similar for mailing lists. I look forward to reviewing your first draft. > > Here?s the draft, in as much detail as is needed: > > - if you post to a list and don?t see it in the archive or get a copy, > then debug it by varying what?s transmitted and who transmits it, i.e., at the endpoints > > Not all E2E problems should start by demanding visibility into the middle of a path. I don't see how what you have in mind does not require such visibility. also, end users love being given tasks like that. But, really, I'd argue that the requirement is already satisfied. You can choose to do all that today. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.e.carpenter at gmail.com Sun Sep 13 13:58:02 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 14 Sep 2020 08:58:02 +1200 Subject: [ih] NO "settlements" as part of Internet History In-Reply-To: References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> <442a4b6d-1384-dc66-0a28-c1406e4a611f@gmail.com> Message-ID: <1ff7906d-f5ea-311e-220e-4838ba9b91c2@gmail.com> Hi Vint, That sounds as if there was seen to be a distinction between email flows (human to human communication) and data flows (machine to machine). When we at CERN discussed connections and costs with Steve Goldstein at NSF, it was in the context of bulk scientific data transfer (for American physicists associated with CERN experiments). We weren't supposed to use NSFnet to access .com addresses, but prior to BGP4 that was a bit of a problem and "policy based routing" was a constant talking point. Harvey Newman (then and now at Caltech) used to say "Every grad student needs 64 kb/s" and that was how we calculated capacity requirements around 1990. We all knew that email was important, but we all knew that money was granted for scientific data transfer. Regards Brian On 14-Sep-20 00:02, Vint Cerf wrote: > Brian, > in 1988 the then Federal Networking Council (or its predecessor, the FRICC) gave me permission to connect the commercial MCI Mail to the NSFNET backbone. This connection occurred in 1989, the same year that UUNET, PSINET and CERFNET came into operation and, I think, interconnected at the CIX. Other email services (Compuserve, OnTyme, Telemail) were also given permission to connect. In 1992 legislation was passed to allow this formally (Boucher Bill I thinik?). > v > > > On Sat, Sep 12, 2020 at 11:12 PM Brian E Carpenter via Internet-history > wrote: > > In my humble (non-American) opinion, some of the arguments made at that > time were very self-serving. I think that Guy Almes and Steve Goldstein > between them could explain better than me, but NSFnet always had an > acceptable use policy that (since it was taxpayer-funded) only allowed > "free" transit for traffic to or from a legitimate NSF user, i.e. one end > or both ends of a flow had to be a research site. Clearly the taxpayer > shouldn't pay for business-to-business traffic, and that fact was the > business case for creating CIX. > > Neither NSFnet nor CIX was free of course; they just had very different > funding sources. It was my understanding at the time that ANS CO+RE was > created precisely to avoid cross-subsidy from NSF money. They did have > the advantage of knowledge transfer. > > (All of this was of intense interest to us at CERN as we hosted a > transatlantic link to NSFnet and we too had to ensure that the NSFnet > AUP was respected. So we followed it pretty closely.) > > Of course the idea that there are no settlements in the Internet is > a bit ridiculous. There are no settlements per "call" but connections > to transit providers and/or IXPs cost money. > > Regards > ? ?Brian Carpenter > > On 11-Sep-20 12:21, the keyboard of geoff goodfellow via Internet-history wrote: > > On Thu, Sep 10, 2020 at 10:42 AM *Jack Haverty via Internet-history > > >> wrote* > > : > > > >> CCITT was working on X.25, and creating X.75, to interconnect their > >> networks.? It was a natural evolution of the PTT's prior interconnection > >> of their telephone networks.? ?Later, as DDN marched down the X.25 path, > >> the subsequent government Internet might have ended up based on > >> X.25/X.75.? ?If it worked. > >> > > > > part and parcel of the X.25 and X.75 networking shibboleth was the notion > > of "settlements" -- just like with the PTT's interconnection of their > > telephone networks -- where The Fee for/of Transit was split along a > > "calls" participants/networks transited. > > > > IIRC, Advanced Network and Services (ANS) tried to "imprint" the > > settlements model on the fledgling Internet -- with them In The Middle > > collecting a fee for transit (for commercial traffic) between networks as > > well as for interconnection with The Budding commercial Internet upstarts > > (PSI, ALTERNET, etc.) the resulting in the founding of the CIX, viz.: > > > > > > *Data Network Raises Monopoly Fear* > > By JOHN MARKOFF > > The New York Times > > December 19, 1991 > > http://www.nytimes.com/1991 > > /12/19/business/data-network-raises-monopoly-fear.html > > > > Soon after President Bush signed legislation calling for the creation of a > > nationwide computer data "superhighway," a debate has erupted over whether > > the Government gave an unfair advantage to a joint venture of I.B.M. MCI > > that built and manages a key part of the network. > > > > The venture, known as Advanced Network and Services, manages a network > > called NSFnet, which connects hundreds of research centers and > > universities. NSFnet also manages links to dozens of other countries. All > > these networks are collectively known as Internet. > > > > Some private competitors say Advanced Network and Services uses its favored > > position to squeeze them out of the data-transmission market by > > establishing rules that make it difficult to connect to NSFnet. > > > > *Traffic Has Doubled* > > > > NSFnet was founded by the National Science Foundation, a Federal agency, > > and is composed of leased telephone lines that link special computers > > called routers, which transmit packages of data to three million users in > > 33 countries. Data traffic over the NSFnet backbone has doubled in the last > > year. > > > > The Government wants to develop a national data highway for electronic > > commerce, digital video transmissions to homes and vast electronic > > libraries that could be drawn on by the nation's schools. > > > > Advanced Network and Services, based in Elmsford, N.Y., was set up last > > year as a nonprofit corporation with $10 million from the International > > Business Machines Corporation and the MCI Communications Corporation. > > Earlier this year it set up a for-profit subsidiary, called ANS CO+RE > > (pronounced core), to sell computer network services. That led some > > competitors to complain that Advanced Network and Services would be able to > > compete unfairly because of its arrangement with the Government. > > > > *Fear Loss of Innovation* > > > > People involved in planning for a national data network say it is essential > > to provide for fair competition, which will lead rival companies to offer > > creative and entrepreneurial services in the hope of building market share. > > Without competiton, they say, the Government will have created a monopoly > > that has little incentive to innovate. > > > > "This is the first major communication business to be born under the > > deregulation era," said David Farber, a computer scientist at the > > University of Pennsylvania and a pioneer in data networking. "This hasn't > > happened since the growth of the telephone industry. You want it to be a > > business that doesn't repeat the errors of the past." > > > > In recent years, the National Science Foundation has tried to shift its > > operations and ownership of NSFnet to Advanced Network and Services. And it > > will try to establish competition through contracts for networks to compete > > with NSFnet next year. > > > > But there is no level playing field, complained William L. Schrader, > > president of Performance Systems International Inc., a Reston, Va., company > > that provides commercial data connections to Internet. He made public two > > letters between officials of Advanced Network and Services and the National > > Science Foundation that he said gave the company unfair control over access > > to the network. The result, he added, was that the Government turned over > > valuable public property to a private company. > > > > "It's like taking a Federal park and giving it to K Mart," Mr. Schrader > > said. "It's not right, and it isn't going to stand." > > > > Performance Systems and several other companies have set up an alternative > > to NSFnet, known as a CIX. Mr. Schrader said his company and the venture of > > I.B.M. and MCI were competing for the same customers but unlike his rival > > he lacked a Federal subsidy. He said he might ask the Internal Revenue > > Service to look at the business relationship between Advanced Network's > > nonprofit and for-profit operations. > > > > *'Very Competitive Environment'* > > > > Allan Weis, the president of Advanced Network, disputed that his company > > had an unfair advantage. "It's a very competitive environment right now," > > he said. > > > > At the National Science Foundation, Stephen Wolff, director of its > > networking division, said I.B.M. and MCI had overbuilt the network and were > > selling commercial service based on the excess capacity that was available. > > > > A number of organizations are working informally to settle the dispute. > > > > "I think it's a mess," said Mitchell D. Kapor, the founder of the Lotus > > Development Corporation and now head of the Electronic Frontier Foundation, > > a public-interest group focusing on public policy issues surrounding data > > networks. "Nobody should have an unfair advantage." > > > > > -- > 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 > 1435 Woodhurst Blvd? > McLean, VA 22102 > 703-448-0965 > > until further notice > > > From geoff at iconia.com Sun Sep 13 14:42:54 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 13 Sep 2020 11:42:54 -1000 Subject: [ih] NO "settlements" as part of Internet History In-Reply-To: <1ff7906d-f5ea-311e-220e-4838ba9b91c2@gmail.com> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> <442a4b6d-1384-dc66-0a28-c1406e4a611f@gmail.com> <1ff7906d-f5ea-311e-220e-4838ba9b91c2@gmail.com> Message-ID: vis-a-vis "We weren't supposed to use NSFnet to access .com addresses..." but what about .US addresses? as a part of Internet History: yours truly registered the first host in the .US domain (fernwood.mpk.ca.us) for Anterior Technology -- which was the 2nd commercial internet business connected to the Internet via BARRNET (our local NSF regional network provider) a half half block away from SRI in Menlo Park back in 1989 out of a spare bedroom on a MIPS M1000 computer. prior to Anterior morphing into wireless email (RadioMail), Anterior started it's commercial business providing moderated USENET feeds (the In Moderation Network) as well as offering commercial dialup/dialout UUCP (for mail and USENET) connections to local businesses viz.: https://www.deepdyve.com/lp/association-for-computing-machinery/news-track-QKpCn05nS0 ERGO, don't see how "policy" routing based on a domain name would "guarantee" the non-commercialness of said traffic, especially In Those Days when (via UUCP) email addresses could take the form of foo! bar at fernwood.mpk.ca.us (or any other UUCP to net relay host). geoff On Sun, Sep 13, 2020 at 10:58 AM Brian E Carpenter < brian.e.carpenter at gmail.com> wrote: > Hi Vint, > > That sounds as if there was seen to be a distinction between email flows > (human to human communication) and data flows (machine to machine). When > we at CERN discussed connections and costs with Steve Goldstein at NSF, > it was in the context of bulk scientific data transfer (for American > physicists associated with CERN experiments). We weren't supposed to use > NSFnet to access .com addresses, but prior to BGP4 that was a bit of a > problem and "policy based routing" was a constant talking point. > > Harvey Newman (then and now at Caltech) used to say "Every grad student > needs 64 kb/s" and that was how we calculated capacity requirements around > 1990. We all knew that email was important, but we all knew that money > was granted for scientific data transfer. > > Regards > Brian > > On 14-Sep-20 00:02, Vint Cerf wrote: > > Brian, > > in 1988 the then Federal Networking Council (or its predecessor, the > FRICC) gave me permission to connect the commercial MCI Mail to the NSFNET > backbone. This connection occurred in 1989, the same year that UUNET, > PSINET and CERFNET came into operation and, I think, interconnected at the > CIX. Other email services (Compuserve, OnTyme, Telemail) were also given > permission to connect. In 1992 legislation was passed to allow this > formally (Boucher Bill I thinik?). > > v > > > > > > On Sat, Sep 12, 2020 at 11:12 PM Brian E Carpenter via Internet-history < > internet-history at elists.isoc.org > > wrote: > > > > In my humble (non-American) opinion, some of the arguments made at > that > > time were very self-serving. I think that Guy Almes and Steve > Goldstein > > between them could explain better than me, but NSFnet always had an > > acceptable use policy that (since it was taxpayer-funded) only > allowed > > "free" transit for traffic to or from a legitimate NSF user, i.e. > one end > > or both ends of a flow had to be a research site. Clearly the > taxpayer > > shouldn't pay for business-to-business traffic, and that fact was the > > business case for creating CIX. > > > > Neither NSFnet nor CIX was free of course; they just had very > different > > funding sources. It was my understanding at the time that ANS CO+RE > was > > created precisely to avoid cross-subsidy from NSF money. They did > have > > the advantage of knowledge transfer. > > > > (All of this was of intense interest to us at CERN as we hosted a > > transatlantic link to NSFnet and we too had to ensure that the NSFnet > > AUP was respected. So we followed it pretty closely.) > > > > Of course the idea that there are no settlements in the Internet is > > a bit ridiculous. There are no settlements per "call" but connections > > to transit providers and/or IXPs cost money. > > > > Regards > > Brian Carpenter > > > > On 11-Sep-20 12:21, the keyboard of geoff goodfellow via > Internet-history wrote: > > > On Thu, Sep 10, 2020 at 10:42 AM *Jack Haverty via Internet-history > > > internet-history at elists.isoc.org> >> wrote* > > > : > > > > > >> CCITT was working on X.25, and creating X.75, to interconnect > their > > >> networks. It was a natural evolution of the PTT's prior > interconnection > > >> of their telephone networks. Later, as DDN marched down the > X.25 path, > > >> the subsequent government Internet might have ended up based on > > >> X.25/X.75. If it worked. > > >> > > > > > > part and parcel of the X.25 and X.75 networking shibboleth was the > notion > > > of "settlements" -- just like with the PTT's interconnection of > their > > > telephone networks -- where The Fee for/of Transit was split along > a > > > "calls" participants/networks transited. > > > > > > IIRC, Advanced Network and Services (ANS) tried to "imprint" the > > > settlements model on the fledgling Internet -- with them In The > Middle > > > collecting a fee for transit (for commercial traffic) between > networks as > > > well as for interconnection with The Budding commercial Internet > upstarts > > > (PSI, ALTERNET, etc.) the resulting in the founding of the CIX, > viz.: > > > > > > > > > *Data Network Raises Monopoly Fear* > > > By JOHN MARKOFF > > > The New York Times > > > December 19, 1991 > > > http://www.nytimes.com/1991 > > > /12/19/business/data-network-raises-monopoly-fear.html > > > > > > Soon after President Bush signed legislation calling for the > creation of a > > > nationwide computer data "superhighway," a debate has erupted over > whether > > > the Government gave an unfair advantage to a joint venture of > I.B.M. MCI > > > that built and manages a key part of the network. > > > > > > The venture, known as Advanced Network and Services, manages a > network > > > called NSFnet, which connects hundreds of research centers and > > > universities. NSFnet also manages links to dozens of other > countries. All > > > these networks are collectively known as Internet. > > > > > > Some private competitors say Advanced Network and Services uses > its favored > > > position to squeeze them out of the data-transmission market by > > > establishing rules that make it difficult to connect to NSFnet. > > > > > > *Traffic Has Doubled* > > > > > > NSFnet was founded by the National Science Foundation, a Federal > agency, > > > and is composed of leased telephone lines that link special > computers > > > called routers, which transmit packages of data to three million > users in > > > 33 countries. Data traffic over the NSFnet backbone has doubled in > the last > > > year. > > > > > > The Government wants to develop a national data highway for > electronic > > > commerce, digital video transmissions to homes and vast electronic > > > libraries that could be drawn on by the nation's schools. > > > > > > Advanced Network and Services, based in Elmsford, N.Y., was set up > last > > > year as a nonprofit corporation with $10 million from the > International > > > Business Machines Corporation and the MCI Communications > Corporation. > > > Earlier this year it set up a for-profit subsidiary, called ANS > CO+RE > > > (pronounced core), to sell computer network services. That led some > > > competitors to complain that Advanced Network and Services would > be able to > > > compete unfairly because of its arrangement with the Government. > > > > > > *Fear Loss of Innovation* > > > > > > People involved in planning for a national data network say it is > essential > > > to provide for fair competition, which will lead rival companies > to offer > > > creative and entrepreneurial services in the hope of building > market share. > > > Without competiton, they say, the Government will have created a > monopoly > > > that has little incentive to innovate. > > > > > > "This is the first major communication business to be born under > the > > > deregulation era," said David Farber, a computer scientist at the > > > University of Pennsylvania and a pioneer in data networking. "This > hasn't > > > happened since the growth of the telephone industry. You want it > to be a > > > business that doesn't repeat the errors of the past." > > > > > > In recent years, the National Science Foundation has tried to > shift its > > > operations and ownership of NSFnet to Advanced Network and > Services. And it > > > will try to establish competition through contracts for networks > to compete > > > with NSFnet next year. > > > > > > But there is no level playing field, complained William L. > Schrader, > > > president of Performance Systems International Inc., a Reston, > Va., company > > > that provides commercial data connections to Internet. He made > public two > > > letters between officials of Advanced Network and Services and the > National > > > Science Foundation that he said gave the company unfair control > over access > > > to the network. The result, he added, was that the Government > turned over > > > valuable public property to a private company. > > > > > > "It's like taking a Federal park and giving it to K Mart," Mr. > Schrader > > > said. "It's not right, and it isn't going to stand." > > > > > > Performance Systems and several other companies have set up an > alternative > > > to NSFnet, known as a CIX. Mr. Schrader said his company and the > venture of > > > I.B.M. and MCI were competing for the same customers but unlike > his rival > > > he lacked a Federal subsidy. He said he might ask the Internal > Revenue > > > Service to look at the business relationship between Advanced > Network's > > > nonprofit and for-profit operations. > > > > > > *'Very Competitive Environment'* > > > > > > Allan Weis, the president of Advanced Network, disputed that his > company > > > had an unfair advantage. "It's a very competitive environment > right now," > > > he said. > > > > > > At the National Science Foundation, Stephen Wolff, director of its > > > networking division, said I.B.M. and MCI had overbuilt the network > and were > > > selling commercial service based on the excess capacity that was > available. > > > > > > A number of organizations are working informally to settle the > dispute. > > > > > > "I think it's a mess," said Mitchell D. Kapor, the founder of the > Lotus > > > Development Corporation and now head of the Electronic Frontier > Foundation, > > > a public-interest group focusing on public policy issues > surrounding data > > > networks. "Nobody should have an unfair advantage." > > > > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org Internet-history at elists.isoc.org> > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > > > -- > > Please send any postal/overnight deliveries to: > > Vint Cerf > > 1435 Woodhurst Blvd > > McLean, VA 22102 > > 703-448-0965 > > > > until further notice > > > > > > > > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From brian.e.carpenter at gmail.com Sun Sep 13 15:18:27 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 14 Sep 2020 10:18:27 +1200 Subject: [ih] NO "settlements" as part of Internet History In-Reply-To: References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> <442a4b6d-1384-dc66-0a28-c1406e4a611f@gmail.com> <1ff7906d-f5ea-311e-220e-4838ba9b91c2@gmail.com> Message-ID: <6471935c-c9a9-4202-d50d-09fd49dd8aff@gmail.com> Indeed. In fact, just now I looked for the oldest message from Vint in my archive to see what route it had followed. It was one SMTP hop from CNRI.Reston.VA.US to CERN, and in 1991 that had to be via our link to the NSFnet at Cornell. What we had to do was make an honest effort to respect the NSFnet acceptable use policy. Nobody except perhaps the money people expected it to be watertight. Just for fun: 1) The path of a message from Vint to me in 1991, one SMTP hop, presumably via NSFnet: From vcerf at NRI.Reston.VA.US Sat Dec 14 22:52:50 1991 Received: by cernvax.cern.ch (5.57/Ultrix2.0-B) id AA16635; Sat, 14 Dec 91 22:52:48 +0100 Received: by dxmint.cern.ch (cernvax) (5.57/3.14) id AA26448; Sat, 14 Dec 91 22:50:42 +0100 Received: from NRI.NRI.Reston.Va.US by NRI.NRI.Reston.VA.US id aa12620; 14 Dec 91 16:44 EST 1) Bill Bostwick to me in 1991, avoiding NSFnet since he was funded by DoE not NSF: From bostwick%darpa.mil at Lbl.Bitnet Fri Oct 11 14:55:28 1991 Received: by cernvax.cern.ch (5.57/Ultrix2.0-B) id AA18358; Fri, 11 Oct 91 14:55:02 +0100 Received: by dxmint.cern.ch (cernvax) (5.57/3.14) id AA20906; Fri, 11 Oct 91 14:54:43 +0100 Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R1) with BSMTP id 5184; Fri, 11 Oct 91 14:41:03 GVA Received: from Lbl.Bitnet by CEARN.cern.ch (Mailer R2.07B) with BSMTP id 5156; Fri, 11 Oct 91 14:41:02 GVA Received: from Csa2.LBL.Gov by Csa3.LBL.Gov with INTERNET ; Fri, 11 Oct 91 06:39:01 PDT Received: from lbl.gov by Csa2.LBL.Gov with INTERNET ; Fri, 11 Oct 91 06:34:51 PDT Received: from vax.darpa.mil (darpa.mil) by lbl.gov (4.1/1.39) id AA00902; Fri, 11 Oct 91 06:38:29 PDT Received: by vax.darpa.mil (5.61/5.61+local-4) id ; Fri, 11 Oct 91 09:34:21 -0400 3) Charlie Catlett to me in 1991, certainly via NSFnet in one SMTP hop: From catlett at ncsa.uiuc.edu Fri Sep 27 16:15:04 1991 Received: by cernvax.cern.ch (5.57/Ultrix2.0-B) id AA11057; Fri, 27 Sep 91 16:15:00 +0200 Received: by dxmint.cern.ch (cernvax) (5.57/3.14) id AA01197; Fri, 27 Sep 91 16:12:58 +0200 Received: from headroom.ncsa.uiuc.edu by bardeen.ncsa.uiuc.edu with SMTP id AA01605 (5.65a/IDA-1.4.2 for brian at cernvax.cern.ch); Fri, 27 Sep 91 09:15:11 -0500 Return-Path: Received: by headroom.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA03413; Fri, 27 Sep 91 09:15:10 CDT Regards Brian On 14-Sep-20 09:42, the keyboard of geoff goodfellow wrote: > vis-a-vis "We weren't supposed to use?NSFnet to access .com addresses..." but what about .US addresses? > > as a part of Internet History: yours truly registered the first host in the .US domain (fernwood.mpk.ca.us ) for Anterior Technology -- which was the 2nd commercial?internet business connected to the Internet via BARRNET?(our local NSF regional network provider) a half half block away from SRI in Menlo Park back in 1989 out of a spare bedroom on a MIPS M1000 computer. > > prior?to Anterior morphing into wireless email (RadioMail), Anterior started it's commercial business providing moderated USENET feeds (the In Moderation Network) as well as offering commercial dialup/dialout UUCP (for mail and USENET) connections to local businesses?viz.: > https://www.deepdyve.com/lp/association-for-computing-machinery/news-track-QKpCn05nS0 > > ERGO, don't see how "policy" routing based on a domain name would "guarantee" the non-commercialness of said traffic, especially In Those Days when (via UUCP) email addresses could take the form of foo!bar at fernwood.mpk.ca.us (or any other UUCP to net relay host). > > geoff > > On Sun, Sep 13, 2020 at 10:58 AM Brian E Carpenter > wrote: > > Hi Vint, > > That sounds as if there was seen to be a distinction between email flows > (human to human communication) and data flows (machine to machine). When > we at CERN discussed connections and costs with Steve Goldstein at NSF, > it was in the context of bulk scientific data transfer (for American > physicists associated with CERN experiments). We weren't supposed to use > NSFnet to access .com addresses, but prior to BGP4 that was a bit of a > problem and "policy based routing" was a constant talking point. > > Harvey Newman (then and now at Caltech) used to say "Every grad student > needs 64 kb/s" and that was how we calculated capacity requirements around > 1990. We all knew that email was important, but we all knew that money > was granted for scientific data transfer. > > Regards > ? ?Brian > > On 14-Sep-20 00:02, Vint Cerf wrote: > > Brian, > > in 1988 the then Federal Networking Council (or its predecessor, the FRICC) gave me permission to connect the commercial MCI Mail to the NSFNET backbone. This connection occurred in 1989, the same year that UUNET, PSINET and CERFNET came into operation and, I think, interconnected at the CIX. Other email services (Compuserve, OnTyme, Telemail) were also given permission to connect. In 1992 legislation was passed to allow this formally (Boucher Bill I thinik?). > > v > > > > > > On Sat, Sep 12, 2020 at 11:12 PM Brian E Carpenter via Internet-history >> wrote: > > > >? ? ?In my humble (non-American) opinion, some of the arguments made at that > >? ? ?time were very self-serving. I think that Guy Almes and Steve Goldstein > >? ? ?between them could explain better than me, but NSFnet always had an > >? ? ?acceptable use policy that (since it was taxpayer-funded) only allowed > >? ? ?"free" transit for traffic to or from a legitimate NSF user, i.e. one end > >? ? ?or both ends of a flow had to be a research site. Clearly the taxpayer > >? ? ?shouldn't pay for business-to-business traffic, and that fact was the > >? ? ?business case for creating CIX. > > > >? ? ?Neither NSFnet nor CIX was free of course; they just had very different > >? ? ?funding sources. It was my understanding at the time that ANS CO+RE was > >? ? ?created precisely to avoid cross-subsidy from NSF money. They did have > >? ? ?the advantage of knowledge transfer. > > > >? ? ?(All of this was of intense interest to us at CERN as we hosted a > >? ? ?transatlantic link to NSFnet and we too had to ensure that the NSFnet > >? ? ?AUP was respected. So we followed it pretty closely.) > > > >? ? ?Of course the idea that there are no settlements in the Internet is > >? ? ?a bit ridiculous. There are no settlements per "call" but connections > >? ? ?to transit providers and/or IXPs cost money. > > > >? ? ?Regards > >? ? ?? ?Brian Carpenter > > > >? ? ?On 11-Sep-20 12:21, the keyboard of geoff goodfellow via Internet-history wrote: > >? ? ?> On Thu, Sep 10, 2020 at 10:42 AM *Jack Haverty via Internet-history > >? ? ?> > >>> wrote* > >? ? ?> : > >? ? ?> > >? ? ?>> CCITT was working on X.25, and creating X.75, to interconnect their > >? ? ?>> networks.? It was a natural evolution of the PTT's prior interconnection > >? ? ?>> of their telephone networks.? ?Later, as DDN marched down the X.25 path, > >? ? ?>> the subsequent government Internet might have ended up based on > >? ? ?>> X.25/X.75.? ?If it worked. > >? ? ?>> > >? ? ?> > >? ? ?> part and parcel of the X.25 and X.75 networking shibboleth was the notion > >? ? ?> of "settlements" -- just like with the PTT's interconnection of their > >? ? ?> telephone networks -- where The Fee for/of Transit was split along a > >? ? ?> "calls" participants/networks transited. > >? ? ?> > >? ? ?> IIRC, Advanced Network and Services (ANS) tried to "imprint" the > >? ? ?> settlements model on the fledgling Internet -- with them In The Middle > >? ? ?> collecting a fee for transit (for commercial traffic) between networks as > >? ? ?> well as for interconnection with The Budding commercial Internet upstarts > >? ? ?> (PSI, ALTERNET, etc.) the resulting in the founding of the CIX, viz.: > >? ? ?> > >? ? ?> > >? ? ?> *Data Network Raises Monopoly Fear* > >? ? ?> By JOHN MARKOFF > >? ? ?> The New York Times > >? ? ?> December 19, 1991 > >? ? ?> http://www.nytimes.com/1991 > >? ? ?> /12/19/business/data-network-raises-monopoly-fear.html > >? ? ?> > >? ? ?> Soon after President Bush signed legislation calling for the creation of a > >? ? ?> nationwide computer data "superhighway," a debate has erupted over whether > >? ? ?> the Government gave an unfair advantage to a joint venture of I.B.M. MCI > >? ? ?> that built and manages a key part of the network. > >? ? ?> > >? ? ?> The venture, known as Advanced Network and Services, manages a network > >? ? ?> called NSFnet, which connects hundreds of research centers and > >? ? ?> universities. NSFnet also manages links to dozens of other countries. All > >? ? ?> these networks are collectively known as Internet. > >? ? ?> > >? ? ?> Some private competitors say Advanced Network and Services uses its favored > >? ? ?> position to squeeze them out of the data-transmission market by > >? ? ?> establishing rules that make it difficult to connect to NSFnet. > >? ? ?> > >? ? ?> *Traffic Has Doubled* > >? ? ?> > >? ? ?> NSFnet was founded by the National Science Foundation, a Federal agency, > >? ? ?> and is composed of leased telephone lines that link special computers > >? ? ?> called routers, which transmit packages of data to three million users in > >? ? ?> 33 countries. Data traffic over the NSFnet backbone has doubled in the last > >? ? ?> year. > >? ? ?> > >? ? ?> The Government wants to develop a national data highway for electronic > >? ? ?> commerce, digital video transmissions to homes and vast electronic > >? ? ?> libraries that could be drawn on by the nation's schools. > >? ? ?> > >? ? ?> Advanced Network and Services, based in Elmsford, N.Y., was set up last > >? ? ?> year as a nonprofit corporation with $10 million from the International > >? ? ?> Business Machines Corporation and the MCI Communications Corporation. > >? ? ?> Earlier this year it set up a for-profit subsidiary, called ANS CO+RE > >? ? ?> (pronounced core), to sell computer network services. That led some > >? ? ?> competitors to complain that Advanced Network and Services would be able to > >? ? ?> compete unfairly because of its arrangement with the Government. > >? ? ?> > >? ? ?> *Fear Loss of Innovation* > >? ? ?> > >? ? ?> People involved in planning for a national data network say it is essential > >? ? ?> to provide for fair competition, which will lead rival companies to offer > >? ? ?> creative and entrepreneurial services in the hope of building market share. > >? ? ?> Without competiton, they say, the Government will have created a monopoly > >? ? ?> that has little incentive to innovate. > >? ? ?> > >? ? ?> "This is the first major communication business to be born under the > >? ? ?> deregulation era," said David Farber, a computer scientist at the > >? ? ?> University of Pennsylvania and a pioneer in data networking. "This hasn't > >? ? ?> happened since the growth of the telephone industry. You want it to be a > >? ? ?> business that doesn't repeat the errors of the past." > >? ? ?> > >? ? ?> In recent years, the National Science Foundation has tried to shift its > >? ? ?> operations and ownership of NSFnet to Advanced Network and Services. And it > >? ? ?> will try to establish competition through contracts for networks to compete > >? ? ?> with NSFnet next year. > >? ? ?> > >? ? ?> But there is no level playing field, complained William L. Schrader, > >? ? ?> president of Performance Systems International Inc., a Reston, Va., company > >? ? ?> that provides commercial data connections to Internet. He made public two > >? ? ?> letters between officials of Advanced Network and Services and the National > >? ? ?> Science Foundation that he said gave the company unfair control over access > >? ? ?> to the network. The result, he added, was that the Government turned over > >? ? ?> valuable public property to a private company. > >? ? ?> > >? ? ?> "It's like taking a Federal park and giving it to K Mart," Mr. Schrader > >? ? ?> said. "It's not right, and it isn't going to stand." > >? ? ?> > >? ? ?> Performance Systems and several other companies have set up an alternative > >? ? ?> to NSFnet, known as a CIX. Mr. Schrader said his company and the venture of > >? ? ?> I.B.M. and MCI were competing for the same customers but unlike his rival > >? ? ?> he lacked a Federal subsidy. He said he might ask the Internal Revenue > >? ? ?> Service to look at the business relationship between Advanced Network's > >? ? ?> nonprofit and for-profit operations. > >? ? ?> > >? ? ?> *'Very Competitive Environment'* > >? ? ?> > >? ? ?> Allan Weis, the president of Advanced Network, disputed that his company > >? ? ?> had an unfair advantage. "It's a very competitive environment right now," > >? ? ?> he said. > >? ? ?> > >? ? ?> At the National Science Foundation, Stephen Wolff, director of its > >? ? ?> networking division, said I.B.M. and MCI had overbuilt the network and were > >? ? ?> selling commercial service based on the excess capacity that was available. > >? ? ?> > >? ? ?> A number of organizations are working informally to settle the dispute. > >? ? ?> > >? ? ?> "I think it's a mess," said Mitchell D. Kapor, the founder of the Lotus > >? ? ?> Development Corporation and now head of the Electronic Frontier Foundation, > >? ? ?> a public-interest group focusing on public policy issues surrounding data > >? ? ?> networks. "Nobody should have an unfair advantage." > >? ? ?> > >? ? ?> > >? ? ?-- > >? ? ?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 > > 1435 Woodhurst Blvd? > > McLean, VA 22102 > > 703-448-0965 > > > > until further notice > > > > > > > > > > > -- > Geoff.Goodfellow at iconia.com > living as The Truth is True > > > From galmes at tamu.edu Sun Sep 13 17:05:38 2020 From: galmes at tamu.edu (Guy Almes) Date: Sun, 13 Sep 2020 20:05:38 -0400 Subject: [ih] NO "settlements" as part of Internet History In-Reply-To: References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> Message-ID: <25039198-3215-fc8c-468e-ca063c78d5bc@tamu.edu> Geoff, Brian, Vint, et al., Ah, settlements, ANS, the CIX, the NSF AUP, circa 1991. As Brian notes, I was a minor player since, in early 1991, I transitioned from the university world (where I'd run an NSFnet-related regional network in Texas) to working at ANS (the "joint venture" that John Markoff refers to in the NYT article below. As with the more interesting (to me) topic of transition from EGP to BGP, I'll try to emphasize the historical part and not attempt to be saying anything that might be part of a currently controversial topic. One preface: this was certainly an era of "exponential growth", both traffic and the number of sites connected and other measures were doubling every few months. And one property of a system experiencing rapid exponential growth is that, along with rapid quantitative changes come what seem like substantial qualitative changes. And this makes communication and cooperation and other things, in a word, hard. Anyway, one thing that I perceived in 1991 was the value of what was sometimes called the "NSFnet model" during the late 1980s -- with campuses connected to (usually) disjoint state/regional networks and with these all connected to a single very fast backbone. Between summer 1988 and the 1991 period of the Markwood article the advantages of that model were quite evident. For example, the NSFnet backbone was using T1 circuits in 1988 while most of the connections to campuses used 56kb/s leased lines. The factor of 24 increase in backbone capacity was key to the rapid exponential growth of the late 1980s. And, by the way, it fueled innovation by raising the bar on scalable applications with growing end-to-end performance. As the regionals began to make greater use of T1 circuits, the need for the NSFnet backbone to grow to T3 was evident, but the thinking (and here I am repeating what I recall being said at the time -- I was not part of this planning) was that NSF could not pay for 100% of the cost of the needed T3 circuits, but they could pay a large part of that. And this would especially work if some other source (e.g., non-agency and perhaps non-research/education-community) could pay for the balance. Similarly, ANS was formed, in part, to organize how the backbone could move from T1 circuits to T3 circuits. The idea was that this would preserve the scalability and rapid increase in backbone capacity and thus spur growth and application innovation. The new commercial networks could then connect to and benefit from this super-fast backbone and also benefit. For several different reasons, some of the pioneering commercial ISPs did not see things that way. They were happy to build their own T1-based national networks and thus be "peer" national networks with the NSFnet/ANS backbone rather than build a set of regional commercial networks that would make use of the new T3 backbone. At the time, this seemed to me (I won't speak for my ANS colleagues or any others) as unfortunate and maybe irrational. Unfortunate in that these new commercial networks would paying more for their multiple T1-based infrastructure and not be "contributing" in modest ways to the economies of scale of a shared super-fast (T3) backbone. The pioneer commercial networks, especially PSI and UUnet/Alternet, wanted to interconnect with "zero settlements" (i.e., paying nothing toward the costs of the T3 backbone). This seemed unfair to us at ANS. And ANS wanted to establish a workable way for commercial traffic to contribute toward the shared 'backbone'. This seemed unfair to the pioneer commercial ISPs. The term "settlements" was indeed used, though I don't recall anyone suggesting anything like the X.25/X.75 model of per-"call" money changing hands. This is all 30 years ago and so much has changed. Trying to be fair to all, I think it comes down to ANS believing in the value of a shared "backbone" layer, even with competition for commercial customers, and with figuring out how to amicably figure out how to arrange for the costs of the "backbone" to be shared between the research/education world and the commercial world. It should have been a "win-win" but was a show-stopper. And the pioneer commercial networks believed in multiple independent national networks, peering with "zero settlements" at exchange points. In many respects, the pros and cons of backbone/hierarchy models and exchange point models remain to this day. I won't say more here, mainly to keep focused on the history of the 1991 era. In hindsight, I think there were several hard lessons that we were all learning. <> While the advantages of the backbone/hierarchy model remain, it was natural to overemphasize those advantages in 1991. Over the multiple decades since the 1984ish deregulation of long distance (inter-LATA) telecommunication services, the relative cost of the "long distance" part of end-to-end communication costs has decreased. <> The non-technical difficulties with asking the pioneer commercial networks to accept a notion of being upstream or downstream from a backbone provider, even apart from any technical or economic or operational issues, was great than I expected. <> While the Internet of circa 1990 was mostly based on universities and research labs and the new commercial players (both providers and customers) wanted access to it, things were changing rapidly. By 1995, with the recompetition for NSF funding for university-based regionals, the university world realized (if no before) than they were no longer the center of the Internet, but that they were, in a word, customers. So there was probably a mix of (a) companies striving for economic/ competitive advantage and (b) companies trying to navigate a set of paradigm shifts that few understood clearly. One closing comment; I vividly recall reading the John Markwood NYT article below when it was new. One quote that makes me grimace / smile even now is Bill Shrader's [["It's like taking a Federal park and giving it to K Mart," Mr. Schrader said.]] Given the origins of PSI with the NSFnet-based regional in New York state, this struck me as extreme chutzpah. I recall wondering why it was bad with a Federal park, but not with a state park. But that was, as I say, 30 years ago. At the time, it was not a pretty picture, but time heals all wounds? Cheers, -- Guy On 9/10/20 8:21 PM, the keyboard of geoff goodfellow via Internet-history wrote: > On Thu, Sep 10, 2020 at 10:42 AM *Jack Haverty via Internet-history > > wrote* > : > >> CCITT was working on X.25, and creating X.75, to interconnect their >> networks. It was a natural evolution of the PTT's prior interconnection >> of their telephone networks. Later, as DDN marched down the X.25 path, >> the subsequent government Internet might have ended up based on >> X.25/X.75. If it worked. >> > > part and parcel of the X.25 and X.75 networking shibboleth was the notion > of "settlements" -- just like with the PTT's interconnection of their > telephone networks -- where The Fee for/of Transit was split along a > "calls" participants/networks transited. > > IIRC, Advanced Network and Services (ANS) tried to "imprint" the > settlements model on the fledgling Internet -- with them In The Middle > collecting a fee for transit (for commercial traffic) between networks as > well as for interconnection with The Budding commercial Internet upstarts > (PSI, ALTERNET, etc.) the resulting in the founding of the CIX, viz.: > > > *Data Network Raises Monopoly Fear* > By JOHN MARKOFF > The New York Times > December 19, 1991 > https://urldefense.com/v3/__http://www.nytimes.com/1991__;!!KwNVnqRv!RmH212ZDH6MdnCAAMUUO7OLJexwNzF_HWvEP5LJV-CL_IWJh4Qof2_qA5z-Yqw$ > /12/19/business/data-network-raises-monopoly-fear.html > > Soon after President Bush signed legislation calling for the creation of a > nationwide computer data "superhighway," a debate has erupted over whether > the Government gave an unfair advantage to a joint venture of I.B.M. MCI > that built and manages a key part of the network. > > The venture, known as Advanced Network and Services, manages a network > called NSFnet, which connects hundreds of research centers and > universities. NSFnet also manages links to dozens of other countries. All > these networks are collectively known as Internet. > > Some private competitors say Advanced Network and Services uses its favored > position to squeeze them out of the data-transmission market by > establishing rules that make it difficult to connect to NSFnet. > > *Traffic Has Doubled* > > NSFnet was founded by the National Science Foundation, a Federal agency, > and is composed of leased telephone lines that link special computers > called routers, which transmit packages of data to three million users in > 33 countries. Data traffic over the NSFnet backbone has doubled in the last > year. > > The Government wants to develop a national data highway for electronic > commerce, digital video transmissions to homes and vast electronic > libraries that could be drawn on by the nation's schools. > > Advanced Network and Services, based in Elmsford, N.Y., was set up last > year as a nonprofit corporation with $10 million from the International > Business Machines Corporation and the MCI Communications Corporation. > Earlier this year it set up a for-profit subsidiary, called ANS CO+RE > (pronounced core), to sell computer network services. That led some > competitors to complain that Advanced Network and Services would be able to > compete unfairly because of its arrangement with the Government. > > *Fear Loss of Innovation* > > People involved in planning for a national data network say it is essential > to provide for fair competition, which will lead rival companies to offer > creative and entrepreneurial services in the hope of building market share. > Without competiton, they say, the Government will have created a monopoly > that has little incentive to innovate. > > "This is the first major communication business to be born under the > deregulation era," said David Farber, a computer scientist at the > University of Pennsylvania and a pioneer in data networking. "This hasn't > happened since the growth of the telephone industry. You want it to be a > business that doesn't repeat the errors of the past." > > In recent years, the National Science Foundation has tried to shift its > operations and ownership of NSFnet to Advanced Network and Services. And it > will try to establish competition through contracts for networks to compete > with NSFnet next year. > > But there is no level playing field, complained William L. Schrader, > president of Performance Systems International Inc., a Reston, Va., company > that provides commercial data connections to Internet. He made public two > letters between officials of Advanced Network and Services and the National > Science Foundation that he said gave the company unfair control over access > to the network. The result, he added, was that the Government turned over > valuable public property to a private company. > > "It's like taking a Federal park and giving it to K Mart," Mr. Schrader > said. "It's not right, and it isn't going to stand." > > Performance Systems and several other companies have set up an alternative > to NSFnet, known as a CIX. Mr. Schrader said his company and the venture of > I.B.M. and MCI were competing for the same customers but unlike his rival > he lacked a Federal subsidy. He said he might ask the Internal Revenue > Service to look at the business relationship between Advanced Network's > nonprofit and for-profit operations. > > *'Very Competitive Environment'* > > Allan Weis, the president of Advanced Network, disputed that his company > had an unfair advantage. "It's a very competitive environment right now," > he said. > > At the National Science Foundation, Stephen Wolff, director of its > networking division, said I.B.M. and MCI had overbuilt the network and were > selling commercial service based on the excess capacity that was available. > > A number of organizations are working informally to settle the dispute. > > "I think it's a mess," said Mitchell D. Kapor, the founder of the Lotus > Development Corporation and now head of the Electronic Frontier Foundation, > a public-interest group focusing on public policy issues surrounding data > networks. "Nobody should have an unfair advantage." > > From dhc at dcrocker.net Sun Sep 13 17:27:02 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Sun, 13 Sep 2020 17:27:02 -0700 Subject: [ih] NO "settlements" as part of Internet History In-Reply-To: <1ff7906d-f5ea-311e-220e-4838ba9b91c2@gmail.com> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> <442a4b6d-1384-dc66-0a28-c1406e4a611f@gmail.com> <1ff7906d-f5ea-311e-220e-4838ba9b91c2@gmail.com> Message-ID: On 9/13/2020 1:58 PM, Brian E Carpenter via Internet-history wrote: > That sounds as if there was seen to be a distinction between email flows > (human to human communication) and data flows (machine to machine). Email was the internetworking gateway drug. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From geoff at iconia.com Sun Sep 13 18:11:28 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 13 Sep 2020 15:11:28 -1000 Subject: [ih] NO "settlements" as part of Internet History In-Reply-To: <25039198-3215-fc8c-468e-ca063c78d5bc@tamu.edu> References: <3E96B7C0-C6A2-4D8C-B5C5-DA18FFFC21A0@lynch.com> <3491ea10-78cc-b657-3c39-62877810d74b@3kitty.org> <658c4d4b-e616-a6cf-d5a3-ca588ee5b6f9@3kitty.org> <25039198-3215-fc8c-468e-ca063c78d5bc@tamu.edu> Message-ID: guy, yours truly would Dearly Love for you (and/or anyone else, Pretty Please!) to chime in and say more here vis-a-vis the history of this subject matter and more BEYOND the 1991 era! a clarification and expansion vis-a-vis "The term "settlements" was indeed used, though I don't recall anyone suggesting anything like the X.25/X.75 model of per-"call" money changing hands." yours truly used the word "calls" specifically because, like as/in the voice landline Public Switched Telephone Networks (PSTN), the X.25/X.75 networks use(d) Virtual Circuits for End-To-End connections and thusly charged users accordingly: in the voice based PSTN the fee/charge/tariff was for the length of time a call: from the receipt by the callers switch of Answer Supervision on the receiving end Switch until call termination. On the X.25/X.75 data networks not only were you charged a fee for the length of time the Virtual Circuit was established/up/connected, but were also docked an additional fee -- per some unit (IIRC, KB) -- for/of data sent/received over the Virtual Circuit "call". luckly, in the Internet "model" we have/had a Sender Keeps All (the revenue) Model with NO inter carrier/inter networking Settlements for our data connections/transmissions (nee "calls" :D) geoff On Sun, Sep 13, 2020 at 2:05 PM *Guy Almes > wrote:* > Geoff, Brian, Vint, et al., > Ah, settlements, ANS, the CIX, the NSF AUP, circa 1991. > As Brian notes, I was a minor player since, in early 1991, I > transitioned from the university world (where I'd run an NSFnet-related > regional network in Texas) to working at ANS (the "joint venture" that > John Markoff refers to in the NYT article below. > > As with the more interesting (to me) topic of transition from EGP to > BGP, I'll try to emphasize the historical part and not attempt to be > saying anything that might be part of a currently controversial topic. > > One preface: this was certainly an era of "exponential growth", both > traffic and the number of sites connected and other measures were > doubling every few months. > And one property of a system experiencing rapid exponential growth is > that, along with rapid quantitative changes come what seem like > substantial qualitative changes. > And this makes communication and cooperation and other things, in a > word, hard. > > Anyway, one thing that I perceived in 1991 was the value of what was > sometimes called the "NSFnet model" during the late 1980s -- with > campuses connected to (usually) disjoint state/regional networks and > with these all connected to a single very fast backbone. Between summer > 1988 and the 1991 period of the Markwood article the advantages of that > model were quite evident. For example, the NSFnet backbone was using T1 > circuits in 1988 while most of the connections to campuses used 56kb/s > leased lines. > The factor of 24 increase in backbone capacity was key to the rapid > exponential growth of the late 1980s. And, by the way, it fueled > innovation by raising the bar on scalable applications with growing > end-to-end performance. > As the regionals began to make greater use of T1 circuits, the need > for the NSFnet backbone to grow to T3 was evident, but the thinking (and > here I am repeating what I recall being said at the time -- I was not > part of this planning) was that NSF could not pay for 100% of the cost > of the needed T3 circuits, but they could pay a large part of that. And > this would especially work if some other source (e.g., non-agency and > perhaps non-research/education-community) could pay for the balance. > Similarly, ANS was formed, in part, to organize how the backbone > could move from T1 circuits to T3 circuits. The idea was that this > would preserve the scalability and rapid increase in backbone capacity > and thus spur growth and application innovation. The new commercial > networks could then connect to and benefit from this super-fast backbone > and also benefit. > For several different reasons, some of the pioneering commercial ISPs > did not see things that way. They were happy to build their own > T1-based national networks and thus be "peer" national networks with the > NSFnet/ANS backbone rather than build a set of regional commercial > networks that would make use of the new T3 backbone. > > At the time, this seemed to me (I won't speak for my ANS colleagues > or any others) as unfortunate and maybe irrational. Unfortunate in that > these new commercial networks would paying more for their multiple > T1-based infrastructure and not be "contributing" in modest ways to the > economies of scale of a shared super-fast (T3) backbone. > > The pioneer commercial networks, especially PSI and UUnet/Alternet, > wanted to interconnect with "zero settlements" (i.e., paying nothing > toward the costs of the T3 backbone). This seemed unfair to us at ANS. > And ANS wanted to establish a workable way for commercial traffic to > contribute toward the shared 'backbone'. This seemed unfair to the > pioneer commercial ISPs. > > The term "settlements" was indeed used, though I don't recall anyone > suggesting anything like the X.25/X.75 model of per-"call" money > changing hands. > > This is all 30 years ago and so much has changed. > Trying to be fair to all, I think it comes down to ANS believing in > the value of a shared "backbone" layer, even with competition for > commercial customers, and with figuring out how to amicably figure out > how to arrange for the costs of the "backbone" to be shared between the > research/education world and the commercial world. It should have been > a "win-win" but was a show-stopper. > And the pioneer commercial networks believed in multiple independent > national networks, peering with "zero settlements" at exchange points. > > In many respects, the pros and cons of backbone/hierarchy models and > exchange point models remain to this day. I won't say more here, mainly > to keep focused on the history of the 1991 era. > > In hindsight, I think there were several hard lessons that we were > all learning. > <> While the advantages of the backbone/hierarchy model remain, it was > natural to overemphasize those advantages in 1991. Over the multiple > decades since the 1984ish deregulation of long distance (inter-LATA) > telecommunication services, the relative cost of the "long distance" > part of end-to-end communication costs has decreased. > <> The non-technical difficulties with asking the pioneer commercial > networks to accept a notion of being upstream or downstream from a > backbone provider, even apart from any technical or economic or > operational issues, was great than I expected. > <> While the Internet of circa 1990 was mostly based on universities and > research labs and the new commercial players (both providers and > customers) wanted access to it, things were changing rapidly. By 1995, > with the recompetition for NSF funding for university-based regionals, > the university world realized (if no before) than they were no longer > the center of the Internet, but that they were, in a word, customers. > > So there was probably a mix of (a) companies striving for economic/ > competitive advantage and (b) companies trying to navigate a set of > paradigm shifts that few understood clearly. > > One closing comment; I vividly recall reading the John Markwood NYT > article below when it was new. One quote that makes me grimace / smile > even now is Bill Shrader's [["It's like taking a Federal park and giving > it to K Mart," Mr. Schrader said.]] Given the origins of PSI with the > NSFnet-based regional in New York state, this struck me as extreme > chutzpah. I recall wondering why it was bad with a Federal park, but > not with a state park. > But that was, as I say, 30 years ago. At the time, it was not a > pretty picture, but time heals all wounds? > > Cheers, > -- Guy > > On 9/10/20 8:21 PM, the keyboard of geoff goodfellow via > Internet-history wrote: > > On Thu, Sep 10, 2020 at 10:42 AM *Jack Haverty via Internet-history > > > > wrote* > > : > > > >> CCITT was working on X.25, and creating X.75, to interconnect their > >> networks. It was a natural evolution of the PTT's prior interconnection > >> of their telephone networks. Later, as DDN marched down the X.25 path, > >> the subsequent government Internet might have ended up based on > >> X.25/X.75. If it worked. > >> > > > > part and parcel of the X.25 and X.75 networking shibboleth was the notion > > of "settlements" -- just like with the PTT's interconnection of their > > telephone networks -- where The Fee for/of Transit was split along a > > "calls" participants/networks transited. > > > > IIRC, Advanced Network and Services (ANS) tried to "imprint" the > > settlements model on the fledgling Internet -- with them In The Middle > > collecting a fee for transit (for commercial traffic) between networks as > > well as for interconnection with The Budding commercial Internet upstarts > > (PSI, ALTERNET, etc.) the resulting in the founding of the CIX, viz.: > > > > > > *Data Network Raises Monopoly Fear* > > By JOHN MARKOFF > > The New York Times > > December 19, 1991 > > > https://urldefense.com/v3/__http://www.nytimes.com/1991__;!!KwNVnqRv!RmH212ZDH6MdnCAAMUUO7OLJexwNzF_HWvEP5LJV-CL_IWJh4Qof2_qA5z-Yqw$ > > /12/19/business/data-network-raises-monopoly-fear.html > > > > Soon after President Bush signed legislation calling for the creation of > a > > nationwide computer data "superhighway," a debate has erupted over > whether > > the Government gave an unfair advantage to a joint venture of I.B.M. MCI > > that built and manages a key part of the network. > > > > The venture, known as Advanced Network and Services, manages a network > > called NSFnet, which connects hundreds of research centers and > > universities. NSFnet also manages links to dozens of other countries. All > > these networks are collectively known as Internet. > > > > Some private competitors say Advanced Network and Services uses its > favored > > position to squeeze them out of the data-transmission market by > > establishing rules that make it difficult to connect to NSFnet. > > > > *Traffic Has Doubled* > > > > NSFnet was founded by the National Science Foundation, a Federal agency, > > and is composed of leased telephone lines that link special computers > > called routers, which transmit packages of data to three million users in > > 33 countries. Data traffic over the NSFnet backbone has doubled in the > last > > year. > > > > The Government wants to develop a national data highway for electronic > > commerce, digital video transmissions to homes and vast electronic > > libraries that could be drawn on by the nation's schools. > > > > Advanced Network and Services, based in Elmsford, N.Y., was set up last > > year as a nonprofit corporation with $10 million from the International > > Business Machines Corporation and the MCI Communications Corporation. > > Earlier this year it set up a for-profit subsidiary, called ANS CO+RE > > (pronounced core), to sell computer network services. That led some > > competitors to complain that Advanced Network and Services would be able > to > > compete unfairly because of its arrangement with the Government. > > > > *Fear Loss of Innovation* > > > > People involved in planning for a national data network say it is > essential > > to provide for fair competition, which will lead rival companies to offer > > creative and entrepreneurial services in the hope of building market > share. > > Without competiton, they say, the Government will have created a monopoly > > that has little incentive to innovate. > > > > "This is the first major communication business to be born under the > > deregulation era," said David Farber, a computer scientist at the > > University of Pennsylvania and a pioneer in data networking. "This hasn't > > happened since the growth of the telephone industry. You want it to be a > > business that doesn't repeat the errors of the past." > > > > In recent years, the National Science Foundation has tried to shift its > > operations and ownership of NSFnet to Advanced Network and Services. And > it > > will try to establish competition through contracts for networks to > compete > > with NSFnet next year. > > > > But there is no level playing field, complained William L. Schrader, > > president of Performance Systems International Inc., a Reston, Va., > company > > that provides commercial data connections to Internet. He made public two > > letters between officials of Advanced Network and Services and the > National > > Science Foundation that he said gave the company unfair control over > access > > to the network. The result, he added, was that the Government turned over > > valuable public property to a private company. > > > > "It's like taking a Federal park and giving it to K Mart," Mr. Schrader > > said. "It's not right, and it isn't going to stand." > > > > Performance Systems and several other companies have set up an > alternative > > to NSFnet, known as a CIX. Mr. Schrader said his company and the venture > of > > I.B.M. and MCI were competing for the same customers but unlike his rival > > he lacked a Federal subsidy. He said he might ask the Internal Revenue > > Service to look at the business relationship between Advanced Network's > > nonprofit and for-profit operations. > > > > *'Very Competitive Environment'* > > > > Allan Weis, the president of Advanced Network, disputed that his company > > had an unfair advantage. "It's a very competitive environment right now," > > he said. > > > > At the National Science Foundation, Stephen Wolff, director of its > > networking division, said I.B.M. and MCI had overbuilt the network and > were > > selling commercial service based on the excess capacity that was > available. > > > > A number of organizations are working informally to settle the dispute. > > > > "I think it's a mess," said Mitchell D. Kapor, the founder of the Lotus > > Development Corporation and now head of the Electronic Frontier > Foundation, > > a public-interest group focusing on public policy issues surrounding data > > networks. "Nobody should have an unfair advantage." > > > > > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From gnu at toad.com Sun Sep 13 18:39:57 2020 From: gnu at toad.com (John Gilmore) Date: Sun, 13 Sep 2020 18:39:57 -0700 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: References: Message-ID: <9914.1600047597@hop.toad.com> dave walden wrote: > And the IEEE Annals of the History of Computing would surely like to see submission of a an anecdote (see https://annals-extras.org/anecdotes/ and https://annals-extras.org/anecdotes/writing/ ) or a longer piece submitted to the peer review process ( see https://www.computer.org/csdl/magazine/an and https://www.computer.org/publications/author-resources/peer-review/magazines ) Why would any veteran of the early Internet ever submit their historical reminisces to a group that locks the information up behind a paywall for its own profit? Click through Dave's links above to notice "Log in to access my content"!!! They'll require you to assign your copyright to them, too, but the "invitation to write for them" doesn't tell you that. Don't feed the IEEE or the ACM that bites you. Don't volunteer for their program committees or to be an editor, author or reviewer. They suck and you shouldn't suck. Put your energy and your time into something that feeds your community, not parasitizes it. Those orgs always have the option to make their information free -- they make a deliberate choice every day to lock it up. Part of what made the Internet successful (besides Interop!) was that anybody could download, read, share, spread -- and implement -- the specs for the protocols that it ran on. Without subscriptions, payments, royalties, copyrights, patents, transcribing things manually from printed paper, etc. Freedom. What a concept. Could catch on! I actually did order a few IEEE standards (through their commercial provider, what was it called? Global Technical Information?), because I had to implement them for a job. They cost like $50 for a 20-page pamphlet, took weeks to get, and were written to be incomprehensible. Whereas the RFCs were open, accessible, and (in the early days with Jon Postel editing) written to be understood. If someone from this list would like to start an open-access academic journal that covers the same subject matter, I would be very happy to recommend you to a likely source of startup funding for it. The best way to destroy bloodsucking copyright monopolies is to out-compete them. John Gilmore PS: Carl Malamud's Public.Resource.org is currently in federal court, defending itself (with EFF.org's help) to be able to publish copies of copyrighted standards, like building codes, that have become required by incorporation into state law. The standards orgs think they can have it both ways -- they write the rules that everyone is required by law to follow, but you can't read them unless you pay their monopoly price for the privilege! That team just won a Supreme Court case in April, affirming that states can't copyright their laws (Georgia tried). Support either or both orgs if you value open societies and oppose secret laws and proprietary standards. See: https://law.resource.org/ https://www.eff.org/cases/publicresource-freeingthelaw https://www.eff.org/deeplinks/2020/04/supreme-court-affirms-no-one-owns-law From brian.e.carpenter at gmail.com Sun Sep 13 19:49:03 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 14 Sep 2020 14:49:03 +1200 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: <9914.1600047597@hop.toad.com> References: <9914.1600047597@hop.toad.com> Message-ID: On 14-Sep-20 13:39, John Gilmore via Internet-history wrote: > dave walden wrote: >> And the IEEE Annals of the History of Computing would surely like to see submission of a an anecdote (see https://annals-extras.org/anecdotes/ and https://annals-extras.org/anecdotes/writing/ ) or a longer piece submitted to the peer review process ( see https://www.computer.org/csdl/magazine/an and https://www.computer.org/publications/author-resources/peer-review/magazines ) > > Why would any veteran of the early Internet ever submit their historical > reminisces to a group that locks the information up behind a paywall for > its own profit? I'll treat that as a non-rhetorical question, because there are quite a few reasons, unfortunately: 1) Reputation. The "Annals" is a very reputable journal with a strong peer-review process. I'm not aware of competitor in the open-access world for this specialization. 2) Tenure. That's a direct consequence of 1). Any academic will go for an A-grade publication because that's what tenure committees want. (And not only in US universities.) 3) Archival. Open-access journals, especially those without a major institutional backer, already have a sad record of closing down and vanishing. This has got to the point that the Internet Archive is now looking at doing formal deals with some of them. This is not a trivial issue: "... 176 digital open-access journals have vanished from the internet over the past two decades." https://www.theregister.com/2020/09/10/open_access_journal/ 4) Cost. Typically an author has to fund page charges to publish in an open-access journal. Some universities are willing to fund this, but not all. Whereas all universities already pay for access to A-grade journals. BTW it doesn't much matter whether you consider non-profits like the IEEE or the ACM, or the for-profit publishers like Springer or Elsevier. They all act much the same. So what's an author to do? Well, at least the non-profits don't forbid you to post the preprint version. Hence things like https://www.cs.auckland.ac.nz/~brian/FirstCiNZ.pdf. But that only lasts until the University drops my web site. The IEEE version will be around indefinitely. Effectively, the bar to creating an open-access "Journal of the History of the Internet" is quite high, because you have to knock off problems 1) through 4). It would be a wonderful thing to do, however. Brian > > Click through Dave's links above to notice "Log in to access my > content"!!! They'll require you to assign your copyright to them, too, > but the "invitation to write for them" doesn't tell you that. > > Don't feed the IEEE or the ACM that bites you. > > Don't volunteer for their program committees or to be an editor, author > or reviewer. They suck and you shouldn't suck. Put your energy and > your time into something that feeds your community, not parasitizes it. > Those orgs always have the option to make their information free -- they > make a deliberate choice every day to lock it up. > > Part of what made the Internet successful (besides Interop!) was that > anybody could download, read, share, spread -- and implement -- the > specs for the protocols that it ran on. Without subscriptions, > payments, royalties, copyrights, patents, transcribing things manually > from printed paper, etc. Freedom. What a concept. Could catch on! > > I actually did order a few IEEE standards (through their commercial > provider, what was it called? Global Technical Information?), because I > had to implement them for a job. They cost like $50 for a 20-page > pamphlet, took weeks to get, and were written to be incomprehensible. > Whereas the RFCs were open, accessible, and (in the early days with Jon > Postel editing) written to be understood. > > If someone from this list would like to start an open-access academic > journal that covers the same subject matter, I would be very happy to > recommend you to a likely source of startup funding for it. The best > way to destroy bloodsucking copyright monopolies is to out-compete them. > > John Gilmore > > PS: Carl Malamud's Public.Resource.org is currently in federal court, > defending itself (with EFF.org's help) to be able to publish copies of > copyrighted standards, like building codes, that have become required by > incorporation into state law. The standards orgs think they can have it > both ways -- they write the rules that everyone is required by law to > follow, but you can't read them unless you pay their monopoly price for > the privilege! That team just won a Supreme Court case in April, > affirming that states can't copyright their laws (Georgia tried). > Support either or both orgs if you value open societies and oppose > secret laws and proprietary standards. See: > > https://law.resource.org/ > https://www.eff.org/cases/publicresource-freeingthelaw > https://www.eff.org/deeplinks/2020/04/supreme-court-affirms-no-one-owns-law > From dave.walden.family at gmail.com Mon Sep 14 00:29:37 2020 From: dave.walden.family at gmail.com (dave walden) Date: Mon, 14 Sep 2020 03:29:37 -0400 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: <9914.1600047597@hop.toad.com> References: <9914.1600047597@hop.toad.com> Message-ID: On 9/13/2020 9:39 PM, John Gilmore wrote: dave walden wrote: > And the IEEE Annals of the History of Computing would surely like to see submission of a an anecdote or a longer piece submitted to the peer review process > Why would any veteran of the early Internet ever submit their historical > reminisces to a group that locks the information up behind a paywall for > its own profit? > > Dave replies: Because I think having the history exist in an organized way in an archival journal is important.? My view of the IEEE situation is: (a) like many other professional societies, they are struggling to adjust and keep doing their good work as the business model has changed out from under them because of digital communication and free exchange of information that came with the Internet we helped develop, and (b) they are moving (having to move) toward open access, e.g., see the anecdotes and events & sightings departments at ?https://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=9173848 If we want scholars who study or write our history in the future to have our valuable memories, I am guessing there is a better chance of them being found and studied in the Annals of the History of Computing (for example) than being found in the archives of this discussion group.? Also, in my experience, the IEEE is pretty good about giving permission to reuse content residing behind the paywall.? I am currently involved in my second instance of publishing a book for which much of the content was originally published in the Annals; in the first instance the book is essentially sold at cost (of printing and Amazon's markup above my wholesale price -- no IEEE fee for reuse); the second book will be similarly sold I understand.? In a more commercial example, a significant amount of the content of the wonderful _ENIAC in Action_ book by Haigh et al. (MIT Press) was previously published in the Annals. The journal of another organization of which I am a member, with a similar 40-year history and organized stable journal archive (http://tug.org/tugboat/contents.html), has open access for journal issues as soon as the next issue is published (so members who support the organization get some minor benefit of earlier access).? But this organization's publishing effort of essentially done by volunteers (who contributed *lots* of their time), and they have only one journal to produce.? (The IEEE Computer Society which produces the Annals has two dozen publications I believe.) My plea is for more practitioners of computing to spend more of their time helping the save the history they witnessed or are witnessing in an organized accessible way.? So much good history is discussed on this list -- for instance the InterOp discussion. Vint noted it would be good for someone to write about that.? I hope someone does.? I suggested one way for that writing to be disseminated beyond this list.? More important is that the history be written and somehow disseminated.? Maybe the discussions here are sufficient dissemination. Dave From vint at google.com Mon Sep 14 01:31:53 2020 From: vint at google.com (Vint Cerf) Date: Mon, 14 Sep 2020 04:31:53 -0400 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: References: <9914.1600047597@hop.toad.com> Message-ID: What about publishing as historical RFCS? On Mon, Sep 14, 2020, 03:29 dave walden via Internet-history < internet-history at elists.isoc.org> wrote: > On 9/13/2020 9:39 PM, John Gilmore wrote: > > dave walden wrote: > > > And the IEEE Annals of the History of Computing would surely like to see > submission of a an anecdote or a longer piece submitted to the peer review > process > > Why would any veteran of the early Internet ever submit their historical > > reminisces to a group that locks the information up behind a paywall for > > its own profit? > > > > Dave replies: > Because I think having the history exist in an organized way in an > archival journal is important. My view of the IEEE situation is: (a) > like many other professional societies, they are struggling to adjust > and keep doing their good work as the business model has changed out > from under them because of digital communication and free exchange of > information that came with the Internet we helped develop, and (b) they > are moving (having to move) toward open access, e.g., see the anecdotes > and events & sightings departments at > https://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=9173848 > If we want scholars who study or write our history in the future to have > our valuable memories, I am guessing there is a better chance of them > being found and studied in the Annals of the History of Computing (for > example) than being found in the archives of this discussion group. > Also, in my experience, the IEEE is pretty good about giving permission > to reuse content residing behind the paywall. I am currently involved > in my second instance of publishing a book for which much of the content > was originally published in the Annals; in the first instance the book > is essentially sold at cost (of printing and Amazon's markup above my > wholesale price -- no IEEE fee for reuse); the second book will be > similarly sold I understand. In a more commercial example, a > significant amount of the content of the wonderful _ENIAC in Action_ > book by Haigh et al. (MIT Press) was previously published in the Annals. > > The journal of another organization of which I am a member, with a > similar 40-year history and organized stable journal archive > (http://tug.org/tugboat/contents.html), has open access for journal > issues as soon as the next issue is published (so members who support > the organization get some minor benefit of earlier access). But this > organization's publishing effort of essentially done by volunteers (who > contributed *lots* of their time), and they have only one journal to > produce. (The IEEE Computer Society which produces the Annals has two > dozen publications I believe.) > > My plea is for more practitioners of computing to spend more of their > time helping the save the history they witnessed or are witnessing in an > organized accessible way. So much good history is discussed on this > list -- for instance the InterOp discussion. Vint noted it would be good > for someone to write about that. I hope someone does. I suggested one > way for that writing to be disseminated beyond this list. More > important is that the history be written and somehow disseminated. > Maybe the discussions here are sufficient dissemination. > > Dave > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From dave.walden.family at gmail.com Mon Sep 14 03:10:35 2020 From: dave.walden.family at gmail.com (dave walden) Date: Mon, 14 Sep 2020 06:10:35 -0400 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: References: <9914.1600047597@hop.toad.com> Message-ID: <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> Can a historical RFC be an original document written today about ih history more generally than about earlier RFCs?? If so, that sounds good to me as long as the existence of the RFC series on the web is stable.? If not, creating such a series with appropriate indexing and guidelines seems like a good idea to me. On 9/14/2020 4:31 AM, Vint Cerf wrote: > What about publishing as historical RFCS? > > From vgcerf at gmail.com Mon Sep 14 03:21:00 2020 From: vgcerf at gmail.com (vinton cerf) Date: Mon, 14 Sep 2020 06:21:00 -0400 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> Message-ID: good question. the independent RFC stream is pretty open; historic is usually with reference to a protocol so it would likely be considered a re-interpretation of the intent of the term. Regardless of the label, I don't see why a historical account could not be an independent stream submission. v On Mon, Sep 14, 2020 at 6:10 AM dave walden via Internet-history < internet-history at elists.isoc.org> wrote: > Can a historical RFC be an original document written today about ih > history more generally than about earlier RFCs? If so, that sounds good > to me as long as the existence of the RFC series on the web is stable. > If not, creating such a series with appropriate indexing and guidelines > seems like a good idea to me. > > On 9/14/2020 4:31 AM, Vint Cerf wrote: > > What about publishing as historical RFCS? > > > > > -- > 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 Sep 14 03:34:23 2020 From: brian.e.carpenter at gmail.com (Brian Carpenter) Date: Mon, 14 Sep 2020 22:34:23 +1200 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> Message-ID: "historic" tends to mean "obsolete" as an RFC label. They could just be labelled "informational" l think. But there are other issues (no photos, for example). Regards Brian (via tiny screen & keyboard) On Mon, 14 Sep 2020, 22:21 vinton cerf via Internet-history, < internet-history at elists.isoc.org> wrote: > good question. the independent RFC stream is pretty open; historic is > usually with reference to a protocol so it would likely be considered a > re-interpretation of the intent of the term. Regardless of the label, I > don't see why a historical account could not be an independent stream > submission. > v > > > On Mon, Sep 14, 2020 at 6:10 AM dave walden via Internet-history < > internet-history at elists.isoc.org> wrote: > > > Can a historical RFC be an original document written today about ih > > history more generally than about earlier RFCs? If so, that sounds good > > to me as long as the existence of the RFC series on the web is stable. > > If not, creating such a series with appropriate indexing and guidelines > > seems like a good idea to me. > > > > On 9/14/2020 4:31 AM, Vint Cerf wrote: > > > What about publishing as historical RFCS? > > > > > > > > -- > > 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 dave.walden.family at gmail.com Mon Sep 14 03:46:23 2020 From: dave.walden.family at gmail.com (dave walden) Date: Mon, 14 Sep 2020 06:46:23 -0400 Subject: [ih] "historical" RFCs as a way to publish ih history not behind a paywall In-Reply-To: References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> Message-ID: <576761d3-13a3-dc53-3723-76fe8e2797d8@gmail.com> I think it is a good option to figure out how to make work. For anyone who cares, I have a long plea for practitioners to work more explicitly to capture history: https://walden-family.com/texland/tb128walden-noticing.pdf? <= a preprint; I believe the print issue is on its way to readers now. On 9/14/2020 6:34 AM, Brian Carpenter wrote: > "historic" tends to mean "obsolete" as an RFC label. They could just > be labelled "informational" l think. But there are other issues (no > photos, for example). > > Regards > ??? Brian > ??? (via tiny screen & keyboard) > > From agmalis at gmail.com Mon Sep 14 04:54:26 2020 From: agmalis at gmail.com (Andrew G. Malis) Date: Mon, 14 Sep 2020 07:54:26 -0400 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> Message-ID: Here's an example of a recent "historically oriented" Informational RFC: https://www.rfc-editor.org/rfc/rfc8700.html . Vint contributed section 3.2. This one was published under the auspices of the IAB, but I believe the current Independent Submissions Editor, Adrian Farrel, would be quite open to similar RFCs. If you would like to sound out Adrian before actually starting any writing, you can reach him at rfc-ise at rfc-editor.org . Also see https://www.rfc-editor.org/about/independent/ and https://www.rfc-editor.org/rfc/rfc4846.txt for some process guidelines. Cheers, Andy On Mon, Sep 14, 2020 at 6:34 AM Brian Carpenter via Internet-history < internet-history at elists.isoc.org> wrote: > "historic" tends to mean "obsolete" as an RFC label. They could just be > labelled "informational" l think. But there are other issues (no photos, > for example). > > Regards > Brian > (via tiny screen & keyboard) > > On Mon, 14 Sep 2020, 22:21 vinton cerf via Internet-history, < > internet-history at elists.isoc.org> wrote: > > > good question. the independent RFC stream is pretty open; historic is > > usually with reference to a protocol so it would likely be considered a > > re-interpretation of the intent of the term. Regardless of the label, I > > don't see why a historical account could not be an independent stream > > submission. > > v > > > > > > On Mon, Sep 14, 2020 at 6:10 AM dave walden via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > > > Can a historical RFC be an original document written today about ih > > > history more generally than about earlier RFCs? If so, that sounds > good > > > to me as long as the existence of the RFC series on the web is stable. > > > If not, creating such a series with appropriate indexing and guidelines > > > seems like a good idea to me. > > > > > > On 9/14/2020 4:31 AM, Vint Cerf wrote: > > > > What about publishing as historical RFCS? > > > > > > > > > > > -- > > > 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 dhc at dcrocker.net Mon Sep 14 06:38:18 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 14 Sep 2020 06:38:18 -0700 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> Message-ID: <4555d364-992d-019a-5b4f-9bd400cc3691@dcrocker.net> On 9/14/2020 3:21 AM, vinton cerf via Internet-history wrote: > good question. the independent RFC stream is pretty open; historic is > usually with reference to a protocol so it would likely be considered a > re-interpretation of the intent of the term. Regardless of the label, I > don't see why a historical account could not be an independent stream > submission. > v Its openness is variable.? In effect, the IETF gets a veto over publication of anything related to IETF work.? The Independent Stream has the option to override the IETF but ... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From agmalis at gmail.com Mon Sep 14 06:50:21 2020 From: agmalis at gmail.com (Andrew G. Malis) Date: Mon, 14 Sep 2020 09:50:21 -0400 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: <4555d364-992d-019a-5b4f-9bd400cc3691@dcrocker.net> References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> <4555d364-992d-019a-5b4f-9bd400cc3691@dcrocker.net> Message-ID: Dave, The IETF can override an independent submission RFC that duplicates or conflicts with IETF technical work (it can't be an end-around), but other than that, the ISE and RFC Editor are free to use their own judgement on what's suitable to publish. Cheers, Andy On Mon, Sep 14, 2020 at 9:38 AM Dave Crocker via Internet-history < internet-history at elists.isoc.org> wrote: > On 9/14/2020 3:21 AM, vinton cerf via Internet-history wrote: > > good question. the independent RFC stream is pretty open; historic is > > usually with reference to a protocol so it would likely be considered a > > re-interpretation of the intent of the term. Regardless of the label, I > > don't see why a historical account could not be an independent stream > > submission. > > v > > Its openness is variable. In effect, the IETF gets a veto over > publication of anything related to IETF work. The Independent Stream > has the option to override the IETF but ... > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From dhc at dcrocker.net Mon Sep 14 06:59:49 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 14 Sep 2020 06:59:49 -0700 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> <4555d364-992d-019a-5b4f-9bd400cc3691@dcrocker.net> Message-ID: <7bf31d6c-f5b4-8442-3204-e24750b3f39b@dcrocker.net> On 9/14/2020 6:50 AM, Andrew G. Malis via Internet-history wrote: > The IETF can override an independent submission RFC that duplicates or > conflicts with IETF technical work (it can't be an end-around), but other > than that, the ISE and RFC Editor are free to use their own judgement on > what's suitable to publish. I co-authored a draft that suggested alternative language to use, in place of words the IETF uses to indicate normative requirement. For example using 'ought' in place of 'should'. This was to avoid relying on use of uppercase to indicate normative effect, though that was not formally defined as required at the time. (It is now.) The belief that using upper-/lower-case as a semantic distinction is one of the remarkable and continuing usability failures of computer science... There was no current work and the draft sought Informational status. It was meant as advice, not requirement. The ISE even got external review (including some folk reading this now) who unanimously felt the draft conflicted with the IETF. My best guess is that this was because we'd made the mistake of use some of those words in an apparently normative fashion. But since there was no actual dialogue between authors and reviewers, I can't be sure. My point is that The Independent Stream for RFC has actual editorial filtering. And editorial policy can vary quite a bit, depending on who the editor is. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From touch at strayalpha.com Mon Sep 14 08:16:30 2020 From: touch at strayalpha.com (Joseph Touch) Date: Mon, 14 Sep 2020 08:16:30 -0700 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: <7bf31d6c-f5b4-8442-3204-e24750b3f39b@dcrocker.net> References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> <4555d364-992d-019a-5b4f-9bd400cc3691@dcrocker.net> <7bf31d6c-f5b4-8442-3204-e24750b3f39b@dcrocker.net> Message-ID: > On Sep 14, 2020, at 6:59 AM, Dave Crocker via Internet-history wrote: > > My point is that The Independent Stream for RFC has actual editorial filtering. And editorial policy can vary quite a bit, depending on who the editor is. How the ISE runs is under active discussion and revision, FWIW. Currently, independent stream requires: - IETF and IAB confirmation of no-overlap with existing work - RSE editorial approval (which generally helps avoid publishing works that prove that 2+2 != ? seriously) - IESG and IAB back-seat driving That last part means that all independent stream docs include a disclaimer as follows: This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. However, although the RFC Editor publishes ?at their discretion?, the IESG and IAB often intercede and demand changes or additional text. Sometimes that intercession makes sense - e.g., to avoid implying a doc is related to IETF work. Other times, it?s just them back-seat driving. So publish there if you want nearly 2 dozen ?editors?... Joe From touch at strayalpha.com Mon Sep 14 08:20:57 2020 From: touch at strayalpha.com (Joseph Touch) Date: Mon, 14 Sep 2020 08:20:57 -0700 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: References: <9914.1600047597@hop.toad.com> Message-ID: > On Sep 14, 2020, at 12:29 AM, dave walden via Internet-history wrote: > > On 9/13/2020 9:39 PM, John Gilmore wrote: > > dave walden wrote: > >> And the IEEE Annals of the History of Computing would surely like to see submission of a an anecdote or a longer piece submitted to the peer review process >> Why would any veteran of the early Internet ever submit their historical >> reminisces to a group that locks the information up behind a paywall for >> its own profit? >> >> Dave replies: > Because I think having the history exist in an organized way in an archival journal is important. Also, they don?t. *EVERY* paper I have ever written with the IEEE and ACM are available at www.strayalpha.com , my website. That is done *with the permission of the IEEE and ACM*. They allow authors to post their work, typically up to the last version formatted by the author (which can include versions updated by the author to look very much like the final version). There are some restrictions - e.g., they don?t allow are posting all of the papers of a journal or conference at a single URL. However, for those two organizations, authors are generally permitted to post a copy of their work at their own site, even with the transfer of copyright. Joe From johnl at iecc.com Mon Sep 14 09:46:15 2020 From: johnl at iecc.com (John Levine) Date: 14 Sep 2020 12:46:15 -0400 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: Message-ID: <20200914164615.33FDF20B8B04@ary.qy> In article you write: > >What about publishing as historical RFCS? I suppose you could ask Adrian as Independent Stream Editor if he'd consider it. From joly at punkcast.com Mon Sep 14 11:52:29 2020 From: joly at punkcast.com (Joly MacFie) Date: Mon, 14 Sep 2020 14:52:29 -0400 Subject: [ih] VIDEO - Steve Crocker at AIS Message-ID: At the Africa Internet Forum earlier today, Steve Crocker gave a brief presentation on ARPANET history https://youtu.be/ybCcUsAzsEk?t=1455 -- -------------------------------------- Joly MacFie +2185659365 -------------------------------------- - From brian.e.carpenter at gmail.com Mon Sep 14 18:55:09 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 15 Sep 2020 13:55:09 +1200 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: <7bf31d6c-f5b4-8442-3204-e24750b3f39b@dcrocker.net> References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> <4555d364-992d-019a-5b4f-9bd400cc3691@dcrocker.net> <7bf31d6c-f5b4-8442-3204-e24750b3f39b@dcrocker.net> Message-ID: Dave, The example you quote was a bit of an oddball since it was explicitly trying to change the way documents *in the IETF stream* used the English language. I don't think that is what we are are discussing here. Anyway, a test case is the way to go. Expanding on what I scribbled last night: Even with the new shiny modern RFC format illustrated at https://www.rfc-editor.org/rfc/rfc8899.html there are considerable format restrictions: simple monochrome diagrams, not even grayscale, restricted use of Unicode, limited font effects, etc. In particular, there's only SVG graphics, so no scope for bitmap graphics such as JPG. So no historic photos. Full disclosure: Since I'm a current member of the Independent Stream Editorial Board, there's a good chance I would be one of the peer reviewers. Regards Brian On 15-Sep-20 01:59, Dave Crocker via Internet-history wrote: > On 9/14/2020 6:50 AM, Andrew G. Malis via Internet-history wrote: >> The IETF can override an independent submission RFC that duplicates or >> conflicts with IETF technical work (it can't be an end-around), but other >> than that, the ISE and RFC Editor are free to use their own judgement on >> what's suitable to publish. > > > I co-authored a draft that suggested alternative language to use, in > place of words the IETF uses to indicate normative requirement. For > example using 'ought' in place of 'should'. This was to avoid relying > on use of uppercase to indicate normative effect, though that was not > formally defined as required at the time. (It is now.) > > The belief that using upper-/lower-case as a semantic distinction is one > of the remarkable and continuing usability failures of computer science... > > There was no current work and the draft sought Informational status. It > was meant as advice, not requirement. > > The ISE even got external review (including some folk reading this now) > who unanimously felt the draft conflicted with the IETF. My best guess > is that this was because we'd made the mistake of use some of those > words in an apparently normative fashion. But since there was no actual > dialogue between authors and reviewers, I can't be sure. > > My point is that The Independent Stream for RFC has actual editorial > filtering. And editorial policy can vary quite a bit, depending on who > the editor is. > > d/ > From dhc at dcrocker.net Mon Sep 14 19:23:47 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 14 Sep 2020 19:23:47 -0700 Subject: [ih] Karl's post from Friday: Re: Interop as part of Internet History In-Reply-To: References: <9914.1600047597@hop.toad.com> <1c6ee073-420b-8491-6ca1-f84151bd337a@gmail.com> <4555d364-992d-019a-5b4f-9bd400cc3691@dcrocker.net> <7bf31d6c-f5b4-8442-3204-e24750b3f39b@dcrocker.net> Message-ID: <4c9f8bc2-08c2-16a4-d01d-b3d4a0dfc3ac@dcrocker.net> On 9/14/2020 6:55 PM, Brian E Carpenter via Internet-history wrote: > Dave, > > The example you quote was a bit of an oddball since it was > explicitly trying to change the way documents *in the IETF stream* > used the English language. I don't think that is what we are > are discussing here. Sorry, no. All of the streams produce RFCs that contain normative language. (OK, maybe the IAB stream doesn't, but IRTF, ISE and IETF certainly do.) So, forgive me, but our draft wasn't specific to the IETF. As for 'change' it was trying to offer advice for avoiding ambiguity, with better vocabulary separation. As I said, I later realized we had some normative language in there, but I considered that an error. That probably demonstrated the need we were trying to address far better than I'd wished... Ultimately, since there was no opportunity for actual discussion, there also was no opportunity for altering the document to permit it to address concerns. But again, my point for the thread here was that there is serious editorial filtering in the ISE, and it isn't always simple to predict what it will be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From touch at strayalpha.com Tue Sep 15 08:26:55 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 08:26:55 -0700 Subject: [ih] Update on filtered list posts Message-ID: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> Hi, all, I have confirmed that ISOC runs a filter that checks for ?inappropriate? words prior to Mailman handling. That filter was configured to trigger on the word ?hook-up? (without the hyphen) due to a spam flurry a few years ago. That tag seems a bit too generic, as we found out. I?ve suggested they look for a more specific phrase if possible, but for the current time, please insert a hyphen or space on that word. Also, note that profanity also trips the trigger, though we?d appreciate avoiding those terms rather than trying to find work-arounds. FYI. Joe (as list admin) From dhc at dcrocker.net Tue Sep 15 08:31:05 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 15 Sep 2020 08:31:05 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> Message-ID: <0797307d-a2aa-2751-a88b-a68a8e5281df@dcrocker.net> On 9/15/2020 8:26 AM, Joseph Touch via Internet-history wrote: > That filter was configured to trigger on the word ?hook-up? (without the hyphen) due to a spam flurry a few years ago. So, ISOC does not want to permit discussions about astronauts docking at the International Space Station? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From geoff at iconia.com Tue Sep 15 09:05:28 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Tue, 15 Sep 2020 06:05:28 -1000 Subject: [ih] Update on filtered list posts In-Reply-To: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> Message-ID: is it possible to see what other words (minus profanity) the ISOC filter considers as ?inappropriate?? isn't it a "violation" of email "protocol" (integrity/sanctity/trust) to not summarily BOUNCE the ?inappropriate? with an SMTP 550 reply as opposed to just /dev/null'ng a "transgressor" (as it so silently did with Karl's "hook-up" message)? the present behavior of the ISOC's mailer filter with respect to "losing" email without any type of notification to anyone seems, well, out-of-line/not congruent with email "norms", does it not? geoff [who since the early 70's has never heard or experienced any email delivery transport "operating" in this manner]. On Tue, Sep 15, 2020 at 5:27 AM Joseph Touch via Internet-history < internet-history at elists.isoc.org> wrote: > Hi, all, > > I have confirmed that ISOC runs a filter that checks for ?inappropriate? > words prior to Mailman handling. > > That filter was configured to trigger on the word ?hook-up? (without the > hyphen) due to a spam flurry a few years ago. > > That tag seems a bit too generic, as we found out. I?ve suggested they > look for a more specific phrase if possible, but for the current time, > please insert a hyphen or space on that word. Also, note that profanity > also trips the trigger, though we?d appreciate avoiding those terms rather > than trying to find work-arounds. > > FYI. > > Joe (as list admin) > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From gtaylor at tnetconsulting.net Tue Sep 15 10:05:08 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 15 Sep 2020 11:05:08 -0600 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> Message-ID: <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> On 9/15/20 10:05 AM, the keyboard of geoff goodfellow via Internet-history wrote: > is it possible to see what other words (minus profanity) the ISOC > filter considers as ?inappropriate?? +1 for access to the list somewhere > isn't it a "violation" of email "protocol" (integrity/sanctity/trust) > to not summarily BOUNCE the ?inappropriate? with an SMTP 550 reply > as opposed to just /dev/null'ng a "transgressor" (as it so silently > did with Karl's "hook-up" message)? It is against the spirit of email delivery. I think that it is not against the specification of SMPT. As I understand it, this filtering happens outside of SMTP. As such, SMTP did not fail in any way. > the present behavior of the ISOC's mailer filter with respect to > "losing" email without any type of notification to anyone seems, > well, out-of-line/not congruent with email "norms", does it not? It definitely violates the principle of least surprise ~> expectation. > [who since the early 70's has never heard or experienced any email > delivery transport "operating" in this manner]. I've run into this a few times. In almost every case, the people that put the filters in place, either PHBs directing or the technicians doing, didn't see the collateral damage or a way to avoid it and they felt the collateral damage was the lesser of the evils vs allowing the undesired email. Quite frequently, the purported sender was assumed to be spoofed, as such bouncing the message would result in a Joe Job, which is another different problem. Though, with the prevalence of SPF and DKIM, that's less likely now. -- Grant. . . . unix || die From ocl at gih.com Tue Sep 15 10:46:01 2020 From: ocl at gih.com (=?UTF-8?Q?Olivier_MJ_Cr=c3=a9pin-Leblond?=) Date: Tue, 15 Sep 2020 19:46:01 +0200 Subject: [ih] Update on filtered list posts In-Reply-To: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> Message-ID: <670f6b42-7b08-d728-0b1c-2d7a03450a1b@gih.com> Hello all, if you are curious, as an amusement, you can do a search on: hook-up spam (without the hypen) in your favourite search engine and will see what kind of emails this word referred to, although a word of warning, don't click on the links as some of them send you to unsecured places. Joking aside, Geoff Goodfellow asked whether a bounce email warning should be sent in return for postings that are deemed inappropriate. The problem is that often spam emails use a forged return address and can cause what's called "backscatter" https://en.wikipedia.org/wiki/Backscatter_(email) So scanners just drop them. This is the eternal problem of "false positives" which has been around since the earliest days of anti-virus scanners. Kindest regards, Olivier On 15/09/2020 17:26, Joseph Touch via Internet-history wrote: > Hi, all, > > I have confirmed that ISOC runs a filter that checks for ?inappropriate? words prior to Mailman handling. > > That filter was configured to trigger on the word ?hook-up? (without the hyphen) due to a spam flurry a few years ago. > > That tag seems a bit too generic, as we found out. I?ve suggested they look for a more specific phrase if possible, but for the current time, please insert a hyphen or space on that word. Also, note that profanity also trips the trigger, though we?d appreciate avoiding those terms rather than trying to find work-arounds. > > FYI. > > Joe (as list admin) From geoff at iconia.com Tue Sep 15 11:16:27 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Tue, 15 Sep 2020 08:16:27 -1000 Subject: [ih] Update on filtered list posts In-Reply-To: <670f6b42-7b08-d728-0b1c-2d7a03450a1b@gih.com> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <670f6b42-7b08-d728-0b1c-2d7a03450a1b@gih.com> Message-ID: aha, now a batting out of order "process" becomes clear, viz.: yours truly posits that the ISOC mail list PTB's have inserted an ?inappropriate? filter (double entendre on purpose :D) Postfix before-queue Milter [http://www.postfix.org/MILTER_README.html] before it "delivers"/"hands over" the goods (i.e. message) to the Mailman Mailing List Manager. how this is an apparent batting out-of-order: the ISOC Mailman Mailing List Manager is most likely configured so as to ONLY accept messages for distribution to IH from extant list members, therefore preventing any (errant/non-list registered email address) submissions to internet-history at elists.isoc.org from being "accepted" and processed. if the ordering were such that the Mailman Mailing List Manager address validation took place before The Forbidden Words Filter did it's thing, THEN a better (and more "correct") Forbidden Words Filtering could take place after sender address validation. then, if The Forbidden Words Filter detected A Forbidden Word, it could then instigate a "reply" message to the already authenticated/permitted/allowed "sender" notifying him/her to the effect their message contained A Forbidden Word and was not redistributed to the IH list. geoff On Tue, Sep 15, 2020 at 7:46 AM Olivier MJ Cr?pin-Leblond via Internet-history wrote: > Hello all, > > if you are curious, as an amusement, you can do a search on: hook-up > spam (without the hypen) in your favourite search engine and will see > what kind of emails this word referred to, although a word of warning, > don't click on the links as some of them send you to unsecured places. > > Joking aside, Geoff Goodfellow asked whether a bounce email warning > should be sent in return for postings that are deemed inappropriate. The > problem is that often spam emails use a forged return address and can > cause what's called "backscatter" > https://en.wikipedia.org/wiki/Backscatter_(email) > > So scanners just drop them. This is the eternal problem of "false > positives" which has been around since the earliest days of anti-virus > scanners. > > Kindest regards, > > Olivier > > On 15/09/2020 17:26, Joseph Touch via Internet-history wrote: > > Hi, all, > > > > I have confirmed that ISOC runs a filter that checks for ?inappropriate? > words prior to Mailman handling. > > > > That filter was configured to trigger on the word ?hook-up? (without the > hyphen) due to a spam flurry a few years ago. > > > > That tag seems a bit too generic, as we found out. I?ve suggested they > look for a more specific phrase if possible, but for the current time, > please insert a hyphen or space on that word. Also, note that profanity > also trips the trigger, though we?d appreciate avoiding those terms rather > than trying to find work-arounds. > > > > FYI. > > > > Joe (as list admin) > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From touch at strayalpha.com Tue Sep 15 11:20:39 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 11:20:39 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> Message-ID: <50E7F6CF-478F-4F2C-9F9D-0ACCDC29C782@strayalpha.com> > On Sep 15, 2020, at 9:05 AM, the keyboard of geoff goodfellow wrote: > > is it possible to see what other words (minus profanity) the ISOC filter considers as ?inappropriate?? They mentioned only the one we tripped over. The rest are just the usual ones. Joe From touch at strayalpha.com Tue Sep 15 11:27:22 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 11:27:22 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <670f6b42-7b08-d728-0b1c-2d7a03450a1b@gih.com> Message-ID: > On Sep 15, 2020, at 11:16 AM, the keyboard of geoff goodfellow via Internet-history wrote: > > aha, now a batting out of order "process" becomes clear, viz. > :... > if the ordering were such that the Mailman Mailing List Manager address > validation took place before The Forbidden Words Filter did it's thing, > THEN a better (and more "correct") Forbidden Words Filtering could take > place after sender address validation. I may be repeating myself, but we?re guests here. The ISOC has graciously offered to include us in the many lists they host for free. There are legitimate reasons for the order they use - e.g., to avoid spam on a large number of lists that are under separate control. I did already ask them to consider the collateral damage of using innocuous excerpts to filter for spam. I hope we can let them decide how to proceed. Joe From touch at strayalpha.com Tue Sep 15 11:29:55 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 11:29:55 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> Message-ID: <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> > On Sep 15, 2020, at 10:05 AM, Grant Taylor via Internet-history wrote: > > On 9/15/20 10:05 AM, the keyboard of geoff goodfellow via Internet-history wrote: >> is it possible to see what other words (minus profanity) the ISOC filter considers as ?inappropriate?? > > +1 for access to the list somewhere PS - I would doubt the ISOC wants to make that list public. It only invites attackers to game it. This is the same reason I never published the complete ruleset on other lists, e.g., to filter out non pre-approved conference announcements on E2E-interest. Joe From dan at lynch.com Tue Sep 15 11:32:53 2020 From: dan at lynch.com (Dan Lynch) Date: Tue, 15 Sep 2020 11:32:53 -0700 Subject: [ih] History Message-ID: <887F5CC9-7B86-495C-98F6-B74EA563DAD8@lynch.com> Karl, in all this flap about your accidental use of the hidden forbidden word in your superb description of the building of the net at various Interop events, did it ever make it to this list? Or could you insert the hyphen and resubmit it? You are an excellent narrator, sir. Thanks Dan Cell 650-776-7313 From gtaylor at tnetconsulting.net Tue Sep 15 11:37:30 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 15 Sep 2020 12:37:30 -0600 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <670f6b42-7b08-d728-0b1c-2d7a03450a1b@gih.com> Message-ID: On 9/15/20 12:16 PM, the keyboard of geoff goodfellow via Internet-history wrote: > yours truly posits that the ISOC mail list PTB's have inserted an > ?inappropriate? filter (double entendre on purpose :D) Postfix > before-queue Milter [http://www.postfix.org/MILTER_README.html] > before it "delivers"/"hands over" the goods (i.e. message) to the > Mailman Mailing List Manager. Agreed. Post-SMTP and Pre-Mailman. > how this is an apparent batting out-of-order: > > the ISOC Mailman Mailing List Manager is most likely configured so > as to ONLY accept messages for distribution to IH from extant list > members, therefore preventing any (errant/non-list registered email > address) submissions to internet-history at elists.isoc.org from being > "accepted" and processed. Are such errant / non-list posts rejected during the incoming SMTP transaction -or- are they bounced after the fact? > if the ordering were such that the Mailman Mailing List Manager > address validation took place before The Forbidden Words Filter > did it's thing, THEN a better (and more "correct") Forbidden Words > Filtering could take place after sender address validation. Maybe. Maybe not. It is highly dependent on what "sender address validation" means and how reliable it is. > then, if The Forbidden Words Filter detected A Forbidden Word, > it could then instigate a "reply" message to the already > authenticated/permitted/allowed "sender" notifying him/her to > the effect their message contained A Forbidden Word and was not > redistributed to the IH list. "authentication" of the purported sender address is a very sticky wicket in this context. Determining if the purported sending address is "permitted" or "allowed" to post to the list are a LOT easier to determine. I have LONG wanted a Mailman milter that would allow more of Mailman's functionality to be integrated during the SMTP transaction. 1) Is the purported sender (SMTP MAIL FROM:..) allowed to post to the mailing list in question (SMTP RCPT TO:...). 2) Apply various sanity checks after the message has been sent (after the closing <.> at the end of the SMTP DATA) to the mailing list or not. 3) REJECT the message /during/ the SMTP transaction /if/ Mailman's normal filters would reject the message. -- Grant. . . . unix || die From jack at 3kitty.org Tue Sep 15 11:49:36 2020 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 15 Sep 2020 11:49:36 -0700 Subject: [ih] History In-Reply-To: <887F5CC9-7B86-495C-98F6-B74EA563DAD8@lynch.com> References: <887F5CC9-7B86-495C-98F6-B74EA563DAD8@lynch.com> Message-ID: <4f30e858-fde3-c77a-968a-55a5dc7d5bcf@3kitty.org> Curiously enough, I *replied* to Karl's offensive message, which included that message in typical "what Karl said" form.??? So my message contained the offensive word in the copy of Karl's text. I received the message (because I bcc myself always for archiving).? Karl got it too, since he replied (his comment about seventeen minutes).? That reply did not contain the earlier offensive message, so perhaps it got through. But I guess no one else got my email? I guess we should have defined a "TCP" to run on top of SMTP, to make sure that all the "datagrams/emails" make it to the other end. /Jack On 9/15/20 11:32 AM, Dan Lynch via Internet-history wrote: > Karl, in all this flap about your accidental use of the hidden forbidden word in your superb description of the building of the net at various Interop events, did it ever make it to this list? Or could you insert the hyphen and resubmit it? You are an excellent narrator, sir. > > Thanks > > Dan > > Cell 650-776-7313 From gnu at toad.com Tue Sep 15 12:12:48 2020 From: gnu at toad.com (John Gilmore) Date: Tue, 15 Sep 2020 12:12:48 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> Message-ID: <15959.1600197168@hop.toad.com> Joseph Touch via Internet-history wrote: > PS - I would doubt the ISOC wants to make that list public. It only invites attackers to game it. > This is the same reason I never published the complete ruleset on other lists, e.g., to filter out non pre-approved conference announcements on E2E-interest. The first thing the censors suppress is something they don't like. The second thing they suppress is the list of things they are suppressing. After that, you never know what they are suppressing, unless you are one of the ones whose voice can't be heard. My mail server for toad.com is a multi-decade victim of anti-spam filters, and my experience is that they come with zero sense and zero accountability. The result of that is that the people who run them don't care about how much collateral damage (censored email that was completely legitimate) that they cause -- because they aren't accountable. This is exacerbated by mailers that arrive configured to use those unaccountable third-party anti-spam services to censor all the locally arriving email. That gives power to the third parties, which they feel free to abuse. In this case, ISOC had a few-weeks problem with somebody spamming about "hook-ups" and they caused a multi-year problem with censoring legitimate messages about connecting Ethernets on trade show floors. It's not spam that makes it more painful to run an email server than it was in the '90s. It's anti-spam. John From touch at strayalpha.com Tue Sep 15 12:13:44 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 12:13:44 -0700 Subject: [ih] History In-Reply-To: <887F5CC9-7B86-495C-98F6-B74EA563DAD8@lynch.com> References: <887F5CC9-7B86-495C-98F6-B74EA563DAD8@lynch.com> Message-ID: <1A0DC1B9-7C33-48EE-8EB2-DC868B803A58@strayalpha.com> I posted it on Sat. > On Sep 15, 2020, at 11:32 AM, Dan Lynch via Internet-history wrote: > > Karl, in all this flap about your accidental use of the hidden forbidden word in your superb description of the building of the net at various Interop events, did it ever make it to this list? Or could you insert the hyphen and resubmit it? You are an excellent narrator, sir. > > Thanks > > Dan > > Cell 650-776-7313 > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From touch at strayalpha.com Tue Sep 15 12:40:19 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 12:40:19 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: <15959.1600197168@hop.toad.com> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> Message-ID: > On Sep 15, 2020, at 12:12 PM, John Gilmore wrote: > > Joseph Touch via Internet-history > wrote: >> PS - I would doubt the ISOC wants to make that list public. It only invites attackers to game it. >> This is the same reason I never published the complete ruleset on other lists, e.g., to filter out non pre-approved conference announcements on E2E-interest. > > The first thing the censors suppress is something they don't like. > > The second thing they suppress is the list of things they are suppressing All anti-spam is inherently censorship, so yes, this is censorship, to be clear. And yes, some types of censorship hide what they filter on - specifically to prevent ?gaming? that mechanism. If this offends your civil liberties, note that this this list is not a government resource. The ISOC is censoring what they consider spam. If you don?t like that, you?re welcome to post elsewhere or provide a long-term stable, archival alternative venue where we can host the list. Joe From gtaylor at tnetconsulting.net Tue Sep 15 12:50:27 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 15 Sep 2020 13:50:27 -0600 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> Message-ID: <686d57a6-cfa7-d43b-f282-ea1c3b8bab78@spamtrap.tnetconsulting.net> On 9/15/20 1:40 PM, Joseph Touch via Internet-history wrote: > All anti-spam is inherently censorship, so yes, this is censorship, > to be clear. Not all {anit-spam,censorship} is {created,motivated,applied} equally. There is a big difference in an objective {anti-spam,censorship,filter} such as "the posting email address must be from a valid domain name which can be verified as having an email server via DNS lookup" and subjective {anti-spam,censorship,filter} "haterid for the color blue (as in blue screen of death has annoyed us that much)". > And yes, some types of censorship hide what they filter on - > specifically to prevent ?gaming? that mechanism. I understand not wanting to advertise what's filtered. But I do think that when asked, the powers that be should privately admit what happened to the effected parties. I also feel like the same mentality behind security of the key material vs security of the algorithm applies here. > The ISOC is censoring what they consider spam. Is there a process to ask the ISOC if they are still seeing a spate of spam (being rejected) by the filter(s) / key word(s) in question? Or if they would be willing to try removing it and re-addressing it if it becomes a problem again? Governments add new laws and remove old laws all the time. Things change. Sometimes the old is no longer needed. -- Grant. . . . unix || die From karl at cavebear.com Tue Sep 15 13:10:00 2020 From: karl at cavebear.com (Karl Auerbach) Date: Tue, 15 Sep 2020 13:10:00 -0700 Subject: [ih] History In-Reply-To: <887F5CC9-7B86-495C-98F6-B74EA563DAD8@lynch.com> References: <887F5CC9-7B86-495C-98F6-B74EA563DAD8@lynch.com> Message-ID: <4adc4b9a-167c-b341-df63-ce8aa2ce6d46@cavebear.com> Yes, it made it to the lists, but as an extension posted by Joe Touch on Sept 12. I could send it again - but my copy has "the bad word" so I'd have to edit it. ;-) The Interop saga is, to my thinking, quite important to the success of the Internet. The show was an important place for two main reasons: ?? - It was a gathering place where real tech folks could (and were required to) pound out flaws in specifications and implementations.? It replaced the old Bake Offs.? The early shows backed marketing with substance - there always were a large number of RFC authors in the background. ?? - It served as a Procrustean metronome-of-doom that forced vendors to actually produce working products by specific dates. There were lots of other reasons ranging from the fact that the show was a great place to learn a lot about how (at the time) large enterprise networks worked and failed to the fact that it was downright a lot of fun (at least to those of us who built and ran it.)? Those of in the core group got our hands on a prodigious amount of expensive gear from many vendors and we weren't shy about giving feedback, often negative, to the vendors. And some tiny reasons grew - I remember a lunch at the Monterey conference where you and Craig Partridge were bemoaning the lack of means to monitor and manage the growing Internet.? That became fuel that powered the development of the various network management protocols - HEMS, CMIP/CMOT, and SNMP that we used in later shows. The show was an early attractor of attacks.? I remember working with Carl Malamud to set up a bunch of NCD X terminals at one of the San Jose shows and being surprised when an remote attacker put up a username/password capture faux login screen.? Nothing surprising these days, but it was new back then. And there was a lot of room to play - That's why we did the first Internet toasters (eventually with a robot to insert/remove the bread), juke box, weather station, talking bear, etherphones, walkabout TV station, USB/iSCSI/Wi-Fi RAID-5, ... and who can ever forget "Fluffy, the inflatable sheep" (there's more to that description but it is a bit "too colorful".) That's not to mention all the small events, such as mbone shows and our impromptu rafting trips on the Youghiogheny river (that's where I met one of our now well known net security people by climbing through the window of her car) to some grand parties (including one three day long event at my house in Santa Cruz and nearby beaches.)? And of course there was that moment of fear and doubt when in Las Vegas we attached a remote location and saw traffic that wasn't ours - and we thought that we had accidentally tapped into one of the casino networks and we expected Guido from Baltimore to show up (turned out to be traffic from a show registration contractor.)?? (A bunch - probably 15+ - of us did get mugged in front of the White House in DC - I can't imagine what kind of stupid mugger would go after a bunch of geeks with Motorola radios squawking away and within sight of the Secret Service.) Some parts were unseen - like how we sometimes did our own version of TV station signoff - we all gathered in the NOC, sang the Star Spangled Banner, and turned off the power switches to the routers. Walking into a giant convention center, like the Atlanta Congress center, knowing that we had a couple of days to install a huge network with thousands upon thousands of nodes, spanning many huge spaces and meeting rooms, crossing railroads, crossing roads and freeways into hotels, and with multiple external providers - that was scary, but fun. And much of the hardest but invisible work was done during the weeks and moths prior to the show when we hot-staged everything, including the cable plant, in a warehouse.? We spent months planning everything from the physical layout to address deployment to DNS to complex redundant routing.? Then we built it. ? It was there were we did some of the more stressful things, like doing power failure testing.? Then we packed it up and shipped it to the convention center. We have a lot of photos.? I wish we had the raw beta tapes that Linda Feferman shot; only a tiny part of her material made it onto that video.? It would be nice if that raw material could go into the Internet Archive collection. ??? ??? --karl-- From touch at strayalpha.com Tue Sep 15 13:45:33 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 13:45:33 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: <686d57a6-cfa7-d43b-f282-ea1c3b8bab78@spamtrap.tnetconsulting.net> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> <686d57a6-cfa7-d43b-f282-ea1c3b8bab78@spamtrap.tnetconsulting.net> Message-ID: > On Sep 15, 2020, at 12:50 PM, Grant Taylor via Internet-history wrote: > > On 9/15/20 1:40 PM, Joseph Touch via Internet-history wrote: >> All anti-spam is inherently censorship, so yes, this is censorship, to be clear. > > Not all {anit-spam,censorship} is {created,motivated,applied} equally. > > There is a big difference in an objective {anti-spam,censorship,filter} such as "the posting email address must be from a valid domain name which can be verified as having an email server via DNS lookup" and subjective {anti-spam,censorship,filter} "haterid for the color blue (as in blue screen of death has annoyed us that much)". The ISOC, for whatever reasons it deems appropriate, uses what is typically a profanity filter that has also been updated to address particular threats, notably the one I mentioned. >> And yes, some types of censorship hide what they filter on - specifically to prevent ?gaming? that mechanism. > > I understand not wanting to advertise what's filtered. But I do think that when asked, the powers that be should privately admit what happened to the effected parties. They did. Again, we?re riding for free here. So yeah, we can ask. But we aren?t really in the position to demand or revolt on this. > I also feel like the same mentality behind security of the key material vs security of the algorithm applies here. In a sense, the filter rules are both the key and the algorithm. There?s no way to expose them without saying ?here?s how to get around them?. > >> The ISOC is censoring what they consider spam. > > Is there a process to ask the ISOC if they are still seeing a spate of spam (being rejected) by the filter(s) / key word(s) in question? Or if they would be willing to try removing it and re-addressing it if it becomes a problem again? I?ve already asked them to consider the collateral damage and consider adjusting their filter on this term. Again, until then, just avoid that word or re-spell as indicated. Joe From geoff at iconia.com Tue Sep 15 14:08:38 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Tue, 15 Sep 2020 11:08:38 -1000 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> Message-ID: vis-a-vis On Tue, Sep 15, 2020 at 9:40 AM Joseph Touch via Internet-history < internet-history at elists.isoc.org> wrote: > [...] > The ISOC is censoring what they consider spam. If you don?t like that, > you?re welcome to post elsewhere *or provide a long-term stable, archival > alternative venue where we can host the list.* Relocating IH list hosting and archive alternative venue to Google Groups? geoff -- Geoff.Goodfellow at iconia.com living as The Truth is True From brian.e.carpenter at gmail.com Tue Sep 15 14:09:54 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 16 Sep 2020 09:09:54 +1200 Subject: [ih] History In-Reply-To: <4f30e858-fde3-c77a-968a-55a5dc7d5bcf@3kitty.org> References: <887F5CC9-7B86-495C-98F6-B74EA563DAD8@lynch.com> <4f30e858-fde3-c77a-968a-55a5dc7d5bcf@3kitty.org> Message-ID: > I guess we should have defined a "TCP" to run on top of SMTP, to make > sure that all the "datagrams/emails" make it to the other end. It's called "encryption". Regards Brian Carpenter From dave.walden.family at gmail.com Tue Sep 15 14:14:11 2020 From: dave.walden.family at gmail.com (David Walden) Date: Tue, 15 Sep 2020 17:14:11 -0400 Subject: [ih] History Message-ID: I will risk mentioning the Annals of the History of Computing one more time. An article submitted to the Anecdotes department will have no traditional peer review, and one editor who will collaborate in making the article better without asking the author to write some different paper than the author wrote, and the accepted article will be published open access without an open access fee. If this interests someone, send your draft to me -- maybe after you have read https://annals-extras.org/anecdotes/writing/ On September 15, 2020, at 4:10 PM, Karl Auerbach via Internet-history wrote: >The Interop saga is, to my thinking, quite important to the success of >the Internet. From touch at strayalpha.com Tue Sep 15 14:26:45 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 14:26:45 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> Message-ID: > On Sep 15, 2020, at 2:08 PM, the keyboard of geoff goodfellow wrote: > > vis-a-vis > On Tue, Sep 15, 2020 at 9:40 AM Joseph Touch via Internet-history > wrote: > [...] > The ISOC is censoring what they consider spam. If you don?t like that, you?re welcome to post elsewhere or provide a long-term stable, archival alternative venue where we can host the list. > > Relocating IH list hosting and archive alternative venue to Google Groups? Google Groups free access limits group size to 100. We?re far too large for that, other potential concerns not withstanding. Joe From brian.e.carpenter at gmail.com Tue Sep 15 14:55:19 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 16 Sep 2020 09:55:19 +1200 Subject: [ih] Update on filtered list posts In-Reply-To: <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> Message-ID: <98b70b6a-7b80-85fc-6f0a-396bace78c23@gmail.com> On 16-Sep-20 06:29, Joseph Touch via Internet-history wrote: > > >> On Sep 15, 2020, at 10:05 AM, Grant Taylor via Internet-history wrote: >> >> On 9/15/20 10:05 AM, the keyboard of geoff goodfellow via Internet-history wrote: >>> is it possible to see what other words (minus profanity) the ISOC filter considers as ?inappropriate?? >> >> +1 for access to the list somewhere > > PS - I would doubt the ISOC wants to make that list public. It only invites attackers to game it. > > This is the same reason I never published the complete ruleset on other lists, e.g., to filter out non pre-approved conference announcements on E2E-interest. It's worth noting that doing the filtering *before* the mail is otherwise processed is certainly an intentional choice, to ensure that the rude words don't get into the list archive. I suspect that's common practice. (There have been instances where the IETF has resorted to manually cleaning dirt out of list archives, when something highly objectionable and off-topic got through. I don't know whether ISOC has had to do that in the past, but it wouldn't surprise me.) Brian From gtaylor at tnetconsulting.net Tue Sep 15 15:05:24 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 15 Sep 2020 16:05:24 -0600 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> Message-ID: On 9/15/20 3:08 PM, the keyboard of geoff goodfellow via Internet-history wrote: > Relocating IH list hosting and archive alternative venue to Google Groups? Google has shown that they can't be counted on for things, especially free things, to be around for a long time. The list of things that they've discontinued is longer than I can remember. -- Grant. . . . unix || die From jack at 3kitty.org Tue Sep 15 15:51:37 2020 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 15 Sep 2020 15:51:37 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> Message-ID: <9b3777ac-3cde-81b6-7e68-195840af427f@3kitty.org> Before going down the path to find an alternate route for these discussions to reach History, maybe Joe can describe what the ISOC's position is on this kind of content they host (or other stuff for that matter). E.g., will this list be archived "forever"??? Will the contents always be free for future people to search/access?? What will happen if/when the ISOC disappears, e.g. do they have some arrangement for the future with some other organization? My sense of deja vu reminds me of the early days (40+ years ago) when many mailing lists and archives were maintained on USC-ISIA on the ARPANET.? There were lots of great debates and discussions on forums like HEADER-PEOPLE, TCP-IP-WG, and many others that held a lot of History.? But when ISIA disappeared, the archives seem to have gone with it.? Like much other now-historical material - even the "important" messages I put into the Datacomputer for longevity. Unless there's some ancient boxes of tapes in Dan's basement... /Jack On 9/15/20 3:05 PM, Grant Taylor via Internet-history wrote: > On 9/15/20 3:08 PM, the keyboard of geoff goodfellow via > Internet-history wrote: >> Relocating IH list hosting and archive alternative venue to Google >> Groups? > > Google has shown that they can't be counted on for things, especially > free things, to be around for a long time.? The list of things that > they've discontinued is longer than I can remember. > > > > From touch at strayalpha.com Tue Sep 15 15:59:29 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 15:59:29 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: <9b3777ac-3cde-81b6-7e68-195840af427f@3kitty.org> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> <9b3777ac-3cde-81b6-7e68-195840af427f@3kitty.org> Message-ID: <5C342CFD-C673-4744-8B31-5394C4B55F5F@strayalpha.com> Hi, Jack, > On Sep 15, 2020, at 3:51 PM, Jack Haverty via Internet-history wrote: > > Before going down the path to find an alternate route for these > discussions to reach History, maybe Joe can describe what the ISOC's > position is on this kind of content they host (or other stuff for that > matter). > > E.g., will this list be archived "forever"? Will the contents always > be free for future people to search/access? To the extent we know today, yes, but nobody signed any sort of contract to that effect. I don?t even know what it would mean if they had. But I did ask when we moved to this site. > What will happen if/when > the ISOC disappears, e.g. do they have some arrangement for the future > with some other organization? That I have no idea, but that?s equivalent to asking the Computer History Museum the same question. Museums have come and gone too. Joe From ajs at crankycanuck.ca Tue Sep 15 16:00:03 2020 From: ajs at crankycanuck.ca (Andrew Sullivan) Date: Tue, 15 Sep 2020 19:00:03 -0400 Subject: [ih] Update on filtered list posts In-Reply-To: <15959.1600197168@hop.toad.com> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> Message-ID: <20200915230003.ytghrw45zbwurzi3@crankycanuck.ca> Hi, I'm the Internet Society's President and CEO, but I read this list at home and it's more convenient for me to reply this way, so that's what I'm doing. (That said, if you want to tell me a thing or two about this post and want me to see it quickly, you're better off to mail me at sullivan at isoc.org, because I don't get to read this list as often as I like.) On Tue, Sep 15, 2020 at 12:12:48PM -0700, John Gilmore via Internet-history wrote: >The first thing the censors suppress is something they don't like. > >The second thing they suppress is the list of things they are suppressing. > >After that, you never know what they are suppressing, unless you are one >of the ones whose voice can't be heard. I want to be clear on a few things. First, the Internet Society doesn't actually _operate_ this mailing list service. We contract it out, to the same people who operate the mailing lists for the IETF, because it turns out that running very large numbers of active mailing lists is something of a specialist skill. We're happy to provide this list a home, however, as part of our contract, because we believe the list is important and valuable for the Internet. Second, list server providers have to walk a difficult line, because on the one hand no list operator wants to maintain a big and troublesome hand-curated set of filters; but on the other hand no list operator can afford to obtain a reputation as being unwilling to cope with the sort of spam that can get through on mailing lists. Walking that line is a big part of the specialist skill we are paying for, and we're loathe to do a lot of second-guessing because in our experience (and that of the IETF) our vendor does a good job at this, with as light a hand as is practical. Third, there's a reason I mention "reputation" in the above. One of the reasons list operators need to be careful is because of the concentration in the mail market these days. If you are a mail sender and you get on the spammy-reputation list of just one or two of the largest providers, you are in for a long slog attempting to prove to people that you have addressed whatever problem they think you have. It is not news that the Final and Ultimate Solution to the Spam Problem has not actually been discovered, so filters are what we live with, and list providers have to live in that world. During the time that a list operator gets on someone's "spammy" list, the chances are higher that list traffic will go to a Junk mailbox, and that will trigger support tickets and so on that the provider needs to process. That costs them money. Finally, generating a bounce for the kind of problem that triggered the observed effect here would likely cause the reputational problem just mentioned, because backscatter remains an issue. I think it would be exceptionally hard to find a list operator that didn't have in place at least _some_ defences, which may indeed be evaluated as "censorship" under one view of the term. If you find one that is not, I might encourage an investigation of their success rate in getting mail to land in people's INBOX, and also some contemplation of how useful it would be to have a list that routinely ends up in the Junk mailbox in most accounts at gmail and o365 and so on. Nevertheless, obviously, if the community actually wanted to move the list again, please rest assured that we stand by ready to help in whatever way the community wishes us to. Best regards, A -- Andrew Sullivan ajs at crankycanuck.ca From dan at lynch.com Tue Sep 15 16:03:36 2020 From: dan at lynch.com (Dan Lynch) Date: Tue, 15 Sep 2020 16:03:36 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: <9b3777ac-3cde-81b6-7e68-195840af427f@3kitty.org> References: <9b3777ac-3cde-81b6-7e68-195840af427f@3kitty.org> Message-ID: Those tapes existed for a while, but I?m sure those 7 track tapes are long gone. As a check on whether they really were in existence when I took over the management at ISI in 1980 I put in a request to retrieve all the old email for Bob Kahn, who was the head of IPTO then and my real boss. It took a week or so but it happened and I asked Bob to peruse them to see if they were ok. Passed! But I?m sure all those tapes are in landfill somewhere. They were not classified, so no protection there. I know Vint has expressed worry/interest in this issue of digital archives. Dan Cell 650-776-7313 > On Sep 15, 2020, at 3:52 PM, Jack Haverty via Internet-history wrote: > > ?Before going down the path to find an alternate route for these > discussions to reach History, maybe Joe can describe what the ISOC's > position is on this kind of content they host (or other stuff for that > matter). > > E.g., will this list be archived "forever"? Will the contents always > be free for future people to search/access? What will happen if/when > the ISOC disappears, e.g. do they have some arrangement for the future > with some other organization? > > My sense of deja vu reminds me of the early days (40+ years ago) when > many mailing lists and archives were maintained on USC-ISIA on the > ARPANET. There were lots of great debates and discussions on forums > like HEADER-PEOPLE, TCP-IP-WG, and many others that held a lot of History. > > But when ISIA disappeared, the archives seem to have gone with it. Like > much other now-historical material - even the "important" messages I put > into the Datacomputer for longevity. > > Unless there's some ancient boxes of tapes in Dan's basement... > > /Jack > > >> On 9/15/20 3:05 PM, Grant Taylor via Internet-history wrote: >>> On 9/15/20 3:08 PM, the keyboard of geoff goodfellow via >>> Internet-history wrote: >>> Relocating IH list hosting and archive alternative venue to Google >>> Groups? >> >> Google has shown that they can't be counted on for things, especially >> free things, to be around for a long time. The list of things that >> they've discontinued is longer than I can remember. >> >> >> >> > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From dhc at dcrocker.net Tue Sep 15 16:05:00 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Tue, 15 Sep 2020 16:05:00 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: <20200915230003.ytghrw45zbwurzi3@crankycanuck.ca> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> <20200915230003.ytghrw45zbwurzi3@crankycanuck.ca> Message-ID: <9ff781cb-01ff-ac3a-c3d7-010f3691ecd7@dcrocker.net> On 9/15/2020 4:00 PM, Andrew Sullivan via Internet-history wrote: > We contract it out, to the same people who operate the mailing lists > for the IETF Who is the operator? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs at crankycanuck.ca Tue Sep 15 16:14:27 2020 From: ajs at crankycanuck.ca (Andrew Sullivan) Date: Tue, 15 Sep 2020 19:14:27 -0400 Subject: [ih] Update on filtered list posts In-Reply-To: <9b3777ac-3cde-81b6-7e68-195840af427f@3kitty.org> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> <9b3777ac-3cde-81b6-7e68-195840af427f@3kitty.org> Message-ID: <20200915231427.a3tp246v5r7qij66@crankycanuck.ca> Hi, Same disclaimer as before. On Tue, Sep 15, 2020 at 03:51:37PM -0700, Jack Haverty via Internet-history wrote: >discussions to reach History, maybe Joe can describe what the ISOC's >position is on this kind of content they host (or other stuff for that >matter). > >E.g., will this list be archived "forever"??? Will the contents always >be free for future people to search/access?? What will happen if/when >the ISOC disappears, e.g. do they have some arrangement for the future >with some other organization? The Internet Society is a 501(c)(3) based in the US with charitable purposes[1] that include educating the academic and scientific communities about the Internet (you can see the formal verbiage at https://www.internetsociety.org/wp-content/uploads/2017/06/Form_1023_IRS.pdf). The Internet Society's Board of Trustees is currently appointed by ISOC Chapters, the Internet Engineering Task Force (via the IAB), and ISOC Organizational Members. So, while I cannot promise that the Internet Society will never disappear, be turned into a stone, be taken over by evil and incompetent management [2], or other such things, I think ISOC has a pretty serious commitment to maintaining a home for the list and its archives. We work hard, for instance, not to lose any material on our own web site or break any URLs (although from time to time things happen when, um, an unfortunate past technology choice is discovered). Certainly, as long as I have anything to say about it, the list and archive will be supported and kept available. As I noted in my other post, the list service itself is operated by the same people as the IETF lists, with a similar standard of care, so we can be confident that hardware failures or the like won't magically make things disappear into thin air. I don't know whether that's adequate to answer your question, but it's what I can provide. Best regards, A [1] Obligatory pitch: anyone can be a member, and you are welcome to donate to us too! [2] Yes, yes, I know what someone is going to say ;-) -- Andrew Sullivan ajs at crankycanuck.ca From dan at lynch.com Tue Sep 15 16:15:14 2020 From: dan at lynch.com (Dan Lynch) Date: Tue, 15 Sep 2020 16:15:14 -0700 Subject: [ih] History In-Reply-To: <7BD22274-26A0-43FA-BD24-D57E91765243@strayalpha.com> References: <7BD22274-26A0-43FA-BD24-D57E91765243@strayalpha.com> Message-ID: <3452081E-929B-400B-973E-30C7B8AA5C5E@lynch.com> Testing again where the replies go. Dan Cell 650-776-7313 > On Sep 15, 2020, at 3:06 PM, Joe Touch wrote: > > ? > The link I just sent. > >>> On Sep 15, 2020, at 2:59 PM, Dan Lynch wrote: >>> >> ?Interesting. I did not get a copy in the list. >> >> And how do I look at the archive? >> >> Thanks >> >> Dan >> >> Cell 650-776-7313 >> >>>> On Sep 15, 2020, at 1:47 PM, Joseph Touch wrote: >>>> >>> ?It appears to be posted here: >>> https://elists.isoc.org/pipermail/internet-history/2020-September/006583.html >>> >>> Are you not getting the copy of the post? Or do you not see it in the archive? >>> >>> Joe >>> >>>> On Sep 15, 2020, at 1:31 PM, Dan Lynch wrote: >>>> >>>> It looks like this did not make it to the list. I don?t see the bad word in it. >>>> >>>> Dan >>>> >>>> Cell 650-776-7313 >>>> >>>> Begin forwarded message: >>>> >>>>> From: Karl Auerbach >>>>> Date: September 15, 2020 at 1:10:04 PM PDT >>>>> To: Dan Lynch , Internet-history >>>>> Subject: Re: History >>>>> Reply-To: karl at cavebear.com >>>>> >>>>> ?Yes, it made it to the lists, but as an extension posted by Joe Touch on Sept 12. >>>>> >>>>> I could send it again - but my copy has "the bad word" so I'd have to edit it. ;-) >>>>> >>>>> The Interop saga is, to my thinking, quite important to the success of the Internet. >>>>> >>>>> The show was an important place for two main reasons: >>>>> >>>>> - It was a gathering place where real tech folks could (and were required to) pound out flaws in specifications and implementations. It replaced the old Bake Offs. The early shows backed marketing with substance - there always were a large number of RFC authors in the background. >>>>> >>>>> - It served as a Procrustean metronome-of-doom that forced vendors to actually produce working products by specific dates. >>>>> >>>>> There were lots of other reasons ranging from the fact that the show was a great place to learn a lot about how (at the time) large enterprise networks worked and failed to the fact that it was downright a lot of fun (at least to those of us who built and ran it.) Those of in the core group got our hands on a prodigious amount of expensive gear from many vendors and we weren't shy about giving feedback, often negative, to the vendors. >>>>> >>>>> And some tiny reasons grew - I remember a lunch at the Monterey conference where you and Craig Partridge were bemoaning the lack of means to monitor and manage the growing Internet. That became fuel that powered the development of the various network management protocols - HEMS, CMIP/CMOT, and SNMP that we used in later shows. >>>>> >>>>> The show was an early attractor of attacks. I remember working with Carl Malamud to set up a bunch of NCD X terminals at one of the San Jose shows and being surprised when an remote attacker put up a username/password capture faux login screen. Nothing surprising these days, but it was new back then. >>>>> >>>>> And there was a lot of room to play - That's why we did the first Internet toasters (eventually with a robot to insert/remove the bread), juke box, weather station, talking bear, etherphones, walkabout TV station, USB/iSCSI/Wi-Fi RAID-5, ... and who can ever forget "Fluffy, the inflatable sheep" (there's more to that description but it is a bit "too colorful".) >>>>> >>>>> That's not to mention all the small events, such as mbone shows and our impromptu rafting trips on the Youghiogheny river (that's where I met one of our now well known net security people by climbing through the window of her car) to some grand parties (including one three day long event at my house in Santa Cruz and nearby beaches.) And of course there was that moment of fear and doubt when in Las Vegas we attached a remote location and saw traffic that wasn't ours - and we thought that we had accidentally tapped into one of the casino networks and we expected Guido from Baltimore to show up (turned out to be traffic from a show registration contractor.) (A bunch - probably 15+ - of us did get mugged in front of the White House in DC - I can't imagine what kind of stupid mugger would go after a bunch of geeks with Motorola radios squawking away and within sight of the Secret Service.) >>>>> >>>>> Some parts were unseen - like how we sometimes did our own version of TV station signoff - we all gathered in the NOC, sang the Star Spangled Banner, and turned off the power switches to the routers. >>>>> >>>>> Walking into a giant convention center, like the Atlanta Congress center, knowing that we had a couple of days to install a huge network with thousands upon thousands of nodes, spanning many huge spaces and meeting rooms, crossing railroads, crossing roads and freeways into hotels, and with multiple external providers - that was scary, but fun. >>>>> >>>>> And much of the hardest but invisible work was done during the weeks and moths prior to the show when we hot-staged everything, including the cable plant, in a warehouse. We spent months planning everything from the physical layout to address deployment to DNS to complex redundant routing. Then we built it. It was there were we did some of the more stressful things, like doing power failure testing. Then we packed it up and shipped it to the convention center. >>>>> >>>>> We have a lot of photos. I wish we had the raw beta tapes that Linda Feferman shot; only a tiny part of her material made it onto that video. It would be nice if that raw material could go into the Internet Archive collection. >>>>> >>>>> --karl-- >>>>> >>>>> >>> From touch at strayalpha.com Tue Sep 15 16:15:55 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 16:15:55 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: <20200915230003.ytghrw45zbwurzi3@crankycanuck.ca> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> <20200915230003.ytghrw45zbwurzi3@crankycanuck.ca> Message-ID: <46D1960F-CB88-438D-92BF-5EBF72CEB1D7@strayalpha.com> Hi all (and esp. Andrew), First, I want to again thank the Andrew and his support for ISOC hosting this list. They don?t have do, and I at least sincerely appreciate their support. Second, I want to remind everyone on this list, in case it isn?t clear, that I created this list as a community service. It was not created as an exercise in group list design or management. It?s offered as-is. If it isn?t wanted or preferred, you?re always welcome to post elsewhere. And finally,I will note that it took me several years and a nontrivial amount of effort and investigation to find a new location that, IMO, is a reasonable home for a list of this nature that I hope will be available long into the future. That process was motivated by a real need due to the lack of reliable Internet services at ISI (ironic, perhaps from the outside). IMHO, the silent failure of a few posts due to legitimate spam filtering with an arguably over-zealous single pattern does not rise to the level of warranting a repeat of that effort. I invite you all to go back to your regularly scheduled debates on actual Internet history now. If you feel you have spare time and want to comment further, I would encourage you to consider focusing your energy on writing a thank you note to Andrew instead. Joe (as list admin) From steffen at sdaoden.eu Tue Sep 15 16:28:25 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 16 Sep 2020 01:28:25 +0200 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> Message-ID: <20200915232825.iai4j%steffen@sdaoden.eu> the keyboard of geoff goodfellow wrote in : |vis-a-vis |On Tue, Sep 15, 2020 at 9:40 AM Joseph Touch via Internet-history < |internet-history at elists.isoc.org> wrote: | |> [...] |> The ISOC is censoring what they consider spam. If you don?t like that, |> you?re welcome to post elsewhere *or provide a long-term stable, archival |> alternative venue where we can host the list.* | |Relocating IH list hosting and archive alternative venue to Google Groups? Even though it now is a purely hobby thing again, mail-archive.com has a two+ decade long service track, and Jeff Breidenbach was super helpful, took MBOX data and joined together two mailing lists without any complaint, and that while maintaining a service which tracks 3101 active lists! Shall i ever win in a lottery he is one of those who deserve a cheque, and if it is only to be passed along somewhere else. They are no hoster, however. --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 dan at lynch.com Tue Sep 15 16:31:21 2020 From: dan at lynch.com (Dan Lynch) Date: Tue, 15 Sep 2020 16:31:21 -0700 Subject: [ih] History In-Reply-To: <3452081E-929B-400B-973E-30C7B8AA5C5E@lynch.com> References: <3452081E-929B-400B-973E-30C7B8AA5C5E@lynch.com> Message-ID: Testing one more time. Sorry. Dan Cell 650-776-7313 > On Sep 15, 2020, at 4:15 PM, Dan Lynch wrote: > > ?Testing again where the replies go. > > Dan > > Cell 650-776-7313 > >>> On Sep 15, 2020, at 3:06 PM, Joe Touch wrote: >>> >> ? >> The link I just sent. >> >>>> On Sep 15, 2020, at 2:59 PM, Dan Lynch wrote: >>>> >>> ?Interesting. I did not get a copy in the list. >>> >>> And how do I look at the archive? >>> >>> Thanks >>> >>> Dan >>> >>> Cell 650-776-7313 >>> >>>>> On Sep 15, 2020, at 1:47 PM, Joseph Touch wrote: >>>>> >>>> ?It appears to be posted here: >>>> https://elists.isoc.org/pipermail/internet-history/2020-September/006583.html >>>> >>>> Are you not getting the copy of the post? Or do you not see it in the archive? >>>> >>>> Joe >>>> >>>>> On Sep 15, 2020, at 1:31 PM, Dan Lynch wrote: >>>>> >>>>> It looks like this did not make it to the list. I don?t see the bad word in it. >>>>> >>>>> Dan >>>>> >>>>> Cell 650-776-7313 >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Karl Auerbach >>>>>> Date: September 15, 2020 at 1:10:04 PM PDT >>>>>> To: Dan Lynch , Internet-history >>>>>> Subject: Re: History >>>>>> Reply-To: karl at cavebear.com >>>>>> >>>>>> ?Yes, it made it to the lists, but as an extension posted by Joe Touch on Sept 12. >>>>>> >>>>>> I could send it again - but my copy has "the bad word" so I'd have to edit it. ;-) >>>>>> >>>>>> The Interop saga is, to my thinking, quite important to the success of the Internet. >>>>>> >>>>>> The show was an important place for two main reasons: >>>>>> >>>>>> - It was a gathering place where real tech folks could (and were required to) pound out flaws in specifications and implementations. It replaced the old Bake Offs. The early shows backed marketing with substance - there always were a large number of RFC authors in the background. >>>>>> >>>>>> - It served as a Procrustean metronome-of-doom that forced vendors to actually produce working products by specific dates. >>>>>> >>>>>> There were lots of other reasons ranging from the fact that the show was a great place to learn a lot about how (at the time) large enterprise networks worked and failed to the fact that it was downright a lot of fun (at least to those of us who built and ran it.) Those of in the core group got our hands on a prodigious amount of expensive gear from many vendors and we weren't shy about giving feedback, often negative, to the vendors. >>>>>> >>>>>> And some tiny reasons grew - I remember a lunch at the Monterey conference where you and Craig Partridge were bemoaning the lack of means to monitor and manage the growing Internet. That became fuel that powered the development of the various network management protocols - HEMS, CMIP/CMOT, and SNMP that we used in later shows. >>>>>> >>>>>> The show was an early attractor of attacks. I remember working with Carl Malamud to set up a bunch of NCD X terminals at one of the San Jose shows and being surprised when an remote attacker put up a username/password capture faux login screen. Nothing surprising these days, but it was new back then. >>>>>> >>>>>> And there was a lot of room to play - That's why we did the first Internet toasters (eventually with a robot to insert/remove the bread), juke box, weather station, talking bear, etherphones, walkabout TV station, USB/iSCSI/Wi-Fi RAID-5, ... and who can ever forget "Fluffy, the inflatable sheep" (there's more to that description but it is a bit "too colorful".) >>>>>> >>>>>> That's not to mention all the small events, such as mbone shows and our impromptu rafting trips on the Youghiogheny river (that's where I met one of our now well known net security people by climbing through the window of her car) to some grand parties (including one three day long event at my house in Santa Cruz and nearby beaches.) And of course there was that moment of fear and doubt when in Las Vegas we attached a remote location and saw traffic that wasn't ours - and we thought that we had accidentally tapped into one of the casino networks and we expected Guido from Baltimore to show up (turned out to be traffic from a show registration contractor.) (A bunch - probably 15+ - of us did get mugged in front of the White House in DC - I can't imagine what kind of stupid mugger would go after a bunch of geeks with Motorola radios squawking away and within sight of the Secret Service.) >>>>>> >>>>>> Some parts were unseen - like how we sometimes did our own version of TV station signoff - we all gathered in the NOC, sang the Star Spangled Banner, and turned off the power switches to the routers. >>>>>> >>>>>> Walking into a giant convention center, like the Atlanta Congress center, knowing that we had a couple of days to install a huge network with thousands upon thousands of nodes, spanning many huge spaces and meeting rooms, crossing railroads, crossing roads and freeways into hotels, and with multiple external providers - that was scary, but fun. >>>>>> >>>>>> And much of the hardest but invisible work was done during the weeks and moths prior to the show when we hot-staged everything, including the cable plant, in a warehouse. We spent months planning everything from the physical layout to address deployment to DNS to complex redundant routing. Then we built it. It was there were we did some of the more stressful things, like doing power failure testing. Then we packed it up and shipped it to the convention center. >>>>>> >>>>>> We have a lot of photos. I wish we had the raw beta tapes that Linda Feferman shot; only a tiny part of her material made it onto that video. It would be nice if that raw material could go into the Internet Archive collection. >>>>>> >>>>>> --karl-- >>>>>> >>>>>> >>>> From johnl at iecc.com Tue Sep 15 16:35:08 2020 From: johnl at iecc.com (John Levine) Date: 15 Sep 2020 19:35:08 -0400 Subject: [ih] Running mailing lists is hard In-Reply-To: Message-ID: <20200915233509.05DC920DF29E@ary.qy> In article you write: >yours truly posits that the ISOC mail list PTB's have inserted >an ?inappropriate? filter ... I run a lot of mailing lists on my own server, and I find this comment just laughable. On today's Internet, 95% (yes, really) of mail is spam, spammers attack every possible aspect of the mail system, and ISOC's contractor does as good a job as any provider I know. Just keeping the mail going at any sort of scale, particularly into the large providers who are the target of a disproportinate amount of the spam, is a challenge. I agree that blocking hook-up is silly, but having seen some of the stuff that people try to send to other ISOC lists, I'm not very surprised they use it as a filter key. On the other hand, if you're offering to host this list, manage the delivery challenges, and arrange for long term archival storage and pay for it, I'm sure we'd all be interested. R's, John From geoff at iconia.com Tue Sep 15 20:57:16 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Tue, 15 Sep 2020 17:57:16 -1000 Subject: [ih] Update on filtered list posts In-Reply-To: <20200915232825.iai4j%steffen@sdaoden.eu> References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> <20200915232825.iai4j%steffen@sdaoden.eu> Message-ID: another point in favor of/for moving the IH to another Mailing List Service Hosting Facility AS WELL AS Archive: the current "facilities" inability (or unwillingness?) for the IH hosting distribution apparatus and archive to be enabled for Image Inclusion (like RFC do now? what would happen if you sent to a Modern Day Formatted RFC to IH...? :D) as a result: "the list is currently limited to text without attachments of any kind" as stated "due to space limitations" and, as such, "the list is not intended as an archive for such material." ... In This Modern Day And Age given the extant "Richness of Expression" used in media presently... not to mention "The Cost" of Modern Day disk storage??? geoff On Tue, Sep 15, 2020 at 1:37 PM Steffen Nurpmeso wrote: > the keyboard of geoff goodfellow wrote in > : > |vis-a-vis > |On Tue, Sep 15, 2020 at 9:40 AM Joseph Touch via Internet-history < > |internet-history at elists.isoc.org> wrote: > | > |> [...] > |> The ISOC is censoring what they consider spam. If you don?t like that, > |> you?re welcome to post elsewhere *or provide a long-term stable, > archival > |> alternative venue where we can host the list.* > | > |Relocating IH list hosting and archive alternative venue to Google > Groups? > > Even though it now is a purely hobby thing again, mail-archive.com > has a two+ decade long service track, and Jeff Breidenbach was > super helpful, took MBOX data and joined together two mailing > lists without any complaint, and that while maintaining a service > which tracks 3101 active lists! Shall i ever win in a lottery he > is one of those who deserve a cheque, and if it is only to be > passed along somewhere else. > They are no hoster, however. > > --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) > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From touch at strayalpha.com Tue Sep 15 21:35:17 2020 From: touch at strayalpha.com (Joseph Touch) Date: Tue, 15 Sep 2020 21:35:17 -0700 Subject: [ih] Update on filtered list posts In-Reply-To: References: <008368E2-3D39-474D-8173-1B4FFEAB7DC6@strayalpha.com> <9c3c943b-d70e-8300-cc67-e58ff6f17af9@spamtrap.tnetconsulting.net> <742CC862-30EF-4A1E-9505-2D1308A4CF32@strayalpha.com> <15959.1600197168@hop.toad.com> <20200915232825.iai4j%steffen@sdaoden.eu> Message-ID: <0CC0F028-505A-4F4E-8213-79470713E2A5@strayalpha.com> > On Sep 15, 2020, at 8:57 PM, the keyboard of geoff goodfellow via Internet-history wrote: > > another point in favor of/for moving the IH to another Mailing List Service > Hosting Facility AS WELL AS Archive: > > the current "facilities" inability (or unwillingness?) for the IH hosting > distribution apparatus and archive to be enabled for Image Inclusion ? That is my choice, not their limitation. It is based on the issue of archive size, the need for potential portability, and the fact that this is a discussion medium - it is not intended to serve as an archive for other historical material. Again, if this isn?t what you want, you?re welcome to post elsewhere. Joe From dave.walden.family at gmail.com Fri Sep 25 08:14:59 2020 From: dave.walden.family at gmail.com (David Walden) Date: Fri, 25 Sep 2020 11:14:59 -0400 Subject: [ih] Publishing our computing memorues Message-ID: Hi, A various times I have encouraged members of this internet history list to publish their stories of computing history in the IEEE Annals of the History of Computing. I still recommend this as this is a place future historian are likely to look for information. Another place you can record your memories is ethw.org which is likely to survive longer than this list or your personal website. See, for instance, https://ethw.org/Archives:BBN_computing_history:_A_Culture_of_Innovation which I created this morning. Since ethw.org is a wiki, collaboration in developing a record of a piece of history is possible. (Computing historians themselves discuss things at sigcis.org) For my general discussion of the importance of we computing practitioners collecting and recording computing history, see https://walden-family.com/texland/tb128walden-noticing.pdf I welcome suggestions for improvement of the argument. Dave From vgcerf at gmail.com Sun Sep 27 13:02:41 2020 From: vgcerf at gmail.com (vinton cerf) Date: Sun, 27 Sep 2020 16:02:41 -0400 Subject: [ih] FTP RIP Message-ID: https://tedium.co/2020/09/25/ftp-internet-history/ v From johnl at iecc.com Sun Sep 27 13:22:57 2020 From: johnl at iecc.com (John Levine) Date: 27 Sep 2020 16:22:57 -0400 Subject: [ih] FTP RIP In-Reply-To: Message-ID: <20200927202258.DC75221E4DF2@ary.qy> In article you write: >https://tedium.co/2020/09/25/ftp-internet-history/ It's an OK article, but what's a picture of a Model 32 Teletype doing there? R's, John From dhc at dcrocker.net Sun Sep 27 14:14:53 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Sun, 27 Sep 2020 14:14:53 -0700 Subject: [ih] FTP RIP In-Reply-To: <20200927202258.DC75221E4DF2@ary.qy> References: <20200927202258.DC75221E4DF2@ary.qy> Message-ID: On 9/27/2020 1:22 PM, John Levine via Internet-history wrote: > It's an OK article By measures of meaningful deployment, "so old it predates email" is incorrect. And "at the beginning, actually played the role of an email client" is incorrect. And "for four years, FTP was technically email of sorts." was wrong on two counts.? First, it was for 10 -- arguably more -- years.? Second the "of sorts" is wrong. And while Abhay was the editor, it was a committee effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jeanjour at comcast.net Sun Sep 27 14:56:38 2020 From: jeanjour at comcast.net (John Day) Date: Sun, 27 Sep 2020 17:56:38 -0400 Subject: [ih] FTP RIP In-Reply-To: References: <20200927202258.DC75221E4DF2@ary.qy> Message-ID: <1029E379-8B52-4FC2-A497-0A18E144C4C9@comcast.net> And the impetus for one of the great Padlipskyisms! When the discussion in an FTP meeting turned to the BYTE command. (The BYTE command essentially set the ?word size? for the file.) Someone asked a question along the lines of ?So what happens if I STORe a file with a BYTE size of 23 and RETRieve it with a BYTE size of 17. Padlipsky sitting in the far corner of the room, piped up, ?Sometimes when changing apples into oranges, you get lemons!? Everyone agreed that was the right answer. ;-) John > On Sep 27, 2020, at 17:14, Dave Crocker via Internet-history wrote: > > On 9/27/2020 1:22 PM, John Levine via Internet-history wrote: >> It's an OK article > > > By measures of meaningful deployment, "so old it predates email" is incorrect. > > And "at the beginning, actually played the role of an email client" is incorrect. > > And "for four years, FTP was technically email of sorts." was wrong on two counts. First, it was for 10 -- arguably more -- years. Second the "of sorts" is wrong. > > And while Abhay was the editor, it was a committee effort. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From sob at sobco.com Sun Sep 27 15:18:23 2020 From: sob at sobco.com (Scott O. Bradner) Date: Sun, 27 Sep 2020 18:18:23 -0400 Subject: [ih] FTP RIP In-Reply-To: References: Message-ID: fwiw - SFTP seems to be alive and well - it is the primary way that Harvard exchanges information with some of its vendors Scott > On Sep 27, 2020, at 4:02 PM, vinton cerf via Internet-history wrote: > > https://tedium.co/2020/09/25/ftp-internet-history/ > > v > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From touch at strayalpha.com Sun Sep 27 18:29:28 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sun, 27 Sep 2020 18:29:28 -0700 Subject: [ih] FTP RIP In-Reply-To: References: Message-ID: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> This thread begs the question of where we?d be had TBL had tried to leverage FTP rather than reinventing the wheel with HTTP. I recall an early interview that claimed the rationale was that FTP opened two connections for every transfer and he only wanted one. It?s been unfortunate how many of FTP?s features had to be (or still remain to be) reinvented in HTTP. Joe From gtaylor at tnetconsulting.net Sun Sep 27 18:54:16 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 27 Sep 2020 19:54:16 -0600 Subject: [ih] FTP RIP In-Reply-To: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> Message-ID: On 9/27/20 7:29 PM, Joseph Touch via Internet-history wrote: > This thread begs the question of where we?d be had TBL had tried > to leverage FTP rather than reinventing the wheel with HTTP. I feel like I've dabbled with this in the past. E.g. retrieved an HTML page via FTP and used ftp:// links in the src parameters for elements. I want to say I did similar with Gopher. Or rather, I created a local file that used a gopher:// link for the source of an image that I knew was on a Gopher server. I seem to recall it working surprisingly well. Though it wasn't practical. > I recall an early interview that claimed the rationale was that > FTP opened two connections for every transfer and he only wanted > one. I don't know that that's /completely/ accurate per say. Yes, there are two connections; control and data. But I believe the control connection can be re-used for multiple subsequent data connections. Firewalling and NATing are two of FTP's Achilles Heals. Specifically FTPS. Aside SFTP (SSH) is significantly different than FTPS (FTP over SSL / TLS). > It?s been unfortunate how many of FTP?s features had to be (or > still remain to be) reinvented in HTTP. I learned in the last few years that it's possible to establish FTP connections with two servers and instruct them to exchange data directly between themselves without traversing the common client. Or at least the protocol supports it. I'm not aware of it being a common implementation, much less execution. -- I do think that FTPS may hinder this somewhat. -- Grant. . . . unix || die From jeanjour at comcast.net Sun Sep 27 19:22:15 2020 From: jeanjour at comcast.net (John Day) Date: Sun, 27 Sep 2020 22:22:15 -0400 Subject: [ih] FTP RIP In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> Message-ID: See below. > On Sep 27, 2020, at 21:54, Grant Taylor via Internet-history wrote: > > On 9/27/20 7:29 PM, Joseph Touch via Internet-history wrote: >> This thread begs the question of where we?d be had TBL had tried to leverage FTP rather than reinventing the wheel with HTTP. > > I feel like I've dabbled with this in the past. E.g. retrieved an HTML page via FTP and used ftp:// links in the src parameters for elements. > > I want to say I did similar with Gopher. Or rather, I created a local file that used a gopher:// link for the source of an image that I knew was on a Gopher server. > > I seem to recall it working surprisingly well. Though it wasn't practical. > >> I recall an early interview that claimed the rationale was that FTP opened two connections for every transfer and he only wanted one. > > I don't know that that's /completely/ accurate per say. Yes, there are two connections; control and data. But I believe the control connection can be re-used for multiple subsequent data connections. The control connection was a Telnet connection and assumed to be ASCII. The purpose was so that commands did not get blocked behind data. Also, for TIPS, the user FTP process was you. You typed the commands. The data connection was normally a fixed offset from the Telnet connection. (NCP sockets were simplex, so there was one for each direction.) The data connection was not ASCII. The data connection was assumed to be binary. The only time the Control connection was used for data transfer was for the MAIL command as opposed to the MLFL command that used the data connection. For the TIPs, devices like a printer or card reader could be ?hardwired? to a given socket. The SOCKet command was used to not use the default data connections. > > Firewalling and NATing are two of FTP's Achilles Heals. Specifically FTPS. Isn?t that a bit backwards? Since FTP was done decades before either one. > > Aside SFTP (SSH) is significantly different than FTPS (FTP over SSL / TLS). Unlike HTTP, FTP required a login. FTP is, in a sense, the first application protocol. (Telnet and NCP were ?in the OS.? Telnet was a terminal device driver protocol.) > >> It?s been unfortunate how many of FTP?s features had to be (or still remain to be) reinvented in HTTP. > > I learned in the last few years that it's possible to establish FTP connections with two servers and instruct them to exchange data directly between themselves without traversing the common client. Or at least the protocol supports it. I'm not aware of it being a common implementation, much less execution. -- I do think that FTPS may hinder this somewhat. That has been there since at least 1973. There are no special commands and nothing special for doing that. It is just using the existing commands to do it. Take care, John > > > > -- > Grant. . . . > unix || die > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From touch at strayalpha.com Sun Sep 27 19:31:50 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sun, 27 Sep 2020 19:31:50 -0700 Subject: [ih] FTP RIP In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> Message-ID: <48E9838D-ADFD-463B-9CFC-E66A690CDBDE@strayalpha.com> > On Sep 27, 2020, at 6:54 PM, Grant Taylor via Internet-history wrote: > > On 9/27/20 7:29 PM, Joseph Touch via Internet-history wrote: >> This thread begs the question of where we?d be had TBL had tried to leverage FTP rather than reinventing the wheel with HTTP. > > I feel like I've dabbled with this in the past. E.g. retrieved an HTML page via FTP and used ftp:// links in the src parameters for elements. > > I want to say I did similar with Gopher. Or rather, I created a local file that used a gopher:// link for the source of an image that I knew was on a Gopher server. > > I seem to recall it working surprisingly well. Though it wasn't practical. For many years, FTP was always the metric of ?how is my link speed?, where HTTP always lagged. The application side of FTP was much more mature (it might still be). > >> I recall an early interview that claimed the rationale was that FTP opened two connections for every transfer and he only wanted one. > > I don't know that that's /completely/ accurate per say. Yes, there are two connections; control and data. But I believe the control connection can be re-used for multiple subsequent data connections. Yes, that?s true for FTP, for subsequent transfers to the same site. I was relaying what I recalled, which included the rationale that ?since we?re only getting one file from a site, two connections result in too much delay?. The irony is indeed that HTTP rather quickly devolved into grabbing dozens of files from a single site (all the images, formats, etc.) and continues to suffer from multiplexing both control and multiple connections with different behaviors over a single channel. > Firewalling and NATing are two of FTP's Achilles Heals. Specifically FTPS. Passive mode addresses both. > Aside SFTP (SSH) is significantly different than FTPS (FTP over SSL / TLS). Yes, FTP might have evolved differently... >> It?s been unfortunate how many of FTP?s features had to be (or still remain to be) reinvented in HTTP. > > I learned in the last few years that it's possible to establish FTP connections with two servers and instruct them to exchange data directly between themselves without traversing the common client. Or at least the protocol supports it. I'm not aware of it being a common implementation, much less execution. -- I do think that FTPS may hinder this somewhat. Yes - see https://en.wikipedia.org/wiki/File_eXchange_Protocol That?s in RFC 959. And FTP included resume since 1972 at least as well. Joe From dhc at dcrocker.net Sun Sep 27 20:48:39 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Sun, 27 Sep 2020 20:48:39 -0700 Subject: [ih] FTP RIP In-Reply-To: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> Message-ID: <693cf23f-9e00-a4dd-0db4-26530718ef2f@dcrocker.net> On 9/27/2020 6:29 PM, Joseph Touch via Internet-history wrote: > It?s been unfortunate how many of FTP?s features had to be (or still > remain to be) reinvented in HTTP. Aspects of that question, and that regret, seem to recur across this body of work. As I recall, SMTP was largely driven by a desire to have only one data transfer, when there were multiple recipients at the same destination.? A thoroughly reasonable desire, IMO.? And yet now, SMTP tends to do single addressee transfers, due to various handling, content and abuse issues. BTW, in discussions of the Web, I usually point out that while Engelbart's work set a stage for the broad framework, Anonymous FTP was actually the first distributed, production service on the net, for getting access to public documents from everywhere.? And it held that position for roughly 20+ years. For the purpose, it was a horrible UX, of course, but still, it served that purpose. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.e.carpenter at gmail.com Sun Sep 27 21:39:27 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 28 Sep 2020 17:39:27 +1300 Subject: [ih] FTP RIP In-Reply-To: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> Message-ID: On 28-Sep-20 14:29, Joseph Touch via Internet-history wrote: > This thread begs the question of where we?d be had TBL had tried to leverage FTP rather than reinventing the wheel with HTTP. > > I recall an early interview that claimed the rationale was that FTP opened two connections for every transfer and he only wanted one. It?s been unfortunate how many of FTP?s features had to be (or still remain to be) reinvented in HTTP. To be clear, he decided to use telnet as the basis for HTTP, which was one step better than using UDP I guess. His day job at the time was supporting RPC usage by physics experiments, and definitely envisaged HTTP as an RPC-like operation but without the expensive machinery needed for safe atomic operations. That's how we got RESTfulness, which any well-educated computer scientist is horrified by. My computer has forgotten how to do telnet, but for many years you could telnet to port 80 on an HTTP server and get something sensible back. Brian From agmalis at gmail.com Mon Sep 28 05:08:02 2020 From: agmalis at gmail.com (Andrew G. Malis) Date: Mon, 28 Sep 2020 08:08:02 -0400 Subject: [ih] FTP RIP In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> Message-ID: Brian, > My computer has forgotten how to do telnet, but for many years you could telnet to port 80 on an HTTP server and get something sensible back. You still can (this is using a MacOS Catalina terminal session): andy at iMac27 ~ % telnet www.google.com 80 Trying 142.250.64.68... Connected to www.google.com. Escape character is '^]'. GET HTTP/1.0 200 OK Date: Mon, 28 Sep 2020 12:01:09 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info." Server: gws X-XSS-Protection: 0 X-Frame-Options: SAMEORIGIN Set-Cookie: 1P_JAR=2020-09-28-12; expires=Wed, 28-Oct-2020 12:01:09 GMT; path=/; domain=.google.com; Secure Set-Cookie: NID=204=e3I_sEH-Z4wS0SsJV3qDNtAw1vbJkECMbPS_IBuMG2EXaBkgYqnu2vwKJQxYwX4ukUQWGKk0Qfrw5_Knteo1d_XzmPo2pdNLUotGdUByBRZlSnn1mJdiJh4eupzec03Fc6qfw_pp91m9et2ysemtF648hh6BxpE8NKjG0CA2eFQ; expires=Tue, 30-Mar-2021 12:01:09 GMT; path=/; domain=.google.com; HttpOnly Accept-Ranges: none Vary: Accept-Encoding And so on .... Cheers, Andy From tte at cs.fau.de Mon Sep 28 05:33:17 2020 From: tte at cs.fau.de (Toerless Eckert) Date: Mon, 28 Sep 2020 14:33:17 +0200 Subject: [ih] FTP RIP In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> Message-ID: <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> On Sun, Sep 27, 2020 at 10:22:15PM -0400, John Day via Internet-history wrote: > The control connection was a Telnet connection and assumed to be ASCII. The purpose was so that commands did not get blocked behind data. Also, for TIPS, the user FTP process was you. You typed the commands. Indeed. I remember doing this. Especially given how FTP supports third party transfers where an operator on host A can initiate ftp transfers directly between hosts B and C. Forgot the CLI commands though... Pretty fundamental functionality that AFAIK are missing from other protocols after FTP. I have not followed later development of secure ftp options, but i would be (positively) surprised if there where cryptographic variants whereby you could set up a cryptographic B<->C connection only using A's credentials on B and A's credentials on C. Oh well, silly, but good business to physically set up a lot of distributed management servers to orchestrate and pinhole traffic between remote B and C via HTTPs, when a NOCs A is on the other side of the planet. Nobody even thinks about how better protocols could solve those problems better. Cheers Toerless > The data connection was normally a fixed offset from the Telnet connection. (NCP sockets were simplex, so there was one for each direction.) The data connection was not ASCII. The data connection was assumed to be binary. The only time the Control connection was used for data transfer was for the MAIL command as opposed to the MLFL command that used the data connection. For the TIPs, devices like a printer or card reader could be ???hardwired??? to a given socket. The SOCKet command was used to not use the default data connections. > > > > > Firewalling and NATing are two of FTP's Achilles Heals. Specifically FTPS. > > Isn???t that a bit backwards? Since FTP was done decades before either one. > > > > Aside SFTP (SSH) is significantly different than FTPS (FTP over SSL / TLS). > > Unlike HTTP, FTP required a login. FTP is, in a sense, the first application protocol. (Telnet and NCP were ???in the OS.??? Telnet was a terminal device driver protocol.) > > > >> It???s been unfortunate how many of FTP???s features had to be (or still remain to be) reinvented in HTTP. > > > > I learned in the last few years that it's possible to establish FTP connections with two servers and instruct them to exchange data directly between themselves without traversing the common client. Or at least the protocol supports it. I'm not aware of it being a common implementation, much less execution. -- I do think that FTPS may hinder this somewhat. > > That has been there since at least 1973. There are no special commands and nothing special for doing that. It is just using the existing commands to do it. > > Take care, > John > > > > > > > > > -- > > Grant. . . . > > unix || die > > > > -- > > 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 -- --- tte at cs.fau.de From jeanjour at comcast.net Mon Sep 28 05:46:59 2020 From: jeanjour at comcast.net (John Day) Date: Mon, 28 Sep 2020 08:46:59 -0400 Subject: [ih] FTP RIP In-Reply-To: <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> Message-ID: <7A7BC9D0-09AF-45B1-8D7C-BEBFC47A5930@comcast.net> > On Sep 28, 2020, at 08:33, Toerless Eckert wrote: > > On Sun, Sep 27, 2020 at 10:22:15PM -0400, John Day via Internet-history wrote: >> The control connection was a Telnet connection and assumed to be ASCII. The purpose was so that commands did not get blocked behind data. Also, for TIPS, the user FTP process was you. You typed the commands. > > Indeed. I remember doing this. Especially given how FTP supports third party transfers where > an operator on host A can initiate ftp transfers directly between hosts B and C. Forgot the > CLI commands though? Nothing special. The user opened a FTP user connection to each host, logged in to them, then using the Sock and PASV commands told one to retrieve and the other to store. > > Pretty fundamental functionality that AFAIK are missing from other protocols after FTP. > > I have not followed later development of secure ftp options, but i would be (positively) surprised > if there where cryptographic variants whereby you could set up a cryptographic B<->C connection > only using A's credentials on B and A's credentials on C. Correct. > > Oh well, silly, but good business to physically set up a lot of distributed management servers > to orchestrate and pinhole traffic between remote B and C via HTTPs, when a NOCs A is on the other > side of the planet. Nobody even thinks about how better protocols could solve those problems better. > > Cheers > Toerless > >> The data connection was normally a fixed offset from the Telnet connection. (NCP sockets were simplex, so there was one for each direction.) The data connection was not ASCII. The data connection was assumed to be binary. The only time the Control connection was used for data transfer was for the MAIL command as opposed to the MLFL command that used the data connection. For the TIPs, devices like a printer or card reader could be ???hardwired??? to a given socket. The SOCKet command was used to not use the default data connections. >> >>> >>> Firewalling and NATing are two of FTP's Achilles Heals. Specifically FTPS. >> >> Isn???t that a bit backwards? Since FTP was done decades before either one. >>> >>> Aside SFTP (SSH) is significantly different than FTPS (FTP over SSL / TLS). >> >> Unlike HTTP, FTP required a login. FTP is, in a sense, the first application protocol. (Telnet and NCP were ???in the OS.??? Telnet was a terminal device driver protocol.) >>> >>>> It???s been unfortunate how many of FTP???s features had to be (or still remain to be) reinvented in HTTP. >>> >>> I learned in the last few years that it's possible to establish FTP connections with two servers and instruct them to exchange data directly between themselves without traversing the common client. Or at least the protocol supports it. I'm not aware of it being a common implementation, much less execution. -- I do think that FTPS may hinder this somewhat. >> >> That has been there since at least 1973. There are no special commands and nothing special for doing that. It is just using the existing commands to do it. >> >> Take care, >> John >> >>> >>> >>> >>> -- >>> Grant. . . . >>> unix || die >>> >>> -- >>> 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 > > -- > --- > tte at cs.fau.de From wfms at wfms.org Mon Sep 28 07:25:21 2020 From: wfms at wfms.org (wfms at wfms.org) Date: Mon, 28 Sep 2020 14:25:21 +0000 (UTC) Subject: [ih] FTP RIP In-Reply-To: <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> Message-ID: On Mon, 28 Sep 2020, Toerless Eckert via Internet-history wrote: > On Sun, Sep 27, 2020 at 10:22:15PM -0400, John Day via Internet-history wrote: >> The control connection was a Telnet connection and assumed to be ASCII. The purpose was so that commands did not get blocked behind data. Also, for TIPS, the user FTP process was you. You typed the commands. > > Indeed. I remember doing this. Especially given how FTP supports third party transfers where > an operator on host A can initiate ftp transfers directly between hosts B and C. Forgot the > CLI commands though... > > Pretty fundamental functionality that AFAIK are missing from other protocols after FTP. > > I have not followed later development of secure ftp options, but i would be (positively) surprised > if there where cryptographic variants whereby you could set up a cryptographic B<->C connection > only using A's credentials on B and A's credentials on C. IIRC, I think the GLOBUS GridFTP extensions do something like this, maybe not via crypto on the data transfer side. A description of the extensions are here: https://www.ogf.org/documents/GFD.20.pdf Haven't followed to see if they ever went to IETF. An overview can be found here: https://www.mcs.anl.gov/~mlink/tutorials/GridFTPTutorialSlides.pdf wfms From johnl at iecc.com Mon Sep 28 07:58:30 2020 From: johnl at iecc.com (John Levine) Date: 28 Sep 2020 10:58:30 -0400 Subject: [ih] FTP RIP In-Reply-To: Message-ID: <20200928145830.54670229FD3A@ary.qy> In article you write: >My computer has forgotten how to do telnet, but for many years you could telnet to port 80 on an HTTP server and get >something sensible back. You still can if you have a telnet client. My FTP server at ftp.iecc.com still works fine if you want to pick up back articles from comp.compilers and the like. R's, John $ telnet www.iecc.com 80 Trying 64.57.183.39... Connected to www.iecc.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 302 Found Date: Mon, 28 Sep 2020 14:57:16 GMT Server: Apache/2.4.46 (FreeBSD) OpenSSL/1.0.2u-freebsd mod_wsgi/4.7.0 Python/3.7 PHP/7.4.10 Location: https://www.iecc.com/ Content-Length: 205 Connection: close Content-Type: text/html; charset=iso-8859-1 302 Found

Found

The document has moved here.

Connection closed by foreign host. From cabo at tzi.org Mon Sep 28 08:01:33 2020 From: cabo at tzi.org (Carsten Bormann) Date: Mon, 28 Sep 2020 17:01:33 +0200 Subject: [ih] FTP RIP In-Reply-To: <7A7BC9D0-09AF-45B1-8D7C-BEBFC47A5930@comcast.net> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> <7A7BC9D0-09AF-45B1-8D7C-BEBFC47A5930@comcast.net> Message-ID: <1CEDEA33-E1AE-4347-849C-80B74E714C50@tzi.org> On 2020-09-28, at 14:46, John Day via Internet-history wrote: > > Nothing special. The user opened a FTP user connection to each host, logged in to them, then using the Sock and PASV commands told one to retrieve and the other to store. And, if raw transfer speed is of the essence, we are sometimes still doing the equivalent by sshing in to the two hosts and then using programs such as netcat (nc) to do the plumbing. No FTP needed? (But ?screen" is quite useful.) Gr??e, Carsten From darius.kazemi at gmail.com Mon Sep 28 08:25:35 2020 From: darius.kazemi at gmail.com (Darius Kazemi) Date: Mon, 28 Sep 2020 08:25:35 -0700 Subject: [ih] FTP RIP In-Reply-To: <20200927202258.DC75221E4DF2@ary.qy> References: <20200927202258.DC75221E4DF2@ary.qy> Message-ID: On Sun, Sep 27, 2020 at 1:23 PM John Levine via Internet-history < internet-history at elists.isoc.org> wrote: > It's an OK article, but what's a picture of a Model 32 Teletype doing > there? > That specific teletype is there to illustrate the point in RFC 114 that "indirect usage" means that a user doesn't have to care about "differences in terminal characteristics". It's a photo of an ARPANET terminal, and I think it's important to stress to people where we can that a good portion of very early ARPANET was printed on paper and that when we talk about terminals and their characteristics we don't just mean purely software terminals. Specifically the teletype pictured was connected to the Sigma 7 at UCLA, according to the person who took the photo: https://www.flickr.com/photos/fastlizard4/8412531873/ From johnl at iecc.com Mon Sep 28 08:42:00 2020 From: johnl at iecc.com (John Levine) Date: 28 Sep 2020 15:42:00 -0000 Subject: [ih] connection performance, FTP RIP In-Reply-To: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <693cf23f-9e00-a4dd-0db4-26530718ef2f@dcrocker.net> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <693cf23f-9e00-a4dd-0db4-26530718ef2f@dcrocker.net> Message-ID: In article <693cf23f-9e00-a4dd-0db4-26530718ef2f at dcrocker.net>, Dave Crocker via Internet-history wrote: >As I recall, SMTP was largely driven by a desire to have only one data >transfer, when there were multiple recipients at the same destination.?? >A thoroughly reasonable desire, IMO.?? And yet now, SMTP tends to do >single addressee transfers, due to various handling, content and abuse >issues. As network speeds have increased but the speed of light has not, multi-address SMTP doesn't save time any more, so it's not worth the effort and the loss in message customization and error handling. -- 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 darius.kazemi at gmail.com Mon Sep 28 08:47:21 2020 From: darius.kazemi at gmail.com (Darius Kazemi) Date: Mon, 28 Sep 2020 08:47:21 -0700 Subject: [ih] FTP RIP In-Reply-To: References: <20200927202258.DC75221E4DF2@ary.qy> Message-ID: On Sun, Sep 27, 2020 at 2:15 PM Dave Crocker via Internet-history < internet-history at elists.isoc.org> wrote: > And while Abhay was the editor, it was a committee effort. > The only claim in the article about Bhushan is that in 1971 he "first developed the File Transfer Protocol". Whether this is correct or not really depends on if you consider RFC 114 or 172 to be the first version of FTP. 114 seems to be pretty clearly a solo effort by Bhushan. It's written in the first person, for one. Worth noting that he refers to it as "a file transfer protocol" rather than "the File Transfer Protocol". He does note that he had help with implementation but it seems like the actual concept for 114 is his. I'd be interested to know if that was not the case. Nine weeks later, RFC 172 comes out as a committee effort and is what I'd consider the first *normative* spec for FTP. RFC 172 does more or less throw out or rework into oblivion what was proposed in 114 (in fact it gets split across two protocols, DTP in 171, and FTP in 172). I'd argue that despite the technical differences, RFC 114 is the first version of FTP, for three reasons: (1) lineage of Bhushan chairing the committee for the 172 version, (2) first use of the term "file transfer protocol" in the RFC series, and most importantly to me, (3) the theoretical framework of direct vs indirect network resource usage laid out in the introduction to 114. The indirect usage proposition is for me is the critical thing that makes FTP (of any version) different from the protocols that came earlier in the RFC series, which were largely variations on "using this protocol is like logging in to this computer from another site and you should read the manual for the specific computer because otherwise you will be lost". -Darius From mfidelman at meetinghouse.net Mon Sep 28 08:48:22 2020 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 28 Sep 2020 11:48:22 -0400 Subject: [ih] FTP RIP In-Reply-To: References: <20200927202258.DC75221E4DF2@ary.qy> Message-ID: On 9/27/20 5:14 PM, Dave Crocker via Internet-history wrote: > On 9/27/2020 1:22 PM, John Levine via Internet-history wrote: >> It's an OK article > > > By measures of meaningful deployment, "so old it predates email" is > incorrect. > > And "at the beginning, actually played the role of an email client" is > incorrect. > > And "for four years, FTP was technically email of sorts." was wrong on > two counts.? First, it was for 10 -- arguably more -- years.? Second > the "of sorts" is wrong. > As I recall, though, the first ARPANET email transfer was accomplished gloming SNDMSG & CPYNET together - to transfer the mail by appending messages to a remote mailbox file (Ray Tomlinson, 2 TENEX machines).? Then, after Ray distributed a description (by postal mail), folks started implementing the stuff on other platforms. If I recall my history correctly, FTP had (has?) a "mail" command added that served to transfer email for a while.? Then came SMTP. There are probably folks on this list who wrote some of those early mailers, and the associated RFCs.? And for the true techno-historians among us, all the documents are archived. (Though, perhaps someone can point to the original notification that Ray distributed to tell people what he'd done.) 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 vgcerf at gmail.com Mon Sep 28 09:02:05 2020 From: vgcerf at gmail.com (vinton cerf) Date: Mon, 28 Sep 2020 12:02:05 -0400 Subject: [ih] FTP RIP In-Reply-To: References: <20200927202258.DC75221E4DF2@ary.qy> Message-ID: that doesn't sound right to me. I don't remember using a TTY with the Sigma-7. Maybe with the IMP? v On Mon, Sep 28, 2020 at 11:26 AM Darius Kazemi via Internet-history < internet-history at elists.isoc.org> wrote: > On Sun, Sep 27, 2020 at 1:23 PM John Levine via Internet-history < > internet-history at elists.isoc.org> wrote: > > > It's an OK article, but what's a picture of a Model 32 Teletype doing > > there? > > > > That specific teletype is there to illustrate the point in RFC 114 that > "indirect usage" means that a user doesn't have to care about "differences > in terminal characteristics". It's a photo of an ARPANET terminal, and I > think it's important to stress to people where we can that a good portion > of very early ARPANET was printed on paper and that when we talk about > terminals and their characteristics we don't just mean purely software > terminals. Specifically the teletype pictured was connected to the Sigma 7 > at UCLA, according to the person who took the photo: > https://www.flickr.com/photos/fastlizard4/8412531873/ > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From darius.kazemi at gmail.com Mon Sep 28 09:09:37 2020 From: darius.kazemi at gmail.com (Darius Kazemi) Date: Mon, 28 Sep 2020 09:09:37 -0700 Subject: [ih] FTP RIP In-Reply-To: <39f2b8aa-717e-d330-bf9e-dbd5b5576360@johnlevine.com> References: <20200927202258.DC75221E4DF2@ary.qy> <39f2b8aa-717e-d330-bf9e-dbd5b5576360@johnlevine.com> Message-ID: Great observations -- it looks like that is indeed the teletype present at the recreated Boelter 3420 so I'm guessing the university must have mislabeled the teletype, or they labeled it as "a teletype much like this one connected to blah blah blah" and it was misread by the photographer. You can see the exact machine (the ITT sticker is clear enough) in the museum space here: https://samueli.ucla.edu/wp-content/uploads/samueli/internet_room-1.jpg On Mon, Sep 28, 2020 at 9:05 AM John R. Levine wrote: > >> It's an OK article, but what's a picture of a Model 32 Teletype doing > there? > >> > > > > That specific teletype is there to illustrate the point in RFC 114 that > > "indirect usage" means that a user doesn't have to care about > "differences > > in terminal characteristics". It's a photo of an ARPANET terminal, ... > > A baudot Model 32? All the ttys I used with computers were ASCII Model 33. > > > Specifically the teletype pictured was connected to the Sigma 7 at UCLA, > > according to the person who took the photo: > > https://www.flickr.com/photos/fastlizard4/8412531873/ > > I know that's what it says, but I think he's mistaken. When I look at > Sigma 7 manuals at bitsavers I see ASCII and EBCDIC, not baudot. > > Also, that tty has an ITT sticker on it which suggests it was connected to > the ITT telex network which was indeed baudot. > > 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 touch at strayalpha.com Mon Sep 28 09:18:38 2020 From: touch at strayalpha.com (Joseph Touch) Date: Mon, 28 Sep 2020 09:18:38 -0700 Subject: [ih] connection performance, FTP RIP In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <693cf23f-9e00-a4dd-0db4-26530718ef2f@dcrocker.net> Message-ID: <2D89809C-780F-4E4E-B8FC-28E95B6AEF8C@strayalpha.com> > On Sep 28, 2020, at 8:42 AM, John Levine via Internet-history wrote: > > As network speeds have increased but the speed of light has not, As a side point, the SOL has actually increased too (not in a good way) in some cases. Signals in fiber propagate at 2/3 the velocity of RF, free space optical, or open-ladder, though they?ve stated roughly the same as coax and twisted-pair. Joe From dhc at dcrocker.net Mon Sep 28 11:17:15 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 28 Sep 2020 11:17:15 -0700 Subject: [ih] FTP RIP In-Reply-To: References: <20200927202258.DC75221E4DF2@ary.qy> Message-ID: <18ec6170-91c5-e60e-0635-65cd0b174c38@dcrocker.net> On 9/28/2020 8:48 AM, Miles Fidelman via Internet-history wrote: > As I recall, though, the first ARPANET email transfer was accomplished > gloming SNDMSG & CPYNET together - to Yes.? Well documented.? And there is a timeline and reference to relevant histories at http://emailhistory.net. Broadly, there was a flurry of activity in the early 1970s, with quite a lot of collaboration and cross-talk. So, almost 25 years ago I was chatting with Abhay about FTP's including the mail commands and he was quite clear that it had been planned all along.? Certainly the public documentation suggests that the topic was active in the midst of the flurry. As a result of the more recent pseudo-controversy about the 'invention' of email, Ray said that his midnight project with sndmsg/cpynet was in direct response to the other email discussions that were happening, of a more elaborate protocol, and a usage model of printing the message and sending it through office paper mail.? I had not heard this piece of his story before.? It's perhaps a bit facile to compare what he did, against what was in the works, to creating Unix and reaction to Multics. But maybe not. Anyhow, the earliest FTP rfc drafts don't contain email, but by the time the specification stabilized, it did. > If I recall my history correctly, FTP had (has?) a "mail" command > added that served to transfer email for a while.? Then came SMTP. SMTP was written 10 years later.? And then it had to go through deployment startup.? The FTP Mail commands served us quite well, for quite awhile. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From bill.n1vux at gmail.com Mon Sep 28 13:03:29 2020 From: bill.n1vux at gmail.com (Bill Ricker) Date: Mon, 28 Sep 2020 16:03:29 -0400 Subject: [ih] FTP RIP In-Reply-To: <1029E379-8B52-4FC2-A497-0A18E144C4C9@comcast.net> References: <20200927202258.DC75221E4DF2@ary.qy> <1029E379-8B52-4FC2-A497-0A18E144C4C9@comcast.net> Message-ID: On Sun, Sep 27, 2020 at 5:57 PM John Day via Internet-history < internet-history at elists.isoc.org> wrote: > And the impetus for one of the great Padlipskyisms! > > When the discussion in an FTP meeting turned to the BYTE command. (The > BYTE command essentially set the ?word size? for the file.) Someone asked > a question along the lines of ?So what happens if I STORe a file with a > BYTE size of 23 and RETRieve it with a BYTE size of 17. > > Padlipsky sitting in the far corner of the room, piped up, ?Sometimes when > changing apples into oranges, you get lemons!? > > Everyone agreed that was the right answer. ;-) The Literary Estate of Mike Padlipsky approves this message. :-D I trust the riposte had to do with Making Lemonade ... (I've used bytes sized 5, 6, and 7 - and remember being annoyed the bit left over in the 36 bit word was not the easily accessible Sign bit, which would have been useful for an OOB EOS/EOF marker; back then, FORTRAN bit twiddling wasn't strong - but not 23 nor 17 ! *shudder* ) // Bill Ricker From jack at 3kitty.org Mon Sep 28 13:41:30 2020 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 28 Sep 2020 13:41:30 -0700 Subject: [ih] FTP RIP In-Reply-To: <18ec6170-91c5-e60e-0635-65cd0b174c38@dcrocker.net> References: <20200927202258.DC75221E4DF2@ary.qy> <18ec6170-91c5-e60e-0635-65cd0b174c38@dcrocker.net> Message-ID: I can toss in a bit of recollections of the early days of FTP and MAIL... In 1970, I was also a grad student in Lick's group at MIT.? Abhay's office was down the hall from mine.? There was lots of ARPANET-related activity, e.g., Abhay's FTP involvement, Bob Bressler's writing of NCP for the MIT-DM machine, Bob Metcalfe's thesis work in "Thin-wire communications" that led to Ethernet, etc. My project at the time was to work on some of Lick's "Electronic Office" visions.?? It wasn't directly related to the ARPANET at first, but quickly evolved into interoffice and intraoffice communications and document handling -- or in other words, what we now call email.?? At the time, it was politically incorrect to use the term "mail" since that was exclusively Postal Service responsibility, not ARPA.? So we called it Electronic Messaging. IIRC, it was common for computer systems of the era (1969/70) to have some mechanism for interaction between users.? E.g., there was something like a "Mail" command, that allowed one user to drop a message into another user's file directory so it became accessible and could be read.? Even in IBM batch processing, you could put cards in your input deck that would send a message to the operator, e.g., to mount a particular tape your job needed.?? I had to do that on the 7094. At the time, there were no "headers" in such messages.? The OS typically put a line at the top saying something like "Message from on " for each message.? On the systems I dealt with, there was just a file in each user's directory, and each incoming message was simply appended to that file by the OS.? No network involved at all.? To read your mail, you printed the file.? To send mail, you used your OS' mail command. As Abhay et al were doing FTP, of course things were implemented before they were documented.?? Someone noticed that you could send a message to another user by simply using FTP to APPEND your message to that user's mailbox file. Although this worked fine on the ITS machine at DM, which had no security at all, it surfaced issues on other machines which had a notion of protecting user's files from others.? Multics was especially picky about such stuff. I don't recall if the APPEND command in FTP was created to enable such message-delivery, or if it was already there and FTP became just a convenient way to deliver a message to a mailbox. But of course, to get a message to another user, you had to know how that user's system stored messages, so you could append to the right file.?? You also often had to be able to log in to that other machine (except for ITSes which let anybody log in...). The "MAIL" command in FTP solved that problem, by giving each server the responsibility of knowing where to put incoming messages for a particular user on that system.? It used the ANONYMOUS account name to let anybody send messages even without having an account.?? As I recall, Multics had especially bad heartburn with ANONYMOUS. I clearly recall using FTP as a "mail client".? You would simply connect to the remote machine, IIRC even by just using Telnet to the FTP port, and you'd be typing directly to the FTP server.? You could then type "MAIL " and it would respond with something like "Type your message, and end it with a line containing a single period".?? Then you type whatever you want, and as soon as you type a line with just a period, the mail command terminated and your message went into that other user's mailbox file. This resulted in very free-form mailbox files, since everything came from ANONYMOUS and there was no particular structure to what people sent. Although you could simply type your message into the Telnet connection, it wasn't very user friendly, since often there was no implementation of backspace.?? So typos remained, no way to fix it.?? But it was easy to write simple programs that allowed a user to create the message text and then make the FTP connection and use the MAIL command to send the message. I didn't use Tenex at the time, but I suspect this is about when Ray (or whoever did it) implemented the SNDMSG/CPYNET mechanism. Mailbox files quickly became messy and hard to read.? Many programs emerged to provide the UI for sending (and maybe also reading) mail.?? To make things better, programs inserted some text at the beginning of each message to help identify it and provide a visual demarcation between messages.? Spooler programs for line printers used a similar technique, putting "banners" between print jobs, so it was easy(ier) to find the end of one and beginning of the next.?? There was no standardization of what was in those "headers".? Some were simply utilitarian (From: JFH at MIT-DM; Subject: Header syntax).? Others could be creative (From: The eloquent keystrokes of Jack, concerning Header syntax).?? No rules. Although humans could understand such stuff, it was challenging to write a program that could correctly parse such free-form information.? I know; I tried. In addition, the "end your message with a line containing only a period" element of the FTP protocol meant that any message might prematurely abort the connection if the text contained the magic line.? To prevent that, it was necessary to scan every outgoing message and do something to alter wherever necessary to avoid . -- something that was annoyingly common in documents (part of an ellipsis). This situation was discussed extensively, of course by using email as the medium, and triggering the formation of various lists such as HEADER-PEOPLE where the pros and cons were debated ad nauseam.?? Sadly, I think little of those discussions was ever captured in RFCs, and email archives seem elusive or incomplete.?? I do recall that the crux of the debate was simplicity of sending quick notes versus the complexity of an office-automation machine.??? So that may have been the "other email discussions" that motivated Ray. The end result was to do an interim first step of the simple design of protocols and formats, and pursue the rest for a second release.? SMTP, the various "header" RFCs et al defined the first step.? AFAIK, the second is still in progress. /Jack Haverty MIT-DM 1970-1977 ? On 9/28/20 11:17 AM, Dave Crocker via Internet-history wrote: > On 9/28/2020 8:48 AM, Miles Fidelman via Internet-history wrote: >> As I recall, though, the first ARPANET email transfer was >> accomplished gloming SNDMSG & CPYNET together - to > > Yes.? Well documented.? And there is a timeline and reference to > relevant histories at http://emailhistory.net. > > Broadly, there was a flurry of activity in the early 1970s, with quite > a lot of collaboration and cross-talk. > > So, almost 25 years ago I was chatting with Abhay about FTP's > including the mail commands and he was quite clear that it had been > planned all along.? Certainly the public documentation suggests that > the topic was active in the midst of the flurry. > > As a result of the more recent pseudo-controversy about the > 'invention' of email, Ray said that his midnight project with > sndmsg/cpynet was in direct response to the other email discussions > that were happening, of a more elaborate protocol, and a usage model > of printing the message and sending it through office paper mail.? I > had not heard this piece of his story before.? It's perhaps a bit > facile to compare what he did, against what was in the works, to > creating Unix and reaction to Multics. But maybe not. > > Anyhow, the earliest FTP rfc drafts don't contain email, but by the > time the specification stabilized, it did. > > >> If I recall my history correctly, FTP had (has?) a "mail" command >> added that served to transfer email for a while.? Then came SMTP. > > SMTP was written 10 years later.? And then it had to go through > deployment startup.? The FTP Mail commands served us quite well, for > quite awhile. > > d/ > From bernie at fantasyfarm.com Mon Sep 28 14:10:28 2020 From: bernie at fantasyfarm.com (Bernie Cosell) Date: Mon, 28 Sep 2020 17:10:28 -0400 Subject: [ih] FTP RIP References: <20200927202258.DC75221E4DF2@ary.qy>, <18ec6170-91c5-e60e-0635-65cd0b174c38@dcrocker.net>, Message-ID: <5F725144.18474.4F492025@bernie.fantasyfarm.com> I am a little amused at all this. The "death of FTP" apparently is caused by a browser or two no longer supporting ftp:// URLs. I guess that the modern view is that the browser is the one and only portal to the Internet and so what it can't see ceases to exist. [and its corollary: what gmail doesn't do or support defines what email is] [I wonder if this means that the FTP client on the various servers I have SSH access to will stop working, and if it'll rip the two ftp clients off of my PC :o)] /Bernie\ Bernie Cosell bernie at fantasyfarm.com -- Too many people; too few sheep -- From brian.e.carpenter at gmail.com Mon Sep 28 14:23:48 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 29 Sep 2020 10:23:48 +1300 Subject: [ih] FTP RIP In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> Message-ID: On 29-Sep-20 03:25, wfms--- via Internet-history wrote: > On Mon, 28 Sep 2020, Toerless Eckert via Internet-history wrote: > >> On Sun, Sep 27, 2020 at 10:22:15PM -0400, John Day via Internet-history wrote: >>> The control connection was a Telnet connection and assumed to be ASCII. The purpose was so that commands did not get blocked behind data. Also, for TIPS, the user FTP process was you. You typed the commands. >> >> Indeed. I remember doing this. Especially given how FTP supports third party transfers where >> an operator on host A can initiate ftp transfers directly between hosts B and C. Forgot the >> CLI commands though... >> >> Pretty fundamental functionality that AFAIK are missing from other protocols after FTP. >> >> I have not followed later development of secure ftp options, but i would be (positively) surprised >> if there where cryptographic variants whereby you could set up a cryptographic B<->C connection >> only using A's credentials on B and A's credentials on C. > > IIRC, I think the GLOBUS GridFTP extensions do something like this, maybe > not via crypto on the data transfer side. A description of the extensions > are here: > > https://www.ogf.org/documents/GFD.20.pdf > > Haven't followed to see if they ever went to IETF. The grid people took an explicit decision *not* to pursue an RFC for GridFTP, sometime before July 2005. So it never received any IETF review, despite being effectively a set of extensions to FTP. (I was the IETF's liaison to the Global Grid Forum until March 2005, and I tried numerous times to get GridFTP discussed in the IETF Apps Area, but it never happened.) I don't know to what extent GridFTP is still used. Since the Globus toolkit is on its way out, so is GridFTP. A main user has been the Worldwide LHC Computational Grid, but they are looking for alternatives: https://arxiv.org/abs/2007.03490 That's an interesting paper if Terabytes/hour is a metric that fits your application. Brian Carpenter > An overview can be > found here: > > https://www.mcs.anl.gov/~mlink/tutorials/GridFTPTutorialSlides.pdf > > wfms > From steffen at sdaoden.eu Mon Sep 28 16:16:57 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 29 Sep 2020 01:16:57 +0200 Subject: [ih] FTP RIP In-Reply-To: <5F725144.18474.4F492025@bernie.fantasyfarm.com> References: <20200927202258.DC75221E4DF2@ary.qy> <18ec6170-91c5-e60e-0635-65cd0b174c38@dcrocker.net> <5F725144.18474.4F492025@bernie.fantasyfarm.com> Message-ID: <20200928231657.9Me_w%steffen@sdaoden.eu> Bernie Cosell wrote in <5F725144.18474.4F492025 at bernie.fantasyfarm.com>: |I am a little amused at all this. The "death of FTP" apparently is \ |caused by a |browser or two no longer supporting ftp:// URLs. I guess that the \ |modern |view is that the browser is the one and only portal to the Internet \ |and so what it |can't see ceases to exist. [and its corollary: what gmail doesn't \ |do or support |defines what email is] | |[I wonder if this means that the FTP client on the various servers \ |I have SSH |access to will stop working, and if it'll rip the two ftp clients off \ |of my PC :o)] It is not so funny given how many DNS root server traffic has been generated by a single browser by decision, and how much pressure (imho) the browser people generate to push DoH (DNS over HTTP), and what ideas are discussed or even are already standardized which require a browser etc. (MUD as of RFC 8520 in discussion for encrypted DNS). Repeated occurrance of "the internet is not only the web" or so can be heard. Let alone pressure due to enforcement of OAuth2 (XOAUTH aka really OAUTHBEARER) which requires refresh tokens via HTTP(S). (And which does not bring any benefit imho.) --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 gnu at toad.com Mon Sep 28 16:30:32 2020 From: gnu at toad.com (John Gilmore) Date: Mon, 28 Sep 2020 16:30:32 -0700 Subject: [ih] "how better protocols could solve those problems better" In-Reply-To: <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> Message-ID: <10027.1601335832@hop.toad.com> Toerless Eckert via Internet-history wrote: > Oh well, silly, but good business to physically set up a lot of > distributed management servers to orchestrate and pinhole traffic > between remote B and C via HTTPs, when a NOCs A is on the other side > of the planet. Nobody even thinks about how better protocols could > solve those problems better. I am trying to think about exactly this. I'm involved in an organization (ampr.org) that would like to catalyze better protocols that could solve Internet users' problems. We've invested money sourced from 1980s Internet address space, and are granting it out to improve the Internet (and ham radio, and digital radio tech in general). We're looking for promising projects that haven't been getting enough attention. We're hedging against the modern trend of proprietary companies that never define any public protocols, because they want everyone to centralize on their own servers and services. This internet-history mailing list community contains some of the (few) people who actually see the Internet as a collection of protocols, mutually agreed upon for the good of everyone. If we can indulge in a bit of "future history", where do you-all see promise in protocol development that's happening today? Where were good starts made, and then abandoned in the past due to the vagaries of history? What new protocols are or should be in development? Or, perhaps a simpler question, where are the pain points in current protocols, even if no replacements are on the horizon? John Gilmore From jnc at mercury.lcs.mit.edu Tue Sep 29 03:38:41 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 29 Sep 2020 06:38:41 -0400 (EDT) Subject: [ih] FTP RIP Message-ID: <20200929103841.2E8A318C0E1@mercury.lcs.mit.edu> > From: Jack Haverty > This situation was discussed extensively, of course by using email as > the medium, and triggering the formation of various lists such as > HEADER-PEOPLE where the pros and cons were debated ad nauseam. > Sadly, I think little of those discussions was ever captured in RFCs, > and email archives seem elusive or incomplete. I did manage to save MSGGROUP and most of Header-People archives, and put them up: http://www.chiappa.net/~jnc/tech/header/ http://www.chiappa.net/~jnc/tech/msggroup/ If anyone knows of a copy of the issing two at the front of H-P (i.e. before 6 November, 1976), that would be great. Luckily I seem to have a pack-rat nature, and have saved a lot of stuff, e.g. the Unix NCP. Noel From jack at 3kitty.org Wed Sep 30 11:48:20 2020 From: jack at 3kitty.org (Jack Haverty) Date: Wed, 30 Sep 2020 11:48:20 -0700 Subject: [ih] FTP RIP In-Reply-To: <20200929103841.2E8A318C0E1@mercury.lcs.mit.edu> References: <20200929103841.2E8A318C0E1@mercury.lcs.mit.edu> Message-ID: <8a949351-f3fb-2a11-2a13-e7a74b28467a@3kitty.org> Hi Noel, Thanks for the pointers.? I lost my own packrat stash when I failed to find a way to move info from Dectapes to a more modern medium. For the historians out there, Noel's message archives provide a rare insight into how network technology was created 50 years ago.?? Many of the messages in that archive (and others now lost) were the kinds of presentations of ideas and ensuing discussions that, in an earlier age, would have been carried out in a succession of papers in learned journals. The novelty and ease of "net mail" was addictive, and lured much of the debate and discussions online instead of onpaper.? You can see a lot of it in the message archives Noel has saved for almost 50 years. It happened first in the network research community, because we built the means to hold such debate online.? The traditional and more formal mechanisms, such as journals and even the informal RFCs, were only part of the collaboration machinery in the ARPANET world.? There were many "mailing lists", as well as much other informal interaction just between pairs or small groups of network-connected researchers by use of email.?? The surviving formal materials, e.g., RFCs, capture a lot of what happened, and, IMHO, the messaging exchanges can reveal a lot of why it happened. /Jack Haverty On 9/29/20 3:38 AM, Noel Chiappa via Internet-history wrote: > > From: Jack Haverty > > > This situation was discussed extensively, of course by using email as > > the medium, and triggering the formation of various lists such as > > HEADER-PEOPLE where the pros and cons were debated ad nauseam. > > Sadly, I think little of those discussions was ever captured in RFCs, > > and email archives seem elusive or incomplete. > > I did manage to save MSGGROUP and most of Header-People archives, and put them up: > > http://www.chiappa.net/~jnc/tech/header/ > http://www.chiappa.net/~jnc/tech/msggroup/ > > If anyone knows of a copy of the issing two at the front of H-P (i.e. before 6 > November, 1976), that would be great. > > Luckily I seem to have a pack-rat nature, and have saved a lot of stuff, e.g. the Unix NCP. > > Noel From craig at tereschau.net Wed Sep 30 16:49:19 2020 From: craig at tereschau.net (Craig Partridge) Date: Wed, 30 Sep 2020 17:49:19 -0600 Subject: [ih] "how better protocols could solve those problems better" In-Reply-To: <10027.1601335832@hop.toad.com> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> <10027.1601335832@hop.toad.com> Message-ID: On Mon, Sep 28, 2020 at 5:31 PM John Gilmore via Internet-history < internet-history at elists.isoc.org> wrote: > > Or, perhaps a simpler question, where are the pain points in current > protocols, even if no replacements are on the horizon? > That's a great question, so I'll take a crack at part of it. >From where I sit, I'm seeing the current protocols in pain related to Big Data. In particular, I'm seeing two pain points: * Naming and organizing big data. We are generating big data in many areas faster than we can name it. And by "name" I don't simply mean giving something a filename but creating an environment to find that name, including the right metadata, and storing the data in places folks can easily retrieve it. You can probably through archiving into that too (when should data with this name be kept or discarded over time?). What good are FTP, SCP, HTTPS, if you can't find or retrieve the data? * We are reaching the end of the TCP checksum's useful life. It is a weak 16-bit checksum (by weak I mean that, in some cases, errors get past at a rate greater than 1 in 2^16) and on big data transfers (gigabytes and larger) in some parts of the Internet errors are slipping through. Beyond making data transfer unreliable the errors are exposing weaknesses in our secure file transfer protocols, which assume that any transport error is due to malice and thus kill connections, without saving data that was successfully retrieved -- instead they force a complete new attempt to transfer (the need for FTP checkpointing lives!). The result in some big data environments is secure file transfers failing as much as 60% (that's not a typo) of the time. Thanks! Craig -- ***** Craig Partridge's email account for professional society activities and mailing lists. From vint at google.com Wed Sep 30 16:51:27 2020 From: vint at google.com (Vint Cerf) Date: Wed, 30 Sep 2020 19:51:27 -0400 Subject: [ih] "how better protocols could solve those problems better" In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> <10027.1601335832@hop.toad.com> Message-ID: would a higher application level check be useful? new options in TCP? something else? v On Wed, Sep 30, 2020 at 7:49 PM Craig Partridge via Internet-history < internet-history at elists.isoc.org> wrote: > On Mon, Sep 28, 2020 at 5:31 PM John Gilmore via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > > Or, perhaps a simpler question, where are the pain points in current > > protocols, even if no replacements are on the horizon? > > > > That's a great question, so I'll take a crack at part of it. > > From where I sit, I'm seeing the current protocols in pain related to Big > Data. In particular, I'm seeing two pain points: > > * Naming and organizing big data. We are generating big data in many areas > faster than we can name it. And by "name" I don't simply mean giving > something a filename but creating an environment to find that name, > including the right metadata, and storing the data in places folks can > easily retrieve it. You can probably through archiving into that too (when > should data with this name be kept or discarded over time?). What good are > FTP, SCP, HTTPS, if you can't find or retrieve the data? > > * We are reaching the end of the TCP checksum's useful life. It is a weak > 16-bit checksum (by weak I mean that, in some cases, errors get past at a > rate greater than 1 in 2^16) and on big data transfers (gigabytes and > larger) in some parts of the Internet errors are slipping through. Beyond > making data transfer unreliable the errors are exposing weaknesses in our > secure file transfer protocols, which assume that any transport error is > due to malice and thus kill connections, without saving data that was > successfully retrieved -- instead they force a complete new attempt to > transfer (the need for FTP checkpointing lives!). The result in some big > data environments is secure file transfers failing as much as 60% (that's > not a typo) of the time. > > Thanks! > > 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 > -- Please send any postal/overnight deliveries to: Vint Cerf 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From craig at tereschau.net Wed Sep 30 16:58:50 2020 From: craig at tereschau.net (Craig Partridge) Date: Wed, 30 Sep 2020 17:58:50 -0600 Subject: [ih] "how better protocols could solve those problems better" In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> <10027.1601335832@hop.toad.com> Message-ID: I've got some NSF funding to figure out what the error patterns are (nobody's capturing them) with the idea we might propose a new checksum and/or add checkpointing into the file transfer protocols. It is little hard to add something on top of protocols that have a fail/discard model. Craig On Wed, Sep 30, 2020 at 5:51 PM Vint Cerf wrote: > would a higher application level check be useful? new options in TCP? > something else? > > v > > > On Wed, Sep 30, 2020 at 7:49 PM Craig Partridge via Internet-history < > internet-history at elists.isoc.org> wrote: > >> On Mon, Sep 28, 2020 at 5:31 PM John Gilmore via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >> > >> > Or, perhaps a simpler question, where are the pain points in current >> > protocols, even if no replacements are on the horizon? >> > >> >> That's a great question, so I'll take a crack at part of it. >> >> From where I sit, I'm seeing the current protocols in pain related to Big >> Data. In particular, I'm seeing two pain points: >> >> * Naming and organizing big data. We are generating big data in many >> areas >> faster than we can name it. And by "name" I don't simply mean giving >> something a filename but creating an environment to find that name, >> including the right metadata, and storing the data in places folks can >> easily retrieve it. You can probably through archiving into that too >> (when >> should data with this name be kept or discarded over time?). What good >> are >> FTP, SCP, HTTPS, if you can't find or retrieve the data? >> >> * We are reaching the end of the TCP checksum's useful life. It is a weak >> 16-bit checksum (by weak I mean that, in some cases, errors get past at a >> rate greater than 1 in 2^16) and on big data transfers (gigabytes and >> larger) in some parts of the Internet errors are slipping through. Beyond >> making data transfer unreliable the errors are exposing weaknesses in our >> secure file transfer protocols, which assume that any transport error is >> due to malice and thus kill connections, without saving data that was >> successfully retrieved -- instead they force a complete new attempt to >> transfer (the need for FTP checkpointing lives!). The result in some big >> data environments is secure file transfers failing as much as 60% (that's >> not a typo) of the time. >> >> Thanks! >> >> 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 >> > > > -- > Please send any postal/overnight deliveries to: > Vint Cerf > 1435 Woodhurst Blvd > McLean, VA 22102 > 703-448-0965 > > until further notice > > > > -- ***** Craig Partridge's email account for professional society activities and mailing lists. From gnu at toad.com Wed Sep 30 17:45:30 2020 From: gnu at toad.com (John Gilmore) Date: Wed, 30 Sep 2020 17:45:30 -0700 Subject: [ih] "how better protocols could solve those problems better" In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> <10027.1601335832@hop.toad.com> Message-ID: <28454.1601513130@hop.toad.com> Craig Partridge wrote: >>> * We are reaching the end of the TCP checksum's useful life. It is a weak >>> 16-bit checksum (by weak I mean that, in some cases, errors get past at a >>> rate greater than 1 in 2^16) and on big data transfers (gigabytes and >>> larger) in some parts of the Internet errors are slipping through. Beyond >>> making data transfer unreliable the errors are exposing weaknesses in our >>> secure file transfer protocols, which assume that any transport error is >>> due to malice and thus kill connections, without saving data that was >>> successfully retrieved -- instead they force a complete new attempt to >>> transfer (the need for FTP checkpointing lives!). The result in some big >>> data environments is secure file transfers failing as much as 60% (that's >>> not a typo) of the time. >> would a higher application level check be useful? new options in TCP? >> something else? > I've got some NSF funding to figure out what the error patterns are > (nobody's capturing them) with the idea we might propose a new checksum > and/or add checkpointing into the file transfer protocols. It is little > hard to add something on top of protocols that have a fail/discard model. A very popular file transfer protocol with application level checksums, and retries at the subblock level is BitTorrent. The file transfer starts by transferring metadata that includes an overall checksum for the file, plus hundreds or thousands of individual subblock checksums. In the main data transfer, if the client receives subblock data that doesn't match the checksum, that subblock gets discarded and re-requested, until the data gets through error-free. Meanwhile, the entire rest of the file continues to be transferred successfully, and the implementations track which parts of the received partial file are known-valid, and which are not, in stable storage that survives crashes and restarts. BT's original purpose was to start with a fast, small metadata transfer, and then allow the rest of a large data file to come from any arbitrary (thus untrustworthy) source on the network, both impeding censorship, and speeding downloads of popular files. The protocol and code are already handling dozens or hundreds of simultaneous TCP connections to retrieve parts of the file from different sources. In use cases where there's only one source for the data, that basic model would also cleanly be extensible to allow opening multiple parallel TCP connections from the same host (for getting past TCP bandwidth x delay product issues and slow recovery from congestion) that also resolve issues in the large-data environment. Besides also providing a higher level, cryptographic checksum and retry mechanism. BitTorrent originally used TCP, and it remains available in all implementations, but implementations now tend to use UDP with peers that support it, because TCP was poorly sensitive to packet delay and tended to produce bufferbloat in intermediate routers. It originally used IPv4 but now also handles IPv6 and is happy to simultaneously handle connections via both. The specs for BitTorrent are published and well maintained, along with an evolution process (BEPs; see http://bittorrent.org/beps/bep_0000.html). Dozens of well maintained, robust implementations exist, both open source and proprietary. Any of these could be adapted for the specific use case of big data transfers (and/or for research use in detecting and reporting patterns of otherwise undetected UDP or TCP data corruption). John From touch at strayalpha.com Wed Sep 30 17:58:09 2020 From: touch at strayalpha.com (Joseph Touch) Date: Wed, 30 Sep 2020 17:58:09 -0700 Subject: [ih] "how better protocols could solve those problems better" In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> <10027.1601335832@hop.toad.com> Message-ID: <0A501269-0908-4C55-BEA3-F9A0E832F52B@strayalpha.com> > On Sep 30, 2020, at 4:58 PM, Craig Partridge via Internet-history wrote: > > I've got some NSF funding to figure out what the error patterns are > (nobody's capturing them) with the idea we might propose a new checksum > and/or add checkpointing into the file transfer protocols. It is little > hard to add something on top of protocols that have a fail/discard model. We already have TCP-MD5, TCP-AO, TLS, and IPsec. Why wouldn?t one (any one) of those suffice? Alternately, your own TCP checksum option - which had 25 yrs to gain traction before it was officially declared obsolete? Joe From jeanjour at comcast.net Wed Sep 30 18:50:32 2020 From: jeanjour at comcast.net (John Day) Date: Wed, 30 Sep 2020 21:50:32 -0400 Subject: [ih] "how better protocols could solve those problems better" In-Reply-To: <0A501269-0908-4C55-BEA3-F9A0E832F52B@strayalpha.com> References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> <10027.1601335832@hop.toad.com> <0A501269-0908-4C55-BEA3-F9A0E832F52B@strayalpha.com> Message-ID: Of greater concern is there is no congestion control. John > On Sep 30, 2020, at 20:58, Joseph Touch via Internet-history wrote: > > > >> On Sep 30, 2020, at 4:58 PM, Craig Partridge via Internet-history wrote: >> >> I've got some NSF funding to figure out what the error patterns are >> (nobody's capturing them) with the idea we might propose a new checksum >> and/or add checkpointing into the file transfer protocols. It is little >> hard to add something on top of protocols that have a fail/discard model. > > We already have TCP-MD5, TCP-AO, TLS, and IPsec. > > Why wouldn?t one (any one) of those suffice? > > Alternately, your own TCP checksum option - which had 25 yrs to gain traction before it was officially declared obsolete? > > Joe > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From jeanjour at comcast.net Wed Sep 30 18:52:14 2020 From: jeanjour at comcast.net (John Day) Date: Wed, 30 Sep 2020 21:52:14 -0400 Subject: [ih] "how better protocols could solve those problems better" In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> <10027.1601335832@hop.toad.com> Message-ID: <3304F3AD-3941-4D9E-B1AE-E9D9DD9F33E2@comcast.net> > On Sep 30, 2020, at 19:49, Craig Partridge via Internet-history wrote: > > On Mon, Sep 28, 2020 at 5:31 PM John Gilmore via Internet-history < > internet-history at elists.isoc.org> wrote: > >> >> Or, perhaps a simpler question, where are the pain points in current >> protocols, even if no replacements are on the horizon? >> > > That's a great question, so I'll take a crack at part of it. > > From where I sit, I'm seeing the current protocols in pain related to Big > Data. In particular, I'm seeing two pain points: > > * Naming and organizing big data. We are generating big data in many areas > faster than we can name it. And by "name" I don't simply mean giving > something a filename but creating an environment to find that name, > including the right metadata, and storing the data in places folks can > easily retrieve it. You can probably through archiving into that too (when > should data with this name be kept or discarded over time?). What good are > FTP, SCP, HTTPS, if you can't find or retrieve the data? Isn?t this what the database schema is for? > > * We are reaching the end of the TCP checksum's useful life. It is a weak > 16-bit checksum (by weak I mean that, in some cases, errors get past at a > rate greater than 1 in 2^16) and on big data transfers (gigabytes and > larger) in some parts of the Internet errors are slipping through. Beyond > making data transfer unreliable the errors are exposing weaknesses in our > secure file transfer protocols, which assume that any transport error is > due to malice and thus kill connections, without saving data that was > successfully retrieved -- instead they force a complete new attempt to > transfer (the need for FTP checkpointing lives!). The result in some big > data environments is secure file transfers failing as much as 60% (that's > not a typo) of the time. > > Thanks! > > 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 gnu at toad.com Wed Sep 30 18:59:51 2020 From: gnu at toad.com (John Gilmore) Date: Wed, 30 Sep 2020 18:59:51 -0700 Subject: [ih] "how better protocols could solve those problems better" In-Reply-To: References: <03461BCD-99D9-4806-B44B-B8F116A1F81C@strayalpha.com> <20200928123317.GK3141@faui48f.informatik.uni-erlangen.de> <10027.1601335832@hop.toad.com> Message-ID: <400.1601517591@hop.toad.com> Craig Partridge wrote: > * Naming and organizing big data. We are generating big data in many areas > faster than we can name it. And by "name" I don't simply mean giving > something a filename but creating an environment to find that name, > including the right metadata, and storing the data in places folks can > easily retrieve it. You can probably through archiving into that too (when > should data with this name be kept or discarded over time?). What good are > FTP, SCP, HTTPS, if you can't find or retrieve the data? The Internet Archive has this problem. I'm not the right expert to talk about what they've done, but I can introduce you. Their current storage design is to keep all their data in "items" which are files up to multi-gigabyte size named with an arbitrary ascii string, and containing metadata from the source. These items are replicated onto multiple drives in multiple data centers for resilience and performance. When drives fail, their former contents are replicated onto new drives from other copies. The items contain the definitive metadata; the indices are caches. Indices are built for high performance searching, originally by reading all the metadata from all the items, and then by incremental updating. The main "catalog" index allows finding which server(s) and drive(s) contain each individual item, by its name. Their metadata is organized around three main types of items: * Uploaded files from arbitrary users who offered them into the Archive's collection. (archive.org, millions of items) * Copies of web pages downloaded by Heritrix, the web crawler that feeds the Wayback Machine which provides a user interface for seeing what web pages looked like in the past. (web.archive.org, containing about 477 billion pages.) * Books, shellac and vinyl records, and CDs that are owned by the Archive or partner libraries, and scanned in professionally. (archive.org or openlibrary.org) Millions of items, but many are not publicly accessible until their copyrights expire. All of these are stored in items, but has different metadata contained within it, and with additional index databases organized for the kinds of expected searches (such as by author, title, musician, web address, date, etc). Finding things in the Archive is considered difficult. Their first few decades focused on saving things for posterity, figuring that better search methods could only be developed if the data itself was first preserved. They are now branching out into improved searchability. For example, they now offer full-text searching of their entire book collection (using an ElasticSearch database built from the OCR'd texts in the photographic scans of each page of each book, all of which are stored in items). Clearly, a key is how the arbitrary strings that name items are generated. I don't know details about this, though for books, some algorithm hints come through in item names like "charlottesweb00whit"; see for example: https://archive.org/details/charlottesweb00whit John