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

[Leonard Kleinrock]

Flow control was a central concern at the UCLA Network Measurement Center (NMC) from the earliest days of the ARPANET.  We set out to push the fledgling network to its limit to determine where it would fail and experienced a number of such failures and studied them.  There is considerable reporting of the flow control issues in my Queueing Systems, Volume II: Computer Applications, in particular in Chapter 6 and “Computer-Communication Networks: Measurement, Flow Control, and ARPANET Traps”.   We studied issues like store-and-forward lockup (which Bob Kahn had predicted), Christmas lockup, reassembly lockup, piggyback lockup, etc.  Importantly, we identified the kinds of problems that can arise when flow control functionality is introduced at various points in the network without regard to other, possibly unknown, flow control mechanisms that exist elsewhere. I agree that the congestion control problem is still unsolved.

I note that the RFNM came up recent email exchanges, and as a side point, it is interesting that we found that the use of RFNMs in the US-Norway satellite channel caused a “capture” effect.  When a stream of messages crossed one-way, say from US to Norway, it created a stream of RFNMs to return, and that sequence of message-RFNM exchanges hogged the half-duplex channel and effectively locked out messages that were waiting to travel the other way from Norway-US. Ha!

Len


> On Feb 13, 2023, at 4:46 PM, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> IMHO by the early 90s, TCP had already won the competition, and organizations everywhere were working on transitioning to the Internet, or perhaps more commonly their own TCP-based corporate intranet, perhaps as a multiprotocol internet for a while.   Other networking technologies still existed in the installed base, but TCP was getting all of the attention.
> 
> The Web emergence in the mid 90s was possibly more a result of TCP's success in enabling universal connectivity rather than a cause of TCP's success.  Once it became obvious that TCP had "won", a company or technology vendor had to adapt to it, rather quickly, or die.
> 
> There were earlier technologies that provided collaborative services similar to those of the Web.   Lotus Notes is one I remember. Perhaps also services like Compuserve or LexisNexis.  IIRC, Notes was based on dial-up connections, not TCP.  IBM bought Lotus.   I don't know if Notes became part of SNA.   But they're both pretty much gone while the Web, based on TCP, explodes in size and reach. LexisNexis is still there, living on the Web.
> 
> Jack
> 
> 
> On 2/13/23 13:03, Steven Ehrbar wrote:
>> On Mon, Feb 13, 2023 at 12:40 PM Jack Haverty via Internet-history
>> <internet-history at elists.isoc.org> wrote:
>>> 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?
>> Because TCP/IP _didn't_ compete in the same market conditions. With
>> the World Wide Web/Mosaic/Netscape in the mid-90s, TCP/IP went out and
>> took over a completely different market than institutional networks,
>> the market for home computers users accessing public services. And
>> then all the personal computers in corporate networks had to be TCP/IP
>> enabled to access the public services being built for home users.
>> After which, the choice for corporations was no longer between using
>> TCP/IP or some other protocol in any given department; it was whether
>> they'd use TCP/IP or _both_ TCP/IP and some other protocol in any
>> given department. And while installed base meant a lot of companies
>> did the "both" for a while, the benefits of transitioning to just one
>> were obvious.
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history