[ih] Internet analyses (Was Re: IPv8...)

[Brian E Carpenter]

Jack,

I dunno. I just haven't thought about these questions since I first read
Saltzer et al [1] and thought "That's right." There's also [2] of course.

If there have been retrospective studies, I guess they are most likely to
be somewhere in the archives of ACM CCR.

Later, the industry managed to break the model by inventing middleboxes,
which I've always regretted [3].

Back in the multiprotocol days of the 1980s we (CERN) spent a lot of
time and effort on application layer gateways, which sound a bit like
your Oracle "Interchange", and we were very, very glad when we could
throw those away.

Regards/Ngā mihi
    Brian Carpenter

[1] https://dl.acm.org/doi/10.1145/357401.357402
[2] http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-clark.html
[3] https://www.rfc-editor.org/rfc/rfc3234.html

On 24-Apr-26 07:38, Jack Haverty via Internet-history wrote:
> Thanks, Greg.  Those studies are not quite what I was seeking.  I was
> curious if there had been "system level" analyses of different
> approaches, decisions made, and results from field observations, and
> conclusions about which was the "right choice" with retrospective
> experience.
> 
> For example, the ARPANET (and others) provided a "virtual circuit"
> service to its attached computers.  In the Internet, TCP provided a
> similar service of a reliable byte-stream between two computers.
> 
> Early ARPANET analyses, circa 1970s or before, analyzed various
> techniques for providing a virtual circuit service.  For example, I
> recall reading arguments proposing or opposing the use of a "front-end"
> to hold much of the communications mechanisms, in lieu of putting such
> mechanisms in the attached computers.   The resultant implementation had
> the ARPANET composed of IMP minicomputers, where much of the flow,
> error, addressing, and such communications mechanisms were implemented.
> 
> In contrast, the TCP architecture moved much of that same kind of
> mechanism into the attached computers, rather than into all of the
> various switching boxes that most underlying component networks.  There
> were some "front end" implementations of TCP, but I think they all died
> out.  While I was at BBN, I saw evidence in comments in IMP code that
> indicated other ideas for Internet capabilities were being considered
> for implementation within IMPs.  For example, there were comments in the
> IMP code about things like "network numbers" of other networks.
> 
> A "system level" analysis might have compared these two approaches.  The
> ARPANET ran for more than a decade and was measured a lot, so the data
> about its behavior may still be available.  The Internet has been
> operational for more than 40 years, so lots of operational data may also
> be available.  A system analysis would consider performance, efficiency,
> reliability, and even things like economics.
> 
> For example, the recent discussions about "installed base" effects might
> be analyzed from an economics perspectove; the "installed base" of the
> TCP universe is not only large because of all the devices and people we
> now have using the Internet, the architectural differences alone make a
> TCP network "larger" than a similar-sized ARPANET.   Such effects were
> even noticeable back in the early 1980s, when the Internet wasn't much
> bigger than the ARPANET by itself.  Changing some mechanism or protocol
> in an IMP was a lot easier than changing a similar mechanism in TCP,
> which had all sorts of computers, operating systems, and organizations
> involved.  Has the "cost" of that difference in size of installed base
> been helpful or harmful?
> 
> Other architectures for "internets" were possible.  Here's one you might
> not know about.
> 
> When I joined Oracle in 1990, I learned more about the end-users' needs
> of that time.  That was the era of "multiprotocol" networks, where all
> sorts of vendors offered their own products and even their own
> "internets" using their own proprietary technology. Corporations,
> including us, were struggling with operating such "multiprotocol"
> networks, to interconnect the systems their various departments had
> bought - perhaps Finance on PCs, corporate records on SNA, Marketing
> committed to Appletalk, Netware here and there, DECNET in Engineering,
> etc.   That "scenario" replaced the "military scenarios" that had been
> in my head during the early Internet research a decade or more earlier.
> 
> I noticed the parallels between TCP's goal to interconnect "islands" of
> different network technologies, and the "islands" of virtual network
> technologies that had been created by all the different implementations
> from the computer/network vendors.   Our forte was software, so we built
> a "router" at levels "up in the stack" (trying to fit this into an ISO
> layer diagram may be hazardous to your mental health).  We called it an
> "Interchange".   It was simply a software package that would be run on
> some computer that had the ability to use more than one type of
> network.  With an "Internet" composed of Interchanges, a computer on one
> kind of network could interact with a computer on a different kind of
> network, even though neither could use both kinds.  A computer on
> Appletalk might access a computer on SNA, and perhaps use an intervening
> TCP network along the way.
> 
> That is yet another architecture for creating an Internet. Basically
> "Interchanges" simply were "patch panels" that plugged together virtual
> circuits.   Every network type had some kind of protocol to deliver
> virtual circuit service, and they were simply interconnected by the
> Interchange software.
> 
> Was patching together virtual circuits a good idea?  I don't know, we
> just did it as a solution to a very real problem that we and our
> customers were experiencing.  The "gateways" in the early Internet could
> have used this architecture and patched together virtual circuits, but
> chose to build on top of "datagrams" instead.  Routers were evolved to
> have the capability to pass around all sorts of datagrams - IP, IPX,
> etc., and that enabled the creation of multi-protocol internets.   Lots
> of choices.  Lots of good reasons, pro and con, for each.
> 
> It also became obvious at that time in the early 1990s, at least to me,
> that TCP had probably won the protocol wars.   All the customers I
> encountered were at some point along their own paths to converting their
> entire world to TCP.   Most common reasons I heard: "It works."  "Our
> new hires out of college know all about TCP."
> 
> The "Interchange" provided a way for them to perform their planned IT
> evolution at their own pace, driven by their own business situation and
> needs.  The cross-protocol capability of Interchanges apparently had
> value.  Even if they never actually used an Interchange, the knowledge
> of its availability helped with a corporation's planning and execution.
> They could migrate different departments IT approaches at their own
> schedule and PERT chart.  It could be especially helpful in situations
> such as mergers and acquisitions, where the two corporations being
> interconnected might have very different IT architectures but had to be
> integrated quickly for business viability.
> 
> That's another "cost" factor for consideration in a system-level
> analysis.   I've wondered how much effect it might have had on the
> success of TCP in the protocol wars by easing the pain in corporations
> of adopting TCP in some "flag day" plan with the associated high risks.
> All the other competitors on the protocol battlefield disappeared in an
> amazingly (to me) short time.
> 
> Unlike the DoD in the 1970s, most corporations didn't have much power to
> declare TCP a "Corporate Standard" and set procurement rules requiring
> its use in any product they purchased.  If a corporation was big enough
> it might have had such clout.   Most corporations did pick some
> standard, usually associated with a particular vendor - e.g., an IBM
> shop, or DEC shop, etc.  But they hated the "lock in" nature of such
> decisions.
> 
> It became pretty common that availability of TCP influenced IT decisions
> in purchasing new equipment.  I recall for example seeing a huge
> semi-truck filled with Sun workstations delivering to a Wall Street
> investment house.  The computer industry figured out that new
> characteristic of their marketplace, TCP became the effective Standard,
> regardless of what the official bodies said.
> 
> Seems to me like there's at least a few PhD theses here.  Have they been
> written...?
> 
> /Jack Haverty
> 
> On 4/22/26 22:21, Greg Skinner wrote:
>> On Apr 21, 2026, at 1:04 PM, Jack Haverty via Internet-history
>> <internet-history at elists.isoc.org> wrote:
>>>
>>> Back in the ARPANET era, there were lots of analytical studies of the
>>> mechanisms of packet networks.  Lots of measurements were also taken,
>>> to compare real-world behavior to the predictions of analytical
>>> models (such as Kleinrock's work at UCLA, and later BBN's work to
>>> monitor the ARPANET as it grew and use the data gathered to modify
>>> the internal mechanisms based on operational behavior.
>>>
>>> Have such theoretical analyses and operational experience ever been
>>> applied to The Internet?    For example, the internal mechanisms in
>>> the ARPANET based routing decisions on measurements of transit time
>>> for packets to traverse the ARPANET.   For pragmatic reasons, that
>>> was not feasible in the early Internet, and routing decisions were
>>> based on "hops" instead of time.  Maybe that's still true?
>>>
>>> Was the Internet ever analyzed mathematically as the ARPANET was? Or
>>> were (are?) measurements of operational behavior used (or even
>>> collected?) in some way to influence technical evolution? Personally
>>> I haven't seen any discussions of such things but I also haven't been
>>> looking.   But I think it's an important aspect of Internet History.
>>>
>>> /Jack
>>>
>>
>> CAIDA <https://www.caida.org> does many types of studies.  Their
>> overview page
>> <https://www.caida.org/catalog/datasets/overview/> provides links to
>> examples.  Some, like this analysis of how ISP competition affects
>> autonomous system path quality and ISP profits, are quite
>> mathematical, IMO. [1]
>>
>> --gregbo
>>
>> [1] https://arxiv.org/pdf/2305.06811
>>
> 
>