[ih] IEN's as txt

Fri Feb 10 11:21:11 PST 2017

I think there's a difference between tracking specifications and
tracking implementations.  It will be interesting to see how your
analysis of old code actually compares to the specs.

One of the beauties of the TCP/IP design is that the specifications did
not overspecify. They essentially defined what the formats and protocols
had to be "on the wire" so that different implementations could
communicate.  But there were a lot of design decisions still to be made
by each implementer or system builder.

For example, one TCP implementation might be oriented toward an
environment where bulk traffic was dominant (FTP).  That implementation
would strive to send "full" datagrams to minimize the overhead of the
TCP/IP headers.  Another implementation might be oriented toward
interactive traffic (Telnet), and strive to get the user data out onto
the wire immediately, since the user might be expecting the computer on
the other end to respond (echo a character, move a cursor, whatever).
Another might be oriented toward voice, another for situations involving
satellite paths, etc., etc.

There were lots of such decisions - how and when and what to retransmit,
what to do when you get back a Source Quench, what to do with different
settings of the header bits (e.g., TOS), etc. etc.  None of these were
specified in the docs.  The packet formats, state machine, and related
mechanisms were specified, but other things, like the user-interface
functionality, were included as examples.

That meant that, even when the specifications were "finalized" there was
still considerable work to be done and decisions to be made about how to
design a specific implementation.  Some of that subsequent work became
more formal as an RFC/IEN (e.g., Van Jacobson's work on retransmission
algorithms.)

As you look at actual implementations, it would be interesting to see
how those kinds of non-mandatory design decisions evolved over the last
30+ years.  I must admit I haven't followed the 1000s of RFCs which
probably capture a lot of the evolution of the protocols and algorithms.

It would also be interesting to see how well implementations actually
followed the specifications and the "recommended practices" that came
with experience.   TCP/IP is so forgiving about many things and a TCP/IP
implementation may "work" even if it's doing lots of things "wrong".

I worked with a TCP in the 1990s that had subpar performance and after a
few hours doing tcpdump analyses I had the pleasure of informing the
computer manufacturer that their TCP had a bug such that only
retransmitted segments would be accepted.  All first-time segments  were
incorrectly dropped as having bad checksums.  Just a bug.  But it
"worked" and was production quality...and in the released product.

A different computer's TCP had the characteristic that, after a glitch
of some kind in the network, it would settle down and traffic flows
would again stabilize on that connection.  As it should.  But tcpdump
revealed that after the glitch, the new stable state had every packet
being sent twice.  The retransmission timer had dropped just below the
round-trip delay.  But everything worked, and nobody complained.  We
only noticed because it was travelling over a very expensive
trans-Pacific circuit and we were watching utilization on that circuit
closely.

I'm not sure if the manufacturers ever fixed either of these behaviors.

As you examine old Unix code, you may unearth interesting artifacts.
For example, one of the Unix implementations (BSD IIRC) decided to put
the IP headers at the *back* of the packet.  This made things easier for
them inside the OS with buffer management.  They had some means to do
this only when communicating with another host running the same OS.  It
worked well for a collection of workstations and servers on a LAN.  But
we (BBN Network Op Center) noticed because one day all sorts of alarms
went off when the "core" gateways started getting streams of "bad
checksum" errors, because those weird Unix packets escaped the LAN and
the gateways didn't know that the IP header would be at the end of the
packet instead of the front.

One of the things I've noticed about RFCs and IENs is that they tend to
assume that the specification and the implementation are equivalent.
Not necessarily true...

HTH,
/Jack

On 02/10/2017 06:14 AM, Vint Cerf wrote:
> 
> 
> On Fri, Feb 10, 2017 at 7:23 AM, Paul Ruizendaal <pnr at planet.nl
> <mailto:pnr at planet.nl>> wrote:
> 
>     Many thanks to all for your input. It already gives me a lot
>     to digest.
> 
>     I understand that I won't find much rationale in the IEN/RFC
>     docs, but at least I can trace that way what the changes were
>     and how this affected the various code bases.
> 
>     ---
> 
>     One fool can ask more questions than a thousand wise men can
>     answer, so here are some other things that puzzle me:
> 
>     - The specs and implementations of 1978/9 don't interoperate (I
>     think) with those from 1981, not at the IP level and not at the
>     TCP level. Why were the protocol numbers never bumped?
> 
> 
> because we were not in "release mode" this was experimental code and we
> were not releasing into a large ecosystem. 
> 
> 
>     - I believe BBN got the contracts for reference implementations
>     in the last quarter of 1980 and that work started immediately.
>     Was there a sense in late 1980 that the specs were already final?
> 
> 
> yes - they were pretty much frozen by 1978.
> 
>      
> 
> 
>     - I think the flag day decision must informally have been taken
>     in the summer of 1981, allowing time for it to travel up and
>     down the chain of command and be formally declared in November.
>     The specs were still changing as late as April, and as Jack said
>     that was in response to bugs creeping out of the woodwork.
>     What gave the comfort to declare TCP ready for use and that the
>     changes were all done? Or was it simply that it could not be
>     postponed further without loss of credibility or some such?
> 
> 
> I wanted to get more experience in operational mode and the only way to
> do that was to get it out into regular use. as program manager I felt a
> lot of urgency since this has been in development since 1973. 
> 
> 
>     - As I understand, in November 1981 there was not a single
>     production quality implementation of the April specs ready.
>     Is that correct and if so, were the spec's simply frozen for
>     a while to allow/force implementations to catch up?
> 
> well, that's your opinion. actually revisions in implementations have
> gone on for decades including new flow control concepts and refined
> addressing interpretations, etc.  
> 
> 
>     - The post flag-day part of Mike Muuss' tcp-ip digest seems to
>     be mostly concerned with routing problems, even more so when the
>     MILNET split happened soon after. Noel's message on GGP and
>     ICMP suggests that this was foreseen. Is that correct or are
>     these issues unrelated?
> 
> 
>     On 10 Feb 2017, at 1:02 , Paul Ruizendaal wrote:
> 
>     > My underlying motive for this is to understand the changes to
>     > TCP (and IP/ICMP/UDP) in the 1978-1981 time frame, and diff's
>     > of the IEN's and RFC's would help. Perhaps this analysis has
>     > already been done?
>     >
>     > One thing that surprised me is that the closing mechanics in the
>     > TCP state diagram kept changing until very late. Perhaps it
>     > was just a matter of ever more precise specification, but if it
>     > was conceptual change it would seem odd that it did not show up
>     > earlier in the testing process and 'bake offs'.
>     >
>     > Same goes for ICMP: it was a late arrival and the rationale for
>     > abandoning the earlier approach is not entirely clear.
>     >
>     > Paul
> 
>     _______
>     internet-history mailing list
>     internet-history at postel.org <mailto:internet-history at postel.org>
>     http://mailman.postel.org/mailman/listinfo/internet-history
>     <http://mailman.postel.org/mailman/listinfo/internet-history>
>     Contact list-owner at postel.org <mailto:list-owner at postel.org> for
>     assistance.
> 
> 
> 
> 
> -- 
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> Reston, VA 20190
> 
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 