RFC 142

Time-out Mechanism in the Host-Host Protocol 🦋

• Network Working Group 🌸 · Request for Comments #142 · NIC #6727
• Authors: Charley Kline and Johnny Wong, UCLA (NMC) 🎀
• Categories: C.1, C.2, C.3, C.5
• Date: 3 May 71
• Updates: none
• Obsoletes: none

So what can actually happen? 💌

Okay bestie, when you send a message to a foreign site, one of four things can happen:

1. Destination IMP down - a Type 7 message comes back 💀
2. Destination IMP up but destination IMP-HOST interface down - a Type 7 message comes back 😭
3. Destination IMP and IMP-HOST interface up, but the IMP-HOST interface is not taking messages - a Type 9 message comes back after the IMP time-out (ask BBN for time) 🙈
4. Destination IMP and IMP-HOST interface up, and the IMP-HOST interface is taking messages - a Type 5 (rfnm) message comes back ✨

A suggestion for handling Type 7 and Type 9 messages was already made in NWG/RFC #117 🧚. This doc is about the next question, and it's a big one: what's supposed to happen to the HOST-HOST protocol when a rfnm comes back? 🤔

The wait-match drama 🎭

When an NCP sends out a STR or RTS control command on a pair of sockets and gets a rfnm back, that pair of sockets is now in a wait-match state 🦋. Everything is fine if a matching RTS or STR, or a CLS, comes back after a reasonable amount of delay. The trouble starts when nothing comes back after a long time 😩.

This can happen if the NCP isn't running at all but its host is still 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. Same problem if you send out a CLS control command and a matching CLS never comes back. The real issue is that resources stay tied up (sockets, links, and table space in the NCP), and we'd really like to release them 🧹.

In our implementation, when a user does a CLOSE, we can't release the sockets until the matching CLS comes back. This protects us from getting confused if a second request is made for the same pair of sockets 🛡️. The fix for all this is a time-out mechanism in the Host-Host protocol, and it works like this:

ne 5 (the stray text you'll see here is a page-break leftover from the original, so we're keeping it as a little souvenir 💅)

a. On sending out a STR or RTS, if you do not get back a matching RTS or STR, or a CLS, in T time units, a CLS will be sent. After sending the time-out CLS, the 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 an 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 a sequence number to connections 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 ⏰.

Here's the figure, bestie. It's giving chaos 🌪️:

       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]