20 Years, One Standard: The Story of TCP/IP (2003)
cbi.umn.edu
cbi.umn.edu
Cerf: Incidentally, just for the record, the sliding window
flow control for TCP came straight out of discussions with
Louie Pouzin [ph?] and his people at INRIA. So, in fact,
Gerard Le Lann [ph?], who was part of Louis Pouzin’s lab,
came to Stanford University in 1974 and participated in a
lot of the design work, and I remember Bob Metcalfe and
Le Lann and I sortof lying down of the living room in my house
in Palo Alto on this giant piece of paper, trying to sketch
what the state diagrams were for these protocols.
Nielson: Louis Pouzin arises all over the place?
Cerf: Absolutely. [2]
[2]:http://archive.computerhistory.org/resources/access/text/201...
Hello, would you like to hear a TCP joke?
Yes, I'd like to hear a TCP joke.
OK, I'll tell you a TCP joke.
OK, I'll hear a TCP joke.
Are you ready to hear a TCP joke?
Yes, I am ready to hear a TCP joke.
OK, I'm about to send the TCP joke. It will last 10 seconds, it has two characters, it does not have a setting, it ends with punchline.
OK, I'm ready to hear the TCP joke that will last 10 seconds, has two characters, does not have a setting and will end with a punchline.
I'm sorry, your connection has timed out... ...Hello, would you like to hear a TCP joke?"... and can only be told through a sliding window".
When you finish the joke, you could sit down for a ReST before retrying, upon which time an ICPM missile hurtles through the room at top volume, shattering everyone's ear drums. The colonel stands up from his teletype desk and hands you an explanatory note proclaiming either administrative prohibition on communications of this nature, and a news update that the local port is presently unreachable due to flooding, and that people should find their own alternate routes should they have business there.
Jokes aside I think there is more to the story than the article, in the early 90's 'ATM' was going to be the future:
https://en.wikipedia.org/wiki/Asynchronous_Transfer_Mode
In a nutshell that is 51 byte packets with layers of TCP/IP on top - 7 layers stuff (or however many it is). Fortunately neat TCP/IP saw off the ATM challenge and its networking complications (where any packet could go any way across a network to not necessarily arrive at the receiving end in an orderly fashion. I am glad we got to the Internet without ATM or 'Token Ring' (imagine a whole internet and one token, that would be funny) or DECnet or any of the other contenders that once existed (such as those Microsoft things). I was there at the time but I have no idea why the world coalesced on TCP/IP putting network engineering voodoo out of business. Getting computers to talk to each other was once a dark art, well beyond the abilities and budgets of mere mortals.
Higher layer protocols gang together multiple cells through the use of segmentation-and-reassembly. An IP packet would be wrapped in, for example, an AAL5 packet (which itself has a header). That in turn would be segmented and transmitted as cells. The receiver would try to recover from cells arriving out of order, or interleaved with other traffic, or various error conditions, and would deliver fully reassembled AAL5 packets to the higher layer.
One problem is that early ATM switches had small buffers and poor buffering strategies leading to cell loss. The loss of one cell out of an AAL5 frame would require recovery by still higher layer protocols, such as TCP.
Instead of ATM switches (unsuccessfully deployed at the PACBell and Ameritech NAPs in the early 1990s), large ISPs used FDDI switches. FDDI has a token. Switched FDDI exploits the token usefully to impose flow control (it can withhold tokens from aggressive senders), and that made Internet Exchange Points (and indeed LANs internal to ISPs) much more stable than they were using ATM of the day.
The tokens you are thinking about are only relevant on a LAN, just like CSMA/CD does not propagate off a local ethernet to the whole Internet.
Decnet Phase IV is still* in the Internet; it's the transport layer for IS-IS (the routing protocol, not the terrorists). It has other niche applications too.
"I have no idea why the world coalesced on TCP/IP"
It wasn't vendor-specific and ran on arbitrary layer two infrastructure. There were address resolution and mapping systems for local area networks of all sorts (ethernet, starlan, token ring, fddi, and on and on and on), while competing protocols were not adapted to arbitrary links quite as quickly. Additionally, IP was trivially serialized (with SLIP initially, then with HDLC and PPP), while the serializations for vendor-supported protocols were fairly complicated.
In short, the motto "IP on everything" reflected many people's goals.
There were also several reference implementations and interoperability was taken seriously (a regular conference existed to test interoperability, even).
Eventually even IBM machines (from mainframes to AS/400s) learned to talk TCP/IP.
The ironical outcome of all this is that devs concerned about performance now need to spend a lot of time on thinking about how to work around the problems of TCP in their particular use case. This is becoming more and more of a pain in the mobile app world because of obvious reasons.
I count eight RFCs in the "Core Functionality" section. [0] I count ~26 RFCs in the "Strongly Encouraged Enhancements" section. [1]
The remaining referenced RFCs are:
* Experimental extensions to TCP
* IANA guidelines to follow when one is extending TCP
* Documents referenced only because of their historical significance
* Documents that provide implementation insights derived from TCP implementers' war stories over the years
Between eight and ~thirty-four RFCs is a damn sight smaller than "more than 150".
[0] This section is stuff that must be implemented to speak TCP.
[1] That section is stuff that improves the performance and/or security of TCP implementations, but is not required to interoperate with other TCP implementations.