[ih] Installed base momentum (was Re: Design choices in SMTP)

[Jack Haverty]

(retransmission - first transmission 2 says ago apparently got lost 
somewhere...)

Thanks for all the observations about why TCP was a rare success story 
in its momentous (momentumous?) battle with the installed base.  Lots of 
good info and observations, but the root causes remain elusive to me at 
least.   Why could TCP/IPV4 annihilate all of the preexisting other 
similar technologies?

For example, I agree that many technologies have failed to be adopted 
because of "lack of market demand".   But why was there such a lack?  
Did the creators of the technology not understand the market?   Did the 
market change so fast that the technology was obsoleted as it was 
released?  Was there some missing feature or difficult requirement that 
made the technology unpalatable to the market?   Was the market 
successfully made aware of the new technology and why they should care?

TCP's notion of "internet" had competition.  For a while in the 1990 
timeframe, a popular notion was the "Global LAN", in which an 
organization could interconnect its LANs at its various sites, forming a 
composite "WLAN" or wide-area local area network.   SNA, XNS, SPX, 
Appletalk et al provided such a capability to form such a global LAN.  
TCP/IP did the same thing, allowing LANs at widespread sites to be 
interconnected to form an internet.  Router vendors created 
"multiprotocol routers" to enable a mix of different "global" 
technologies to utilize the same expensive communications circuits.  The 
TCP/IP machinery survives to this day; all of the others have 
disappeared.  They all competed in the same market conditions.  TCP 
didn't just become one of the "top three" in the competitive space.   It 
became pretty much the ony one left standing.  Why did TCP/IP win?

Second comment -- The metric of "adoption" when it's based on deployment 
of the new or replacement technology doesn't seem appropriate - e.g., 
the 30+% adoption of TCP/IP V6.  A better metric for evaluating how 
successfully a "new release" is being adopted, IMHO, would be the metric 
of the survival rate of the prior release - the one hopefully being 
replaced.  In other words, a metric for the success of deployment of 
IPV6 would be the diminishing rate of usage of IPV4.

If a new technology is adopted at a certain rate, but the one it is 
supposed to replace does not fade away, the new technology is just YANP 
- Yet Another Network Protocol, making the operational system even more 
complex and difficult to operate and maintain.  Today, it seems to me 
that IPV6 is still YANP.  Many of the technologies defined in RFCs and 
some category of Standard may also be stuck in YANP limbo.

Last comment -- We have been discussing what happened historically to 
cause what we see today.   But perhaps equally important are things that 
did not happen, and thereby helped TCP/IP in the battle.   What was 
important because it did not happen?

I can relate one example from my personal experience.  I suspect there 
were a lot of others over the decades.

In 1990, I joined Oracle as "Internet Architect".  Oracle's customers 
were global and involved in any industry you can imagine. Oracle's 
mission was to provide database software that would run on whatever 
computer, using whatever operating system, connected to whatever network 
a customer had chosen.   To deliver that software, we had a very unusual 
kaleidoscopic computer center - instead of staid rows of blue, or red, 
or black, or whatever colored equipment from the chosen IT vendor, we 
had at least one of every kind of computer you could get.   We also 
operated our own corporate network, using multiprotocol routers (Cisco), 
connecting our offices internationally.   All of that was necessary to 
build and test the software, to assure that it would in fact run on any 
computer, and network, a customer might have.  Any (database) client 
could interact with any (database) server over whatever kind of network 
was involved.

Running a multiprotocol network was not for the faint of heart. YANP on 
steroids.  Our customers  increasingly had the same situation. When 
prices fell far enough, they couldn't enforce a corporate network 
standard for IT, but rather might discover Appletalk in Marketing, some 
kind of PC LAN in Sales and Accounting, SNA in mainframe territory, 
perhaps DECNET in Manufacturing, etc.

This struck me as entirely analogous to the situation that motivated TCP 
- too many different kinds of networks involved.  TCP bound them all 
together into a cohesive supernetwork.   TCP was "One protocol to rule 
them all, one protocol to bind them" (did I get it right...?0

So we pursued a similar solution, following the lead of that ARPA 
research and Bilbo Baggins.  Instead of "gateways" (aka "routers"), we 
developed something we called an "Interchange".  This was simply 
software that would run on some or just a few machines that had the 
ability to use more than one network protocol (e.g., SPX and TCP). Every 
network protocol had some mechanism for creating "reliable byte 
streams".  The Interchange was a very simple "patch panel" that would 
take serial connections from each side and "plug them together" to 
create a composite "reliable serial byte-stream" from end to end.  By 
going through Interchanges, a client on any network could interact with 
a server on any other network.  So a client on an Appletalk machine 
could utilize a database on a DECNET machine, possibly traversing a TCP 
"backbone" along the way.   For testing, we could set up such 
configurations just using our own multiprotocol internet.

This "Interchange" mechanism was called TNS, or Transparent Networking 
Substrate, and enabled clients and servers to interact, no matter what 
kind of computers or networks they were on.

I recall being frequently accosted, e.g,. at Interop, by people who 
wanted us to release TNS as a separate product and API, so that it could 
be used for other kinds of interactions across a mix of networks - e.g., 
transferring files from a PC on a LAN to an archival site on a 
mainframe.   We thought about it, but decided not to do it for a lot of 
reasons.  We weren't a "network company" marketing protocol 
implementations.   We understood how database software in clients and 
servers utilized the TNS, but undoubtedly lots of issues and problems 
would arise when other kinds of interactions were tried over TNS.   
Support knew how to troubleshoot database problems, but TNS problems 
with other activities would add another dimension of idiosyncracies.   
Lots of reasons, despite some indication of a market demand.

So we never released TNS as a separate capability.   But there was 
nothing particularly secret about how it worked, and nothing patented, 
so anybody could have created a similar "patch panel" mechanism.   But 
no one did, AFAIK.

If such a TNS general capability had been available, would it have 
disrupted TCP's battle to dominance, by removing many of the annoyances 
inherent in multiprotocol installations?  Perhaps, perhaps not.  But it 
seems that things that did not happen, like general availability of a 
TNS, might be important historically.

Restricted to database activity, the TNS capability that we did deploy 
may even have helped TCP's advance.  With Interchanges, it was possible 
for our customers to plan and execute a more orderly and controlled 
transition to TCP.   During interim and testing phases, Interchanges 
could be used to maintain client-server connectivity as the underlying 
networks were migrated to TCP.  The company could keep running, with no 
potentially suicidal "Flag Days" to fear.  Corporations like such 
methodical and careful approaches.

IMHO, the 1980s and 1990s were a very complex period with lots of things 
being done, and not done.   The TNS story was likely just one example of 
many.

That's why I opined that some Historian may someday be able to sort it 
all out.

Hope this helps,
Jack Haverty




On 2/9/23 18:16, Jack Haverty via Internet-history wrote:
> On 2/9/23 14:57, Dave Crocker via Internet-history wrote:
>> Such is the lesson of installed base momentum.
> I agree - the installed base is a formidable obstacle to getting any 
> kind of replacement propagated.   Stagnation and fragmentation into 
> silos seems to be the result, as players introduce a desired new 
> technology into just the components that they can control.
>
> But I also wonder -- How did TCP overcome the momentum of the 
> installed base?
>
> At the time, in the 1990ish timeframe, there was a huge installed base 
> of network technology.   Hundreds of thousands of computers utilizing 
> networks based on SNA, SPX, XNS, Decnet, etc. etc.   TCP existed, but 
> was a small player, confined largely to the academic and research 
> communities.
>
> But almost overnight, actually over just a few years, TCP became a 
> real player, and then the dominant player, and by now all of the other 
> technologies of that installed base have simply disappeared. The 
> installed base of 1990 is gone without a trace.  Are there any 
> computers anywhere still running those well-established 
> technologies?   I haven't encountered any, but I wouldn't be surprised 
> if some still existed.   Perhaps something running Cobol somewhere.
>
> So how did TCP manage to blast through that momentum of the installed 
> base, creating such a chaos in the collision?   And how did it do it 
> so rapidly?
>
> Curiously, that collision of TCP with the installed base involved 
> TCP/IP V4.   TCP/IP V6 has come along and its been quite a few years 
> in transition.   It seems that the momentum of the installed base of 
> TCP/IP V4 has blunted the adoption of TCP/IP V6.   Why? What's different?
>
> A similar situation seems to exist in other network areas, e.g., the 
> mechanisms of electronic mail that we've been discussing.  New 
> technologies can get invented and documented, but often never get 
> widely deployed.  Why?   What magic incantations were used to deploy 
> TCP in the 1990s that have been apparently now lost.
>
> Perhaps some historian has some answers....
>
> Jack