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

Jack Haverty via Internet-history <[email protected]> Fri, 1 May 2026 13:58:12 -0700
Newsgroups	gmane.culture.internet.history
Message-ID	<[email protected]>
Yes!  Once a User gets something working at all, performance is the next 
issue.

I remember using a tool called a "waterfall diagram" to analyze 
performance isues as the ARPANET evolved into the DDN through the late 
1980s.  All it required was a pencil and paper, and knowledge or tools 
to determine how an application worked.  Many old systems were being 
brought online to DDN, and many of them worked but took forever to do 
users' commands.

The diagrams were very useful in analyzing performance issues on 
networks, especially as RPC (Remote Procedure Call) mechanisms started 
to appear.   It was easy to spread an application across a network, with 
clients and servers interacting in the same way they had inside a single 
machine.

Very few seemed to understand that calls to a library routine inside one 
computer could happen much faster than calls that had to traverse a 
network.   So design of an application made a big difference in 
performance over a network.  The waterfall diagram is still used today 
to analyze performance issues involving websites.

When I got to Oracle as "Internet Architect" in 1990 there were few 
others, especially in customers' IT, that knew much about networks. It 
was also the era when "Global LANs" were being aggressively promoted, 
which further hid the unavoidable effects of physical geography.  The 
speed of light (or electrons) stayed the same.   I ended up giving lots 
of talks internally and to customers about the impacts of networking on 
their application designs, and how to use the waterfall diagram to 
figure out what was going on.

But I can't recall where I learned about the idea of waterfall 
diagrams.  Does anyone remember the origin of "waterfall diagrams" or 
how they were used in areas before networking?

/Jack Haverty

On 5/1/26 12:28, Steve Crocker wrote:
> Indeed!  I learned the hard way to check performance issues as well as correctness when lashing separate services together.  Interactions that look like they'll happen in microseconds sometimes take millions of microseconds, ie seconds, with very unpleasant consequences.
>
> Steve
>
> Sent from my iPhone
>
>> On May 1, 2026, at 3:24 PM, Jack Haverty via Internet-history <[email protected]> wrote:
>>
>> 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 <
>>> [email protected]> 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
>>>>
>>>> [email protected]
>>>> bluesky: @dcrocker.bsky.social
>>>> mast: @[email protected]
>>>> +1.408.329.0791
>>>>
>>>> Volunteer, Silicon Valley Chapter
>>>> Northern California Coastal Region
>>>> Information & Planning Coordinator
>>>> American Red Cross
>>>> [email protected]
>>>>
>>>> --
>>>> Internet-history mailing list
>>>> [email protected]
>>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>> -
>>>> Unsubscribe:
>>>> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>>>>
>> --
>> Internet-history mailing list
>> [email protected]
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -
>> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>> <OpenPGP_signature.asc>

-- 
Internet-history mailing list
[email protected]
https://elists.isoc.org/mailman/listinfo/internet-history
-
Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
OpenPGP_signature.asc (application/pgp-signature, 665 B)