RFC 690

RFC 690: Comments on the proposed Host/IMP Protocol Change 🎀

okay so the title block first 💅 this is RFC 690, titled Comments on the proposed Host/IMP Protocol Change. Jon Postel from USC-ISI wrote it, and it's on NIC #32699, dated June 6, 1975. It's in the Network Working Group. The original doesn't list a category or status, and it doesn't obsolete or update anything. 📋✨

It's a set of comments on Dave Walden's RFC 687, which proposed a bunch of changes to the host–IMP protocol. Jon reproduces each of Dave's points and then adds his own thoughts underneath. We're going through them in order 🦋

---

1. Expanded Leader Size 🌸

Dave wants the leader to grow from two to five 16-bit words, which leaves room for field expansions and additions.

Jon's take: the existing protocols set the host header at 40 bits, so together with the leader the length was 72 bits. That's a cute boundary for both 8-bit and 36-bit machines 🍓 This suggestion would make the prefix 80 + 40 = 120 bits, which is not so nice. Unless the host header gets extended to 64 bits, for a total prefix of 144 bits. 🙈

2. Expanded Address Field 🧚

The address field goes up to 24 bits: 16 bits of IMP address and 8 bits of host address. Dave says that's more than adequate for any foreseeable ARPA Network growth.

Jon says just a few years ago 256 seemed like a lot of hosts, so an extensible scheme might be more appropriate. He concedes that 16,777,216 is big. 💜

3. New Message Length Field 📏

A new field lets the source host optionally specify the message length (in bits) to the IMP subnetwork. The IMP subnetwork may be able to use that info, when it's available, to make better use of network buffer storage. The destination host may be able to use it too, for its buffer storage. This field is 13 bits wide.

Jon says this sounds very useful. But if we ever want longer messages than now, the field should be wider, say 16 bits. 🔥

4. Expanded Handling Type Field 💅

The handling type field, which currently tells apart priority and non-priority message streams and so on, grows to eight bits. That opens up the possibility of a number of parallel message streams with different handling characteristics between pairs of hosts. Examples: priority, non-priority, varying numbers of packets per message (see item 5), unordered messages (the present type-3 messages), and a message stream that requires guaranteed capacity. Only some of these facilities will be available in the near term.

Jon says this sounds like a good extension ✨

5. Source Host Control of Packets per Message 📦

The source host may be able to specify a message stream that uses a given number of packets per multi-packet message, like two packets per message or five. Since the IMP network won't have to use eight packet-buffers for reassembly like it does now, this may give better service for these messages. It helps users who need both low delay and high throughput. 👑

Jon thinks this seems strange, and asks why not use the message length (from item 3) to figure out how many packets are needed for the message. 🤔

6. Unordered (type-3) Message Change 💖

Unordered messages get indicated by a handling type instead of a message type, as they are now. This fits with the need to check the host access control capabilities of all messages. It causes a slight backward incompatibility for the three or so hosts that currently use type-3 messages in their research.

Jon says good, a current special case becomes a general facility 🦋

7. Change in Format of Fake Host Addresses 🎀

The For/From IMP bit gets eliminated. The fake host addresses become the four highest host numbers, so IMP Teletype will be host 252.

Jon says that's another change for the better 🌈

8. Addition of a Parameter to the IMP to Host NOP ⭐

The IMP to host NOP gets a parameter that specifies the address (IMP and host number) of the host.

Jon calls this a clever touch, and very handy 🧚

9. Backward Compatibility 🫶

The old and new formats get supported in parallel in the IMPs for the foreseeable future, so hosts can phase over gradually. A host can tell its IMP whether to use the old or new formats. Because of that, it's possible for a host to switch back and forth between the two modes for debugging. The host picks the mode through the format of the host to IMP NOP message, and the IMP uses the mode of the host to IMP NOP message it has received. A host can use either the old or new format without needing to know anything about the other format's messages, other than to discard them if they arrive. The IMP initializes by sending several NOP messages of each type, so the hosts know its choice.

A host that doesn't implement the new format won't be able to address hosts on IMPs with an IMP-number greater than 63. Still, the IMPs will do the conversion needed, wherever possible, so hosts using the old format can talk to hosts using the new format, and the reverse. Finally, it will be possible to convert the leader format from old to new, or the reverse, without knowing the message type.

Jon says this sounds difficult to implement, but since it's all in the IMP, it's fine. Something along these lines is crucial in an operating environment. He's starting to get concerned, though, about changes to the host–host protocol and network control programs 😭

[What happened to 10?]

11. Non-blocking Host Interface 🚦

A mechanism lets the IMP refuse a message from a host without blocking the host interface. This lets the IMP gather the resources it needs to send the refused message, and then ask the host to resend it. The host can also ask to be able to send a message and be notified when it's possible, without the message actually being sent and refused.

Jon says this is another welcome addition 💜

12. Maximum Message Length 📉

The maximum number of bits of data in a message may be reduced by a few bits.

Jon doesn't see why, but says it doesn't matter much 🙄

---

Jon's overall verdict: a fine set of suggestions, though he's concerned about the host–host protocol changes implied here, or made more desirable by these suggestions. His rough guess is that there's easily a couple of person-months of system programmer time for each operating system on the net implied here. Say 24 systems times 2 person-months each, which is 24 × 2 = 48 person-months, which is 48 = 4 person-years. And he notes this may be the lower bound. 💀✨

---

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.            11/99 ]