[ih] A revolution in Internet point-of-view - Was Re: Internet analyses (Was Re: IPv8...)

[Jack Haverty]

Connectors are everywhere.  Even in software.  We call them APIs, or 
protocols, depending on how many computers are involved.  But they are 
essentially also "connectors".   Corrosion happens too, but in a 
different way from metal sliding on metal in plugs and sockets.

Wherever there is a software connector, chances are that the things on 
either side were built by different people.  Specs are often incomplete 
or imprecise and different people interpret them differently.  Corrosion 
happens when new software is released and behaves differently when using 
an existing API or protocol.  Connectors, of all types, are causes of 
many computer and network problems.

When TCP2 was evolving into TCP4, we added a bunch of tools to help in 
diagnosing network problems.  One example was the various "source 
routing" mechanisms, which would be especially helpful when The Internet 
was experiencing some kind of problem in the routing mechanisms.  Many 
of these were subsequently discarded as being unnecessary, which was 
true, but only in the situation where the network was working perfectly.

Modularity is considered a good thing, but implies a need for 
connectors.  When people actually experience troubleshooting and 
operational problems they find the problems with all types of 
connectors.   I think too few software or protocol designers ever 
actually get experience in operations, so they never learn the issues 
associated with connectors.

I've wondered what effect "connectors" have on the users' and ISPs' 
experience in The Internet and how it's changed over time.

For example, I suspect most ISPs pay some attention to their own 
system's handling of IP datagrams, perhaps collecting data through SNMP 
or other mechanisms, and fixing problems as they notice them.

But does anybody watch how their computers behave?  TCP puts much of the 
error-control mechanisms in the users' devices, where it operates to 
compensate for lost datagrams and other failures of the underlying 
datagram service.

When I was involved in operating pieces of The Internet, it was common 
to see problems in TCP behavior, such as excessive and persistent 
unnecessary retransmissions.  In effect, the "connector" of TCP between 
two computers was "corroded" and causing failures, which the human user 
often wouldn't even notice.

SNMP had definitions useful for monitoring TCP behavior, and some TCP 
implementations actually provided them.   We found them to be a valuable 
tool for diagnosing network problems.   They were also valuable for 
detecting problems, by enabling comparisons of past "good" behavior 
versus measured behavior now.

TCP is very good at hiding problems from both the human users and the 
operators tasked with keeping the datagrams flowing.

In today's Internet, does anyone monitor TCP behavior?   A TCP 
connection may involve paths through several ISPs, and their 
"connectors".  How are users' problems diagnosed?  How has that part of 
network management changed over time?

Fortunately, our cat hasn't figured out how to use software "connectors" 
to get a human's attention.  He does know how to do so by chewing 
through an Ethernet cable.  He does also attack the software connectors, 
so far unsuccessfully.  Walking on a keyboard, even with paws, may 
eventually do something really nasty.

/Jack Haverty

On 5/1/26 00:29, vinton cerf via Internet-history wrote:
> Dave,
> I think it was more than that - a real software problem requiring
> recompilation and reloading of the HP print system. I did have a connector
> problem but it was associated with the demonstration of Arpanet conducted
> in 1974 or 1975 from Sao Paulo, Brazil.
>
>
>
>
> On Thu, Apr 30, 2026 at 11:06 PM Dave Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> On 4/30/2026 4:55 PM, vinton cerf wrote:
>>> To add to Dave's story
>>
>> Since MCI Mail wound up being relevant to Internet history, when Vint
>> used MMDF to interconnect with Internet mail, I'll add to his addition.
>>
>> MCI Mail was built using a collection of vendors for different parts of
>> the system. (HP had the remote laster printers.)
>>
>> Six months before the scheduled public demo was the first meeting, with
>> all the vendors in the same room.
>>
>> Vint got up to greet everyone and set the stage.  He said we did not
>> have much time but we were going to meet the September deadline.  Then
>> he said that if anything stopped us -- not that it would, but if it did
>> -- it would be a connector.
>>
>> As I recall, that middle-of-the-night-before-the-demo problem that Vint
>> described turned out to be a connector.
>>
>> d/
>>
>> --
>> Dave Crocker
>>
>> dhc at dcrocker.net
>> bluesky: @dcrocker.bsky.social
>> mast: @dcrocker at mastodon.social
>> +1.408.329.0791
>>
>> Volunteer, Silicon Valley Chapter
>> Northern California Coastal Region
>> Information & Planning Coordinator
>> American Red Cross
>> dave.crocker2 at redcross.org
>>
>> --
>> 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
>>

-------------- 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/20260501/871d2da1/attachment.asc>