[ih] lack of service guarantees in the internet meaning that it cannot ever "fail"

[Jack Haverty]

Aaaacck!  In my list of ancient operating systems infected by the first
TCP/IP...how could I forget the Fuzzball!  Nothing was like a Fuzzball!
Sorry DaveM....  /Jack

On Wed, 2009-10-28 at 09:14 -0400, Vint Cerf wrote:
> +1
> 
> vint
> 
> On Oct 28, 2009, at 2:39 AM, Jack Haverty wrote:
> 
> > On Tue, 2009-10-27 at 20:04 -0700, Ted Faber wrote:
> >> It
> >> seems clear that the protocol was designed to allow developers access
> >> to
> >> the TCP timeout and retransmission information in this limited way
> >> when
> >> it was helpful to them in implementing their application.  The base
> >> protocol has few extraneous knobs, so I assume this was carefully
> >> thought out.
> >
> > Well, I guess I have some legitimate claim to being one of the
> > designers, since I implemented the first PDP-11 Unix TCP and was
> > involved in the ongoing TCP and Internet WG meetings and ICCB/IAB way
> > back when.
> >
> > Ted's analysis is right on target.  There was considerable thought and
> > discussion given to timeouts and timing in general.  The specific
> > assumptions we made about timing (e.g., the maximum lifetime of a  
> > packet
> > as it wandered around the net) had direct impact on design decisions
> > such as the size of the sequence space, and therefore the number of  
> > bits
> > in the various fields in the TCP and IP headers.  It also drove the
> > requirement for use of a random number generator to pick an initial
> > value for the TCP sequence number - if a machine rebooted before all  
> > of
> > its "old" packets were flushed from the net, much confusion could
> > otherwise result.
> >
> > TCP/IP was designed to function in a military environment, where nasty
> > things could happen to the net - partitioning, destruction of nodes,
> > etc.  The design criteria was that the data should get through if at  
> > all
> > possible, no matter how long it took.  Networks might go away and be
> > "reconstituted" as new hardware was deployed or moved into range.
> >
> > The implication of this on the TCP/IP machinery was that it should  
> > never
> > give up - things might get better.  Connections would be broken only  
> > if
> > the "other end" responded and performed a close or abort sequence  
> > (RST,
> > FIN, et al).  If the other end didn't respond, the TCP/IP was to
> > continue trying, forever, with an increasing length of time between
> > retransmissions to avoid flooding the net.
> >
> > The design principle was that only the higher-level application could
> > legitimately decide that it was no longer worth trying to communicate,
> > possibly because whatever it was trying to do was no longer  
> > relevant, or
> > because it had additional knowledge that further attempts were futile,
> > or because it had found an alternative way to accomplish its tasks.
> >
> > In order to help the application make the decision whether to keep
> > trying or abort, the TCP/IP implementation was supposed to make
> > information about the connection behavior available to the  
> > application -
> > e.g., tell the application that it hadn't heard anything from the  
> > other
> > side for a while (the "timeout"), or that the other side was  
> > responsive,
> > but was not willing to take any more data (the TCP window was closed).
> >
> > The TCP/IP software was never supposed to close a connection because  
> > of
> > a timeout - it would only close a connection on instructions from the
> > application that opened the connection, or on word from the other  
> > end to
> > close/reset.
> >
> > These kinds of timing considerations also caused the protocol itself  
> > to
> > change as we got some field experience.  Early TCP protocol specs have
> > several fewer states in the state machine than the final TCPV4 because
> > of that.
> >
> > The protocol used "across the wire" between conversing TCP/IP
> > implementations was well specified.  However, if I remember correctly,
> > the interface ("API") between a TCP/IP and it's user application was
> > only specified as an example.  There were simply too many different
> > kinds of operating systems and computer environments around at that  
> > time
> > to define a standard API. IBM 360s didn't look like Unix which didn't
> > look like Multics which didn't look like Tenex which really didn't  
> > look
> > at all like the Packet Radio OS (I forget it's name...).  DOS,  
> > Windows,
> > and Macs weren't even around yet.
> >
> > It was left to each implementation designer to provide an appropriate
> > API which best fit into their particular machine environment.
> > Personally, the PDP-11/40 Unix environment was so limited (32K  
> > memory -
> > that's K, not M or G), that there wasn't a lot of room for anything
> > fancy in my API.
> >
> > Unfortunately, I think that lack of specific standard API resulted in
> > some TCP/IP implementations that did not provide the intended kind of
> > information and control through the API, or that decided on their  
> > own to
> > abort a connection that "timed out".
> >
> > The TCP/IP "service specification" was something like - "Keep trying
> > until hell freezes over."  So, getting back to the original question -
> > yes, the Internet couldn't "fail" as long as it kept trying.
> >
> > HTH,
> > /Jack Haverty
> > Point Arena, CA
> >
> >
> 
>