RFC 660

SOME CHANGES TO THE IMP AND THE IMP/HOST INTERFACE ✨

Title block tea 🫖: This one is from the Network Working Group and it's RFC 660 🎀. D. Walden (BBN-NET) wrote it, it's dated Oct 1974, and it's NIC #31202. The header doesn't list a category or status, and it doesn't say what it obsoletes or updates, so no drama there 💅.

Okay so, in the next few weeks the IMP software is getting some glow-ups 🦋. Some of them touch the IMP/Host software interface as specified in BBN Report No. 1822, Specifications for the Interconnection of a Host and an IMP. There are four areas: a) decoupling of the message number sequences of Hosts, b) Host/Host access control, c) expanding the message number window from four to eight, and d) provision for messages outside the normal message number mechanism. All of these changes are backward compatible, with possible minor exceptions in timing ⏱️🌸.

a. Decoupling of the Host/Host message number sequences

Bestie, this one's a big deal 😭. Since 1972 the IMP system has allowed exactly four messages to be outstanding at a time between any pair of IMPs. That means only four messages total across every possible pair of Hosts on the two IMPs 💀. Since they all had to share those four slots, the Hosts could totally interfere with each other 🙈. To kill that possibility, the IMP's message number logic is soon going to allow a separate message number sequence between each pair of Hosts ✨.

To keep the space needed for all these Host/Host sequences manageable (they currently need the same kind of space as the IMP/IMP sequences), the Host/Host sequences will be taken dynamically from a limited pool of possible sequences 🧚. The pool will be big enough that it seldom gets in the way of a pair of Hosts that want to talk. Hosts will never be prevented from communicating 🫶. And if the Hosts on one IMP want to talk to so many other Hosts at once that the pool runs out, the space in the pool gets quickly multiplexed in time across all the desired Host/Host conversations. So none gets stopped, though they might all get a little slower 🐢.

b. Host/Host access control

Upon instructions from ARPA, we're adding a Host/Host access control mechanism to the IMPs 👑. Any pair of Hosts that wants to communicate gets checked (via bits in the IMP) to verify they have administrative permission to do so 🔥. This check normally happens whenever a pair of Hosts tries to communicate after not having communicated for two minutes ⏰. If the pair isn't allowed to communicate, a special type of Destination Dead Message (sub-code 3) gets sent back to the source Host 💅. By default, though, every Host is allowed to communicate with every other Host initially 🌈.

c. Message number window

Once the message number sequences are on a Host/Host basis instead of an IMP/IMP basis, the number of messages allowed to be outstanding at a time between a pair of Hosts gets expanded from four to eight 📈. That permits increased Host/Host throughput in some cases 🚀.

d. Message outside the normal mechanism

For certain limited experiments being run on the network, it's thought to be desirable for specified Hosts to be able to communicate outside the normal ordered, error-controlled message sequences 🧪. So the IMP/Host protocol gets the following expansion 🎀.

i. A single packet message coming from the source Host to the source IMP with a (new) special message type, 3, goes directly into the IMP store-and-forward logic with a mark saying the packet is this special kind of message. A multi-packet message of type 3 gets discarded 🗑️.

ii. Such messages (packets) are routed normally to the destination IMP, and they might arrive out of order 🌀.

iii. At the destination IMP, messages of the special type go directly onto the destination Host output queue. They skip the reassembly logic and get marked with a special (new) IMP to Host message type, also 3 🦋.

iv. There's no source-to-destination retransmission logic, no reassembly, no RFNMs, no incomplete transmissions, etc. 🙃

v. If at any time there are insufficient resources in the network to handle one of these special messages (for example, the destination Host won't take it), the message gets discarded 💔.

vi. By using the special message type between the Host and the IMP, the normal message number mechanism is preserved for all the Host/Host transmissions that currently depend on it 💜.

Okay, real talk ⚠️: uncontrolled use of this mechanism would degrade the network's performance for everybody. So the set of Hosts allowed to use it will be regulated by the Network Control Center 👀.

Last but not least, please file this note with your copy of BBN Report 1822 until that document gets updated 📎🌸.