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

[Brian E Carpenter]

I gave my answer: TCP/IP came for free on Unix just when Unix was
taking over the universe.

We did "Interchange" solutions for email and file transfer at CERN.
GIFT, the file transfer gateway, started in 1985; MINT, the mail
interchange gateway, started in 1986. They were sinks for systems
programmer and operational resource, and getting rid of them was the
major driver for seeking a universal solution. By 1989, installing
TCP/IP plus its apps everywhere was simpler and cheaper.

> Today, it seems to me that IPV6 is still YANP.

I really don't think so, because IPv4 really has run out of
addresses and multiple layers of NAT are very, very painful.
But the timescale is vastly different from what we anticipated
in 1994, and we put too many features in IPv6.

Regards
    Brian Carpenter

On 14-Feb-23 08:40, Jack Haverty via Internet-history wrote:
> (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