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

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