Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!GATEWAY.MITRE.ORG!barns
From: barns@GATEWAY.MITRE.ORG (Bill Barns)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SO_KEEPALIVE considered harmful?
Message-ID: <8905261507.AA26325@gateway.mitre.org>
Date: 26 May 89 15:07:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 50

Sigh.  The Tenex TCP of ages ago certainly allowed the user timeout to
be set infinite, by specifying a value of 0.  If there are older ones
than that, I don't think they can be much older!  I think the claims
about the old TCP's having this capability are grounded in fact.

However, it just may be that Bob & Dave fell into a trap here.  I
almost wrote the message they both wrote, but went off to check RFC 793
and I did not locate any text stating that an RFC 793 conformant TCP
necessarily has to provide any particular range of user timeout
settings, except that the default is five minutes.  And I was just SURE
it was there.  Oops.  The designers probably had it so firmly in their
minds from prior discussions that they forgot to write it down explicitly.

THAT sounds like a job for **!!HOST REQUIREMENTS MAN!!**

However**2, TCP is ALSO specified in MIL-STD-1778, and it DOES have an
explicit requirement for the TCP to allow the upper layer to choose
whether a user timeout should result in a notification to the upper
layer or should cause the TCP to abort the connection.  This is
referred to in many places but the most coherent description is in
section 9.2.9.  For your convenience, I've appended it below.

Sad to say, there are (other) inconsistencies within the MIL-STD and
between it and the RFC.  The MIL-STD, section 9.4.4.7, sets the default
timeout as 120 unidentified units.  Obviously 24ths of a minute... etc.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-------

[MIL-STD-1778]

9.2.9  ULP timeout and ULP timeout action.  The timeout allows a ULP to
set up a timeout for all data submitted to the TCP entity.  If some
data is not successfully delivered to the destination within the
timeout period, the state of ULP_timeout_action is checked.  If
ULP_timeout_action is 1, the TCP entity will terminate the connection.
If it is 0, the TCP entity informs the ULP that a timeout has occurred,
and then resets the timer.  The timeout appears as an optional
parameter in the open request and the send request.  Upon receiving
either an active open request, or a SYN segment after a passive
request, the TCP entity must maintain a timer set for the interval
specified by the ULP.  As acknowledgments arrive from the remote TCP,
the timer is cancelled and set again for the timeout interval.  As
parameters of the SEND request, timeout and timeout_action can change
during connection lifetime.  If the timeout is reduced below the age of
data waiting to be acknowledged, the event dictated by
ULP_timeout_action will occur.  The implementor may choose to allow
additional options when informing the ULP in case of a timeout; for
example, informing the ULP only on the first timeout.