[ih] state of the internet probes? (was Re: AOL in perspective)
Karl Auerbach
karl at iwl.com
Thu Sep 18 15:46:47 PDT 2025
How does this new work dovetail, if at all with the Nimrod idea? (I
think Noel C. is present on this list. And it would certainly make Dave
Bridgham happy.)
I know this is not a question or observation of Internet History but I
am wondering about the collision - at least I consider it a collision -
between classic Internet packet routing and traffic engineering (e.g.
MPLS or source routing) and Software Defined (SD) networks? (I consider
SD to be rather a return to hard-nosed concepts of IBM's SNA LU6.2 where
things are nailed down and under the management of a central system that
computes and then distributes forwarding tables.)
Back around year 2000 I helped a bit on a DARPA project that was looking
at coupling traffic modelling, service level agreements, and, when
deviations occurred, troubleshooting (I am a repairman at heart). We
were computing end-to-end MPLS paths and deploying those, and
pre-deploying fail-over paths, based on a rather dynamic input of
service level demands. Our fail-over requirement was 150 milliseconds
in order to sustain usable conversational (two way) voice.
--karl--
On 9/18/25 1:35 PM, Andrew G. Malis via Internet-history wrote:
> 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