RFC 394

Network Working Group 💖 Request for Comments #394, also known as NIC 11856, written by John M. McQuillan at Bolt Beranek and Newman Inc. on 27 September 1972. It's filed under category B.1 and it updates RFC #381. It obsoletes nothing. 📝

TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL ✨

okay so this note is about two changes to the IMP-Host communication protocol. The base protocol is described in BBN Report 1822 and was revised in RFC 381 🎀. The first change is about the IMP-to-Host interface and the 30-second timeout on each IMP transmission to the Host ⏰. The second change is about the Host-to-IMP interface and proposes a brand new timeout mechanism 🔥. These changes are independent, both in what they say and how they get built 💅. The author wants comments on each proposal 🫶.

Here's the plan: if no adverse comments come in, these get installed in the network on Tuesday, October 10 🦋. If serious adverse comments come in, action gets delayed until early November 😭.

1) Declaring an unresponsive Host as dead to the network 💀

Right now, a Host gets 30 seconds to accept each packet of a regular message, and it also gets 30 seconds to accept non-regular messages 🙈. If the Host is unresponsive for that whole period, the IMP does all of this:

• a) All messages held for the Host get discarded 🗑️.
• b) The source Host for each discarded message gets a type 9, subtype 0 message (Incomplete Transmission - Destination Host Tardy) 📨.
• c) The IMP ready line gets dropped and raised again 🔄.
• d) The Host gets sent 3 type 4 messages (NOP) 🧚.
• e) The Host gets sent a type 10 message (IMP-Host Interface Reset) 🌸.

Here's the new bit 💖. The author proposes that the IMP also declare the Host dead to the network ☠️. Then, when the IMP gets the next bit from the Host, it declares the Host alive again and starts the 30-second delay, while the news that the Host is alive spreads through the whole network 🌈.

Why? Some Hosts have their ready lines up even when they can't accept bits from the IMP, and several Hosts are like this 😤. Some have their ready lines wired to stay on all the time 🙄. Terminal use and survey programs get super annoying when you have to wait 30 seconds just to learn a Host isn't responding 😩. Other Hosts drop into "break-point mode" for system debugging, sometimes for several minutes at a time 🛑. In that mode the NCP software isn't running, so messages pile up in the network and then get thrown away 💔. The author thinks it's better to call those Hosts dead until they send a message* to the IMP ✨. That way, any source Host trying to talk to them can be told right away that the destination Host is dead 🏃‍♀️.

*Thus a Host should send its IMP at least two NOPs (or other messages) whenever it receives a type 10 message from its IMP. 🚨

2) Timing out Host-to-IMP messages in 15 seconds ⏱️

When the IMP gets a message from a Host, it has to grab several internal resources before it can process that message 🧠. It has to assign the message a message number, make an entry in an internal table, and so on 📋. If any of those resources aren't free, the IMP just waits until they are 😴. It can't take in any more messages from the Host during that wait, so the interface gets stopped 🛑. Usually this is only momentary, but sometimes the IMP can't process a message it already started accepting for many seconds 😬.

This is an especially rough situation for Hosts with half-duplex interfaces 💔. If the IMP takes 30 seconds to process a message, the IMP-to-Host timeout from section 1) kicks in, and the Host loses every message sent to it during the last 30 seconds 😭. It's also worth knowing that the half-duplex interface can cause a deadly embrace 💀. For example, the IMP might not be able to get the resources it needs for a message because the Host has several messages queued up that are tying up storage, message numbers, or table slots. The Host has to accept those messages before any more messages can be put into the network 🔒. Even Hosts with full-duplex interfaces can run into this, and it might get in the way of other useful communication 🙃.

Here's the proposal 🎀. The IMP tells the Host when it can't keep processing a message it has started accepting. The IMP tries for 15 seconds, and then sends the Host a type 9, subtype 4 message (bits 30,31,32 = 100), defined as Incomplete Transmission - Resources Unavailable 🚦. In this case, the IMP hasn't been able to send any part of the message into the network 🙅‍♀️. The IMP still takes in the rest of the message 📥. After that, a Host with a half-duplex interface should start accepting messages from the IMP 👂. A Host with a full-duplex interface might try to send some other message instead 🔁. And if the Host wants to, it may retransmit the incomplete message 💅.

[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the   ]
[ direction of Alex McKenzie.                      1/97 ]