From mfidelman at meetinghouse.net Fri Apr 1 11:51:40 2022 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 1 Apr 2022 14:51:40 -0400 Subject: [ih] Automated Network Management [was: GOSIP & compliance] In-Reply-To: <94157f9a-4544-cac8-9312-00232a11707f@3kitty.org> References: <967226810.844120.1648769888555@mail.yahoo.com> <624641FC.23433.28FA8FCD@bernie.fantasyfarm.com> <94157f9a-4544-cac8-9312-00232a11707f@3kitty.org> Message-ID: <1b23249f-6c0f-121b-1a40-b1c3a32fc6ad@meetinghouse.net> For what it's worth.... Jack Haverty via Internet-history wrote: > I can provide some recollections of the origin and intent of ANM - > Automated Network Management. > > Sometime in early 1983, Bob Kahn and I were talking one day about the > Internet.? In particular, we were musing about how the Internet might > be operated and managed as EGP was introduced and the Internet became > a loose confederation of individual Autonomous Systems, each operated > and managed by a separate organization. That was quite different from > the ARPANET, which had a centralized management approach with the NOC > and refined it over a decade of operation. We had used that ARPANET > model as a guide to put the first management mechanisms into the "core > gateways", basically using the success of the ARPANET techniques to > get the Internet going quickly as a reliable operational > communications facility. But, as the saying goes, it was obvious that > "it won't scale". When I arrived at BBN, circa 1985, we were just about to split the ARPANET in two (Academic, MILNET), as well as deploy several parallel classified networks - to yield the Defense Data Network (DDN).? My first assignment was to develop the network management architecture for the DDN - which mostly involved developing a CONOPS that fit into the way DCA was managing both underlying circuits, and its other networks, and coincidentally, modifications to the network management software used for the ARPANET. It actually scaled pretty well.? The nodes basically managed themselves, re-routed around failed circuits and nodes, etc. "Network Management" consisted of collecting performance & error information, providing information to the Network Analysis group for long-range capacity & topology planning, and responding to faults, mostly by dispatching service requests to carriers, and sometimes dispatching BBN personnel to repair nodes (we had the contract). The major issues that we came across were mostly operational: - Traditionally, circuit service requests were initiated by base comms. officers at either end of a circuit.? It took a lot of procedural and contractual changes to get folks like AT&T Long Lines to accept calls from BBN staff, manning the three central NOCs (DC, EUR, PAC). - We had to update our databases to include information about circuit ownership, contract details, local points of contact, and such.? As I recall, there were some software updates, but most of this was all administrative. - It also turned out that the carriers knew from nothing about "packet error rates" - so we had to update systems to report bit error rates. But, as I say, it all scaled pretty well, for a considerable amount of time.? I'm not really sure that things have changed all that much as the Internet grew.? It still seems the case that network equipment mostly self-manages, network admins use things like Nagios to track statistics and errors, ticketing systems to track incidents, and a lot of informal communication (e.g., on things like the nanog list) to coordinate responses to weird stuff (like routing table corruptions). 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 gregskinner0 at icloud.com Sat Apr 2 09:41:35 2022 From: gregskinner0 at icloud.com (Greg Skinner) Date: Sat, 2 Apr 2022 09:41:35 -0700 Subject: [ih] GOSIP & compliance In-Reply-To: <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> Message-ID: <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> > On Mar 28, 2022, at 11:19 AM, John Day wrote: > > Just to add to the comments, > >> On Mar 28, 2022, at 12:48, Craig Partridge via Internet-history wrote: >> >> The UDP vs. TCP debate was pretty fierce and the experience of the time >> came down firmly on the UDP side. Recall this was the era of daily >> congestion collapse of the Internet between 1987 and 1990. > > Somehow this argument (which I know was intense at the time) is the most absurd. All of the functions in TCP that are relevant are feedback functions that only involve the source and destination. In between, the handling of UDP and TCP packets by the routers is the same. If anything, TCP packets with congestion control have a better chance of being received and a TCP solution would have required fewer packets be generated in the first place. (The last thing a management system should be doing when things go bad is generating lots of traffic, but SNMP was good at that.) No argument from me about management systems generating too much traffic. However, regarding congestion control, around 1987, mitigation was underway, but solutions that were widely deployed in TCP/IP implementations were still a few years off. That helped make UDP more attractive, at least in the short term. [?] >> There was a network management project in the late 1980s, name now eludes >> me but led by Jil Wescott and DARPA funded, that sound similar in goals to >> what Jack H. describes doing at Oracle. I leaned on wisdom from those >> folks (esp. the late Charlie Lynn) as Glenn Trewitt and I sought to figure >> out what HEMS should look like. Right. From the tcp-ip mailing list and Usenet newsgroup, January 1987: ?? Date: Tue, 20-Jan-87 12:12:04 EST From: leiner at ICARUS.RIACS.EDU To: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring Craig, As you probably are aware, there has been quite a bit of work done already in "monitoring". In fact, Jil Westcott at BBN has been doing some work in automated network monitoring related to ADDCOMPE and packet radio networks. There have also been several proposals for "monitoring protocols". I'm happy to see you working in this area. It is clearly critical for large internets like NSFnet and the evolving national research internet. Hopefully, with this new push, a "standard approach" can be developed. Barry ?? BTW, interested readers can see discussions on this and related topics at the ban.ai TCP/IP mailing list archive . (You may get a message indicating SSL certificates have expired.) ?gregbo From jeanjour at comcast.net Sat Apr 2 10:25:41 2022 From: jeanjour at comcast.net (John Day) Date: Sat, 2 Apr 2022 13:25:41 -0400 Subject: [ih] GOSIP & compliance In-Reply-To: <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> Message-ID: Please explain how UDP packets are less susceptible to congestion than TCP packets? I would really like to know. > On Apr 2, 2022, at 12:41, Greg Skinner wrote: > > >> On Mar 28, 2022, at 11:19 AM, John Day > wrote: >> >> Just to add to the comments, >> >>> On Mar 28, 2022, at 12:48, Craig Partridge via Internet-history > wrote: >>> >>> The UDP vs. TCP debate was pretty fierce and the experience of the time >>> came down firmly on the UDP side. Recall this was the era of daily >>> congestion collapse of the Internet between 1987 and 1990. >> >> Somehow this argument (which I know was intense at the time) is the most absurd. All of the functions in TCP that are relevant are feedback functions that only involve the source and destination. In between, the handling of UDP and TCP packets by the routers is the same. If anything, TCP packets with congestion control have a better chance of being received and a TCP solution would have required fewer packets be generated in the first place. (The last thing a management system should be doing when things go bad is generating lots of traffic, but SNMP was good at that.) > > No argument from me about management systems generating too much traffic. However, regarding congestion control, around 1987, mitigation was underway, but solutions that were widely deployed in TCP/IP implementations were still a few years off. That helped make UDP more attractive, at least in the short term. > > [?] > >>> There was a network management project in the late 1980s, name now eludes >>> me but led by Jil Wescott and DARPA funded, that sound similar in goals to >>> what Jack H. describes doing at Oracle. I leaned on wisdom from those >>> folks (esp. the late Charlie Lynn) as Glenn Trewitt and I sought to figure >>> out what HEMS should look like. > > Right. From the tcp-ip mailing list and Usenet newsgroup, January 1987: > > ?? > > Date: Tue, 20-Jan-87 12:12:04 EST > From: leiner at ICARUS.RIACS.EDU > To: mod.protocols.tcp-ip > Subject: Re: Gateway Monitoring > > Craig, > > As you probably are aware, there has been quite a bit of work done > already in "monitoring". In fact, Jil Westcott at BBN has been doing > some work in automated network monitoring related to ADDCOMPE and packet > radio networks. There have also been several proposals for "monitoring > protocols". > > I'm happy to see you working in this area. It is clearly critical for > large internets like NSFnet and the evolving national research internet. > Hopefully, with this new push, a "standard approach" can be developed. > > Barry > > ?? > > BTW, interested readers can see discussions on this and related topics at the ban.ai TCP/IP mailing list archive . (You may get a message indicating SSL certificates have expired.) > > ?gregbo > > From craig at tereschau.net Sat Apr 2 12:05:17 2022 From: craig at tereschau.net (Craig Partridge) Date: Sat, 2 Apr 2022 13:05:17 -0600 Subject: [ih] GOSIP & compliance In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> Message-ID: Hi John: The answer at the time ran as follows. X number of datagrams are sent from the monitored station to the monitoring center (let's say X is 4) and all but one are discarded in the routers due to congestion loss. In UDP, 1 datagram gets through -- one hopes with useful data -- in a timely way. In TCP, unless the 1 datagram that gets through is the first datagram, you get nothing until the missing datagrams arrive to move the window forward. So you get substantially delayed or not data, as in many cases in the 1980s, the connection would instead fail. Craig On Sat, Apr 2, 2022 at 11:26 AM John Day via Internet-history < internet-history at elists.isoc.org> wrote: > Please explain how UDP packets are less susceptible to congestion than TCP > packets? I would really like to know. > > > > > On Apr 2, 2022, at 12:41, Greg Skinner wrote: > > > > > >> On Mar 28, 2022, at 11:19 AM, John Day jeanjour at comcast.net>> wrote: > >> > >> Just to add to the comments, > >> > >>> On Mar 28, 2022, at 12:48, Craig Partridge via Internet-history > > wrote: > >>> > >>> The UDP vs. TCP debate was pretty fierce and the experience of the time > >>> came down firmly on the UDP side. Recall this was the era of daily > >>> congestion collapse of the Internet between 1987 and 1990. > >> > >> Somehow this argument (which I know was intense at the time) is the > most absurd. All of the functions in TCP that are relevant are feedback > functions that only involve the source and destination. In between, the > handling of UDP and TCP packets by the routers is the same. If anything, > TCP packets with congestion control have a better chance of being received > and a TCP solution would have required fewer packets be generated in the > first place. (The last thing a management system should be doing when > things go bad is generating lots of traffic, but SNMP was good at that.) > > > > No argument from me about management systems generating too much > traffic. However, regarding congestion control, around 1987, mitigation > was underway, but solutions that were widely deployed in TCP/IP > implementations were still a few years off. That helped make UDP more > attractive, at least in the short term. > > > > [?] > > > >>> There was a network management project in the late 1980s, name now > eludes > >>> me but led by Jil Wescott and DARPA funded, that sound similar in > goals to > >>> what Jack H. describes doing at Oracle. I leaned on wisdom from those > >>> folks (esp. the late Charlie Lynn) as Glenn Trewitt and I sought to > figure > >>> out what HEMS should look like. > > > > Right. From the tcp-ip mailing list and Usenet newsgroup, January 1987: > > > > ?? > > > > Date: Tue, 20-Jan-87 12:12:04 EST > > From: leiner at ICARUS.RIACS.EDU > > To: mod.protocols.tcp-ip > > Subject: Re: Gateway Monitoring > > > > Craig, > > > > As you probably are aware, there has been quite a bit of work done > > already in "monitoring". In fact, Jil Westcott at BBN has been doing > > some work in automated network monitoring related to ADDCOMPE and packet > > radio networks. There have also been several proposals for "monitoring > > protocols". > > > > I'm happy to see you working in this area. It is clearly critical for > > large internets like NSFnet and the evolving national research internet. > > Hopefully, with this new push, a "standard approach" can be developed. > > > > Barry > > > > ?? > > > > BTW, interested readers can see discussions on this and related topics > at the ban.ai TCP/IP mailing list archive < > https://ban.ai/multics/non-multics-docs/tcpip-digest/sd-archive/archive/>. > (You may get a message indicating SSL certificates have expired.) > > > > ?gregbo > > > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > -- ***** Craig Partridge's email account for professional society activities and mailing lists. From jeanjour at comcast.net Sat Apr 2 18:19:21 2022 From: jeanjour at comcast.net (John Day) Date: Sat, 2 Apr 2022 21:19:21 -0400 Subject: [ih] GOSIP & compliance In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> Message-ID: <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> Thanks, I can see that it is an argument for it. Pretty weak in my estimation, but it seems to misunderstand the problem. Given that was at the height of the silly ?everything has to be connectionless? fad, I am sure that had a lot to do with it too. With the overhead of BER that didn?t leave a lot of room for much useful in the packet. So you send a flurry of UDP packets and some get through and you hope that the ones that do are useful. Doesn?t sound great. Now if this flurry is commands to agents, the likelihood of random commands arriving in some order sounds more dangerous than useful. It could easily make a bad situation worse. If they are responses, then the manager is getting bits and pieces of information (and small ones at that) and trying to assemble some sort of picture of what is going on. GetNext was a pretty lame excuse for being able to retrieve a large structure in one operation. Sure it generated more than 2 packets but considerably less than GetNext would require and the Get/Read would be a snapshot, where with GetNext the information could change out from under you. Let me tell a story: In the 70s and early 80s, this was called network control. Starting with the ARPANET, I was always a firm believer that management was more appropriate, that events in the network were happening too fast for a human in the loop. The most one could do was *manage* it. To capture that, by 1984 I had adopted the phrase, ?Monitor and Repair, but not Control.? I was giving a talk at Motorola cellular once and used that line. This was when Motorola had the entire UK cellular system. The old guys in the front row insisted *they* controlled *their* networks. Having heard this sort of thing before, I demurred. When a young engineer in the back of the room who had baby sat the UK system for 3 years, piped up and said he thought he knew what I meant. He related an incident in the UK where the number of switch crashes dropped off precipitously for 6 weeks and then came back up. They couldn?t figure it out. They hadn?t made any configuration changes, changed anything. Then they realized it was the 6 weeks the operators had been on strike! ;-) The network did much better when the operators weren?t trying to control it! ;-) Most of the time, the network would do better on its own than with operator help. The UDP argument would seem to belong more in the old model of network control. If things have gotten so bad that the UDP argument might be useful, the battle has already been lost. Something, probably a lot of something, wasn?t done earlier. The network is critical to the business, whether it is data, electricity, pipeline, water, etc. (They are remarkably similar.) As much uncertainty as possible needs to driven out of the task as possible and contingencies for that that can't. Network Management has to be one of the most boring tasks in networking. ;-) All in all, it is nice to understand the argument, but I don?t buy it. Reliable transport for request/responses, and connectionless for the event stream. Thanks again, John > On Apr 2, 2022, at 15:05, Craig Partridge wrote: > > Hi John: > > The answer at the time ran as follows. X number of datagrams are sent from the monitored station to the monitoring center (let's say X is 4) and all but one are discarded in the routers due to congestion loss. > > In UDP, 1 datagram gets through -- one hopes with useful data -- in a timely way. > > In TCP, unless the 1 datagram that gets through is the first datagram, you get nothing until the missing datagrams arrive to move the window forward. So you get substantially delayed or not data, as in many cases in the 1980s, the connection would instead fail. > > Craig > > On Sat, Apr 2, 2022 at 11:26 AM John Day via Internet-history > wrote: > Please explain how UDP packets are less susceptible to congestion than TCP packets? I would really like to know. > > > > > On Apr 2, 2022, at 12:41, Greg Skinner > wrote: > > > > > >> On Mar 28, 2022, at 11:19 AM, John Day >> wrote: > >> > >> Just to add to the comments, > >> > >>> On Mar 28, 2022, at 12:48, Craig Partridge via Internet-history >> wrote: > >>> > >>> The UDP vs. TCP debate was pretty fierce and the experience of the time > >>> came down firmly on the UDP side. Recall this was the era of daily > >>> congestion collapse of the Internet between 1987 and 1990. > >> > >> Somehow this argument (which I know was intense at the time) is the most absurd. All of the functions in TCP that are relevant are feedback functions that only involve the source and destination. In between, the handling of UDP and TCP packets by the routers is the same. If anything, TCP packets with congestion control have a better chance of being received and a TCP solution would have required fewer packets be generated in the first place. (The last thing a management system should be doing when things go bad is generating lots of traffic, but SNMP was good at that.) > > > > No argument from me about management systems generating too much traffic. However, regarding congestion control, around 1987, mitigation was underway, but solutions that were widely deployed in TCP/IP implementations were still a few years off. That helped make UDP more attractive, at least in the short term. > > > > [?] > > > >>> There was a network management project in the late 1980s, name now eludes > >>> me but led by Jil Wescott and DARPA funded, that sound similar in goals to > >>> what Jack H. describes doing at Oracle. I leaned on wisdom from those > >>> folks (esp. the late Charlie Lynn) as Glenn Trewitt and I sought to figure > >>> out what HEMS should look like. > > > > Right. From the tcp-ip mailing list and Usenet newsgroup, January 1987: > > > > ?? > > > > Date: Tue, 20-Jan-87 12:12:04 EST > > From: leiner at ICARUS.RIACS.EDU > > > To: mod.protocols.tcp-ip > > Subject: Re: Gateway Monitoring > > > > Craig, > > > > As you probably are aware, there has been quite a bit of work done > > already in "monitoring". In fact, Jil Westcott at BBN has been doing > > some work in automated network monitoring related to ADDCOMPE and packet > > radio networks. There have also been several proposals for "monitoring > > protocols". > > > > I'm happy to see you working in this area. It is clearly critical for > > large internets like NSFnet and the evolving national research internet. > > Hopefully, with this new push, a "standard approach" can be developed. > > > > Barry > > > > ?? > > > > BTW, interested readers can see discussions on this and related topics at the ban.ai TCP/IP mailing list archive >. (You may get a message indicating SSL certificates have expired.) > > > > ?gregbo > > > > > > -- > 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 bpurvy at gmail.com Sat Apr 2 19:00:13 2022 From: bpurvy at gmail.com (Bob Purvy) Date: Sat, 2 Apr 2022 19:00:13 -0700 Subject: [ih] GOSIP & compliance In-Reply-To: <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> Message-ID: Didn't you mean to say "the *powerful* GetNext" ? ? I lost my copy of *The Simple Book*, somehow. On Sat, Apr 2, 2022 at 6:19 PM John Day via Internet-history < internet-history at elists.isoc.org> wrote: > Thanks, > > I can see that it is an argument for it. Pretty weak in my estimation, but > it seems to misunderstand the problem. > Given that was at the height of the silly ?everything has to be > connectionless? fad, I am sure that had a lot to do with it too. With the > overhead of BER that didn?t leave a lot of room for much useful in the > packet. > > So you send a flurry of UDP packets and some get through and you hope that > the ones that do are useful. Doesn?t sound great. Now if this flurry is > commands to agents, the likelihood of random commands arriving in some > order sounds more dangerous than useful. It could easily make a bad > situation worse. If they are responses, then the manager is getting bits > and pieces of information (and small ones at that) and trying to assemble > some sort of picture of what is going on. > > GetNext was a pretty lame excuse for being able to retrieve a large > structure in one operation. Sure it generated more than 2 packets but > considerably less than GetNext would require and the Get/Read would be a > snapshot, where with GetNext the information could change out from under > you. > > Let me tell a story: > In the 70s and early 80s, this was called network control. Starting with > the ARPANET, I was always a firm believer that management was more > appropriate, that events in the network were happening too fast for a human > in the loop. The most one could do was *manage* it. To capture that, by > 1984 I had adopted the phrase, ?Monitor and Repair, but not Control.? > > I was giving a talk at Motorola cellular once and used that line. This was > when Motorola had the entire UK cellular system. The old guys in the front > row insisted *they* controlled *their* networks. Having heard this sort of > thing before, I demurred. When a young engineer in the back of the room who > had baby sat the UK system for 3 years, piped up and said he thought he > knew what I meant. He related an incident in the UK where the number of > switch crashes dropped off precipitously for 6 weeks and then came back up. > They couldn?t figure it out. They hadn?t made any configuration changes, > changed anything. Then they realized it was the 6 weeks the operators had > been on strike! ;-) The network did much better when the operators weren?t > trying to control it! ;-) Most of the time, the network would do better > on its own than with operator help. > > The UDP argument would seem to belong more in the old model of network > control. If things have gotten so bad that the UDP argument might be > useful, the battle has already been lost. Something, probably a lot of > something, wasn?t done earlier. > > The network is critical to the business, whether it is data, electricity, > pipeline, water, etc. (They are remarkably similar.) As much uncertainty as > possible needs to driven out of the task as possible and contingencies for > that that can't. Network Management has to be one of the most boring tasks > in networking. ;-) > > All in all, it is nice to understand the argument, but I don?t buy it. > Reliable transport for request/responses, and connectionless for the event > stream. > > Thanks again, > John > > > > On Apr 2, 2022, at 15:05, Craig Partridge wrote: > > > > Hi John: > > > > The answer at the time ran as follows. X number of datagrams are sent > from the monitored station to the monitoring center (let's say X is 4) and > all but one are discarded in the routers due to congestion loss. > > > > In UDP, 1 datagram gets through -- one hopes with useful data -- in a > timely way. > > > > In TCP, unless the 1 datagram that gets through is the first datagram, > you get nothing until the missing datagrams arrive to move the window > forward. So you get substantially delayed or not data, as in many cases in > the 1980s, the connection would instead fail. > > > > Craig > > > > On Sat, Apr 2, 2022 at 11:26 AM John Day via Internet-history < > internet-history at elists.isoc.org > > wrote: > > Please explain how UDP packets are less susceptible to congestion than > TCP packets? I would really like to know. > > > > > > > > > On Apr 2, 2022, at 12:41, Greg Skinner > wrote: > > > > > > > > >> On Mar 28, 2022, at 11:19 AM, John Day jeanjour at comcast.net> jeanjour at comcast.net>>> wrote: > > >> > > >> Just to add to the comments, > > >> > > >>> On Mar 28, 2022, at 12:48, Craig Partridge via Internet-history > < > http://elists.isoc.org/ >> wrote: > > >>> > > >>> The UDP vs. TCP debate was pretty fierce and the experience of the > time > > >>> came down firmly on the UDP side. Recall this was the era of daily > > >>> congestion collapse of the Internet between 1987 and 1990. > > >> > > >> Somehow this argument (which I know was intense at the time) is the > most absurd. All of the functions in TCP that are relevant are feedback > functions that only involve the source and destination. In between, the > handling of UDP and TCP packets by the routers is the same. If anything, > TCP packets with congestion control have a better chance of being received > and a TCP solution would have required fewer packets be generated in the > first place. (The last thing a management system should be doing when > things go bad is generating lots of traffic, but SNMP was good at that.) > > > > > > No argument from me about management systems generating too much > traffic. However, regarding congestion control, around 1987, mitigation > was underway, but solutions that were widely deployed in TCP/IP > implementations were still a few years off. That helped make UDP more > attractive, at least in the short term. > > > > > > [?] > > > > > >>> There was a network management project in the late 1980s, name now > eludes > > >>> me but led by Jil Wescott and DARPA funded, that sound similar in > goals to > > >>> what Jack H. describes doing at Oracle. I leaned on wisdom from > those > > >>> folks (esp. the late Charlie Lynn) as Glenn Trewitt and I sought to > figure > > >>> out what HEMS should look like. > > > > > > Right. From the tcp-ip mailing list and Usenet newsgroup, January > 1987: > > > > > > ?? > > > > > > Date: Tue, 20-Jan-87 12:12:04 EST > > > From: leiner at ICARUS.RIACS.EDU > > > > > To: mod.protocols.tcp-ip > > > Subject: Re: Gateway Monitoring > > > > > > Craig, > > > > > > As you probably are aware, there has been quite a bit of work done > > > already in "monitoring". In fact, Jil Westcott at BBN has been doing > > > some work in automated network monitoring related to ADDCOMPE and > packet > > > radio networks. There have also been several proposals for "monitoring > > > protocols". > > > > > > I'm happy to see you working in this area. It is clearly critical for > > > large internets like NSFnet and the evolving national research > internet. > > > Hopefully, with this new push, a "standard approach" can be developed. > > > > > > Barry > > > > > > ?? > > > > > > BTW, interested readers can see discussions on this and related topics > at the ban.ai TCP/IP mailing list archive < > https://ban.ai/multics/non-multics-docs/tcpip-digest/sd-archive/archive/ < > https://ban.ai/multics/non-multics-docs/tcpip-digest/sd-archive/archive/>>. > (You may get a message indicating SSL certificates have expired.) > > > > > > ?gregbo > > > > > > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org Internet-history at elists.isoc.org> > > https://elists.isoc.org/mailman/listinfo/internet-history < > 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 Sun Apr 3 12:20:00 2022 From: jack at 3kitty.org (Jack Haverty) Date: Sun, 3 Apr 2022 12:20:00 -0700 Subject: [ih] GOSIP & compliance In-Reply-To: <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> Message-ID: <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> On 4/2/22 18:19, John Day via Internet-history wrote: > So you send a flurry of UDP packets and some get through and you hope that the ones that do are useful. Doesn?t sound great. Very true.?? But IMHO it was more complex than that, if you look at the overall *system* architecture - which unfortunately may have never been written down except maybe as fragments in notes from various meetings in the early 80s.?? Here's some that I remember.... UDP defined a "datagram mode" somewhat analogous to the ARPANET's "uncontrolled packets" ("type 3" IIRC).? The ARPANET operators at BBN were staunchly opposed to allowing such packets to be used, for fear that they would seriously disrupt the normal "virtual circuit" mechanisms internal to the ARPANET structure.? So "datagrams" on the ARPANET, while possible, were only rarely permitted, for specific experiments, between specific Hosts. At one point in the early gateway development, I remember trying to get permission to have the gateways use type 3 packets on the ARPANET.?? IIRC that was never approved.?? The risk of causing serious degradation to other users was too high I guess. Thinking about the whole system of the Internet, UDP packets were prime candidates for different handling by the mesh of gateways that might carry them.? In particular, we anticipated that there would be one or more additional "Types Of Service" that could be selected, and that such different Types Of Service would be treated quite differently by the gateways and routing mechanisms. So, for example, the TTL field in the IP headers, i.e, Time-To-Live, was expected to evolve into an actual metric of Time, rather than Hops -- once the appropriate hardware was in place.?? Then the gateways would, somehow, be able to detect that a particular datagram wouldn't likely get to its destination before its TTL expired.? Such a datagram could therefore be discarded as soon as that death sentence was noticed, rather than waiting for it to actually travel through the network and get discarded only when its TTL reached zero.?? We expected that a lot of datagrams would get discarded at the gateways where a megabit-level LAN connected to the kilobit-level ARPANET. Other "system" aspects might involve routing.? E.g., perhaps there are multiple possible paths through the network, one with low latency but also low bandwidth, and another with high latency but high bandwidth.?? That situation existed in the early 80s when the US was covered coast-to-coast by both the ARPANET (low latency, tens-of-kilobits bandwidth) and the WidebandNet (satellite latency but high bandwidth).? Clever routing decisions could send packets by different paths, depending on what they needed. Decisions on how to best use the network resources at the moment, to satisfy the users' needs, at the moment, probably couldn't be made by humans.?? That was where "Automated Network Management" would play a role, developing mechanisms and associated protocols for having computers make such decisions, adapting to conditions in the network as they changed. Since this email thread still mentions "compliance" I'll add one other piece of the system.? Sometime in the early 80s, IIRC, the National Bureau of Standards (now NIST), created a set of conformance tests for verifying that a TCP implementation actually conformed to the TCP specification.? They also created a process by which independent labs could be certified as Testers, authorized to perform the tests and provide certificates of compliance to the applicants.? Such a certificate was mandatory in procurements; if you didn't have a certificate, the government would not be allowed to buy your product.? This was a placeholder for some mechanisms that assured that the technology defined by specifications was actually what was deployed in the field. That piece of the system, like many others, was really just a placeholder for an important component that would evolve over time.?? There were many others.?? The TTL "time" being implemented as "hops" is one example.?? The "Source Quench" mechanism, where a gateway would notify a sender that it had dropped one of that sender's datagrams, was another.?? It was a placeholder for whatever kind of information would have to flow between the network switches and the network users (TCPs or even applications in Hosts) in order to implement mechanisms such as Congestion Control.? TOS (Type-of-Service) bits in the IP header were put in place, but the Services they might select were to be determined. IIRC, no one thought that these placeholder mechanisms were well-defined, or even that they would work.?? There was much to still be figured out, and the placeholders replaced with real mechanisms once somebody figured out what they should be. The expectation was that two newly formed groups would work together to define and deploy the next generation of TCP/UDP/IP over the next few years.?? The IRTF would focus the Research efforts, to perform experiments, analyze results, and figure out what mechanisms and algorithms would solve the issues involving the placeholders.?? The IETF would take the results of that research and instantiate it into actual protocols, formats, message structures, and network services, and deploy and refine them into the operational Internet, That would include such issues as how to modify an existing operational system to change its underlying mechanisms from Version X to Version X+1. Being able to define and deploy next generation mechanisms was an important requirement of the overall Internet system. So, for UDP, we didn't believe at the time that UDP datagrams would be any less dangerous in the Internet as they had been in the ARPANET.? But we (at leat I) believed that such problems would arise only when the network approached the limits of its resources. Putting in more and faster circuits, and more powerful switching hardware, to keep ahead of the user traffic demands would keep the network operating well, while the various "placeholder" issues were worked out and the new algorithms and protocols were deployed. Part of the History of the Internet would capture how the technology and implementations has actually evolved over the ensuing 40 years. It might explain how we got to today's problems such as "buffer bloat", as a consequence of pouring more and more memory into the system to keep ahead of the demand curve. Jack Haverty The expectation was that From amckenzie3 at yahoo.com Sun Apr 3 12:50:46 2022 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Sun, 3 Apr 2022 19:50:46 +0000 (UTC) Subject: [ih] Monitoring, Operating, Controlling ... In-Reply-To: <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> Message-ID: <1021098516.710017.1649015446673@mail.yahoo.com> Indeed, a better name for the ARPAnet center at BBN would have been the Network Monitoring Center.? We didn't pick that name because the acronym NMC was already taken by the Network Measurement Center at UCLA.? Eventually we switched to the name Network Operations Center which I think better described the function. Cheers,Alex On Saturday, April 2, 2022, 09:19:57 PM EDT, John Day via Internet-history wrote: Thanks, I can see that it is an argument for it. Pretty weak in my estimation, but it seems to misunderstand the problem. Given that was at the height of the silly ?everything has to be connectionless? fad, I am sure that had a lot to do with it too. With the overhead of BER that didn?t leave a lot of room for much useful in the packet. So you send a flurry of UDP packets and some get through and you hope that the ones that do are useful.? Doesn?t sound great. Now if this flurry is commands to agents, the likelihood of random commands arriving in some order sounds more dangerous than useful. It could easily make a bad situation worse. If they are responses, then the manager is getting bits and pieces of information (and small ones at that) and trying to assemble some sort of picture of what is going on. GetNext was a pretty lame excuse for being able to retrieve a large structure in one operation. Sure it generated more than 2 packets but considerably less than GetNext would require and the Get/Read would be a snapshot, where with GetNext the information could change out from under you. Let me tell a story: In the 70s and early 80s, this was called network control. Starting with the ARPANET, I was always a firm believer that management was more appropriate, that events in the network were happening too fast for a human in the loop. The most one could do was *manage* it. To capture that, by 1984 I had adopted the phrase, ?Monitor and Repair, but not Control.? I was giving a talk at Motorola cellular once and used that line. This was when Motorola had the entire UK cellular system. The old guys in the front row insisted *they* controlled *their* networks. Having heard this sort of thing before, I demurred. When a young engineer in the back of the room who had baby sat the UK system for 3 years, piped up and said he thought he knew what I meant. He related an incident in the UK where the number of switch crashes dropped off precipitously for 6 weeks and then came back up. They couldn?t figure it out. They hadn?t made any configuration changes, changed anything. Then they realized it was the 6 weeks the operators had been on strike! ;-) The network did much better when the operators weren?t trying to control it!? ;-)? Most of the time, the network would do better on its own than with operator help. The UDP argument would seem to belong more in the old model of network control.? If things have gotten so bad that the UDP argument might be useful, the battle has already been lost. Something, probably a lot of something, wasn?t done earlier. The network is critical to the business, whether it is data, electricity, pipeline, water, etc. (They are remarkably similar.) As much uncertainty as possible needs to driven out of the task as possible and contingencies for that that can't. Network Management has to be one of the most boring tasks in networking. ;-) All in all, it is nice to understand the argument, but I don?t buy it. Reliable transport for request/responses, and connectionless for the event stream. Thanks again, John > On Apr 2, 2022, at 15:05, Craig Partridge wrote: > > Hi John: > > The answer at the time ran as follows.? X number of datagrams are sent from the monitored station to the monitoring center (let's say X is 4) and all but one are discarded in the routers due to congestion loss. > > In UDP, 1 datagram gets through -- one hopes with useful data -- in a timely way. > > In TCP, unless the 1 datagram that gets through is the first datagram, you get nothing until the missing datagrams arrive to move the window forward.? So you get substantially delayed or not data, as in many cases in the 1980s, the connection would instead fail. > > Craig > > On Sat, Apr 2, 2022 at 11:26 AM John Day via Internet-history > wrote: > Please explain how UDP packets are less susceptible to congestion than TCP packets?? I would really like to know. > > > > > On Apr 2, 2022, at 12:41, Greg Skinner > wrote: > > > > > >> On Mar 28, 2022, at 11:19 AM, John Day >> wrote: > >> > >> Just to add to the comments, > >> > >>> On Mar 28, 2022, at 12:48, Craig Partridge via Internet-history >> wrote: > >>> > >>> The UDP vs. TCP debate was pretty fierce and the experience of the time > >>> came down firmly on the UDP side. Recall this was the era of daily > >>> congestion collapse of the Internet between 1987 and 1990. > >> > >> Somehow this argument (which I know was intense at the time) is the most absurd. All of the functions in TCP that are relevant are feedback functions that only involve the source and destination. In between, the handling of UDP and TCP packets by the routers is the same. If anything, TCP packets with congestion control have a better chance of being received and a TCP solution would have required fewer packets be generated in the first place. (The last thing a management system should be doing when things go bad is generating lots of traffic, but SNMP was good at that.) > > > > No argument from me about management systems generating too much traffic.? However, regarding congestion control, around 1987, mitigation was underway, but solutions that were widely deployed in TCP/IP implementations were still a few years off.? That helped make UDP more attractive, at least in the short term. > > > > [?] > > > >>> There was a network management project in the late 1980s, name now eludes > >>> me but led by Jil Wescott and DARPA funded, that sound similar in goals to > >>> what Jack H. describes doing at Oracle.? I leaned on wisdom from those > >>> folks (esp. the late Charlie Lynn) as Glenn Trewitt and I sought to figure > >>> out what HEMS should look like. > > > > Right.? From the tcp-ip mailing list and Usenet newsgroup, January 1987: > > > > ?? > > > > Date:? ? ? Tue, 20-Jan-87 12:12:04 EST > > From:? ? ? leiner at ICARUS.RIACS.EDU > > > To:? ? ? ? mod.protocols.tcp-ip > > Subject:? Re: Gateway Monitoring > > > > Craig, > > > > As you probably are aware, there has been quite a bit of work done > > already in "monitoring".? In fact, Jil Westcott at BBN has been doing > > some work in automated network monitoring related to ADDCOMPE and packet > > radio networks.? There have also been several proposals for "monitoring > > protocols". > > > > I'm happy to see you working in this area.? It is clearly critical for > > large internets like NSFnet and the evolving national research internet. > > Hopefully, with this new push, a "standard approach" can be developed. > > > > Barry > > > > ?? > > > > BTW, interested readers can see discussions on this and related topics at the ban.ai TCP/IP mailing list archive >.? (You may get a message indicating SSL certificates have expired.) > > > > ?gregbo > > > > > > -- > 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 geoff at iconia.com Sun Apr 3 15:03:53 2022 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 3 Apr 2022 12:03:53 -1000 Subject: [ih] Monitoring, Operating, Controlling ... In-Reply-To: <1021098516.710017.1649015446673@mail.yahoo.com> References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <1021098516.710017.1649015446673@mail.yahoo.com> Message-ID: beggin' your pardon Alex, but IIRC, the ARPANET was managed by what was called Network Control Center (NCC) not Network Operations Center (NOC), viz.: https://www.rfc-editor.org/rfc/rfc356.txt https://www.beylebooks.com/read/the-arpanet-network-control-center-program with a host named BBN-NCC, viz.: http://www.faqs.org/rfcs/rfc289.html in addition to there also being the NCC-TIP, viz.: https://www.rfc-editor.org/rfc/rfc619.html geoff On Sun, Apr 3, 2022 at 9:51 AM Alex McKenzie via Internet-history < internet-history at elists.isoc.org> wrote: > Indeed, a better name for the ARPAnet center at BBN would have been the > Network Monitoring Center. We didn't pick that name because the acronym > NMC was already taken by the Network Measurement Center at UCLA. > Eventually we switched to the name Network Operations Center which I think > better described the function. > Cheers,Alex > > On Saturday, April 2, 2022, 09:19:57 PM EDT, John Day via > Internet-history wrote: > > Thanks, > > I can see that it is an argument for it. Pretty weak in my estimation, but > it seems to misunderstand the problem. > Given that was at the height of the silly ?everything has to be > connectionless? fad, I am sure that had a lot to do with it too. With the > overhead of BER that didn?t leave a lot of room for much useful in the > packet. > > So you send a flurry of UDP packets and some get through and you hope that > the ones that do are useful. Doesn?t sound great. Now if this flurry is > commands to agents, the likelihood of random commands arriving in some > order sounds more dangerous than useful. It could easily make a bad > situation worse. If they are responses, then the manager is getting bits > and pieces of information (and small ones at that) and trying to assemble > some sort of picture of what is going on. > > GetNext was a pretty lame excuse for being able to retrieve a large > structure in one operation. Sure it generated more than 2 packets but > considerably less than GetNext would require and the Get/Read would be a > snapshot, where with GetNext the information could change out from under > you. > > Let me tell a story: > In the 70s and early 80s, this was called network control. Starting with > the ARPANET, I was always a firm believer that management was more > appropriate, that events in the network were happening too fast for a human > in the loop. The most one could do was *manage* it. To capture that, by > 1984 I had adopted the phrase, ?Monitor and Repair, but not Control.? > > I was giving a talk at Motorola cellular once and used that line. This was > when Motorola had the entire UK cellular system. The old guys in the front > row insisted *they* controlled *their* networks. Having heard this sort of > thing before, I demurred. When a young engineer in the back of the room who > had baby sat the UK system for 3 years, piped up and said he thought he > knew what I meant. He related an incident in the UK where the number of > switch crashes dropped off precipitously for 6 weeks and then came back up. > They couldn?t figure it out. They hadn?t made any configuration changes, > changed anything. Then they realized it was the 6 weeks the operators had > been on strike! ;-) The network did much better when the operators weren?t > trying to control it! ;-) Most of the time, the network would do better > on its own than with operator help. > > The UDP argument would seem to belong more in the old model of network > control. If things have gotten so bad that the UDP argument might be > useful, the battle has already been lost. Something, probably a lot of > something, wasn?t done earlier. > > The network is critical to the business, whether it is data, electricity, > pipeline, water, etc. (They are remarkably similar.) As much uncertainty as > possible needs to driven out of the task as possible and contingencies for > that that can't. Network Management has to be one of the most boring tasks > in networking. ;-) > > All in all, it is nice to understand the argument, but I don?t buy it. > Reliable transport for request/responses, and connectionless for the event > stream. > > Thanks again, > John > > > > On Apr 2, 2022, at 15:05, Craig Partridge wrote: > > > > Hi John: > > > > The answer at the time ran as follows. X number of datagrams are sent > from the monitored station to the monitoring center (let's say X is 4) and > all but one are discarded in the routers due to congestion loss. > > > > In UDP, 1 datagram gets through -- one hopes with useful data -- in a > timely way. > > > > In TCP, unless the 1 datagram that gets through is the first datagram, > you get nothing until the missing datagrams arrive to move the window > forward. So you get substantially delayed or not data, as in many cases in > the 1980s, the connection would instead fail. > > > > Craig > > > > On Sat, Apr 2, 2022 at 11:26 AM John Day via Internet-history < > internet-history at elists.isoc.org > > wrote: > > Please explain how UDP packets are less susceptible to congestion than > TCP packets? I would really like to know. > > > > > > > > > On Apr 2, 2022, at 12:41, Greg Skinner > wrote: > > > > > > > > >> On Mar 28, 2022, at 11:19 AM, John Day jeanjour at comcast.net> jeanjour at comcast.net>>> wrote: > > >> > > >> Just to add to the comments, > > >> > > >>> On Mar 28, 2022, at 12:48, Craig Partridge via Internet-history > < > http://elists.isoc.org/ >> wrote: > > >>> > > >>> The UDP vs. TCP debate was pretty fierce and the experience of the > time > > >>> came down firmly on the UDP side. Recall this was the era of daily > > >>> congestion collapse of the Internet between 1987 and 1990. > > >> > > >> Somehow this argument (which I know was intense at the time) is the > most absurd. All of the functions in TCP that are relevant are feedback > functions that only involve the source and destination. In between, the > handling of UDP and TCP packets by the routers is the same. If anything, > TCP packets with congestion control have a better chance of being received > and a TCP solution would have required fewer packets be generated in the > first place. (The last thing a management system should be doing when > things go bad is generating lots of traffic, but SNMP was good at that.) > > > > > > No argument from me about management systems generating too much > traffic. However, regarding congestion control, around 1987, mitigation > was underway, but solutions that were widely deployed in TCP/IP > implementations were still a few years off. That helped make UDP more > attractive, at least in the short term. > > > > > > [?] > > > > > >>> There was a network management project in the late 1980s, name now > eludes > > >>> me but led by Jil Wescott and DARPA funded, that sound similar in > goals to > > >>> what Jack H. describes doing at Oracle. I leaned on wisdom from > those > > >>> folks (esp. the late Charlie Lynn) as Glenn Trewitt and I sought to > figure > > >>> out what HEMS should look like. > > > > > > Right. From the tcp-ip mailing list and Usenet newsgroup, January > 1987: > > > > > > ?? > > > > > > Date: Tue, 20-Jan-87 12:12:04 EST > > > From: leiner at ICARUS.RIACS.EDU > > > > > To: mod.protocols.tcp-ip > > > Subject: Re: Gateway Monitoring > > > > > > Craig, > > > > > > As you probably are aware, there has been quite a bit of work done > > > already in "monitoring". In fact, Jil Westcott at BBN has been doing > > > some work in automated network monitoring related to ADDCOMPE and > packet > > > radio networks. There have also been several proposals for "monitoring > > > protocols". > > > > > > I'm happy to see you working in this area. It is clearly critical for > > > large internets like NSFnet and the evolving national research > internet. > > > Hopefully, with this new push, a "standard approach" can be developed. > > > > > > Barry > > > > > > ?? > > > > > > BTW, interested readers can see discussions on this and related topics > at the ban.ai TCP/IP mailing list archive < > https://ban.ai/multics/non-multics-docs/tcpip-digest/sd-archive/archive/ < > https://ban.ai/multics/non-multics-docs/tcpip-digest/sd-archive/archive/>>. > (You may get a message indicating SSL certificates have expired.) > > > > > > ?gregbo > > > > > > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org Internet-history at elists.isoc.org> > > https://elists.isoc.org/mailman/listinfo/internet-history < > 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 > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From mfidelman at meetinghouse.net Sun Apr 3 15:15:05 2022 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 3 Apr 2022 18:15:05 -0400 Subject: [ih] Monitoring, Operating, Controlling ... In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <1021098516.710017.1649015446673@mail.yahoo.com> Message-ID: <4eb6117c-7b54-e9fd-7493-d78e9c533371@meetinghouse.net> the keyboard of geoff goodfellow via Internet-history wrote: > beggin' your pardon Alex, but IIRC, the ARPANET was > managed by what was called Network Control Center (NCC) > not Network Operations Center (NOC), viz.: > https://www.rfc-editor.org/rfc/rfc356.txt > https://www.beylebooks.com/read/the-arpanet-network-control-center-program > with a host named BBN-NCC, viz.: > http://www.faqs.org/rfcs/rfc289.html > in addition to there also being the NCC-TIP, viz.: > https://www.rfc-editor.org/rfc/rfc619.html > > geoff > > On Sun, Apr 3, 2022 at 9:51 AM Alex McKenzie via Internet-history < > internet-history at elists.isoc.org> wrote: > >> Indeed, a better name for the ARPAnet center at BBN would have been the >> Network Monitoring Center. We didn't pick that name because the acronym >> NMC was already taken by the Network Measurement Center at UCLA. >> Eventually we switched to the name Network Operations Center which I think >> better described the function. >> Cheers,Alex >> >> On Saturday, April 2, 2022, 09:19:57 PM EDT, John Day via >> Internet-history wrote: >> >> Thanks, >> >> I can see that it is an argument for it. Pretty weak in my estimation, but >> it seems to misunderstand the problem. >> Given that was at the height of the silly ?everything has to be >> connectionless? fad, I am sure that had a lot to do with it too. With the >> overhead of BER that didn?t leave a lot of room for much useful in the >> packet. >> >> So you send a flurry of UDP packets and some get through and you hope that >> the ones that do are useful. Doesn?t sound great. Now if this flurry is >> commands to agents, the likelihood of random commands arriving in some >> order sounds more dangerous than useful. It could easily make a bad >> situation worse. If they are responses, then the manager is getting bits >> and pieces of information (and small ones at that) and trying to assemble >> some sort of picture of what is going on. >> >> GetNext was a pretty lame excuse for being able to retrieve a large >> structure in one operation. Sure it generated more than 2 packets but >> considerably less than GetNext would require and the Get/Read would be a >> snapshot, where with GetNext the information could change out from under >> you. >> >> Let me tell a story: >> In the 70s and early 80s, this was called network control. Starting with >> the ARPANET, I was always a firm believer that management was more >> appropriate, that events in the network were happening too fast for a human >> in the loop. The most one could do was *manage* it. To capture that, by >> 1984 I had adopted the phrase, ?Monitor and Repair, but not Control.? >> >> Interesting use of words.? In the military, Command & Control is usually NOT considered real-time, while "Battle Management" is the term of art for the real-time activity.? (Unless things have changed recently.) When it comes to the ARPANET, and the DDN - "monitor & repair" was very much the operating model for the NOCs.? At the same time, "control" took the form of performance tuning and other such not-quite-real-time configuration activities. 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 casner at acm.org Sun Apr 3 22:58:10 2022 From: casner at acm.org (Stephen Casner) Date: Sun, 3 Apr 2022 22:58:10 -0700 (PDT) Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: On Sun, 3 Apr 2022, Jack Haverty via Internet-history wrote: > UDP defined a "datagram mode" somewhat analogous to the ARPANET's > "uncontrolled packets" ("type 3" IIRC). The ARPANET operators at BBN were > staunchly opposed to allowing such packets to be used, for fear that they > would seriously disrupt the normal "virtual circuit" mechanisms internal to > the ARPANET structure. So "datagrams" on the ARPANET, while possible, were > only rarely permitted, for specific experiments, between specific Hosts. I have often seen/heard the ARPANET uncontrolled packets referenced as "type 3", e.g. by our late Danny Cohen. But they were actually "type 0, subtype 3". I remember implementing that for packet voice. Check BBN 1822 pp. 3-14 and 3-35. -- Steve From vgcerf at gmail.com Mon Apr 4 02:33:56 2022 From: vgcerf at gmail.com (vinton cerf) Date: Mon, 4 Apr 2022 05:33:56 -0400 Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: thanks for that bit of precision, Steve! I am guilty of that "summary" too v On Mon, Apr 4, 2022 at 1:58 AM Stephen Casner via Internet-history < internet-history at elists.isoc.org> wrote: > On Sun, 3 Apr 2022, Jack Haverty via Internet-history wrote: > > > UDP defined a "datagram mode" somewhat analogous to the ARPANET's > > "uncontrolled packets" ("type 3" IIRC). The ARPANET operators at BBN > were > > staunchly opposed to allowing such packets to be used, for fear that they > > would seriously disrupt the normal "virtual circuit" mechanisms internal > to > > the ARPANET structure. So "datagrams" on the ARPANET, while possible, > were > > only rarely permitted, for specific experiments, between specific Hosts. > > I have often seen/heard the ARPANET uncontrolled packets referenced as > "type 3", e.g. by our late Danny Cohen. But they were actually "type > 0, subtype 3". I remember implementing that for packet voice. Check > BBN 1822 pp. 3-14 and 3-35. > > -- Steve > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From jack at 3kitty.org Mon Apr 4 09:27:43 2022 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 4 Apr 2022 09:27:43 -0700 Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: Guilty!? I've always found it difficult to get the correct terminology. Actually, thinking and remembering a bit more, to be even more precise those "type 0, subtype 3" globs of bits weren't "packets" either.?? They were "messages", passed back and forth between a Host and its attached IMP.?? The IMP carved those messages up and put the data into one or more "packets" which were what actually got sent over the wires.? Actually, there may have been more technical chicanery involved there, with things like "frames" in the mix.? At the final IMP in the path, all those "packets" were "reassembled" and the data delivered to the Host in "messages".?? But I don't recall if the receiving Host could tell that an incoming message was sent out as a type 0, subtype 3 from the transmitting Host. IIRC, it was the IMP-to-IMP packets which were uncontrolled, and handled outside the normal mechanisms of error control, flow control, congestion control, etc.? I don't think I ever knew exactly how all that worked -- but the old IMP code is available online should anyone be curious. Then of course if you looked more closely, you might see that the TCPs involved were sending and receiving data from their users' application programs.? At one point there were even "Letters" passing across that interface, which the TCP would carve up into "datagrams", which it might supply to an attached ARPANET port as "messages".? Somewhere down the path, a Gateway might receive a message, determin that it wouldn't fit into the next network, so it would carve up the datagram into "fragments", which were themselves smaller datagrams, leaving putting it all back together as a challenge for the TCP running in the Host at the ultimate destination. Complicating things even further, if the applications involved were transferring electronic mail, they would be also accepting "messages" from human users, carving them up into "letters" for TCP, which would carve them up into "datagrams", which might become a string of a different kind of "messages", which might become a gaggle of "packets", with "fragments" spontaneously appearing in the fray from time to time.?? The life of a bit in its travels through the Internet is crazy and frenetic.?? Ask any bit which has gotten discarded along the way and now lies in a bit bucket somewhere in the net. There just weren't enough words to precisely describe the carnage involved in computer networking...reminds me of those old late-night TV ads "It slices, it chops, it dices, it shreds!? Call this number to order your Acme Kitchen Wizard!? Call now and get two for the price of one!" Jack Haverty On 4/3/22 22:58, Stephen Casner wrote: > On Sun, 3 Apr 2022, Jack Haverty via Internet-history wrote: > >> UDP defined a "datagram mode" somewhat analogous to the ARPANET's >> "uncontrolled packets" ("type 3" IIRC). The ARPANET operators at BBN were >> staunchly opposed to allowing such packets to be used, for fear that they >> would seriously disrupt the normal "virtual circuit" mechanisms internal to >> the ARPANET structure. So "datagrams" on the ARPANET, while possible, were >> only rarely permitted, for specific experiments, between specific Hosts. > I have often seen/heard the ARPANET uncontrolled packets referenced as > "type 3", e.g. by our late Danny Cohen. But they were actually "type > 0, subtype 3". I remember implementing that for packet voice. Check > BBN 1822 pp. 3-14 and 3-35. > > -- Steve From tte at cs.fau.de Mon Apr 4 09:42:26 2022 From: tte at cs.fau.de (Toerless Eckert) Date: Mon, 4 Apr 2022 18:42:26 +0200 Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: References: <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: On Mon, Apr 04, 2022 at 09:27:43AM -0700, Jack Haverty via Internet-history wrote: > There just weren't enough words to precisely describe the carnage involved > in computer networking...reminds me of those old late-night TV ads "It > slices, it chops, it dices, it shreds!? Call this number to order your Acme > Kitchen Wizard!? Call now and get two for the price of one!" Trying to parse... So we should send the Internet to Tom Dickson ? Or just TCP and QUIC ? https://www.youtube.com/watch?v=rofgMueCOqo Cheers Toerless Sorry! As they'd say in court, you opened the door wide open ;-) > Jack Haverty > > > > > On 4/3/22 22:58, Stephen Casner wrote: > > On Sun, 3 Apr 2022, Jack Haverty via Internet-history wrote: > > > > > UDP defined a "datagram mode" somewhat analogous to the ARPANET's > > > "uncontrolled packets" ("type 3" IIRC). The ARPANET operators at BBN were > > > staunchly opposed to allowing such packets to be used, for fear that they > > > would seriously disrupt the normal "virtual circuit" mechanisms internal to > > > the ARPANET structure. So "datagrams" on the ARPANET, while possible, were > > > only rarely permitted, for specific experiments, between specific Hosts. > > I have often seen/heard the ARPANET uncontrolled packets referenced as > > "type 3", e.g. by our late Danny Cohen. But they were actually "type > > 0, subtype 3". I remember implementing that for packet voice. Check > > BBN 1822 pp. 3-14 and 3-35. > > > > -- Steve > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history -- --- tte at cs.fau.de From vgcerf at gmail.com Mon Apr 4 09:43:50 2022 From: vgcerf at gmail.com (vinton cerf) Date: Mon, 4 Apr 2022 12:43:50 -0400 Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: i think the point about the type 0 subtype 3 is that they may not have been reassembled and might have had limits as to size (unlike the 8000 bit "message"). As I recall they were "uncontrolled" which means the space reservation protocol was not in force for them. Since these were used for voice (and maybe video), they might have been limited to single packet size (1000+ bits) and were not assured of delivery. Steve Casner, any more specifics? Copying Bob Kahn in case he is not on the internet-history list v On Mon, Apr 4, 2022 at 12:27 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > Guilty! I've always found it difficult to get the correct terminology. > > Actually, thinking and remembering a bit more, to be even more precise > those "type 0, subtype 3" globs of bits weren't "packets" either. They > were "messages", passed back and forth between a Host and its attached > IMP. The IMP carved those messages up and put the data into one or > more "packets" which were what actually got sent over the wires. > Actually, there may have been more technical chicanery involved there, > with things like "frames" in the mix. At the final IMP in the path, all > those "packets" were "reassembled" and the data delivered to the Host in > "messages". But I don't recall if the receiving Host could tell that > an incoming message was sent out as a type 0, subtype 3 from the > transmitting Host. > > IIRC, it was the IMP-to-IMP packets which were uncontrolled, and handled > outside the normal mechanisms of error control, flow control, congestion > control, etc. I don't think I ever knew exactly how all that worked -- > but the old IMP code is available online should anyone be curious. > > Then of course if you looked more closely, you might see that the TCPs > involved were sending and receiving data from their users' application > programs. At one point there were even "Letters" passing across that > interface, which the TCP would carve up into "datagrams", which it might > supply to an attached ARPANET port as "messages". Somewhere down the > path, a Gateway might receive a message, determin that it wouldn't fit > into the next network, so it would carve up the datagram into > "fragments", which were themselves smaller datagrams, leaving putting it > all back together as a challenge for the TCP running in the Host at the > ultimate destination. > > Complicating things even further, if the applications involved were > transferring electronic mail, they would be also accepting "messages" > from human users, carving them up into "letters" for TCP, which would > carve them up into "datagrams", which might become a string of a > different kind of "messages", which might become a gaggle of "packets", > with "fragments" spontaneously appearing in the fray from time to > time. The life of a bit in its travels through the Internet is crazy > and frenetic. Ask any bit which has gotten discarded along the way and > now lies in a bit bucket somewhere in the net. > > There just weren't enough words to precisely describe the carnage > involved in computer networking...reminds me of those old late-night TV > ads "It slices, it chops, it dices, it shreds! Call this number to > order your Acme Kitchen Wizard! Call now and get two for the price of > one!" > > Jack Haverty > > > > > On 4/3/22 22:58, Stephen Casner wrote: > > On Sun, 3 Apr 2022, Jack Haverty via Internet-history wrote: > > > >> UDP defined a "datagram mode" somewhat analogous to the ARPANET's > >> "uncontrolled packets" ("type 3" IIRC). The ARPANET operators at BBN > were > >> staunchly opposed to allowing such packets to be used, for fear that > they > >> would seriously disrupt the normal "virtual circuit" mechanisms > internal to > >> the ARPANET structure. So "datagrams" on the ARPANET, while possible, > were > >> only rarely permitted, for specific experiments, between specific Hosts. > > I have often seen/heard the ARPANET uncontrolled packets referenced as > > "type 3", e.g. by our late Danny Cohen. But they were actually "type > > 0, subtype 3". I remember implementing that for packet voice. Check > > BBN 1822 pp. 3-14 and 3-35. > > > > -- Steve > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From jack at 3kitty.org Mon Apr 4 10:16:37 2022 From: jack at 3kitty.org (Jack Haverty) Date: Mon, 4 Apr 2022 10:16:37 -0700 Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: I never got to actually use 0/3 messages, so my memory on how they behaved is fuzzy.? But IIRC they were also not subject to the normal IMP<->Host flow control mechanisms of RFNMs. Those mechanisms enabled the IMP to control the flow of data from a Host into the network, including the ultimate step of shutting off all data transfer from a Host at the 1822 hardware level by temporarily disabling the clock that regulated bit flow.? Just as effective as pulling the plug.? Perhaps Steve remembers, or someone could look at the old code to trace how it handled 0/3 messages. I suspect that avoidance of Host-IMP flow control was likely a major reason for the opposition to widespead use of 0/3 service, or any use that might evolve into widespread use later, such as to support voice.? If 0/3 permission enabled any host on the ARPANET to submit continuous flows of 0/3 data at Host-IMP line speed, that would probably have quickly caused problems that the NOC would have hads trouble diagnosing and fixing. It seems that maybe today's switches (routers) avoid such problems simply by putting lots of now-inexpensive memory into the system, with the unfortunate side-effect of "buffer bloat". Jack On 4/4/22 09:43, vinton cerf wrote: > i think the point about the type 0 subtype 3 is that they may not have > been reassembled and might have had limits as to size (unlike the 8000 > bit "message"). As I recall they were "uncontrolled" which means the > space reservation protocol was not in force for them. Since these were > used for voice (and maybe video), they might have been limited to > single packet size (1000+ bits) and were not assured of delivery. > > Steve Casner, any more specifics? Copying Bob Kahn in case he is not > on the internet-history list > > v > > > On Mon, Apr 4, 2022 at 12:27 PM Jack Haverty via Internet-history > wrote: > > Guilty! I've always found it difficult to get the correct terminology. > > Actually, thinking and remembering a bit more, to be even more > precise > those "type 0, subtype 3" globs of bits weren't "packets" > either.?? They > were "messages", passed back and forth between a Host and its > attached > IMP.?? The IMP carved those messages up and put the data into one or > more "packets" which were what actually got sent over the wires. > Actually, there may have been more technical chicanery involved > there, > with things like "frames" in the mix.? At the final IMP in the > path, all > those "packets" were "reassembled" and the data delivered to the > Host in > "messages".?? But I don't recall if the receiving Host could tell > that > an incoming message was sent out as a type 0, subtype 3 from the > transmitting Host. > > IIRC, it was the IMP-to-IMP packets which were uncontrolled, and > handled > outside the normal mechanisms of error control, flow control, > congestion > control, etc.? I don't think I ever knew exactly how all that > worked -- > but the old IMP code is available online should anyone be curious. > > Then of course if you looked more closely, you might see that the > TCPs > involved were sending and receiving data from their users' > application > programs.? At one point there were even "Letters" passing across that > interface, which the TCP would carve up into "datagrams", which it > might > supply to an attached ARPANET port as "messages".? Somewhere down the > path, a Gateway might receive a message, determin that it wouldn't > fit > into the next network, so it would carve up the datagram into > "fragments", which were themselves smaller datagrams, leaving > putting it > all back together as a challenge for the TCP running in the Host > at the > ultimate destination. > > Complicating things even further, if the applications involved were > transferring electronic mail, they would be also accepting "messages" > from human users, carving them up into "letters" for TCP, which would > carve them up into "datagrams", which might become a string of a > different kind of "messages", which might become a gaggle of > "packets", > with "fragments" spontaneously appearing in the fray from time to > time.?? The life of a bit in its travels through the Internet is > crazy > and frenetic.?? Ask any bit which has gotten discarded along the > way and > now lies in a bit bucket somewhere in the net. > > There just weren't enough words to precisely describe the carnage > involved in computer networking...reminds me of those old > late-night TV > ads "It slices, it chops, it dices, it shreds!? Call this number to > order your Acme Kitchen Wizard!? Call now and get two for the > price of one!" > > Jack Haverty > > > > > On 4/3/22 22:58, Stephen Casner wrote: > > On Sun, 3 Apr 2022, Jack Haverty via Internet-history wrote: > > > >> UDP defined a "datagram mode" somewhat analogous to the ARPANET's > >> "uncontrolled packets" ("type 3" IIRC).? The ARPANET operators > at BBN were > >> staunchly opposed to allowing such packets to be used, for fear > that they > >> would seriously disrupt the normal "virtual circuit" mechanisms > internal to > >> the ARPANET structure.? So "datagrams" on the ARPANET, while > possible, were > >> only rarely permitted, for specific experiments, between > specific Hosts. > > I have often seen/heard the ARPANET uncontrolled packets > referenced as > > "type 3", e.g. by our late Danny Cohen.? But they were actually > "type > > 0, subtype 3".? I remember implementing that for packet voice.? > Check > > BBN 1822 pp. 3-14 and 3-35. > > > > -- Steve > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From amckenzie3 at yahoo.com Mon Apr 4 12:40:38 2022 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Mon, 4 Apr 2022 19:40:38 +0000 (UTC) Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: <1194358522.929379.1649101238664@mail.yahoo.com> Jack and others, I'm a one finger typist so I'm not going to go into a lot of detail, but there are some misstatements in your message.1. 0/3 messages were restricted to a length which would fit in one IMP packet, so they were not fragmented and reassembled by the IMPs.2. 0/3 messages were not subject to end-end control by the IMP subnet, so in that sense they were not subject to error control, flow control, and congestion control as normal Host-Host messages were.3. All packets were subject to error control, flow control, and to some extent to congestion control between each pair of adjacent IMPs.? Error control was by hardware checksums, timeouts, and retransmissions.? Flow control was the limit of 8 "logical channels" over each IMP-IMP circuit.*? There could only be one outstanding (un-acked) packet on each logical channel. If there were more packets waiting they were queued.4. Congestion control of sorts was provided by the IMPs including queue length for a given outgoing line as part of the "distance" measurement in computing routes (this was not implemented in the IMPs until at least the mid-70s). I believe 0/3 packets were not placed on transmission queues if there was not an available "logical channel" for immediate transmission, but I could be wrong about that. * I believe there were additional logical channels provided for the USA-Norway and the California-Hawaii satellite links but perhaps this never got implemented. Cheers,Alex On Monday, April 4, 2022, 12:27:56 PM EDT, Jack Haverty via Internet-history wrote: Guilty!? I've always found it difficult to get the correct terminology. Actually, thinking and remembering a bit more, to be even more precise those "type 0, subtype 3" globs of bits weren't "packets" either.?? They were "messages", passed back and forth between a Host and its attached IMP.?? The IMP carved those messages up and put the data into one or more "packets" which were what actually got sent over the wires.? Actually, there may have been more technical chicanery involved there, with things like "frames" in the mix.? At the final IMP in the path, all those "packets" were "reassembled" and the data delivered to the Host in "messages".?? But I don't recall if the receiving Host could tell that an incoming message was sent out as a type 0, subtype 3 from the transmitting Host. IIRC, it was the IMP-to-IMP packets which were uncontrolled, and handled outside the normal mechanisms of error control, flow control, congestion control, etc.? I don't think I ever knew exactly how all that worked -- but the old IMP code is available online should anyone be curious. Then of course if you looked more closely, you might see that the TCPs involved were sending and receiving data from their users' application programs.? At one point there were even "Letters" passing across that interface, which the TCP would carve up into "datagrams", which it might supply to an attached ARPANET port as "messages".? Somewhere down the path, a Gateway might receive a message, determin that it wouldn't fit into the next network, so it would carve up the datagram into "fragments", which were themselves smaller datagrams, leaving putting it all back together as a challenge for the TCP running in the Host at the ultimate destination. Complicating things even further, if the applications involved were transferring electronic mail, they would be also accepting "messages" from human users, carving them up into "letters" for TCP, which would carve them up into "datagrams", which might become a string of a different kind of "messages", which might become a gaggle of "packets", with "fragments" spontaneously appearing in the fray from time to time.?? The life of a bit in its travels through the Internet is crazy and frenetic.?? Ask any bit which has gotten discarded along the way and now lies in a bit bucket somewhere in the net. There just weren't enough words to precisely describe the carnage involved in computer networking...reminds me of those old late-night TV ads "It slices, it chops, it dices, it shreds!? Call this number to order your Acme Kitchen Wizard!? Call now and get two for the price of one!" Jack Haverty On 4/3/22 22:58, Stephen Casner wrote: > On Sun, 3 Apr 2022, Jack Haverty via Internet-history wrote: > >> UDP defined a "datagram mode" somewhat analogous to the ARPANET's >> "uncontrolled packets" ("type 3" IIRC).? The ARPANET operators at BBN were >> staunchly opposed to allowing such packets to be used, for fear that they >> would seriously disrupt the normal "virtual circuit" mechanisms internal to >> the ARPANET structure.? So "datagrams" on the ARPANET, while possible, were >> only rarely permitted, for specific experiments, between specific Hosts. > I have often seen/heard the ARPANET uncontrolled packets referenced as > "type 3", e.g. by our late Danny Cohen.? But they were actually "type > 0, subtype 3".? I remember implementing that for packet voice.? Check > BBN 1822 pp. 3-14 and 3-35. > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- Steve -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From casner at acm.org Tue Apr 5 16:42:25 2022 From: casner at acm.org (Stephen Casner) Date: Tue, 5 Apr 2022 16:42:25 -0700 (PDT) Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: Answering Vint and Jack inline... On Mon, 4 Apr 2022, vinton cerf wrote: > i think the point about the type 0 subtype 3 is that they may not have been > reassembled and might have had limits as to size (unlike the 8000 bit > "message"). As I recall they were "uncontrolled" which means the space > reservation protocol was not in force for them. Since these were used for > voice (and maybe video), they might have been limited to single packet size > (1000+ bits) and were not assured of delivery. Correct, 1822 says the type 0 subtype 3 messages were limited to 991 data bits in addition to the 96-bit leader. Also there was no source-to-destination control of these messages (no retransmission, no RFNM, no error reports). For packet voice we did not want packets any larger because we wanted to limit the packetization delay. In the NTC 78 paper mentioned here recently we tested 5 to 18 50-bit LPC parcels per packet (250 to 900 bits). Each parcel encoded 10 ms of voice. No video during that era over ARPANET. Video came later on the Wideband Satellite Network. On Mon, 4 Apr 2022, Jack Haverty wrote: > I never got to actually use 0/3 messages, so my memory on how they behaved is > fuzzy. But IIRC they were also not subject to the normal IMP<->Host flow > control mechanisms of RFNMs. Those mechanisms enabled the IMP to control the > flow of data from a Host into the network, including the ultimate step of > shutting off all data transfer from a Host at the 1822 hardware level by > temporarily disabling the clock that regulated bit flow. Just as effective as > pulling the plug. Perhaps Steve remembers, or someone could look at the old > code to trace how it handled 0/3 messages. There was no specialization of the IMP<->Host interface for the type 0 subtype 3 messages. The bit-level transfer was the same. The IMP could discard the message as soon as it came in, so there would be no reason to delay transfer at the bit level > I suspect that avoidance of Host-IMP flow control was likely a major reason > for the opposition to widespead use of 0/3 service, or any use that might > evolve into widespread use later, such as to support voice. If 0/3 permission > enabled any host on the ARPANET to submit continuous flows of 0/3 data at > Host-IMP line speed, that would probably have quickly caused problems that the > NOC would have hads trouble diagnosing and fixing. Depends how effective the discard implementations were. -- Steve From jack at 3kitty.org Tue Apr 5 18:53:50 2022 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 5 Apr 2022 18:53:50 -0700 Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: If the IMP used its ability to discard 0/3 messages, and did so aggressively (i.e., most "effectively"), that seems to me more powerful even than stopping bit flow at the hardware level. It would permit "normal" traffic to flow unimpeded, while discarding 0/3 bits, so that the 0/3 traffic only travelled when there was little else to send. Such an algorithm would seem to have the effect of making 0/3 traffic absolutely lowest priority.? E.g., if there was other traffic, perhaps several FTPs in progress involving several Hosts but sharing one or more IMP-IMP circuits, I would expect that traffic to "clog up" all of the channels, even if those Hosts were careful about RFNM counting to avoid being hardware-blocked.?? So while such "other" normal traffic was heavy, all 0/3 traffic might just disappear. I wonder if your test data showed such effects... I.e., did the tests you did involve paths through several IMPs, while they were handling lots of other competing traffic???? Did 0/3 flow drop off (get discarded) when normal traffic increased?? What was the bottom line result - were 0/3 messages useful for carrying voice while coexisting with other traffic? My suspicion, not knowing how the IMP code behaved, is that the "normal" traffic was the primary concern, and 0/3 got any bandwidth that was left over.?? But it would probably take a dive into the code to figure that out for sure.?? Maybe Alex remembers more. After the ARPANET paths were replaced by circuits directly between IP routers, the "Source Quench" mechanisms could perform the similar function of dropping datagrams when there were no resources to handle them.? Were similar voice tests done in that environment, using UDP rather than IMP 0/3?? How did they compare....? I guess I'm still curious how "buffer bloat" evolved over time. More memory would prevent "uncontrolled" traffic like UDP from being discarded, of course with the side effect of possibly getting delivered long after it was still usable. Jack On 4/5/22 16:42, Stephen Casner wrote: > Answering Vint and Jack inline... > > On Mon, 4 Apr 2022, vinton cerf wrote: > >> i think the point about the type 0 subtype 3 is that they may not have been >> reassembled and might have had limits as to size (unlike the 8000 bit >> "message"). As I recall they were "uncontrolled" which means the space >> reservation protocol was not in force for them. Since these were used for >> voice (and maybe video), they might have been limited to single packet size >> (1000+ bits) and were not assured of delivery. > Correct, 1822 says the type 0 subtype 3 messages were limited to 991 > data bits in addition to the 96-bit leader. Also there was no > source-to-destination control of these messages (no retransmission, no > RFNM, no error reports). > > For packet voice we did not want packets any larger because we wanted > to limit the packetization delay. In the NTC 78 paper mentioned here > recently we tested 5 to 18 50-bit LPC parcels per packet (250 to 900 > bits). Each parcel encoded 10 ms of voice. > > No video during that era over ARPANET. Video came later on the > Wideband Satellite Network. > > On Mon, 4 Apr 2022, Jack Haverty wrote: > >> I never got to actually use 0/3 messages, so my memory on how they behaved is >> fuzzy. But IIRC they were also not subject to the normal IMP<->Host flow >> control mechanisms of RFNMs. Those mechanisms enabled the IMP to control the >> flow of data from a Host into the network, including the ultimate step of >> shutting off all data transfer from a Host at the 1822 hardware level by >> temporarily disabling the clock that regulated bit flow. Just as effective as >> pulling the plug. Perhaps Steve remembers, or someone could look at the old >> code to trace how it handled 0/3 messages. > There was no specialization of the IMP<->Host interface for the type 0 > subtype 3 messages. The bit-level transfer was the same. The IMP > could discard the message as soon as it came in, so there would be no > reason to delay transfer at the bit level > >> I suspect that avoidance of Host-IMP flow control was likely a major reason >> for the opposition to widespead use of 0/3 service, or any use that might >> evolve into widespread use later, such as to support voice. If 0/3 permission >> enabled any host on the ARPANET to submit continuous flows of 0/3 data at >> Host-IMP line speed, that would probably have quickly caused problems that the >> NOC would have hads trouble diagnosing and fixing. > Depends how effective the discard implementations were. > > -- Steve From casner at acm.org Wed Apr 6 13:10:31 2022 From: casner at acm.org (Stephen Casner) Date: Wed, 6 Apr 2022 13:10:31 -0700 (PDT) Subject: [ih] ARPANET uncontrolled packets (was: GOSIP & compliance) In-Reply-To: References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <625540fd-cbf5-860c-9467-618a159f468b@3kitty.org> Message-ID: On Tue, 5 Apr 2022, Jack Haverty wrote: > If the IMP used its ability to discard 0/3 messages, and did so aggressively > (i.e., most "effectively"), that seems to me more powerful even than stopping > bit flow at the hardware level. It would permit "normal" traffic to flow > unimpeded, while discarding 0/3 bits, so that the 0/3 traffic only travelled > when there was little else to send. Yes, 1822 says "If at any time there are insufficient resources in the network to handle one of these messages, it will be immediately discarded." > Such an algorithm would seem to have the effect of making 0/3 traffic > absolutely lowest priority. E.g., if there was other traffic, perhaps several > FTPs in progress involving several Hosts but sharing one or more IMP-IMP > circuits, I would expect that traffic to "clog up" all of the channels, even > if those Hosts were careful about RFNM counting to avoid being > hardware-blocked. So while such "other" normal traffic was heavy, all 0/3 > traffic might just disappear. Yes, but in practice at the time we were doing the packet voice work in the 1970s this was not a problem. The severe ARPANET congestion occurred later in the 1980s. > I wonder if your test data showed such effects... I.e., did the tests you did > involve paths through several IMPs, while they were handling lots of other > competing traffic? Did 0/3 flow drop off (get discarded) when normal > traffic increased? What was the bottom line result - were 0/3 messages useful > for carrying voice while coexisting with other traffic? The tests reported in the NTC 78 paper were for traffic between ISI and LL. That was a cross-country path through a minimum of 8 IMPs. I don't recall if we chose test times when competing traffic was low, but the paper does not report packet losses. The effect of higher packet rates was more delay through the network (presumably) due to processing delays in the IMPs. What I recall about our use of type 0 subtype 3 packets was that the first tests required coordination with the NOC to enable the packets on the designated test IMPs at the arranged test time. But over time as the tests showed that the traffic was not going to crash the network the policy became more relaxed. Eventually the facility was always enabled on our IMPs and it was used routinely for our packet voice work. > After the ARPANET paths were replaced by circuits directly between IP routers, > the "Source Quench" mechanisms could perform the similar function of dropping > datagrams when there were no resources to handle them. Were similar voice > tests done in that environment, using UDP rather than IMP 0/3? How did they > compare....? Certainly the packet audio and video work progressed to use UDP over the DARTnet, for example, in later years. I don't recall Source Quench ever being a useful function, though. Packets were just dropped. Initially such traffic worked well only on network paths with low loads, but over time as network capacity grew the packet audio and video presented a smaller portion of the overall load so the best-effort service worked most of the time in most places. That's essentially where we are today. -- Steve From karl at cavebear.com Thu Apr 7 12:45:27 2022 From: karl at cavebear.com (Karl Auerbach) Date: Thu, 7 Apr 2022 12:45:27 -0700 Subject: [ih] Monitoring, Operating, Controlling ... In-Reply-To: <1021098516.710017.1649015446673@mail.yahoo.com> References: <87157443-d081-cfee-04e0-59f37d062d47@cavebear.com> <5f96ddef-1dd4-91c9-41ca-a6805a591e7f@dcrocker.net> <095d2950-bddb-68f9-4d2c-e9649b68d1e2@cavebear.com> <260392E3-0401-4EAE-A10A-D8648D4D166B@comcast.net> <7CC3A82D-C613-45EE-938D-B233624FAD7E@icloud.com> <343227CF-C9B7-4C4A-A041-98BC0A5830FE@comcast.net> <1021098516.710017.1649015446673@mail.yahoo.com> Message-ID: <2538eef2-b5e4-4e14-9439-7b91869eae14@cavebear.com> My grandfather repaired radios; my father repaired TVs.? I grew up fixing things; I had my hands inside open, running TVs when I was five years old.? (And yes, very early on I learned what it feels like to become the best path between a high voltage CRT and ground, and I know too well the vibrating feel of a 60hz current running through my body.) When the Internet management notions came along circa 1990 there was no discussion (at least none that I heard) of a difference between "management" of a running network and "troubleshooting" of a network that was failing to deliver even basic services. In my TV repair world "management" is the "fine tuning" knob used to make small adjustments to receiver frequency to remove the fuzz from a channel. And "troubleshooting" is when there's no picture at all and I pull the back off the TV and start looking for burned out tubes or resistors. (Or just as often, using my nose to pick up the scent of something burnt.)? Or, as was sometimes the case, the cotton thread that loops between the fine tuning knob and the variable capacitor had slipped off or broken. In my TV repair guy world there was a big difference between "management" and "troubleshooting" and "repair".? But that distinction seemed quite lost when we got to "Internet Management". Even as far back as the late 1980s it was obvious to me that if I could not sustain a TCP session between two points on the net the tool kit that I would need was not "management" but, rather "diagnosis and repair". So I was dumbfounded at the assertion in the SNMP world (of which I was an early part) that it had to be "UDP all the way" because one could not trust that TCP would be usable while by some magic a sequence of UDP packets would be. Hence the horror of SNMP's "get next" and lexi-ordering, and then the subsequent horrors of SNMP security models, and now the horror of DTLS (datagram TLS) over UDP. Our company has had an SNMP test suite product for a couple of decades.? And the most common failure of SNMP implementations is a failure to properly perform 'get next".? I've coded in that realm and it is quite difficult to get right.? And from the point of view of a management client, there is no guarantee that the data obtained through a get-next sweep is consistent, there being a possibility that things had changed between successive queries in a get-next sweep. That failure mode is still common today. I've watched SNMP activity.? It can be a buzz saw of packets racing back and forth on a net.? It can sometimes be the dominant flow of traffic on a link. And I've compared it to alternatives based on TCP, such as my rewrite of SNMP (https://www.iwl.com/idocs/knmp-overview ) and observed packet-count reductions of two orders (or more) of decimal magnitude and even greater improvements in reductions of the wall-clock time required to make a sweep.? (And I won't mention greatly improved consistency between data points.) In other words, as a "management tool" SNMP is classic camel - a racehorse designed by a committee - except that a camel does at least some things extremely well. For doing some troubleshooting jobs SNMP over UDP is useful - such as watching whether the packet count of an interface is increasing at a explainable rate. But for doing the "control" part of management, SNMP was and is a dud.? During meetings at the IETF we would discuss how do we assure sequencing of control operations.? Of course we could attempt a "set" and then do a readback.? But that's inefficient and slow, and subject to race conditions.? Our example was using SNMP to control a bomber.? We'd want to make sure that the command "open the bomb bay doors" was received and completed before we issued the command "release bombs".? (Sometimes we used the example "Is aircraft flying?" and "raise landing gear".) I hope Netconf turns out better for management and control.? It's been a long time since I reviewed its present status, but it began life as a kind of remote XML editor that could have had a hard time squeezing into IoT devices, particularly ones even smaller than the ESP32 based stuff I often work with.? I don't know how much of that fat has been shed. But on our Internet monitoring, diagnostics, and repair are getting the very short end of the stick.? And that stick is getting shorter as we impose ever stronger security barriers to block access to fetch data or to control a device. David Isenberg wrote "Rise of the Stupid Network" back in 1997. https://www.isen.com/stupid.html And we tend to differentiate between a control plane and a switching plane.? I submit that we need another kind of plane, a monitoring plane - sort of a set of smart automated eyeballs that observe the behavior of our networks that looks for patterns of ill activity or flows outside of predicted constraints.? It is difficult define what would be done when these things are observed, and a lot of limits and damping (and human gatekeeping) would be needed else we could have created an efficient kill-switch for the Internet. But as the Internet increasingly becomes a utility upon which we depend for our health, safety, and well being we need to get far more serious about management, monitoring, control, and diagnosis, and repair. ??? ??? --karl-- From geoff at iconia.com Sun Apr 10 11:11:36 2022 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 10 Apr 2022 08:11:36 -1000 Subject: [ih] The New Campaign for a Sex-Free Internet Message-ID: *Sex, money, and the future of online free speech* EXCERPT: For more than a decade, both amateurs and professionals shared their sometimes sweet, sometimes weird, and often graphic sexual activity on Pornhub. Launched in 2007 not long after YouTube and with a similar free-for-all spirit, the site represented a new wave of "adult entertainment" in which anyone with an internet connection could partake and anyone with a digital camera could become a star. Dubbed "tube sites," Pornhub and its various peers began to dominate web traffic generally and porn consumption specifically. These sites trod on porn's established business model, but for savvy sex workers the tube site network could provide a way to break into the business or reach audiences directly, without the porn industry's usual middlemen. To monetize one's presence in the early days took some creativity, but tube sites would eventually offer content partnerships that allowed people to get paid directly for their videos. Their competitors, such as cam sites and clip stores, made the process of charging money and getting paid even smoother. The result? For the first time, people with a truly diverse array of body types, looks, races, ethnicities, sexualities, gender identities, and kinks had direct access to the tools of porn production and distribution. In the past, porn had catered to a much more narrow range of tastes, with predictable results. Now audiences could access all sorts of content that defied conventional notions of who and what was deserving of lust. On sites like Pornhub and the microblogging platform Tumblr, outside-the-mainstream content thrived. And then, one day, it was gone. In December 2020, without warning, Pornhub removed all videos posted by unverified users?a massive cache of content encompassing anything not posted by formal content partners or members of the platform's official model program. More than 10 million videos were suspended, and unverified users were banned from uploading or downloading new videos. It was more than a disruption to the site. The unannounced disappearing of so many videos was "a huge cultural loss," says Ashley, a transgender sex worker and civil rights activist with a robust presence on social media and in offline organizing. (At Ashley's request, we're identifying her by first name only.) Ashley volunteers with the Sex Workers Outreach Project (SWOP) Behind Bars, a group dedicated to helping incarcerated sex workers. She recently helped spearhead a campaign protesting financial discrimination against sex workers and LGBTQ content creators. Unverified videos, Ashley says, are "inclusive, just by definition, of all the queer content that people felt unsafe with being directly affiliated with." The Pornhub purge came about two years after Tumblr's ban on any content depicting sex acts, and preceded a similar announcement in summer 2021 from OnlyFans, a subscription content site popularized by sex workers. OnlyFans would later reverse this edict, but the fate of adult content on the site remains uncertain. Then, in September 2021, the first user-uploaded porn site?Xtube, founded in 2006 and now owned by the same parent company as Pornhub?shut down entirely. Demand for online porn hasn't weakened, at least not according to web traffic numbers. Nor do there seem to be fewer people willing to create and post it; it's not uncommon to hear sex workers complain about the glut of adult content creators these days. Nonetheless, it's a financially precarious, and perhaps even dangerous, time to be in the business of online porn. And one of the biggest reasons why is that a constellation of activist groups, rooted in deeply conservative opposition to virtually any depiction of sexuality in the public sphere, have put considerable pressure on the middlemen who keep online porn in business. In some cases, that pressure has led to the creation of onerous new laws; in others, it has been aided by support from powerful figures in business and government. These groups have repeatedly sought to conflate the existence of consensual commercial sex and porn production with the prospect of forced sexual exploitation, often with lurid statistics about exploited minors that don't stand up to scrutiny. Although these groups say their aim is merely to rid the web of abuse, it's clear that their true goal is to eliminate the vast majority of adult sexual content from the web through a combination of legal pressure tactics, lobbying for new laws, and political intimidation. It's a campaign for a sex-free web. Rather than help vulnerable women, these efforts threaten to make life worse for the very people they claim to want to help?while simultaneously stifling internet expression more broadly. *From 'Morality' to 'Exploitation'*... [...] https://reason.com/2022/04/09/the-new-campaign-for-a-sex-free-internet/ -- Geoff.Goodfellow at iconia.com living as The Truth is True From geoff at iconia.com Sun Apr 10 16:46:04 2022 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Sun, 10 Apr 2022 13:46:04 -1000 Subject: [ih] The Internet Is Not What You Think It Is: A History, A Philosophy, A Warning Message-ID: EXCERPT: THE INTERNET HAS lost its way and taken society with it. Since the mid-2010s, we hear warnings of ?dis/misinformation.? We hear about the loss of trust in our institutions and the need to reinvent them for the internet age. In short, we are living in a ?crisis moment? ? one ironically experienced by many of us while stuck at home. Many have diagnosed these symptoms and proposed policy solutions, but few have done the hard work of rummaging around in the internet?s history to find the roots of the problems ? and almost none have taken a truly long view. In *The Internet Is Not What You Think It Is* , Justin E. H. Smith, a philosopher and historian of science, argues that we?ve been much too narrow-minded in our understanding of the internet. In presenting a longue dur?e history, he challenges our assumptions about what the internet is and what we?re doing when we?re on it. Only by understanding the internet?s long history ? by understanding the circumstances in which the internet?s many parts were conceived ? can we, he claims, take back control of our lives and shape the internet in a way more conducive to human flourishing. ? JULIEN CROCKETT: You credit the birth of *The Internet Is Not What You Think It Is * with a melancholic piece you wrote in 2018??19, ?*It?s All Over*.? Can you tell us about that piece and why it inspired you to write about the internet and ultimately this book?... [...] https://lareviewofbooks.org/article/the-internet-is-not-what-you-think-it-is-a-history-a-philosophy-a-warning/ -- Geoff.Goodfellow at iconia.com living as The Truth is True From jericho at attrition.org Mon Apr 11 10:19:13 2022 From: jericho at attrition.org (jericho) Date: Mon, 11 Apr 2022 12:19:13 -0500 (CDT) Subject: [ih] Map of the Internet - May 1973 Message-ID: https://twitter.com/workergnome/status/807704855276122114 "Going through old papers my dad gave me, I found his map of the internet as of May 1973." -- Not sure if there is a history of the progression of old Internet maps somewhere, but this may or may not be a new addition if so. .b From olejacobsen at me.com Mon Apr 11 10:23:45 2022 From: olejacobsen at me.com (Ole Jacobsen) Date: Mon, 11 Apr 2022 10:23:45 -0700 Subject: [ih] Map of the Internet - May 1973 In-Reply-To: References: Message-ID: <88A99560-E93E-49A9-B8FC-DE9594E1E193@me.com> Well, it's an ARPANET map and there are several of those floating around for various years. Noel Chiappa (on this list) can give you the pointer. Ole > On Apr 11, 2022, at 10:19, jericho via Internet-history wrote: > > > https://twitter.com/workergnome/status/807704855276122114 > > "Going through old papers my dad gave me, I found his map of the internet as of May 1973." > > > > -- > > Not sure if there is a history of the progression of old Internet maps somewhere, but this may or may not be a new addition if so. > > .b > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office: +1 415-550-9433 Cell: +1 415-370-4628 Web: protocoljournal.org E-mail: olejacobsen at me.com E-mail: ole at protocoljournal.org Skype: organdemo From darius.kazemi at gmail.com Mon Apr 11 10:55:48 2022 From: darius.kazemi at gmail.com (Darius Kazemi) Date: Mon, 11 Apr 2022 10:55:48 -0700 Subject: [ih] Map of the Internet - May 1973 In-Reply-To: <88A99560-E93E-49A9-B8FC-DE9594E1E193@me.com> References: <88A99560-E93E-49A9-B8FC-DE9594E1E193@me.com> Message-ID: A decent compendium of early internet maps (ARPA and otherwise) here: https://personalpages.manchester.ac.uk/staff/m.dodge/cybergeography/atlas/historical.html Brad Fidler has a paper on specifically ARPANET maps in IEEE Annals: https://www.computer.org/csdl/magazine/an/2015/01/man2015010044/13rRUy0ZzUm On Mon, Apr 11, 2022, 10:23 AM Ole Jacobsen via Internet-history < internet-history at elists.isoc.org> wrote: > > > Well, it's an ARPANET map and there are several of those floating around > for various years. > > Noel Chiappa (on this list) can give you the pointer. > > Ole > > > On Apr 11, 2022, at 10:19, jericho via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > > > https://twitter.com/workergnome/status/807704855276122114 > > > > "Going through old papers my dad gave me, I found his map of the > internet as of May 1973." > > > > > > > > -- > > > > Not sure if there is a history of the progression of old Internet maps > somewhere, but this may or may not be a new addition if so. > > > > .b > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > Ole J. Jacobsen > Editor and Publisher > The Internet Protocol Journal > Office: +1 415-550-9433 > Cell: +1 415-370-4628 > Web: protocoljournal.org > E-mail: olejacobsen at me.com > E-mail: ole at protocoljournal.org > Skype: organdemo > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From olejacobsen at me.com Mon Apr 11 10:56:49 2022 From: olejacobsen at me.com (Ole Jacobsen) Date: Mon, 11 Apr 2022 10:56:49 -0700 Subject: [ih] Map of the Internet - May 1973 In-Reply-To: References: <88A99560-E93E-49A9-B8FC-DE9594E1E193@me.com> Message-ID: <57BABB96-399D-4A5D-9D35-8A024D5E369D@me.com> The Noel Chiappa pages are here: http://mercury.lcs.mit.edu/~jnc/tech/arpanet.html > On Apr 11, 2022, at 10:55, Darius Kazemi wrote: > > A decent compendium of early internet maps (ARPA and otherwise) here: https://personalpages.manchester.ac.uk/staff/m.dodge/cybergeography/atlas/historical.html > > Brad Fidler has a paper on specifically ARPANET maps in IEEE Annals: https://www.computer.org/csdl/magazine/an/2015/01/man2015010044/13rRUy0ZzUm > On Mon, Apr 11, 2022, 10:23 AM Ole Jacobsen via Internet-history > wrote: > > > Well, it's an ARPANET map and there are several of those floating around for various years. > > Noel Chiappa (on this list) can give you the pointer. > > Ole > > > On Apr 11, 2022, at 10:19, jericho via Internet-history > wrote: > > > > > > https://twitter.com/workergnome/status/807704855276122114 > > > > "Going through old papers my dad gave me, I found his map of the internet as of May 1973." > > > > > > > > -- > > > > Not sure if there is a history of the progression of old Internet maps somewhere, but this may or may not be a new addition if so. > > > > .b > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > Ole J. Jacobsen > Editor and Publisher > The Internet Protocol Journal > Office: +1 415-550-9433 > Cell: +1 415-370-4628 > Web: protocoljournal.org > E-mail: olejacobsen at me.com > E-mail: ole at protocoljournal.org > Skype: organdemo > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office: +1 415-550-9433 Cell: +1 415-370-4628 Web: protocoljournal.org E-mail: olejacobsen at me.com E-mail: ole at protocoljournal.org Skype: organdemo From jmamodio at gmail.com Mon Apr 11 11:13:53 2022 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 11 Apr 2022 13:13:53 -0500 Subject: [ih] Map of the Internet - May 1973 In-Reply-To: References: Message-ID: That was ARPANet ... -J On Mon, Apr 11, 2022 at 12:19 PM jericho via Internet-history < internet-history at elists.isoc.org> wrote: > > https://twitter.com/workergnome/status/807704855276122114 > > "Going through old papers my dad gave me, I found his map of the internet > as of May 1973." > > > > -- > > Not sure if there is a history of the progression of old Internet maps > somewhere, but this may or may not be a new addition if so. > > .b > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From dan at lynch.com Mon Apr 11 14:09:05 2022 From: dan at lynch.com (Dan Lynch) Date: Mon, 11 Apr 2022 14:09:05 -0700 Subject: [ih] Map of the Internet - May 1973 In-Reply-To: References: Message-ID: And I came to SRI in April of that year and it was exactly like that. Our PDP-10 was connected through a PDP-15. Odd, but it worked flawlessly. Dan Cell 650-776-7313 > On Apr 11, 2022, at 11:14 AM, Jorge Amodio via Internet-history wrote: > > ?That was ARPANet ... > -J > >> On Mon, Apr 11, 2022 at 12:19 PM jericho via Internet-history < >> internet-history at elists.isoc.org> wrote: >> >> >> https://twitter.com/workergnome/status/807704855276122114 >> >> "Going through old papers my dad gave me, I found his map of the internet >> as of May 1973." >> >> >> >> -- >> >> Not sure if there is a history of the progression of old Internet maps >> somewhere, but this may or may not be a new addition if so. >> >> .b >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From gnu at toad.com Thu Apr 14 00:39:35 2022 From: gnu at toad.com (John Gilmore) Date: Thu, 14 Apr 2022 00:39:35 -0700 Subject: [ih] The Long List of Things That Have To Be Figured Out Someday In-Reply-To: References: <1c479fac-c88d-729a-5b3d-69aaa811f8c7@gmail.com> Message-ID: <21120.1649921975@hop.toad.com> Jack Haverty said, about the Internet: > "We Still Had Long List of Things That Had To Be Figured Out Someday > and the technology kind of got out of our hands and > went out into the user's environment before it was ready to go" and > "It Should All Just Work But The Reality Is It Still Doesn't, There's A Long > List of Things That Have To Get Done" geoff goodfellow asked: > curious if anyone has a copy or memory of what > the Long List of Things That Had To Be Figured Out Someday? Dave Taht asked me a similar question in 2013, "what Big Problems do we need to solve with the Internet over the next 10 years?". He blogged my responses. These are not direct answers to what Jack Haverty would've said if we had asked him, but there's probably some overlap. http://the-edge.taht.net/post/gilmores_list/ The list is succinct, so I'll include it inline: Gilmore?s List * Routing scalability at planetary scale * Uncensorable, untappable Internet infrastructure (Freedombox-ish) * Routing scalability at city scale among peer nodes (Freedombox-ish) * A fully distributed database replacement for DNS * How to crutch along on IPv4 without destroying end-to-end? * Finishing the IPv6 transition, sanely, and safely. * DNSSEC as a trustable infrastructure. * Delivering fiber speeds to ordinary consumers. * Keeping email relevant while ending its centralized censorship. * Reliable, secure wireless ad hoc peer to peer radio communication. * Reliable, working long-haul wireless Internet that isn?t owned by crabbed censorial monopolist cellular companies. * Restoring ?network neutrality? by restoring competition among ISPs. * Reliable, working, worldwide voice interaction (telephone) replacement. * Copyright and patent defense/collaboration is another; or perhaps a better way to put it is ?how the next Internet can pay creators without throwing away all the advantages of worldwide instant communication? * Digital value transfer (reliable digital cash) * Reliable node-level cyber security * Reliable network-level cyber security * Reliable internetwork-level cyber security * Privacy on a large scale network. * How to leverage information asymmetries for ordinary users? benefit. * Distributed social networking. * Avoidance of pinch-points like Google and Facebook that bend a widely distributed system into an access network that somehow always leads to their monopoly. * What replaces the Web as the next big obvious thing that we should?ve done years before which takes over the world?s idea of ?what the Internet is?? * Creating better business models than (1) move bits as a commodity, and (2) force ads on people! John From lars at nocrew.org Tue Apr 19 23:24:40 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 20 Apr 2022 06:24:40 +0000 Subject: [ih] Run TENEX in emulation! Message-ID: <7wk0bk6zmf.fsf@junk.nocrew.org> Hello, In reference to an earlier thread on ths list, "Run TENEX in emulation?", I can now answer in the affirmative. Richard Cornwell and I have been working on getting TENEX running on his PDP-10 emulator. The first roadblock was finding a consistent set of files to assemble and link a working monitor, using TOPS-20 for bootstrapping. Several ones we tried had various problems, but finally we came across this one from the dual KI10 at SUMEX. We still don't have everything working in perfect order, but at least we can get to the mini-exec and have it load EXEC and run from DECtape. syslod$g DO YOU REALLY WANT TO CLOBBER THE DISC BY RE-INITIALIZING? Y OK, YOU ASKED FOR IT. TENEX RESTARTING, WAIT... NO CHECKDSK TENEX IN OPERATION NO EXEC .INIT BIT TABLE. READ BADSPOTS FROM FILE: tty: [Confirm] ^Z .GET FILE DTA0:EXEC.SAV [Confirm] .START. SUMEX-AIM Tenex 1.31.82, SUMEX-AIM EXEC 1.51 ENTER DATE AND TIME AS MM/DD/YY HH:MM -- 04/20/77 08:00:00 PLEASE RECONFIRM: WEDNESDAY, APRIL 20, 1977 08:00:00 @dir DIRECTORY.;1 DSKBTTBL.;1 INDEX. ;1 JOBPMF.;100002,100001,100000;T @enable !quit .HALT TENEX. . From jnc at mercury.lcs.mit.edu Tue Apr 26 05:56:42 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 26 Apr 2022 08:56:42 -0400 (EDT) Subject: [ih] A name from the past Message-ID: <20220426125642.B026D18C077@mercury.lcs.mit.edu> So I was reading an article "Data Communications at the NPL (1965-1975)" in the 'Annals of the History of Computing' (as it was then; Vol 9, No 3/4, if anyone wants to look at it), and it refers (on pg 228.) to an "Alan Marshall, an American computer professional then working in England". I'm wondering if this might be the same Alan Marshall who was later the chief engineer at Proteon? It's not a super-unusual name, so there might easily be two; and the description as a "computer professional" doesn't sound like Proteon's Marshall, who I would describe as a hardware guy who was more working on analog communication gear, when I met him in around 1979 or so. I've lost touch with him, and in any case there's a good chance we've lost him (Howard Salwen died a few years back), or I'd ask him directly. Anyone have anything useful? Noel From karl at cavebear.com Tue Apr 26 12:51:45 2022 From: karl at cavebear.com (Karl Auerbach) Date: Tue, 26 Apr 2022 12:51:45 -0700 Subject: [ih] Internet sounds Message-ID: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> I was wondering what sounds people associate with the early Internet. For instance, I remember the clatter of teletypes, Telebit and Hayes modem tones, VT52 buzzes, the RF interference caused screeches from the AM radio perched near IMP #1, the PC/IP telnet "chirp", the sound of a DECwriter, etc. (I also wonder if anyone might have recordings, particularly of the VT52 razzy buzz or the PC/IP telnet "chirp".) ??? --karl-- From sob at sobco.com Tue Apr 26 12:55:46 2022 From: sob at sobco.com (Scott Bradner) Date: Tue, 26 Apr 2022 15:55:46 -0400 Subject: [ih] Internet sounds In-Reply-To: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> Message-ID: <8345CC6A-51E1-4EFB-9E7D-80F0E6ED5232@sobco.com> I learned programming on the PDP-1 prototype at Information International Inc (Tripple-I) it had a Macintosh amp tied to the low order bit of the accumulator register - easy to tell when you had a programming loop :-) Scott > On Apr 26, 2022, at 3:51 PM, Karl Auerbach via Internet-history wrote: > > I was wondering what sounds people associate with the early Internet. > > For instance, I remember the clatter of teletypes, Telebit and Hayes modem tones, VT52 buzzes, the RF interference caused screeches from the AM radio perched near IMP #1, the PC/IP telnet "chirp", the sound of a DECwriter, etc. > > (I also wonder if anyone might have recordings, particularly of the VT52 razzy buzz or the PC/IP telnet "chirp".) > > --karl-- > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From awalding at gmail.com Tue Apr 26 12:58:29 2022 From: awalding at gmail.com (Andrew Walding) Date: Tue, 26 Apr 2022 14:58:29 -0500 Subject: [ih] Internet sounds In-Reply-To: <8345CC6A-51E1-4EFB-9E7D-80F0E6ED5232@sobco.com> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <8345CC6A-51E1-4EFB-9E7D-80F0E6ED5232@sobco.com> Message-ID: I would add the sounds of the daisy wheel printers and dot matrix printers to the list. On Tue, Apr 26, 2022 at 2:56 PM Scott Bradner via Internet-history < internet-history at elists.isoc.org> wrote: > I learned programming on the PDP-1 prototype at Information International > Inc (Tripple-I) > it had a Macintosh amp tied to the low order bit of the accumulator > register - easy to tell > when you had a programming loop :-) > > Scott > > > On Apr 26, 2022, at 3:51 PM, Karl Auerbach via Internet-history < > internet-history at elists.isoc.org> wrote: > > > > I was wondering what sounds people associate with the early Internet. > > > > For instance, I remember the clatter of teletypes, Telebit and Hayes > modem tones, VT52 buzzes, the RF interference caused screeches from the AM > radio perched near IMP #1, the PC/IP telnet "chirp", the sound of a > DECwriter, etc. > > > > (I also wonder if anyone might have recordings, particularly of the VT52 > razzy buzz or the PC/IP telnet "chirp".) > > > > --karl-- > > > > > > > > -- > > 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 clemc at ccc.com Tue Apr 26 13:13:04 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 26 Apr 2022 16:13:04 -0400 Subject: [ih] Internet sounds In-Reply-To: References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <8345CC6A-51E1-4EFB-9E7D-80F0E6ED5232@sobco.com> Message-ID: The traditional clatter of ASR33's in a terminal room ;-) ? On Tue, Apr 26, 2022 at 3:59 PM Andrew Walding via Internet-history < internet-history at elists.isoc.org> wrote: > I would add the sounds of the daisy wheel printers and dot matrix printers > to the list. > > On Tue, Apr 26, 2022 at 2:56 PM Scott Bradner via Internet-history < > internet-history at elists.isoc.org> wrote: > > > I learned programming on the PDP-1 prototype at Information International > > Inc (Tripple-I) > > it had a Macintosh amp tied to the low order bit of the accumulator > > register - easy to tell > > when you had a programming loop :-) > > > > Scott > > > > > On Apr 26, 2022, at 3:51 PM, Karl Auerbach via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > > > > I was wondering what sounds people associate with the early Internet. > > > > > > For instance, I remember the clatter of teletypes, Telebit and Hayes > > modem tones, VT52 buzzes, the RF interference caused screeches from the > AM > > radio perched near IMP #1, the PC/IP telnet "chirp", the sound of a > > DECwriter, etc. > > > > > > (I also wonder if anyone might have recordings, particularly of the > VT52 > > razzy buzz or the PC/IP telnet "chirp".) > > > > > > --karl-- > > > > > > > > > > > > -- > > > 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 bpurvy at gmail.com Tue Apr 26 13:22:01 2022 From: bpurvy at gmail.com (Bob Purvy) Date: Tue, 26 Apr 2022 13:22:01 -0700 Subject: [ih] Internet sounds In-Reply-To: References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <8345CC6A-51E1-4EFB-9E7D-80F0E6ED5232@sobco.com> Message-ID: There are sound effects libraries that studios use for TV and movie productions: farm noises, NYC street sounds, airports, subways, etc. So someone can probably make a (fairly small) amount of money putting all these sounds together and selling it as a library. If it hasn't been done already. On Tue, Apr 26, 2022 at 1:13 PM Clem Cole via Internet-history < internet-history at elists.isoc.org> wrote: > The traditional clatter of ASR33's in a terminal room ;-) > ? > > On Tue, Apr 26, 2022 at 3:59 PM Andrew Walding via Internet-history < > internet-history at elists.isoc.org> wrote: > > > I would add the sounds of the daisy wheel printers and dot matrix > printers > > to the list. > > > > On Tue, Apr 26, 2022 at 2:56 PM Scott Bradner via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > > > I learned programming on the PDP-1 prototype at Information > International > > > Inc (Tripple-I) > > > it had a Macintosh amp tied to the low order bit of the accumulator > > > register - easy to tell > > > when you had a programming loop :-) > > > > > > Scott > > > > > > > On Apr 26, 2022, at 3:51 PM, Karl Auerbach via Internet-history < > > > internet-history at elists.isoc.org> wrote: > > > > > > > > I was wondering what sounds people associate with the early Internet. > > > > > > > > For instance, I remember the clatter of teletypes, Telebit and Hayes > > > modem tones, VT52 buzzes, the RF interference caused screeches from the > > AM > > > radio perched near IMP #1, the PC/IP telnet "chirp", the sound of a > > > DECwriter, etc. > > > > > > > > (I also wonder if anyone might have recordings, particularly of the > > VT52 > > > razzy buzz or the PC/IP telnet "chirp".) > > > > > > > > --karl-- > > > > > > > > > > > > > > > > -- > > > > Internet-history mailing list > > > > Internet-history at elists.isoc.org > > > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > -- > > > Internet-history mailing list > > > Internet-history at elists.isoc.org > > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From lyndon at orthanc.ca Tue Apr 26 14:48:50 2022 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Tue, 26 Apr 2022 14:48:50 -0700 Subject: [ih] Internet sounds In-Reply-To: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> Message-ID: <93d959cc4b869351@orthanc.ca> > For instance, I remember the clatter of teletypes, Telebit and Hayes > modem tones, VT52 buzzes, the RF interference caused screeches from > the AM radio perched near IMP #1, the PC/IP telnet "chirp", the > sound of a DECwriter, etc. These are all generic computer sounds. Nothing to do with the Internet per se. (Well, okay, the IMP :-)) For me, the first "sound" that I would definitively associate with the Internet specifically is Carl Malamud's _Internet Talk Radio_ program from 1993. --lyndon From touch at strayalpha.com Tue Apr 26 14:58:52 2022 From: touch at strayalpha.com (touch at strayalpha.com) Date: Tue, 26 Apr 2022 14:58:52 -0700 Subject: [ih] Internet sounds In-Reply-To: <93d959cc4b869351@orthanc.ca> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <93d959cc4b869351@orthanc.ca> Message-ID: The variable speed Mac diskettes, startup sounds of various machines, etc. Don?t forget the sound of a paper jam (esp when a dot matrix head crunches into it)? or better, if you could get a band printer to burst into flames (enough X?s and it would create enough paper dust and heat?.) Joe ? Dr. Joe Touch, temporal epistemologist www.strayalpha.com From cabo at tzi.org Tue Apr 26 16:02:24 2022 From: cabo at tzi.org (Carsten Bormann) Date: Wed, 27 Apr 2022 01:02:24 +0200 Subject: [ih] Internet sounds In-Reply-To: <8345CC6A-51E1-4EFB-9E7D-80F0E6ED5232@sobco.com> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <8345CC6A-51E1-4EFB-9E7D-80F0E6ED5232@sobco.com> Message-ID: <3EFD2A27-7A53-468D-8D24-36FAB2F725C9@tzi.org> On 2022-04-26, at 21:55, Scott Bradner via Internet-history wrote: > > I learned programming on the PDP-1 prototype at Information International Inc (Tripple-I) > it had a Macintosh amp tied to the low order bit of the accumulator register - easy to tell > when you had a programming loop :-) In this spirit ? this wasn?t the ?early Internet?, but still ~ 1984: Our X.25/SLIP gateway (*) was running on a PC, and each time a packet entered, the code applied a voltage to the PC loudspeaker (~ 1 line of code), and each time processing was completed, the voltage was removed (1 more). The resulting sound of a galloping herd (**) helped tremendously with debugging the code. This hack really came to life when our Datex-P line (German X.25) developed a problem that occasionally made the line really slow. An intermittent problem, essentially unfixable. But the sound was audibly different during these episodes, with breaks that indicated retransmission. With that immediate feedback through the changing soundscape, we were able to pin down the problem: The line went bad each time the snow on the streets was melting, and recovered when it became dry again. No problems with rain, just with melting snow. Deutsche Bundespost were incredulous about our problem report, but quickly found the defect and fixed it. This may be not so impressive today with grafana and all, but at the time we were mightily impressed with how simple audio feedback was improving our problem solving skills. Gr??e, Carsten (*) I know? but it was the quickest we could nail together with our 4.2BSD host. (**) It helped that packets/s rates at the time still were in the audible range :-) From brian.e.carpenter at gmail.com Tue Apr 26 16:34:13 2022 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 27 Apr 2022 11:34:13 +1200 Subject: [ih] Internet sounds In-Reply-To: <93d959cc4b869351@orthanc.ca> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <93d959cc4b869351@orthanc.ca> Message-ID: <758b50cc-d475-c321-ea50-e7c671725f2e@gmail.com> On 27-Apr-22 09:48, Lyndon Nerenberg (VE7TFX/VE6BBM) via Internet-history wrote: >> For instance, I remember the clatter of teletypes, Telebit and Hayes >> modem tones, VT52 buzzes, the RF interference caused screeches from >> the AM radio perched near IMP #1, the PC/IP telnet "chirp", the >> sound of a DECwriter, etc. > > These are all generic computer sounds. Nothing to do with the Internet > per se. (Well, okay, the IMP :-)) > > For me, the first "sound" that I would definitively associate with > the Internet specifically is Carl Malamud's _Internet Talk Radio_ > program from 1993. "On June 24, 1993, the band Severe Tire Damage was the first to perform live on the Mbone." (https://en.wikipedia.org/wiki/Mbone#History) But there was audio and video using early versions of VIC/VAT before 1993. I was in a transatlantic teleconf at UCL in 1991, and I seem to remember remote audio in the very early days of RIPE (1989?). Archives from those days may be hard to find, however. Mark Handley might have some pointers for the UCL work. Regards Brian From jack at 3kitty.org Tue Apr 26 17:49:42 2022 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 26 Apr 2022 17:49:42 -0700 Subject: [ih] Internet sounds In-Reply-To: <758b50cc-d475-c321-ea50-e7c671725f2e@gmail.com> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <93d959cc4b869351@orthanc.ca> <758b50cc-d475-c321-ea50-e7c671725f2e@gmail.com> Message-ID: <755770da-818e-cfce-b1a1-531d9b0995a5@3kitty.org> My most memorable "computer sound" of the 70s was the ear-shattering squeal of one of dozens of fans in various pieces of computer equipment.? That occurred when the bearings were getting worn. Running 24x7 a fan would last only a few years at best.? You would "test" a fan by just tapping on it with your finger, which of course placed your ears in prime striking distance of the squeal.?? Time to get the toolbox out and replace fans.?? I replaced a lot of fans.... "Internet sounds" are a bit more difficult.? Networks were notoriously difficult for doing a dog-and-pony show, since there was little visible or audible activity involved.? Not even a spinning magtape.? Networks are definitely introverts. But I do remember one salient sound that I associate with The Internet.?? In particular, I heard it at many of the meetings of various working groups and committees involved in the early Internet design and deployment.?? This was all before social media, audio or video teleconferencing, or even the ability to send pictures or audio over the Net.?? We had to actually convene in a room somewhere to thrash out technical details.? Time frame was roughly 1980 +- a few years. The sound I recall was an indication that the "Rat Hole Protocol" had been started (RHP?). What's RHP? Well, I don't remember who started it or when, but there was an undocumented rule at the meetings where anyone, from the lowliest coder to the person-in-charge, could, at any time, during any presentation, by any speaker, shout "Rat Hole!!!" loudly enough to be heard by everyone in the room.?? This would cause an immediate cessation of the current discussion, while everyone considered whether or not we had gotten way off topic.? Usually a rough consensus formed quickly, and the group climbed out of the Rat Hole, and resumed serious debate about whatever the topic of the meeting was supposed to be.?? Even Vint Cerf could be a "Rat Hole!" target, and IIRC he quickly agreed. It strikes me now that the "Rat Hole!" process was analogous to the "Call the Question" part of Robert's Rules.? It was used to halt endless unproductive discussions and get back on track to building the Internet. I wonder now how important the RHP was to the success of the Internet?? Without it, would we still be arguing instead of writing code...?? Hmmm, is RHP still in use? Anyway, "Rat Hole!!" is my most memorable "Internet Sound".?? Sorry, no audio tape that I know about. Jack Haverty On 4/26/22 16:34, Brian E Carpenter via Internet-history wrote: > On 27-Apr-22 09:48, Lyndon Nerenberg (VE7TFX/VE6BBM) via > Internet-history wrote: >>> For instance, I remember the clatter of teletypes, Telebit and Hayes >>> modem tones, VT52 buzzes, the RF interference caused screeches from >>> the AM radio perched near IMP #1, the PC/IP telnet "chirp", the >>> sound of a DECwriter, etc. >> >> These are all generic computer sounds.? Nothing to do with the Internet >> per se. (Well, okay, the IMP :-)) >> >> For me, the first "sound" that I would definitively associate with >> the Internet specifically is Carl Malamud's _Internet Talk Radio_ >> program from 1993. > > "On June 24, 1993, the band Severe Tire Damage was the first to > perform live on the Mbone." > (https://en.wikipedia.org/wiki/Mbone#History) > > But there was audio and video using early versions of VIC/VAT before > 1993. I was in a transatlantic teleconf at UCL in 1991, and I seem to > remember remote audio in the very early days of RIPE (1989?). > > Archives from those days may be hard to find, however. Mark Handley > might have some pointers for the UCL work. > > Regards > ?? Brian From jnc at mercury.lcs.mit.edu Tue Apr 26 18:26:37 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 26 Apr 2022 21:26:37 -0400 (EDT) Subject: [ih] A name from the past Message-ID: <20220427012637.339AF18C07E@mercury.lcs.mit.edu> > an article "Data Communications at the NPL (1965-1975)" in the 'Annals > of the History of Computing' (as it was then; Vol 9, No 3/4, if anyone > wants to look at it) This has some other interesting tidbits. On pg. 231, it observes: "This document [Scantlebury, Bartlett, "A Protocol for Use in the NPL Data Communications Network", April, 1967] contains what appears to be the first occurrence in print of the term 'protocol' in a data communications context". Interesting! On pg. 240, it describes the NPL network's 'isarithmic congestion control', defined as a "computer could .. inject a data packet into the network only [in place of another]", which sounds remarkably like the basic principle of Van's congestion control design! Finally, in the "Acknowledgements" section, we find listed a "B. E. Carpenter", who I rather suspect is our Brian Carpenter! The paper came out in 1988, and Brian had done his and Doran's book on "Turing's ACE Report" in 1986, and it involved close interaction with NPL; its Acknowledgements section thanks Martin Campbell-Kelly, the author of the NPL history paper. Noel From jeanjour at comcast.net Tue Apr 26 18:47:18 2022 From: jeanjour at comcast.net (John Day) Date: Tue, 26 Apr 2022 21:47:18 -0400 Subject: [ih] A name from the past In-Reply-To: <20220427012637.339AF18C07E@mercury.lcs.mit.edu> References: <20220427012637.339AF18C07E@mercury.lcs.mit.edu> Message-ID: <1572004B-C39F-4906-8F6F-82D515B43F6D@comcast.net> > On Apr 26, 2022, at 21:26, Noel Chiappa via Internet-history wrote: > >> an article "Data Communications at the NPL (1965-1975)" in the 'Annals >> of the History of Computing' (as it was then; Vol 9, No 3/4, if anyone >> wants to look at it) > > This has some other interesting tidbits. > > On pg. 231, it observes: "This document [Scantlebury, Bartlett, "A Protocol > for Use in the NPL Data Communications Network", April, 1967] contains what > appears to be the first occurrence in print of the term 'protocol' in a > data communications context". Interesting! Perhaps. When were the SWIFT and early airline networks done. Baran didn?t use the term? > > On pg. 240, it describes the NPL network's 'isarithmic congestion control', > defined as a "computer could .. inject a data packet into the network only > [in place of another]", which sounds remarkably like the basic principle of > Van's congestion control design! How do you figure? I thought Van?s congestion control was based on AIMD? Isarithmic congestion control is essentially static allocation of buffers which was known (by their own admission) to be very inefficient. The earliest congestion control work on connectionless networks was done at the University of Waterloo in the mid-1970s with extensive simulations and modeling. The NPL Net was packet-switched by virtual-circuit and I think it was a star network, but don?t quote me on that yet. ;-) > > Finally, in the "Acknowledgements" section, we find listed a "B. E. > Carpenter", who I rather suspect is our Brian Carpenter! The paper came out > in 1988, and Brian had done his and Doran's book on "Turing's ACE Report" in > 1986, and it involved close interaction with NPL; its Acknowledgements > section thanks Martin Campbell-Kelly, the author of the NPL history paper. John > > Noel > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From brian.e.carpenter at gmail.com Tue Apr 26 19:20:06 2022 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 27 Apr 2022 14:20:06 +1200 Subject: [ih] A name from the past In-Reply-To: <20220427012637.339AF18C07E@mercury.lcs.mit.edu> References: <20220427012637.339AF18C07E@mercury.lcs.mit.edu> Message-ID: <8a5f45e6-5239-03ce-5290-ce5d372aa3ad@gmail.com> On 27-Apr-22 13:26, Noel Chiappa via Internet-history wrote: > > an article "Data Communications at the NPL (1965-1975)" in the 'Annals > > of the History of Computing' (as it was then; Vol 9, No 3/4, if anyone > > wants to look at it) ... > Finally, in the "Acknowledgements" section, we find listed a "B. E. > Carpenter", who I rather suspect is our Brian Carpenter! The paper came out > in 1988, and Brian had done his and Doran's book on "Turing's ACE Report" in > 1986, and it involved close interaction with NPL; its Acknowledgements > section thanks Martin Campbell-Kelly, the author of the NPL history paper. Yes, that would be me. I'm not sure what I contributed except reviewing a draft. Martin essentially commissioned the ACE book for the Charles Babbage Institute (and his wife retyped some of Turing's writing from an almost illegible carbon copy). I was blissfully ignorant of NPL's original network, despite having visited Donald Davies' lab as a grad student for other reasons. Brian From bpurvy at gmail.com Tue Apr 26 21:14:26 2022 From: bpurvy at gmail.com (Bob Purvy) Date: Tue, 26 Apr 2022 21:14:26 -0700 Subject: [ih] Internet sounds In-Reply-To: <755770da-818e-cfce-b1a1-531d9b0995a5@3kitty.org> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <93d959cc4b869351@orthanc.ca> <758b50cc-d475-c321-ea50-e7c671725f2e@gmail.com> <755770da-818e-cfce-b1a1-531d9b0995a5@3kitty.org> Message-ID: You know, CHM guys, we *could* actually rig up a "studio", borrow some good mics, and record some of this stuff. I doubt it would bring in a whole LOT of money, but maybe a few dollars. When I was a wee lad, my big brother actually listened to records of drag racing sounds. You never know what people will like... On Tue, Apr 26, 2022 at 5:49 PM Jack Haverty via Internet-history < internet-history at elists.isoc.org> wrote: > My most memorable "computer sound" of the 70s was the ear-shattering > squeal of one of dozens of fans in various pieces of computer > equipment. That occurred when the bearings were getting worn. Running > 24x7 a fan would last only a few years at best. You would "test" a fan > by just tapping on it with your finger, which of course placed your ears > in prime striking distance of the squeal. Time to get the toolbox out > and replace fans. I replaced a lot of fans.... > > "Internet sounds" are a bit more difficult. Networks were notoriously > difficult for doing a dog-and-pony show, since there was little visible > or audible activity involved. Not even a spinning magtape. Networks > are definitely introverts. > > But I do remember one salient sound that I associate with The > Internet. In particular, I heard it at many of the meetings of various > working groups and committees involved in the early Internet design and > deployment. This was all before social media, audio or video > teleconferencing, or even the ability to send pictures or audio over the > Net. We had to actually convene in a room somewhere to thrash out > technical details. Time frame was roughly 1980 +- a few years. > > The sound I recall was an indication that the "Rat Hole Protocol" had > been started (RHP?). > > What's RHP? > > Well, I don't remember who started it or when, but there was an > undocumented rule at the meetings where anyone, from the lowliest coder > to the person-in-charge, could, at any time, during any presentation, by > any speaker, shout "Rat Hole!!!" loudly enough to be heard by everyone > in the room. This would cause an immediate cessation of the current > discussion, while everyone considered whether or not we had gotten way > off topic. Usually a rough consensus formed quickly, and the group > climbed out of the Rat Hole, and resumed serious debate about whatever > the topic of the meeting was supposed to be. Even Vint Cerf could be a > "Rat Hole!" target, and IIRC he quickly agreed. > > It strikes me now that the "Rat Hole!" process was analogous to the > "Call the Question" part of Robert's Rules. It was used to halt endless > unproductive discussions and get back on track to building the Internet. > > I wonder now how important the RHP was to the success of the Internet? > Without it, would we still be arguing instead of writing code...? Hmmm, > is RHP still in use? > > Anyway, "Rat Hole!!" is my most memorable "Internet Sound". Sorry, no > audio tape that I know about. > > Jack Haverty > > > On 4/26/22 16:34, Brian E Carpenter via Internet-history wrote: > > On 27-Apr-22 09:48, Lyndon Nerenberg (VE7TFX/VE6BBM) via > > Internet-history wrote: > >>> For instance, I remember the clatter of teletypes, Telebit and Hayes > >>> modem tones, VT52 buzzes, the RF interference caused screeches from > >>> the AM radio perched near IMP #1, the PC/IP telnet "chirp", the > >>> sound of a DECwriter, etc. > >> > >> These are all generic computer sounds. Nothing to do with the Internet > >> per se. (Well, okay, the IMP :-)) > >> > >> For me, the first "sound" that I would definitively associate with > >> the Internet specifically is Carl Malamud's _Internet Talk Radio_ > >> program from 1993. > > > > "On June 24, 1993, the band Severe Tire Damage was the first to > > perform live on the Mbone." > > (https://en.wikipedia.org/wiki/Mbone#History) > > > > But there was audio and video using early versions of VIC/VAT before > > 1993. I was in a transatlantic teleconf at UCL in 1991, and I seem to > > remember remote audio in the very early days of RIPE (1989?). > > > > Archives from those days may be hard to find, however. Mark Handley > > might have some pointers for the UCL work. > > > > Regards > > Brian > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From olejacobsen at me.com Tue Apr 26 21:45:05 2022 From: olejacobsen at me.com (Ole Jacobsen) Date: Tue, 26 Apr 2022 21:45:05 -0700 Subject: [ih] Internet sounds In-Reply-To: References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <93d959cc4b869351@orthanc.ca> <758b50cc-d475-c321-ea50-e7c671725f2e@gmail.com> <755770da-818e-cfce-b1a1-531d9b0995a5@3kitty.org> Message-ID: <95E42FC0-4581-42CF-A77D-368AE2B2CD3F@me.com> I have (somewhere) an audio cassette with recordings from the early SATNET packet voice experiments between NDRE, Lincoln Labs, UCL and ISI. Maybe one of these days I'll get it converted to MP3. Ole > On Apr 26, 2022, at 21:14, Bob Purvy via Internet-history wrote: > > You know, CHM guys, we *could* actually rig up a "studio", borrow some good > mics, and record some of this stuff. I doubt it would bring in a whole LOT > of money, but maybe a few dollars. > > When I was a wee lad, my big brother actually listened to records of drag > racing sounds. You never know what people will like... > > On Tue, Apr 26, 2022 at 5:49 PM Jack Haverty via Internet-history < > internet-history at elists.isoc.org> wrote: > >> My most memorable "computer sound" of the 70s was the ear-shattering >> squeal of one of dozens of fans in various pieces of computer >> equipment. That occurred when the bearings were getting worn. Running >> 24x7 a fan would last only a few years at best. You would "test" a fan >> by just tapping on it with your finger, which of course placed your ears >> in prime striking distance of the squeal. Time to get the toolbox out >> and replace fans. I replaced a lot of fans.... >> >> "Internet sounds" are a bit more difficult. Networks were notoriously >> difficult for doing a dog-and-pony show, since there was little visible >> or audible activity involved. Not even a spinning magtape. Networks >> are definitely introverts. >> >> But I do remember one salient sound that I associate with The >> Internet. In particular, I heard it at many of the meetings of various >> working groups and committees involved in the early Internet design and >> deployment. This was all before social media, audio or video >> teleconferencing, or even the ability to send pictures or audio over the >> Net. We had to actually convene in a room somewhere to thrash out >> technical details. Time frame was roughly 1980 +- a few years. >> >> The sound I recall was an indication that the "Rat Hole Protocol" had >> been started (RHP?). >> >> What's RHP? >> >> Well, I don't remember who started it or when, but there was an >> undocumented rule at the meetings where anyone, from the lowliest coder >> to the person-in-charge, could, at any time, during any presentation, by >> any speaker, shout "Rat Hole!!!" loudly enough to be heard by everyone >> in the room. This would cause an immediate cessation of the current >> discussion, while everyone considered whether or not we had gotten way >> off topic. Usually a rough consensus formed quickly, and the group >> climbed out of the Rat Hole, and resumed serious debate about whatever >> the topic of the meeting was supposed to be. Even Vint Cerf could be a >> "Rat Hole!" target, and IIRC he quickly agreed. >> >> It strikes me now that the "Rat Hole!" process was analogous to the >> "Call the Question" part of Robert's Rules. It was used to halt endless >> unproductive discussions and get back on track to building the Internet. >> >> I wonder now how important the RHP was to the success of the Internet? >> Without it, would we still be arguing instead of writing code...? Hmmm, >> is RHP still in use? >> >> Anyway, "Rat Hole!!" is my most memorable "Internet Sound". Sorry, no >> audio tape that I know about. >> >> Jack Haverty >> >> >> On 4/26/22 16:34, Brian E Carpenter via Internet-history wrote: >>> On 27-Apr-22 09:48, Lyndon Nerenberg (VE7TFX/VE6BBM) via >>> Internet-history wrote: >>>>> For instance, I remember the clatter of teletypes, Telebit and Hayes >>>>> modem tones, VT52 buzzes, the RF interference caused screeches from >>>>> the AM radio perched near IMP #1, the PC/IP telnet "chirp", the >>>>> sound of a DECwriter, etc. >>>> >>>> These are all generic computer sounds. Nothing to do with the Internet >>>> per se. (Well, okay, the IMP :-)) >>>> >>>> For me, the first "sound" that I would definitively associate with >>>> the Internet specifically is Carl Malamud's _Internet Talk Radio_ >>>> program from 1993. >>> >>> "On June 24, 1993, the band Severe Tire Damage was the first to >>> perform live on the Mbone." >>> (https://en.wikipedia.org/wiki/Mbone#History) >>> >>> But there was audio and video using early versions of VIC/VAT before >>> 1993. I was in a transatlantic teleconf at UCL in 1991, and I seem to >>> remember remote audio in the very early days of RIPE (1989?). >>> >>> Archives from those days may be hard to find, however. Mark Handley >>> might have some pointers for the UCL work. >>> >>> Regards >>> Brian >> >> -- >> 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 Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office: +1 415-550-9433 Cell: +1 415-370-4628 Web: protocoljournal.org E-mail: olejacobsen at me.com E-mail: ole at protocoljournal.org Skype: organdemo From vgcerf at gmail.com Tue Apr 26 23:31:52 2022 From: vgcerf at gmail.com (vinton cerf) Date: Wed, 27 Apr 2022 02:31:52 -0400 Subject: [ih] A name from the past In-Reply-To: <8a5f45e6-5239-03ce-5290-ce5d372aa3ad@gmail.com> References: <20220427012637.339AF18C07E@mercury.lcs.mit.edu> <8a5f45e6-5239-03ce-5290-ce5d372aa3ad@gmail.com> Message-ID: roger scantlebury is still around and could answer questions about NPLNET. Shall I pursue? v On Tue, Apr 26, 2022 at 10:20 PM Brian E Carpenter via Internet-history < internet-history at elists.isoc.org> wrote: > On 27-Apr-22 13:26, Noel Chiappa via Internet-history wrote: > > > an article "Data Communications at the NPL (1965-1975)" in the > 'Annals > > > of the History of Computing' (as it was then; Vol 9, No 3/4, if > anyone > > > wants to look at it) > > ... > > Finally, in the "Acknowledgements" section, we find listed a "B. E. > > Carpenter", who I rather suspect is our Brian Carpenter! The paper came > out > > in 1988, and Brian had done his and Doran's book on "Turing's ACE > Report" in > > 1986, and it involved close interaction with NPL; its Acknowledgements > > section thanks Martin Campbell-Kelly, the author of the NPL history > paper. > > Yes, that would be me. I'm not sure what I contributed except reviewing > a draft. Martin essentially commissioned the ACE book for the Charles > Babbage Institute (and his wife retyped some of Turing's writing > from an almost illegible carbon copy). I was blissfully ignorant of > NPL's original network, despite having visited Donald Davies' lab > as a grad student for other reasons. > > Brian > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From vgcerf at gmail.com Tue Apr 26 23:37:30 2022 From: vgcerf at gmail.com (vinton cerf) Date: Wed, 27 Apr 2022 02:37:30 -0400 Subject: [ih] A name from the past In-Reply-To: References: <20220427012637.339AF18C07E@mercury.lcs.mit.edu> <8a5f45e6-5239-03ce-5290-ce5d372aa3ad@gmail.com> Message-ID: wikipedia: https://en.wikipedia.org/wiki/NPL_network v On Wed, Apr 27, 2022 at 2:31 AM vinton cerf wrote: > roger scantlebury is still around and could answer questions about NPLNET. > Shall I pursue? > > v > > > On Tue, Apr 26, 2022 at 10:20 PM Brian E Carpenter via Internet-history < > internet-history at elists.isoc.org> wrote: > >> On 27-Apr-22 13:26, Noel Chiappa via Internet-history wrote: >> > > an article "Data Communications at the NPL (1965-1975)" in the >> 'Annals >> > > of the History of Computing' (as it was then; Vol 9, No 3/4, if >> anyone >> > > wants to look at it) >> >> ... >> > Finally, in the "Acknowledgements" section, we find listed a "B. E. >> > Carpenter", who I rather suspect is our Brian Carpenter! The paper came >> out >> > in 1988, and Brian had done his and Doran's book on "Turing's ACE >> Report" in >> > 1986, and it involved close interaction with NPL; its Acknowledgements >> > section thanks Martin Campbell-Kelly, the author of the NPL history >> paper. >> >> Yes, that would be me. I'm not sure what I contributed except reviewing >> a draft. Martin essentially commissioned the ACE book for the Charles >> Babbage Institute (and his wife retyped some of Turing's writing >> from an almost illegible carbon copy). I was blissfully ignorant of >> NPL's original network, despite having visited Donald Davies' lab >> as a grad student for other reasons. >> >> Brian >> -- >> Internet-history mailing list >> Internet-history at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/internet-history >> > From ocl at gih.com Wed Apr 27 00:01:07 2022 From: ocl at gih.com (=?UTF-8?Q?Olivier_MJ_Cr=c3=a9pin-Leblond?=) Date: Wed, 27 Apr 2022 10:01:07 +0300 Subject: [ih] Internet sounds In-Reply-To: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> Message-ID: <9553087e-d210-7aa0-5184-fd01ae13fcf1@gih.com> For many, I would say a majority of Americans, the sound of the early Internet was: https://www.youtube.com/watch?v=dudJjUU9Nhs and in case you wanted to know whose voice it was: https://youtu.be/cv1B9sPPOXo Kindest regards, Olivier On 26/04/2022 22:51, Karl Auerbach via Internet-history wrote: > I was wondering what sounds people associate with the early Internet. > > For instance, I remember the clatter of teletypes, Telebit and Hayes > modem tones, VT52 buzzes, the RF interference caused screeches from > the AM radio perched near IMP #1, the PC/IP telnet "chirp", the sound > of a DECwriter, etc. > > (I also wonder if anyone might have recordings, particularly of the > VT52 razzy buzz or the PC/IP telnet "chirp".) > > ??? --karl-- > > > -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html From robert.mcmillan at wsj.com Wed Apr 27 09:31:56 2022 From: robert.mcmillan at wsj.com (McMillan, Robert) Date: Wed, 27 Apr 2022 12:31:56 -0400 Subject: [ih] Internet sounds In-Reply-To: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> Message-ID: This show is focused on Windows sounds, but at the very beginning it has a great archival recording of a 1960s computer starting up. https://www.20k.org/episodes/tadaitswindows Bob On Tue, Apr 26, 2022 at 3:51 PM Karl Auerbach via Internet-history < internet-history at elists.isoc.org> wrote: > I was wondering what sounds people associate with the early Internet. > > For instance, I remember the clatter of teletypes, Telebit and Hayes > modem tones, VT52 buzzes, the RF interference caused screeches from the > AM radio perched near IMP #1, the PC/IP telnet "chirp", the sound of a > DECwriter, etc. > > (I also wonder if anyone might have recordings, particularly of the VT52 > razzy buzz or the PC/IP telnet "chirp".) > > --karl-- > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From craig at tereschau.net Wed Apr 27 09:49:01 2022 From: craig at tereschau.net (Craig Partridge) Date: Wed, 27 Apr 2022 10:49:01 -0600 Subject: [ih] Internet sounds In-Reply-To: References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> Message-ID: My favorite sound memory is hearing the Mark I computer (1940s computer) fire up. The background is amusing. In the 1970s/1980s half of the Mark I was on display in Harvard's computer science building (the other half had been sent to the Smithsonian I believe). So a register bank, two paper tape readers, and some memory. One evening a few of us were curious and started looking it over closely, when one guy (Marc Elvy, brilliant guy who died too young) noted that the machine was plugged in and decided to flip the on switch. It started! The Mark I used a rotor to synchronize all the parts and the roar of the rotor and the noise of the card readers and relays clattering was impressive (if short-lived -- we immediately yelled "turn it off" for fear of damaging it). Craig On Wed, Apr 27, 2022 at 10:32 AM McMillan, Robert via Internet-history < internet-history at elists.isoc.org> wrote: > This show is focused on Windows sounds, but at the very beginning it has a > great archival recording of a 1960s computer starting up. > > https://www.20k.org/episodes/tadaitswindows > > Bob > > > > On Tue, Apr 26, 2022 at 3:51 PM Karl Auerbach via Internet-history < > internet-history at elists.isoc.org> wrote: > > > I was wondering what sounds people associate with the early Internet. > > > > For instance, I remember the clatter of teletypes, Telebit and Hayes > > modem tones, VT52 buzzes, the RF interference caused screeches from the > > AM radio perched near IMP #1, the PC/IP telnet "chirp", the sound of a > > DECwriter, etc. > > > > (I also wonder if anyone might have recordings, particularly of the VT52 > > razzy buzz or the PC/IP telnet "chirp".) > > > > --karl-- > > > > > > > > -- > > 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 bpurvy at gmail.com Wed Apr 27 09:54:13 2022 From: bpurvy at gmail.com (Bob Purvy) Date: Wed, 27 Apr 2022 09:54:13 -0700 Subject: [ih] Internet sounds In-Reply-To: References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> Message-ID: I've looked into these sound libraries. We might make *dozens* of dollars creating one! It would be fun, though. On Wed, Apr 27, 2022 at 9:49 AM Craig Partridge via Internet-history < internet-history at elists.isoc.org> wrote: > My favorite sound memory is hearing the Mark I computer (1940s computer) > fire up. The background is amusing. In the 1970s/1980s half of the Mark I > was on display in Harvard's computer science building (the other half had > been sent to the Smithsonian I believe). So a register bank, two paper > tape readers, and some memory. One evening a few of us were curious and > started looking it over closely, when one guy (Marc Elvy, brilliant guy who > died too young) noted that the machine was plugged in and decided to flip > the on switch. It started! The Mark I used a rotor to synchronize all the > parts and the roar of the rotor and the noise of the card readers and > relays clattering was impressive (if short-lived -- we immediately yelled > "turn it off" for fear of damaging it). > > Craig > > > On Wed, Apr 27, 2022 at 10:32 AM McMillan, Robert via Internet-history < > internet-history at elists.isoc.org> wrote: > > > This show is focused on Windows sounds, but at the very beginning it has > a > > great archival recording of a 1960s computer starting up. > > > > https://www.20k.org/episodes/tadaitswindows > > > > Bob > > > > > > > > On Tue, Apr 26, 2022 at 3:51 PM Karl Auerbach via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > > > I was wondering what sounds people associate with the early Internet. > > > > > > For instance, I remember the clatter of teletypes, Telebit and Hayes > > > modem tones, VT52 buzzes, the RF interference caused screeches from the > > > AM radio perched near IMP #1, the PC/IP telnet "chirp", the sound of a > > > DECwriter, etc. > > > > > > (I also wonder if anyone might have recordings, particularly of the > VT52 > > > razzy buzz or the PC/IP telnet "chirp".) > > > > > > --karl-- > > > > > > > > > > > > -- > > > 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 tte at cs.fau.de Thu Apr 28 08:34:05 2022 From: tte at cs.fau.de (Toerless Eckert) Date: Thu, 28 Apr 2022 17:34:05 +0200 Subject: [ih] Internet sounds In-Reply-To: <758b50cc-d475-c321-ea50-e7c671725f2e@gmail.com> References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <93d959cc4b869351@orthanc.ca> <758b50cc-d475-c321-ea50-e7c671725f2e@gmail.com> Message-ID: On Wed, Apr 27, 2022 at 11:34:13AM +1200, Brian E Carpenter via Internet-history wrote: > > For me, the first "sound" that I would definitively associate with > > the Internet specifically is Carl Malamud's _Internet Talk Radio_ > > program from 1993. > > "On June 24, 1993, the band Severe Tire Damage was the first to > perform live on the Mbone." > (https://en.wikipedia.org/wiki/Mbone#History) > > But there was audio and video using early versions of VIC/VAT before > 1993. I was in a transatlantic teleconf at UCL in 1991, and I seem to > remember remote audio in the very early days of RIPE (1989?). Same here. Alas i do not remember the exact dates, but the first sound "across" the Internet for me was most likely VIC/VAT conferences too. MICE project @UCL for example was quite active. I think to remember that the "places all over the world" channel also had audio and of course my later boss was at NASA posting NASA TV to the MBone. think We also quickly "commercialized" the MBone ourselves to replace actual monthly business travel in our region (bavaria). Other early sounds would be early multi-user XWindows games that we played even between cities. In my experience, that remote display rendering was was fast enough with 64kbps links, which we got at hmm. 1988 i think. And those games had some bits of sounds.. Equipment noise specific to Internet/networking was more boring in that time-frame when one luckily didn't have to work with actual audio channel modems (or didn't do audiofications? like Carsten - Nice!). I guess most home users would still consider such modem noise as Internet noise throughout the 90th. I mostly remember that i had to start complaining about the noise of router fans starting at the end of the 80, and couldn't stop silencing them myself until about 20 years later, when there where seemingly enough user who complained about it so vendors started to put in silent fans. Cheers Toerless > Archives from those days may be hard to find, however. Mark Handley > might have some pointers for the UCL work. > > Regards > Brian > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history -- --- tte at cs.fau.de From casner at acm.org Thu Apr 28 23:12:50 2022 From: casner at acm.org (Stephen Casner) Date: Thu, 28 Apr 2022 23:12:50 -0700 (PDT) Subject: [ih] Internet sounds In-Reply-To: References: <1a323e34-7a8d-1203-93a8-ce7d2f634522@cavebear.com> <93d959cc4b869351@orthanc.ca> <758b50cc-d475-c321-ea50-e7c671725f2e@gmail.com> Message-ID: On Thu, 28 Apr 2022, Toerless Eckert via Internet-history wrote: > On Wed, Apr 27, 2022 at 11:34:13AM +1200, Brian E Carpenter via Internet-history wrote: > > > For me, the first "sound" that I would definitively associate with > > > the Internet specifically is Carl Malamud's _Internet Talk Radio_ > > > program from 1993. > > > > "On June 24, 1993, the band Severe Tire Damage was the first to > > perform live on the Mbone." > > (https://en.wikipedia.org/wiki/Mbone#History) > > > > But there was audio and video using early versions of VIC/VAT before > > 1993. I was in a transatlantic teleconf at UCL in 1991, and I seem to > > remember remote audio in the very early days of RIPE (1989?). > > Same here. Alas i do not remember the exact dates, but the first sound > "across" the Internet for me was most likely VIC/VAT conferences too. > MICE project @UCL for example was quite active. I think to remember > that the "places all over the world" channel also had audio > and of course my later boss was at NASA posting NASA TV to the MBone. > think We also quickly "commercialized" the MBone ourselves to replace > actual monthly business travel in our region (bavaria). If we want to take packet audio transmissions as examples of Internet sounds, then the earliest dates would depend upon one's definition of "Internet". The initial packet voice experiments over ARPANET started in 1974. That audio in CVSD and LPC encoding suffered from various artifacts. The 1978 ISI movie spearheaded by Danny Cohen and titled Digital Voice Conferencing includes a soundtrack in the LPC encoding. During the June 1982 program review meeting at Lincoln Lab there were several demos including a four-party conference with participants on the Packet Radio Net, the Wideband Net and LEXNET at Lincoln. I don't remember if any of that was recorded, but Cliff Weinstein might. Later in the 1980s packet video was added and the implementation of video conferencing over the Wideband Net stabilized to the point that unrelated groups used it for distributed meetings. But by then the sound was not unique to Internet. The first IETF audiocast was from San Diego in March 1992. This was a precursor to the MBone with an ad-hoc set of IP multicast tunnels connected to the DARTnet as the core network. vat and NEVOT were in use. Some of that might have been recorded, but it was 64kbps mu-law audio, same as long-distance telephony, so again the sound was not unique to the Internet. Some initial slow-frame-rate video was included for the next IETF in Cambridge, MA in July 1992. The name "MBone" was coined at the end of that meeting when we set a goal to keep the ad-hoc multicast tunnels operational between meetings and to improve their organization. Over the next couple of years the nv program was the first MBone video tool to be used widely, then later VIC. -- Steve From pnr at planet.nl Sat Apr 30 02:01:44 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 30 Apr 2022 11:01:44 +0200 Subject: [ih] Internet sounds In-Reply-To: References: Message-ID: According to wikipedia, the ?IMPs? of Pouzin's CYCLADES network - called CIGALEs - had a speaker attached; according to Wikipedia: "The name CIGALE (French pronunciation: ?[si?al]) ? French for cicada ? originates from the fact that the developers installed a speaker at each computer, so that "it went 'chirp chirp chirp' like cicadas" when a packet passed a computer.? I've always wondered what that sounded like, but I would not expect any recordings or recreations to exist. > On 29 Apr 2022, at 21:00, internet-history-request at elists.isoc.org wrote: > > Send Internet-history mailing list submissions to > internet-history at elists.isoc.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://elists.isoc.org/mailman/listinfo/internet-history > or, via email, send a message with subject or body 'help' to > internet-history-request at elists.isoc.org > > You can reach the person managing the list at > internet-history-owner at elists.isoc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Internet-history digest..." > > > Today's Topics: > > 1. Re: Internet sounds (Stephen Casner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Apr 2022 23:12:50 -0700 (PDT) > From: Stephen Casner > To: Toerless Eckert > Cc: Brian E Carpenter , > internet-history at elists.isoc.org > Subject: Re: [ih] Internet sounds > Message-ID: > > Content-Type: text/plain; charset=US-ASCII > > On Thu, 28 Apr 2022, Toerless Eckert via Internet-history wrote: > >> On Wed, Apr 27, 2022 at 11:34:13AM +1200, Brian E Carpenter via Internet-history wrote: >>>> For me, the first "sound" that I would definitively associate with >>>> the Internet specifically is Carl Malamud's _Internet Talk Radio_ >>>> program from 1993. >>> >>> "On June 24, 1993, the band Severe Tire Damage was the first to >>> perform live on the Mbone." >>> (https://en.wikipedia.org/wiki/Mbone#History) >>> >>> But there was audio and video using early versions of VIC/VAT before >>> 1993. I was in a transatlantic teleconf at UCL in 1991, and I seem to >>> remember remote audio in the very early days of RIPE (1989?). >> >> Same here. Alas i do not remember the exact dates, but the first sound >> "across" the Internet for me was most likely VIC/VAT conferences too. >> MICE project @UCL for example was quite active. I think to remember >> that the "places all over the world" channel also had audio >> and of course my later boss was at NASA posting NASA TV to the MBone. >> think We also quickly "commercialized" the MBone ourselves to replace >> actual monthly business travel in our region (bavaria). > > If we want to take packet audio transmissions as examples of Internet > sounds, then the earliest dates would depend upon one's definition of > "Internet". The initial packet voice experiments over ARPANET started > in 1974. That audio in CVSD and LPC encoding suffered from various > artifacts. The 1978 ISI movie spearheaded by Danny Cohen and titled > Digital Voice Conferencing includes a soundtrack in the LPC encoding. > > During the June 1982 program review meeting at Lincoln Lab there were > several demos including a four-party conference with participants on > the Packet Radio Net, the Wideband Net and LEXNET at Lincoln. I don't > remember if any of that was recorded, but Cliff Weinstein might. > > Later in the 1980s packet video was added and the implementation of > video conferencing over the Wideband Net stabilized to the point that > unrelated groups used it for distributed meetings. But by then the > sound was not unique to Internet. > > The first IETF audiocast was from San Diego in March 1992. This was a > precursor to the MBone with an ad-hoc set of IP multicast tunnels > connected to the DARTnet as the core network. vat and NEVOT were in > use. Some of that might have been recorded, but it was 64kbps mu-law > audio, same as long-distance telephony, so again the sound was not > unique to the Internet. > > Some initial slow-frame-rate video was included for the next IETF in > Cambridge, MA in July 1992. The name "MBone" was coined at the end of > that meeting when we set a goal to keep the ad-hoc multicast tunnels > operational between meetings and to improve their organization. Over > the next couple of years the nv program was the first MBone video tool > to be used widely, then later VIC. > > -- Steve > > > ------------------------------ > > 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 31, Issue 22 > ************************************************