RFC 467

RFC 467 🎀

Proposed Change To Host-Host Protocol Resynchronization Of Connection Status

Okay so this doc is from 20 February 1973 and it was written by J. Burchfiel and R. Tomlinson at Bolt Beranek and Newman (NIC 14741). Its header doesn't say anything about a category or status, and it doesn't list anything it obsoletes or updates, so there's nothing else to note up top 💅

---

I. Introduction ✨

Bestie, the current Host-Host protocol (NIC #8246) has zero provisions for resynchronizing the status information kept at the two ends of each connection 😭 If either host has a service interruption, or a control message gets lost or corrupted in an interface or in the subnet, the status info at the two ends of the connection becomes inconsistent. Not cute.

And since the current protocol has no way to fix this, the NCPs at both ends stay "confused" forever 💀 A super frequent and frustrating symptom is the "lost allocate" phenomenon. The receiving NCP thinks it has bit and message allocations outstanding, while the sending NCP thinks it has no allocation at all. So information flow over that connection can literally never restart. Main character problem, but make it a connection problem 🙈

Now, the Host-Host RST (reset) command is NOT the move here, because it destroys all connections between the two hosts. We need a way to reset only the affected connection without disturbing any others. Protect the other connections, pls 🫶

There's also a second troublesome symptom called the "half-closed" connection. After a service interruption or network partitioning, one NCP may believe the connection is still open, while the other believes it's closed. (Does not exist.) 🦋 When an inconsistency like this is discovered, the "open" end of the connection should be closed.

---

II. The RCR and RCS Commands 🌸

To get allocation resynchronized, we're proposing the addition of the following two commands to the host-host protocol. Two new commands, iconic behavior 👑

         8           8
   +-----------+-----------+
   |    RCS    |   link    |   Reset connection by sender
   +-----------+-----------+

         8           8
   +-----------+-----------+
   |    RCR    |   link    |   Reset connection by receiver
   +-----------+-----------+

So the RCS command is sent from the host sending on "link" to the host receiving on "link". The sending host can send it whenever it wants to re-synch the status info for the connection. Some circumstances where the sending Host might choose to do this:

1. After a timeout when there is traffic to move but no allocation. (Assumes that an allocation has been lost)
2. When an inconsistent event occurs associated with that connection (e.g. an outstanding allocation in excess of 2^32 bits or 2^16 messages.

Next, the mechanics of re-synchronizing the allocations are honestly simple 🧚

1. Empty all messages and allocates from the "pipeline".
2. Zero the variables at both ends indicating bit and message allocation.
3. Restart allocate/message exchanges in the normal way.

And this resynchronization scheme is race-free because the RCS and RCR commands are used as a positive acknowledgement pair. Two commands, one perfect handshake 🔥

---

III. Resynchronization by Sender 💜

To initiate resynchronization, the sending NCP should:

1. Put the connection in a "waiting-for-RCR-reply" state. No more regular messages may be transmitted over this connection until the RCR reply is received.
2. Wait until the message pipeline is empty, i.e. until a RFNM has been received for each regular message sent over this connection. This synchronizes the control and data activity, and also assures that the data stream will not be corrupted during the control re-synchronization exchange. Patience is a virtue, babe 🫶
3. Send the RCS command.
4. Continue to process allocates normally, updating the variables which indicate outstanding bit and message allocation.

When the receiving NCP receives the RCS, it should:

1. Zero the variables indicating outstanding bit and message allocation.
2. Reset the connection to the state which indicates readiness to accept a message.
3. Confirm the re-synchronization by sending the RCR reply.
4. Reconsider bit and message allocation, and send an ALL command for any allocation it cares to do.

When the sending host receives the RCR reply, it should:

1. Zero the variables indicating outstanding bit and message allocate.
2. Put the connection into the "ready-to-send-message" state in preparation for any forthcoming ALL commands.

And at this point, the "pipeline" contains no messages and no allocates, and the outstanding allocation variables at both ends are in agreement. (With value zero) ✨🎀 Everyone is on the same page now, slay.

Heads up, this is part 1 of 2. Part 2 picks up at Section IV (Resynchronization By Receiver) 👀

VII. Redefinition of RTS, STR, ERR (link) to Handle Half-closed Connections ✨

okay so the "missing CLS" situation from before can show up in two different ways 🙈 let's go bestie

The first way starts at the NCP at the "open" end. It may keep sending regular messages on the link of the half-closed connection, or control messages that reference its link 📨 The NCP at the "closed" end should respond with the ERR message, saying the link is unknown. (Error code = 5 does not correspond to an open connection). Once the "open" end gets that ERR, it should close the connection by fixing its tables, with no CLS command needed 💅 and now both ends are finally on the same page 🫶

The second way starts at the "closed" end. It might (thinking the connection is closed, bless it 😭) send an STR or RTS to reopen the connection. The NCP at the "open" end will notice something's off when that RTS or STR shows up, because it names the same foreign socket as an existing open connection 👀 In that case the "open" end should close the connection (again, without sending any CLS command) to get both ends in agreement before it responds to the RTS/STR 💖

VIII. Conclusions 🎀

Section II's resynchronization scheme has one super important property: the data stream is preserved through the exchange 🌈 no data gets lost, so it's totally safe to start resynchronization from either end at any time. When in doubt, resynchronize 💜

The changed semantics of RTS, STR, and ERR(code 5) give us the sync we need to finish closing those half-closed connections ✨

Honestly, the protocol changes above make the host-host protocol way more robust 💪 useful work can keep going even when the communications components lapse 🦋 main character energy for sure 👑

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Via Genie 08/00]