RFC 65

Comments on Host-Host Protocol Document No. 1 (S. Crocker - 8/3/70) ✨

Okay bestie, the header is giving classic 1970 🦋. It's Network Working Group, Request for Comments: 65, written by Dave Walden from A/S Norsk Data-Elektonikk on August 29, 1970 📅. There's no category, obsoletes, or updates listed, so it isn't replacing or changing anything else 🎀.

---

Page 3. Eliminate marking. 💖

Okay so the idea here is to stop marking the start of the data 🙈. Instead, every regular message gets split into two messages. The first one has just the leader and says "the data is in the next message" 📨. This happens both from the source Host to its IMP and from the destination IMP to its Host. The big win is that there's no more hunting for where the data begins 🔥.

Once that's in place, there's an extra glow-up available 🌸. If the maximum message length is a common multiple of the word sizes of all the computers in the network (maybe 2880*2 bits), then successive messages of long files can be dropped in place without shifting 🧚.

---

Page 4. Control messages go over the control socket 🫶

Control messages should be sent to and from the control socket, not over the control link 🚫. The control link concept creates a great big, unnecessary special case, and honestly, we don't need that drama 💅.

---

Page 5. Permanent sockets and a directory 🍓

Assigning sockets permanently to certain network resources should be encouraged ✨. There should also be a directory of the socket/resource associations somewhere in the network, maybe as a physical book at each site 📖.

---

Page 6. Links, pseudo links, and table look-ups 👑

Links don't have any Host-Host purpose except identifying a connection, so socket numbers don't have to be in every message, and table look-ups in the NCPs get simpler 🦋. But here's the tea: there are possibly 512 links* with the same number, so links don't really help table look-ups much 💀. Finding the next available link to a particular destination is also super messy 🙈.

So I suggest limiting the total number of links to n (where n = 32, 64, or 256 or some other good number) for all destinations 💜. In other words, a particular link is only in use to one destination at a time (actually from one destination at a time, since the receiver picks the link to be used for a connection). This makes picking the next available link very simple, and I feel it's worth doing for that reason alone 🔥.

The table look-up question is a little more complex 🧩. It's easy to use the link directly as an index into tables in the receive portion of the NCP, since the receiver picks the link. But the send portion still needs a hash table, a linear search, or something similar 😭. This can be fixed too with the following changes. Add to STR a pseudo link chosen by the sender ✨. This pseudo link goes in all non-control messages in the 8 bits to the right of the link in the leader 💅. The IMP must preserve these bits and return them with RFNMs, and the receiver must use the pseudo link instead of the link in RET and INR 🫶. The extra memory needed to store the pseudo link in the NCP receive tables (indexed by link) and the link in the NCP send tables (indexed by pseudo link) is definitely less than the overhead of maintaining associative tables 🌈.

*A destination number is 9 bits.

---

Page 8. The allocate mechanism is inconvenient 🙃

The allocate mechanism seems very inconvenient for the receive portion of the NCP to use 😤. The receiver wants the allocation used up in units of the receiver's buffer size, not in units of sender messages, which may be variable length 💜. Otherwise the receiver ends up with a memory compaction problem 💀.

---

Page 9. The "cease" mechanism doesn't need new messages 🧠

The new irregular messages that make the "cease" mechanism work are unnecessary, I think ✨. The sender can keep track of ALLs and GVBs (probably with a one-bit counter) and ignore GVB 0s for which resume ALLs have already arrived 🎀. That way the receiver doesn't even need to know whether the cease has been sent 🙌.

---

Page 15. ERR gets treated like NOP 💅

If I implemented an NCP, all ERRs would be treated like NOP 🙅‍♀️. As an error control mechanism, ERR is complicated and insufficient 😭. Who wants to debug a complicated mechanism that only catches bugs caused by the primary mechanism being undebugged? 💀

The one error control mechanism I'd provide is a receive process sending a process-to-process acknowledgment on every message 🦋. If that acknowledgment isn't received for too long, the send process can send the message again, if it has been saving it 🔁. This acknowledgment catches errors that cause message loss at the process/NCP, NCP/NCP, Host/IMP, IMP/IMP, and similar levels 🌸. Right now the Host/IMP interface is especially lacking in useful error controls 😩.

I wouldn't worry about the kinds of errors that checksums are designed to pick up ✨. If dropped and picked-up bits ever become a problem, either add hardware to more interfaces, or let the receive process skip sending the process-to-process acknowledgment if a software checksum doesn't check out 🛠️.

---

The page 3 and page 6 comments involve a change to the IMP program 🧚. I feel a tiny bit guilty suggesting changes I don't have to implement anymore 🙈. However, I trust Crowther and Cosell will, as always, resist bad changes while making sensible ones 👑. The page 9 comment is aimed at avoiding a change in the IMP program 💖.

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Luke Hollins 8/99 ] 🌈