Time-Out Mechanism in the Host-Host Protocol
A proposed timeout for resolving unanswered Host-Host connection commands.
Kline, C. and J. Wong, "Time-Out Mechanism in the Host-Host Protocol", RFC 142, DOI 10.17487/RFC0142, May 1971, <https://www.rfc-editor.org/info/rfc142>.
@misc{rfc142,
series = {Request for Comments},
number = 142,
howpublished = {RFC 142},
publisher = {RFC Editor},
doi = {10.17487/RFC0142},
url = {https://www.rfc-editor.org/info/rfc142},
author = {C. Kline and J. Wong},
title = {{Time-Out Mechanism in the Host-Host Protocol}},
pagetotal = 2,
year = 1971,
month = may,
} RFC text
Contents
Network Working Group Charley Kline
Request for Comments #142 Johnny Wong
NIC #6727 UCLA (NMC)
Categories: C.1, C.2, C.3, C.5 3 May 71
Updates: none
Obsoletes: none
Time-out Mechanism in the Host-Host Protocol
On sending a message to a foreign site, the following situations can
occur:
1. Destination IMP down - Type 7 message is returned
2. Destination IMP up but destination IMP-HOST interface is
down - Type 7 message is returned.
3. Destination IMP and IMP-HOST interface up, but IMP-HOST inter-
face is not taking messages - Type 9 message is returned after
IMP time-out (ask BBN for time).
4. Destination IMP and IMP-HOST interface up and IMP-HOST inter-
face is taking messages - Type 5 (rfnm) message is returned.
A suggestion for handling type 7 and type 9 messages has been made in
NWG/RFC #117. In this document we would like to discuss in detail the
problem: what should happen to the HOST-HOST protocol on receiving a
rfnm?
When a NCP sends out a STR or RTS control command on a pair of sockets
and gets a rfnm back, this pair of sockets will be in a wait-match
state. Everything is fine if a matching RTS or STR, or CLS is
returned after a reasonable amount of delay. Trouble will arise when
nothing is returned after a long time.
This can happen if the NCP is not running at all but its host is
taking in messages (e.g. UCLA's host will receive messages even if the
NCP is not running), or if the NCP is running very slowly. The same
problem exists on sending out a CLS control command and a matching CLS
is never returned. The trouble is that resources are tied up, e.g.
sockets, links and table space in the NCP; and one would like to
release these resources. In our implementation, when a user does a
CLOSE, we can't release the sockets until the matching CLS is
returned. This protects us from getting confused if a seconds request
is made for the same pair of sockets. This problem can be solved by
including a time-out mechanism in the Host-Host protocol. This
operates as follows:
ne 5
a. On sending out a STR or RTS and if you do not get back a match-
ing RTS or STR, or a CLS in T time units a CLS will be sent.
After sending the time-out CLS race condition can be avoided
by ignoring the matching RTS or STR that arrives before the
matching CLS.
b. On sending out a CLS (any kind, including the time-out CLS),
and if you do not get back a matching CLS in T time units, the
matching CLS is assumed to have returned. However, if a RTS or
STR is sent on the same pair of sockets anytime after the time
out and before a CLS is returned, and then we receive the CLS,
there is no way to determine whether this returning CLS is for
matching the previous CLS or for refusing the RTS or STR. (See
the figure for detail). So far we could not solve this race
condition except by assigning sequence number to connection
throughout the Network which we don't think is a good solution
at all. Hence, we would like to bring the attention of the
Host-Host Protocol Glitch Cleaning Committe to this problem.
The time limit T should be a Network Standard and its value should
be decided also.
Reason Our NCP
------ -------
1. User requests connection 1. RTS ->
2. User gets tired requests CLS
(or NCP timeout) 2. CLS ->
3. No matching CLS returned in
T time units 3. CLS assumed returned
free socket and other
resources
4. User requests another connection
over same socket pair 4. RTS ->
5. CLS received ?? does it belong to
2 or 4?
Figure
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Gert Doering 4/97]
ISO Plain Language
On this page
§1When Commands Receive No Match
After sending to a foreign site, an IMP may return Type 7 or Type 9 messages for some failure conditions, or Type 5 (RFNM) when the destination interface is taking messages. The note focuses on what the Host-Host protocol should do if an NCP sends STR or RTS and then receives an RFNM but no matching RTS, STR or CLS arrives after a long time.
A similar problem occurs when a sent CLS never receives a matching CLS. Sockets, links and NCP table space remain tied up while the host waits.
A host can receive an RFNM but still wait a long time for the matching connection command. Waiting also holds sockets and other resources that the host might want to reuse.
§1Timeout Actions for STR, RTS and CLS
If a sent STR or RTS has no matching RTS, STR or CLS within T time units, the proposal sends a CLS. It says the host can avoid one race by ignoring a matching RTS or STR that arrives before the matching CLS.
If a sent CLS receives no matching CLS within T time units, the host assumes the matching CLS has returned and frees the resources.
After waiting T time units for a connection response, the host sends CLS. If a close receives no matching close within T, the host treats it as completed and frees the resources.
§1A Late Close Can Be Ambiguous
After timing out a CLS, a host may free the socket pair and send a new RTS or STR on it. If a CLS then arrives, the host cannot tell whether it matches the earlier close or refuses the new connection.
The authors say they have not solved this race and do not favor assigning network-wide sequence numbers to connections. They ask the Host-Host Protocol Glitch Cleaning Committee to consider the issue; the value of T also remains to be decided as a network standard.
A late CLS could refer to an old close or a new connection request on the same sockets. The note identifies this ambiguity but does not solve it.