[ih] Date of RFC 791 for celebration

[Jack Haverty]

On Wed, 2006-03-29 at 09:13 -0500, Noel Chiappa wrote:
> So it looks as if my prior take:
> 
>     >> 3 was the first version that had the headers fully split (and
> included
>     >> "protocol numbers" to identify which transport protocol was
> being used
>     >> ..) but my guess is that it included variable-length addresses.
> I seem
>     >> to recall that 3.1 had the variable-length addresses removed,
> and 4 was
>     >> an editorial cleanup of 3.1
> 
> is likely accurate (although I wish we could recover a 3.1 spec to be
> sure).
> (Note: the field called "Format" in the IP3 header is what we now call
> the
> "protocol number".)
> 
> 
>     > TCP 3 was a paper specification driven by the experience gained
> from
>     > running TCP 2.5s.
> 
> Ah, interesting. Do you concur with the position that TCP 2.5 (which
> is,
> apparently, undocumented - except perhaps in those minutes) was
> basically the
> same *protocol* as TCP 2 (which had fixed-length addresses, BTW), but
> with the
> *implementation* split up into separate IP and TCP layers?
> 

Hmmm....precede everything I say with "If I remember correctly...",
since 28 years is a long time.

I think it's difficult to understand the history of "the Internet",
without considering other things that were happening in the same
timeframes.

The TCP2.5->3->4 timeframe was also the period in which the Internet was
being pretty forcefully pulled from a research project toward being an
operational system.   For example, some of the changes in the 3/3.1
timeframe related to adding fields for use by Autodin-II to implement
security and precedence functionality.   All of this eventually led to
the January 1983 flag-day when Arpanet became a TCP-only net, as well as
the DDN being TCP-based.

I don't think it's quite so clean to say that 2.5 was the same as 2 but
for the implementation split.   There were quite a few minor tweaks
going on continuously at the time, with functions such as URGENT, Rubber
EOLs, and maybe even the state diagram (more states in the closing
interactions).   Some, maybe most, of these probably didn't affect the
headers (except for new options), but did affect the behavior of the
state machines.  

At the time, documentation was usually one of those things that you (or,
even better, someone else) did after everything worked.  Before that
point, email and FTP ruled.  So the TCP 2-morph-to-2.5+epsilon evolution
was documented unfortunately mostly in emails and a file or two that you
could FTP from ISI, and captured every 3 months in the working group, at
least on the blackboard.   One of Jon's emails lamented the fact that
packet formats and especially state diagrams were so hard to create in
ascii text.

Also, it wasn't clear exactly *how* to specify a protocol with enough
precision to guarantee interoperability but enough flexibility to permit
a wide range of implementations in the many operating systems of that
day (there wasn't even agreement on how many bits were in a byte...hence
TCP's use of "octet").   The January 1979 "bakeoff" was where everything
really got nailed down - we didn't get to leave the building until the
different implementations could talk to each other.

I have an email from Jon sent prior to the bakeoff, presenting a
proposed new format for specifying TCP.  The subject was "TCP
pseudo-program" sent 8 Jan 1979 to a bunch of the TCP implementors, to
review for discussion at the bakeoff meeting.  It's a pseudo-program
written in, as Jon puts it. "an obscure language (L10), and will be
converted to a well known language before general circulation"  This
"proposed spec" was a file <INC-PROJECT>EVENT-ACTION.NLS.15 on ISIE. 

So, part of why all these versions weren't documented is probably that
we didn't know quite how to do it.    Errr, ummm, well, actually we were
probably more inclined to write code....

I believe the TCP 3 specification attempted to capture the current
snapshot of thinking for the next release, when the current running TCPs
were all some variant of TCP 2.  This was driven by the government's
need to have a formal spec for regular contractors (not us
research-weirdos-wearing-sandals) to implement as part of other "real
world" projects such as Autodin-II.   There was also a strong pressure
to move the TCP technology into an operational environment (i.e., for
government programs' use, not part of the research projects), in order
to show that all of that research funding was actually producing some
potentially useful results.  

I remember lots of muttering and protests (many from me at least) that
"it's not ready yet" and "we have to figure out how to do xxx"   Funny,
the same thing happens in the commercial world when you need to hit a
product ship deadline.   But us researchers in those days didn't think
that way and Vint had to beat us up a bit. 

So, I don't really remember much about the TCP3/3.1 from a specification
point of view, since I don't think any of the "research" projects were
implementing it.   TCP 2 was the working base, and there were lots of
discussions ongoing at meetings and especially email until key decision
points like that June 1978 decision on the header formats.  When it
finally settled down and the implementations converged, TCP3 was already
spoken for, so the new implementations were TCP4.

Remember, at the time TCP was a research program which was supposed to
be supplanted by the "real" technology from CCITT or ISO or whomever,
which would of course use the experiences from the research community to
influence the design of "the real thing".   Everybody in the "real
world" was working on their own Internetting technology which was of
course going to be the ultimate unique winner - IBM, CCITT, ISO, Xerox,
DEC, etc. etc. etc.   Perhaps the TCP spec could be useful to prop up a
leg on a wobbly desk or something...while the real internet design is
being polished off.

So, TCP 3 was specified, and contracts were awarded, and teams were
formed to implement the beast.

But, probably because TCP 3 was specified before it was implemented,
there were some problems...  So TCP 4 came into being, and that's what
we all implemented for the Jan 1979 bakeoff.  I remember at some meeting
a discussion with one of the "real world" contractors (perhaps Gary
Grossman at DTI?) who was lamenting the fact that his TCP was version 3,
and he couldn't talk to anyone else, and couldn't change to TCP4 because
of contractual constraints.

I think TCP4 would have actually been TCP3, except that TCP3 was
prematurely cast into specification and contracts without the
now-traditional Internet rule of getting it to work first (aka "rough
consensus and running code").   I don't think it's right to think of 4
as an "editorial cleanup" of 3.  TCP 4 was the one that worked as the
successor to TCP2.5, and to my mind it was actually finalized at the
January 1979 bakeoff (we kept changing our individual implementations
until it all worked and we could go get dinner).  I don't think that the
header formats changed much if at all from the June 1978 decision, but
rather behavioral details were worked out - in particular I remember
checksumming was a real nightmare to get right, given the "pseudo
headers". 

I think the implementation atructural reworking had more to do with the
demands of outside projects (e.g., voice) to be able to access the
Internet as a datagram service rather than the TCP byte-stream service.
So there was a need to make sure implementations provided user API
access to IP packet functionality, not just TCP.   Some people also had
ideas of doing things like running TCP over X.25 (or other protocol), or
running TP4 over IP, and other such fun.  There were also various
projects trying different implementation approached, such as putting TCP
and/or IP in an outboard front-end processor (akin to the IBM 3270
approach I believe).

Of course, TCP and IP are on-the-wire protocols, so it shouldn't matter
at all how an implementation is architected, as long as the on-the-wire
formats and behavior are correct.  I remember a "manual TCP" that I used
for debugging.   A packet came in, and a DDT breakpoint fired.   I
looked at the packet in the buffer, looked at the spec and decided how
to respond, patched the appropriate data into an output buffer, and
executed the packet-send routine in DDT.   Perfectly legal
implementation.   Great for debugging, but of course you had to set
retransmission timeouts really long.....

So, people may have been re-architecting their code at the time, but I
don't think it was because of the evolution of the spec per se, since
the spec shouldn't dictate implementation architecture.   More likely is
that the various packet-voice projects that Bob Kahn was expecially
interested in was driving the need to access IP without TCP.  Also, with
TCP and IP separated, it just made sense to restructure an
implementation so it was easier to debug one piece at a time.

I have a listing of my Unix TCP4 from December 1978, and it also has the
TCP and IP code split into different modules.  But it was all assembler
code and everything ran in a single process with common data areas so I
think I split it purely for organizational reasons.

I wonder when UDP came into being (i.e., implementation, not
specification) to define a way of accessing that IP datagram
functionality.   I remember it happening at some meeting (was almost a
no-brainer), but can't remember when.

By the way, one last comment on the specification frenzy.  TCP/IP was,
and is, very permissive in terms of implementations.  Jon's mantra of
"be flexible in what you receive, be precise in what you send" (or
something like that) led to some problems when specs went to
implementation.   For example, since IP datagrams can arrive in any
order or be lost and retransmitted, a TCP implementation could be very
very primitive and still "meet the spec".  One implementation I
encountered years ago used a minimalist approach - if the datagram you
get isn't the next one you want in the sequence space, just discard it
since it will get retransmitted anyway.

Writing a spec, and awarding a contract, while avoiding such
poor-quality products, was a pretty difficult problem.....

Enough, my brain hurts.   Hope this was interesting.

/Jack