RFC 57

Thoughts and Reflections on NWG/RFC #54 🎀

Okay bestie, first the basics 💖 This is RFC #57 from the Network Working Group, written by Mike Kraley (Harvard) and John Newkirk (Harvard), dated June 19, 1970. The original doesn't list a category or status, and it doesn't obsolete or update anything, so there's nothing else to note up here 🧚

While writing NWG/RFC #54, a few new ideas popped up that the NWG hadn't talked about yet, or that were still too fuzzy 🫶 So they didn't make it into the official protocol proffering. We still thought they were good discussion material and could maybe land in the second level protocol later 🌈

I. Errors and Overflow ✨

Following the discussion in NWG/RFC #48, we decided there are two kinds of "errors" that need to be told apart 💅 The first is a real error, like an RFC made of two send sockets. Only a broken NCP can generate this kind of error 💀 Without hardware or software bugs, these should never happen, and the right response when one is detected was laid out in the description of the ERR command in NWG/RFC #54.

The second kind of "error" is an overflow, which happens when finite system resources run out 😭 Say an RFC comes in but there's no room to build the tables and queues it needs. That's not a real error, because nobody did anything wrong (unless the system planners skimped on table space, lol). The recovery is also well defined: you just repeat the request later 🦋 So overflow should be treated differently from a real error, and we think that's important 🔥

In NWG/RFC #54, an overflow got reported by sending back a CLS, like the connection was refused. Honestly, this does the job. It handles the necessary functions and leaves the connection in the correct state 🙈 But the user who started the connection gets misinformed. They think the foreign process turned them down when that's not what happened. In some algorithms, that difference is everything 👑

We also felt that when you define an error, it helps to say why it was detected, not just what caused it ✨ While writing the pseudo-Algol program mentioned in NWG/RFC #55, we came up with 9 error types (plus the unspecified one). So we'd like to extend the ERR message with an 8-bit field right after the op code, to say which type of error it is. The length and text fields would follow, same as before 🍓 Here are the error types we're proposing:

0.  UNSPECIFIED ERROR
1.  HOMOSEX  (invalid send/rcv pair in an RFC)
2.  ILLEGAL OP CODE
3.  ILLEGAL LEADER (bad message type, etc.)
4.  ILLEGAL COMMAND SEQUENCE
5.  ILLEGAL SOCKET SPECIFICATION - COMMAND
6.  ILLEGAL COMMAND LENGTH (last command in message was too short)
7.  CONNECTION NOT OPEN - DATA
8.  DATA OVERFLOW (message longer than advertised available
    buffer space)
9.  ILLEGAL SOCKET SPECIFICATION - DATA (socket does not exist)

Given everything above, we'd also like an extra control command just for signalling overflow 💖

+-------------+-------------------+---------------------+
|     OVF     |     my socket     |     your socket     |
+-------------+-------------------+---------------------+

The OVF message looks a lot like CLS, and it replaces CLS in this situation 🎀 The socket numbers are 32 bits each, and they match the socket numbers in the RFC that's getting rejected. An incoming OVF should behave exactly like an incoming CLS. The one difference is that the user gets told they weren't refused. They just overtaxed the foreign host's resources 😭

There's another option: keep using CLS and add an eight-bit field to say where it came from. We think that's conceptually worse, and harder to build too 🙅‍♀️ Overflow also doesn't need heavy thinking if it's rare. We don't think it'll be rare, though, and leaving out a proper overflow signal would put an unnecessary limit on the user 🧚

II. Host Up and Host Down 🌸

Things can get messy when a host goes down and tries to come back 🥺 There are two cases worth separating. A "soft" crash is when the system knows the machine is about to go down, so there's time to run pre-recovery procedures 🌈 A "hard" crash is usually a system failure. You get basically no warning, and what the machine looks like after it recovers is hardly ever predictable 💀

After a hard crash, the network is in an undefined state. The NCP's data structures are probably destroyed or meaningless 😭 The network only marks the host as dead for processes that tried to send data and got refused. The crashed host's only real option is to re-initialize its tables. So what can the foreign hosts do? 🤔

We'd like to add two control commands: RESET (RST) and RESET REPLY (RSR). Each one is just an op code with no parameters 🫶 When a host gets an RST, it immediately ends all of its connections with the sender, but it does not send any CLS messages 🙅‍♀️ The receiver also notes that the RST's originator is alive, then echoes an RSR back to the sender. When a host gets an RSR, it notes that the echoing host is alive ✨ (You can partly fake the RST function if a host closes all its relevant table entries right when it finds out another host is down.)

So after a hard crash, every connection and connection request gets terminated 💅 The RST tells all the foreign hosts that we're alive again, and every functioning NCP sends back an RSR. From that, you can build a host live table (see NWG/RFC #55), and then connections can start up again 🦋

There are still related problems when the network is still carrying messages from before the crash and needs to sync up with an NCP that has a freshly initialized environment 🙈 We don't have the tools to unblock links, discard messages, and so on. Those tools are exactly what this proposal would need. We think more work with BBN should sort this out 👑

Soft crashes aren't nearly as urgent, but they need more sophisticated (read: complicated) fixes 🧠 Our early experiments on the network show that a good initialization and recovery protocol is way more necessary 🔥

Lots of these ideas got their start, or came together, through conversations with Steve Crocker and Jon Postel 🫶 We also want to shout out Jim Balter and Charles Kline of UCLA, who put a ton of effort into the pseudo-Algol program. That program was the predecessor of a lot of our recent documentation 🌸

[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by  Katsunori Tanaka 2/98 ]