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]
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?
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.
ATM's cell size is 53 bytes of which 5 bytes are per-cell header.
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.
I think you can work some sliding windows in there, eg.
"... 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.
Possibly not very on topic, but it might not be wise to call TCP a single standard when it has become to complex nowadays. The tangled mess of RFCs describing TCP has become so complex that an RFC is written to provide a roadmap of TCP[0]. And that roadmap references more than 150 other RFCs.
> And that roadmap references more than 150 other RFCs.
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.
Heh... The problem here is that TCP is being asked to do too much now. We're expecting the same protocol to work well over the entire range of networks. Starting with two servers on the same 10 gig switch with a ping latency in microseconds all the way to mobile networks with intermittent connectivity and 100's of milliseconds ping latency.
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.
[2]:http://archive.computerhistory.org/resources/access/text/201...
[3]:http://conservancy.umn.edu/handle/11299/155666
[4]:http://pouzinsociety.org/about