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

[John Day]

Jack,
You are correct that in the day TCP was lumped with virtual circuit by the PTTs in the connection/connectionless debate.

However, TCP is not virtual circuit in the same sense as the ARPANET or worse, X.25. Virtual circuit hard allocates capacity (and sometimes buffering).  TCP merely has end-to-end feedback over a datagram service. Capacity is not hard allocated. The two really aren’t the same at all. We should never have let the PTTs lump them together.

Take care,
John

> On Apr 23, 2026, at 15:38, Jack Haverty via Internet-history <internet-history at elists.isoc.org> 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
>> 
> 
> -- 
> 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