[ih] state of the internet probes? (was Re: AOL in perspective)
Andrew G. Malis
agmalis at gmail.com
Thu Sep 18 13:35:46 PDT 2025
Jack,
Source routing for IPv4 and v6 is back in a huge way and is now in use
operationally for traffic engineering. See the work of the IETF's SPRING
working group:
https://datatracker.ietf.org/wg/spring/about/ for the working group.
RFC 7855 <https://www.rfc-editor.org/rfc/rfc7855.html> for the intro and
use cases.
Cheers,
Andy
On Wed, Sep 17, 2025 at 6:27 PM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:
> We didn't do a good job of documenting the various features of Internet
> technology that were put in to address operational issues during the
> major overhaul to evolve TCP2 into TCP4. Jil's work, and SNMP, came
> several years later. The features needed to support operations included
> a nonitoring/control protocol such as SNMP, but also lots of other
> mechanisms.
>
> One example I remember involved routing. The experience with the
> ARPANET had revealed that the most difficult operational problems were
> associated with failures of routing, which could be caused by bugs or
> even hardware failures. When routing didn't work, it was difficult or
> impossible to communicate with IMPs from the NOC.
>
> To provide some tools for such situations, several different kinds of
> "source routing" were added to IP. Source routing enabled a host
> computer to dictate the route that a datagram would take. It
> effectively bypassed the routing mechanisms of the gateways, so it could
> be used even while the routing mechanism was broken. Similarly, a
> TypeOfService value could be used to indicate that particular datagrams
> be placed at the head of a queue, to force them to be handled even when
> congestion was occurring. Source Routing could also be used for many
> everyday operations work, such as testing specific interfaces on a
> gateway somewhere out in the Internet, e.g., to figure out why it wasn't
> being used by Routing. That was the way to get management packets
> delivered.
>
> There were also other uses of Source Routing as workarounds for Internet
> capabilities that hadn't been figured out yet. For example, there was a
> perceived need for things like "Policy-Based Routing", "Lowest-Latency
> Routing", "Expressway Routing", and other such needs that the simple
> hop-count routing couldn't address. Source Routing provided a way to
> manually specify desired routes, while research continued into how to
> put the appropriate capabilities into the base protocols.
>
> IIRC, none of that was explained in the specs of IPV4. Unfortunately it
> was defined as "Options", so it might not have even been implemented in
> some OSes, or tested if it was. When IPV6 was being defined, I suspect
> the reasons for such features in IPV4 were forgotten, and not included
> in V6.
>
> IMHO, people who design protocols should also at some point operate them.
>
> Jack
>
> On 9/17/25 14:48, Craig Partridge wrote:
> > I wrote too swiftly. I suspect Jack may be remembering a DARPA
> > project that Jil Wescott led that sought to build a distributed
> > network management service (the idea being the service talked to all
> > devices on the network, and then any monitoring app could simply
> > connect to the service and learn what was going on -- this meant
> > managed devices weren't getting bombarded with pings and such and
> > could do their job). Her team included Charlie Lynn and Ross Callon
> > and Karen Seo, and in odd moments, me.
> >
> > I took some of the lessons from that project to HEMS. I will say I
> > got the lesson half-right/half-wrong. The right part, and this one of
> > Jil's big takeaways, was if the network is a mess, you are only going
> > to get some management packets through, so make sure each has as much
> > information/does as much as possible. The wrong part was my take was
> > a sick network meant use TCP, because TCP will fight to get your data
> > -- whereas others argued it was UDP, because UDP, while unreliable,
> > often did a great job of getting *a* packet through.
> >
> > SNMP chose UDP (rightly) and put the minimum info in each packet
> > (which I continue to think was a mistake :-)).
> >
> > Craig
> >
> > On Wed, Sep 17, 2025 at 3:39 PM Craig Partridge <craig at tereschau.net>
> > wrote:
> >
> > SNMP was a simplified network management protocol influenced
> > primary by HEMS (which got to the RFC stage and a prototype but
> > never launched) and a little bit by the nascent CMIP.
> >
> > Craig (who co-created HEMS with Glen Trewitt)
> >
> > On Wed, Sep 17, 2025 at 3:32 PM Jack Haverty via Internet-history
> > <internet-history at elists.isoc.org> wrote:
> >
> > Right, SNMP came later, as a "Simplified" version of NMP -
> > Network
> > Management Protocol, which may have only existed in email
> > discussions.
> >
> > IIRC, the earliest work on Internet management was done by David
> > Floodpage as part of the "make Internet 24x7" work, and
> > documented in
> > some IENs, e.g., https://www.rfc-editor.org/ien/ien132.txt
> >
> > All that led eventually to SNMP, which is what is most likely
> > to be
> > recognized today.
> >
> > Jack
> >
> > On 9/17/25 13:46, Barbara Denny via Internet-history wrote:
> > > Jack,
> > > I think you may have meant to type SMTP or something else,
> > not SNMP.
> > > SNMP was more in the time frame of my looking at network
> > management startups.
> > > barbara
> > > On Wednesday, September 17, 2025 at 01:29:11 PM PDT,
> > Barbara Denny via
> > Internet-history<internet-history at elists.isoc.org> wrote:
> > >
> > > Sun was definitely selling workstations when I got to SRI
> > in the fall of 1983. I remembered being surprised that I had
> > a model 100 in my office when I arrived.
> > > Then in the mid to late? 1980s Network management startup
> > offerings would just use ping to figure out their customer's
> > network (well maybe not all of them). I briefly looked at
> > them to decide what we might install for a military testbed in
> > South Korea.
> > > barbara
> > > On Wednesday, September 17, 2025 at 12:58:28 PM PDT,
> > Jack Haverty via
> > Internet-history<internet-history at elists.isoc.org> wrote:
> > >
> > > FYI, I don't recall ever seeing any "status report"
> > myself, probably
> > > because I didn't use any of the computers involved. I don't
> > know much
> > > of the history of BSD. My recollection is that the
> > incident involved
> > > the DEC Vax machines which were becoming more prolific at
> > the time. It
> > > was sometime around 1980 +- a few years, definitely before
> > July 1983
> > > when I switched jobs.
> > >
> > > I remember that the way the incident was stopped involved
> > someone at
> > > ARPA (Vint Cerf? Barry Leiner? Bob Kahn?). They had
> > leverage over
> > > the OS since it was a project funded by ARPA. The source
> > of the
> > > changes in traffic may not have been the OS itself, but
> > perhaps some
> > > user-level program that was either distributed with, or
> > updated, a new
> > > OS release. It's possible that Sun was involved too, if
> > only because
> > > ARPA projects were significant customers. But I thought
> > Sun emerged a
> > > bit later in the 1980s.
> > >
> > > /Jack
> > >
> > > On 9/17/25 08:46, Jeremy C. Reed wrote:
> > >> On Thu, 4 Sep 2025, Jack Haverty via Internet-history wrote:
> > >>
> > >>> Several years later, circa 1980, we had a similar
> > experience with the
> > >>> ARPANET and the emerging Internet which was being built
> > around it.
> > >>> Lots of now inexpensive minicomputer gear had appeared on the
> > >>> Internet, connected by LANs to the ARPANET. I was the
> > "Internet guy"
> > >>> at BBN, and one day a NOC operator stuck his head in my
> > office and
> > >>> said something like "What's your Internet doing!!?" It
> > was probably
> > >>> a bit more colorful than that. The ARPANET was thrashing
> > again, and
> > >>> the NOC had traced the problem to traffic to/from
> > gateways. That
> > >>> made it my problem.
> > >>>
> > >>> Debug, XNET, SNMP, ... IIRC, it turned out that Berkeley
> > had just
> > >>> released a new version of BSD, and announced it to the user
> > >>> community. There were a lot of BSD systems out there.
> > The new BSD
> > >>> included a new feature, that probed all the gateways out
> > on the
> > >>> ARPANET and generated a status report of "State of the
> > Internet".
> > >>> Updated automatically of course.
> > >>>
> > >>> The server that performed all that probing was part of the
> > new OS
> > >>> release. And... it was "enabled" by default. So as the
> > new release
> > >>> propagated out into all those systems, they all started
> > probing every
> > >>> gateway continuously. Like Marc's SURVEY program, this
> > caused the
> > >>> ARPANET to internally hemorrhage. A quick call to ARPA,
> > and a quick
> > >>> order to Berkeley, and the cyberattack stopped. Took a
> > while IIRC.
> > >> What is this automated probing of all gateways to generate
> > a report?
> > >>
> > >> (I tried looking at all known BSD releases but cannot find
> > yet.)
> > >>
> > >> I had also read a story about an overload and that Sun or
> > Berkeley had
> > >> a new release with a tool to continuously probe every
> > gateway on the
> > >> Arpanet to maintain a little display of the state. (I
> > cannot find who
> > >> I got it from and I asked again this month who I thought I
> > got it from
> > >> but no memory of it.)
> > >>
> > >> Does anyone know what this tool was? Was it Sun or BSD?
> > >>
> > >> Any example of the status report or display?
> > >
> > >
> > >
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> > -
> > Unsubscribe:
> >
> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
> >
> >
> >
> > --
> > *****
> > Craig Partridge's email account for professional society
> > activities and mailing lists.
> >
> >
> >
> > --
> > *****
> > 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
> -
> Unsubscribe:
> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>
More information about the Internet-history
mailing list