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: <9348@ucbvax.ARPA>
Date: Fri, 26-Jul-85 02:40:25 EDT
Article-I.D.: ucbvax.9348
Posted: Fri Jul 26 02:40:25 1985
Date-Received: Sat, 27-Jul-85 03:31:03 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 27

From: CERF@USC-ISI.ARPA


The design of TCP explicitly did NOT introduce an are-you-there
automatic facility. We reasoned that the process above the TCP
level did not care what the condition of the other end was until
it had some data to send. If the process sent data (or a request
or query or a task initiation etc.) then it MIGHT care about
response. Certainly in that case, TCP tries to send repeatedly
and reports back when it cannot get an ACK within the specified
amount of time.  Once the data is accepted (ACKED), only the
process using TCP knows when it should get impatient about getting
an answer. TCP certainly doesn't know.  

If the using process does have a time out after which in really
wants an answer, that is the right time for it to query the
other side (e.g. send a query at the protocol layer above TCP)
and find out what its condition is.

It is fair to argue about reinventing the wheel for each protocol
above TCP, but it was our thought at the time that each process
or application would have different levels of patience regarding
when to get nervous about not hearing a response. So we left out
that feature in TCP, not wanting to impose something arbitrary on
the next level of protocol up.

Vint Cerf