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!cbosgd!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: A Noop Strategy for TCP - second level comments.
Message-ID: <9382@ucbvax.ARPA>
Date: Fri, 26-Jul-85 23:33:45 EDT
Article-I.D.: ucbvax.9382
Posted: Fri Jul 26 23:33:45 1985
Date-Received: Mon, 29-Jul-85 05:28:33 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 46

From: imagen!geof@su-shasta.ARPA


TCP gives higher level protocols the responsibility of probing the
foreign system.  I believe that the higher level protocols divide up
into the following three categories (this is in contrast to one comment
recently made on the list):
	1. Applications where the TCP connection is never idle.  
	   No problem.
	2. Applications where the TCP connection is idle but monitored
	   by a human user.  Give the user a method to probe the connection
	   (like telnet remote echo, or null probes), and you've solved
	   the problem.  Ultimately, every user has his or her own internal
	   timer that says how long he/she is willing to wait. 
	   E.g., User FTP, User Telnet
	3. Applicationes where the TCP connection is idle and are not
	   monitored by a human user.  Then the higher level protocol
	   needs to send probes so that it doesn't hand forever.  
	   E.g.: SMTP, Server Telnet, Server FTP

There is one point of commonality between 2 & 3:

	If a TCP connection is idle, it must always be possible for either
	side to send the other a probe.

I have believed this point for some time.  It is interesting that the
rule is broken by the most obvious example of [3] -- SMTP.  Between the
time a User SMTP finishes sending a message (it sends the ".") and the
time the server sends the response, the user is unable to send any data
down the TCP connection, but must wait for the server.  The TCP
connection is idle, and TCP (as we all know by now) doesn't probe the
connection.  If the server crashes, the user is left hanging forever.

The usual solution is a timeout.  But there is wide variance in both
the time that a system can tolerate a hung SMTP server and the time
that it legitimately takes a slow server to process a message.  So
timeouts will always be causing certain messages/server combinations
to reliably fail.  Not quite what you wanted for a supposedly
autonomous service.  The real fix is an SMTP-level probe.

The same problem is exhibited by XNS Courier, which requires that all
XNS sequenced packet protocol implementations implement keep-alive
probes (probes are permitted but not required by the spec).  Beware if
you implement Courier on top of TCP!

- Geof