[ih] state of the internet probes? (was Re: AOL in perspective)

[Jack Haverty]

Apologies if you already got this message.   I didn't receive it from the ISOC reflector, but I did get the error report below, which advises me that something went wrong and to send mail to postmaster for further help.  But postmaster at what site?

Seems ironic that my reply about the lack of operations focus triggered a connection timeout somewhere in the bowels of the Internet, highlighting the very issue of handling problems occurring during operations.

/Jack

============================================================

This is the mail system at host smtp-out.flockmail.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                    The mail system

<internet-history at elists.isoc.org>: connect to elists.isoc.org[4.31.198.48]:25:
     Connection timed out


Reporting-MTA: dns; smtp-out.flockmail.com
X-Postfix-Queue-ID: 04DE6140028
X-Postfix-Sender: rfc822;jack at 3kitty.org
Arrival-Date: Wed, 17 Sep 2025 20:35:51 +0000 (UTC)

Final-Recipient: rfc822;internet-history at elists.isoc.org
Original-Recipient:rfc822;internet-history at elists.isoc.org
Action: failed
Status: 4.4.1
Diagnostic-Code: X-Postfix; connect to elists.isoc.org[4.31.198.48]:25:
     Connection timed out


ForwardedMessage.eml

Subject:
Re: [ih] state of the internet probes? (was Re: AOL in perspective)
From:
Jack Haverty <jack at 3kitty.org>
Date:
9/17/25, 13:35

To:
internet-history at elists.isoc.org


On 9/17/25 12:52, Karl Auerbach via Internet-history wrote:
>
> It bothers me that the IETF does not have a formal effort to assure 
> that all Internet protocol designs are coupled to evaluations of 
> failure modes, designation of test points, and tools to exercise those 
> test points.  I really fear a Rub-Goldberg-ization of the Internet.

I share your concern.  Over the years I've learned that very few 
designers and implementers of protocols and algorithms are also ever 
actually involved in operating the things they built.  In development 
you have lots of tools to debug, and the ability to just stop a system 
and slowly run it with lots of breakpoints to see where it's flawed.

But in operations, the primary objective is to get the system running 
again as fast as possible.

So, there's very few tools built in to the designs, but intended for use 
in operations.  When I took over the gateway project with the charter to 
make it 24x7 operational, we adopted many of the tools and techniques 
that had been created over a decade of ARPANET operations.  The ARPANET 
as designed didn't have such tools either, but by then a decade of 
operational necessity had created them.

Some of those "Internet operations tools" were captured in ICMP. But 
ICMP was not included in the DoD Standards in the early 1980s, and we 
had to lobby hard to get it implemented.  People couldn't understand why 
it was necessary.  Over time since then, I think some of those tools 
have been deprecated and are now not implemented any more, because no 
one remembers why they were there and what good they were.

Designers tend to assume everything will work perfectly, as the system 
is designed to do.  Operators know it doesn't work that way.

/Jack

PS - in the 1970s, we kept a cheap AM radio by our PDP-10 system 
console.  By tuning it to an unused frequency, you could tell what the 
OS was doing by simply listening to the noise patterns in the static.    
Sound was also useful.  I'll never forget the blood-curdling screams of 
a cooling fan as it failed deep inside some computer cabinet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250917/840b82e1/attachment.asc>