Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: A Noop Strategy for TCP
Message-ID: <9340@ucbvax.ARPA>
Date: Thu, 25-Jul-85 23:52:17 EDT
Article-I.D.: ucbvax.9340
Posted: Thu Jul 25 23:52:17 1985
Date-Received: Sat, 27-Jul-85 03:01:41 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 49

From: imagen!geof@su-shasta.ARPA


It seems that every now and then someone new brings up the topic of
keep-alives again.  I guess that I'll be the one (probably of many) to
answer this time.

TCP is a general purpose protocol, which is used over networks where
bandwidth is cheap and over networks where bandwidth is expensive. 
Since a major goal of the Internet protocol is to abstract the exact
nature of the network(s) in use, it is almost always impossible for a
host to know what networks a TCP connection is using (Indeed, the
connection may be using more than one set of networks).

The only way to verify that a TCP connection is working is to send a
packet over the connection.  On some networks, this costs money.  On
others it costs processing time in loaded gateways.  In short, it would
unacceptably expensive for TCP implementations that use SOME parts of
the Internet to probe the connection every so often just to verify that
the connection is still there.  Since an implementation has no way of
knowing what parts of the Internet it is using, this sort of probe was
left out of TCP-IP.

This means that probing the connection is left as a higher-level issue,
one that TCP explicitly does not deal with.  This is actually a good
idea for another reason.  Some protocols don't need to verify that an
idle connection is still around, because they always push data through
that connection.  Other implementations don't need to determine that
the connection has gone down until they are actually needed again.  For
example, a TAC never times out its TCP connection -- it relies on the
human user (which is always present) to decide for himself that the
connection is dead.

If you need to generate timeouts on your telnet programs, the place to
do it is within telnet itself.  Now you can understand why the telnet
specification suggests sending bogus option negotiations (the other
thing to do is to send AYT's, but some hosts do silly things with them,
like converting them into random control characters that are sent to an
application).

One more thing: at MIT we used to have problems with gateways crashing.
Sometimes (in the early days) a gateway would crash for ten or fifteen
minutes.  How elated were we that TCP does not send keep-alive probes,
since they would have determined (in their cleverness) that the
connection should have been reset, while we human users had higher level
information (Mr. Chiappa yelling down the hall) that the connection
would soon return to good health.

- Geof