[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