RFC 117

okay bestie, RFC 117 is giving "we wrote the big protocol doc and then realised the edge cases were a MESS" 💅✨

Some Comments on the Official Protocol 🦋 is by J. Wong from UCLA (NIC #5826), dated 7 April 1971. It's a Network Working Group doc, Request for Comments: 117 🌸. Its categories are B.1, C.1, C.2, C.3, C.4, and C.5 🗂️. It doesn't list anything it obsoletes or updates, so it's its own little main character 👑.

Okay so Document No. 1 and NWG/RFC No. 107 gave a super detailed breakdown of connection establishment, connection termination and flow control over the Network 📚. BUT while everyone was building the NCP, they realised the handling of ERR control commands, messages of types other than 0 (regular), 4 (nop), and 5 (rfnm), and messages with the From-imp bit on were barely discussed 😭. So problems popped up whenever those situations happened.

The Protocol is not complete if those situations aren't handled clearly, and the Host-Host Protocol Glitch Cleaning Committee should take this into consideration 🧹 (lowkey the best committee name ever). This doc shares experience with these unfavorable situations and suggestions for handling them 💜.

---

1. ERR Control Commands ✨

In Document No. 1, these error conditions are described:

• a. Illegal Op. code.
• b. End of message encountered before all expected parameters.
• c. Bad socket polarity within commands.
• d. Link number not in the range of 0 <= L < 32.
• e. A request (other than RTS/STR) on a non-existent socket.
• f. A request (ALL, GVB, RET, INR, INS) on a non-existent link number.
• g. Transmit over non-existent link number.

Other error conditions are:

• h. A request (GVB, RET, INR, INS) on an existent link, but connection is not established.
• i. Transmit over an existent link, but connection is not established.
• j. ALL or GVB on a send connection.
• k. RET on a receive connection.
• l. An attempt to send more than the allocated number of bits or messages.
• m. ECO, ERP, ERR commands do not have the defined number of bits of data.

In Document No. 1, each site is supposed to document the info on their ERR command. Nobody has done that yet 🙈, and the main reason is that we aren't sure what info is important. In NWG/RFC No. 107, the text portion of the ERR Commands is decided to have a fixed length of 80 bits, because 80 bits is long enough to hold the longest non-ERR command 📏. Some of the error conditions above want more info than the command itself, which is so relatable. These error conditions show up A LOT in the experimental stage of the NCP. If every NCP is operating properly, none of them should ever occur. So the ERR commands are an excellent debugging tool for the protocol 🔍. It's desirable to define a set of possible error conditions, and for each one, define a set of arguments in the matching ERR command, so there's enough info to tell what's wrong. The suggested arguments for each situation (a - m) are below:

• a.
  1. Op. code in error.
  2. Part of message following op. code (A maximum of 72 bits).
• b, c, d, e, f.
  1. The command in error.
• g.
  1. Link number.
  2. Beginning of message (A maximum of 72 bits).
• h.
  1. Command in error.
  2. Socket numbers for the connection.
  3. Status of the connection.
• i.
  1. Link number.
  2. Beginning of message (A maximum of 72 bits).
  3. Socket numbers for the connection.
  4. Status of the connection.
• j, k.
  1. Command in error.
  2. Socket numbers for the connection.
• l.
  1. Link number.
  2. Beginning of message (A maximum of 72 bits).
  3. Number of bits sent.
  4. Number of bits allocated.
  5. Number of messages allocated.
• m.
  1. The Command in error.

Each of the ERR commands should have a special error code (8 bits) to tell the error type, an 80-bits field to store the command in error, and extra fields for socket numbers and other info 💖.

---

2. Imp-to-host messages of types other than 0, 4, and 5. 🌈

From the BBN report 1822, these message types will cause difficulty in implementing the Protocol 😬:

• a. Type 2 - Imp going down.
• b. Type 7 - Destination host or imp dead.
• c. Type 9 - Incomplete transmission.

It was discovered that when you send a message to a site whose imp or host isn't running, a Type 7 or Type 9 message comes back 🔙. That can happen in two situations:

• a. The foreign host or imp is not up at all.
• b. Some connections have been established, and the foreign host or imp goes down.

The first one isn't much of a problem, because the NCP has no entry in its table for that site ✅.

The second one is messier 🫠. If the table entries for connections to the dead host aren't cleared, then by the time that host comes back up, those entries still exist and the info will be super misleading. One suggestion to fix this:

• a. Whenever a NCP comes up, it sends a RESET Control Command to every other site.
• b. Associated with each site there is a bit called the up-bit. If a RESET-reply command is received from some site, the corresponding up-bit is set to 1. Race condition can be avoided by ignoring all messages from sites which have not returned the RESET-reply command.
• c. Messages can only be sent to sites with the up-bit on.
• d. If a RESET control command is received, the Table entries corresponding to the site are cleared, a RESET-reply is immediately returned, and the up-bit for the site is set.
• e. The up-bit is reset to 0 when a Type 7 or Type 9 message is received from a particular site.

The above solution will handle the Type 2 messages also 🙌. When a host gets a Type 2 message, it has no way to tell the other NCP's that its imp is going down. Later messages to this host will return a Type 7 or 9 message, and then the solution above kicks in 🧚.

With the introduction of the RESET and RESET-reply Control command, the ECO and ERP control command are no longer important and should be removed 🗑️.

---

3. Messages with the From-imp bit on. 💜

These kinds of messages aren't discussed at all 🤷‍♀️. Some statistical measurements have been made on messages with the From-imp bit on. We should classify what these messages represent.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Randy Dunlap 4/97]