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

[Noel Chiappa]

    > On Thu, Feb 9, 2023 at 7:16 PM Jack Haverty wrote:

    > 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?

Like most things in history, there was no single cause. These seem to me
(building on resonses by others) to be the most important ones (the first,
below, was IMO the most important):

- The TCP/IP world had a _long_ head start in building a large (both in
numbers and physical extent) multi-organizational network using heterogeneous
systems. So in addition to the Metcalfe effect of community size, we ran into
(and partially solved) various real scaling issues that anyone attempting to
build such a thing would run into, before anyone else. The
'multi-organizational' one is not thought of much, but it was critical.

- Our experience in actually using our network (the 'dogfood' effect) meant
that the pieces (applications supported, and components available 'off the
shelf') we had assembled actually quickly allowed useful work to be done.
(More of a gating factor than a _driver_, of course, but a key gating factor).

- We supported, as mentioned, heterogeneous systems; there was a TCP/IP
implementation available for just about anything. This factor took out a lot
of early contendors.

- The TCP/IP world was _very_ open; our documents were freely available;
anyone could turn up at an IETF meeting and participate _as a peer_, etc.

It 'won' so quickly because of the Metcalfe effect, and its head start.


    > From: Craig Partridge

    > We figured out congestion collapse well enough for the time

It should be remembered that the ARPANET people (hi!) had perhaps solved this
problem a long time before. I'm trying to remember how explicitly they saw
this as a separate problem from the issue of running out of buffer space for
message re-assembly at the destination IMP, but I seem to recall that RFNMs
were seen as a needed throttle to prevent the network as a whole from being
overrun (i.e. what we now think of as 'congestion', although IIRC that term
wasn't used then), as well as flow control to the source host (as we would
now call it).

I don't recall exactly where I saw that, but I'd try the BBN proposal to
DARPA's RFP, and the first JFIPS paper ("The interface message processor for
the ARPA computer network").


    > From: Andrew Odlyzko

    > I vividly recall an internal AT&T meeting around 1998 when a high-level
    > AT&T executive, in response to a question about IP from one of our
    > research group, said that the Internet was a toy network, full of porn,
    > and ATM was going to be the real thing

This brought a big smile to my face; those of us with long memories will
recall that someone associated with the OSI effort had said _almost exactly_
the same thing - two decades before!

The phrase that I recall was 'toy academic nework', and maybe something about
'roll it up and take it away'! (I wasn't there to hear it in person; it was
conveyed to me by Dave Clark or David Reed.)

Such comments, in reality, imparted a great impetus to contest, and suceed,
of course. (Cue my story about Lyman Chapin and his 'not very politically
sophisticated' comment! :-)

	Noel