Network Working Group Jon Postel
RFC # 690 USC-ISI
NIC # 32699 June 6,
1975 Comments on the proposed Host/IMP Protocol Change
This is a set of comments on Dave Walden's
RFC 687 suggesting a set of
changes to the host--imp protocol. Dave's points are reproduced here
with my comments underneath.
1. Expanded Leader Size. The leader will be expanded from two to five
16-bit words. This will provide space for necessary field expansions
and additions.
The existing protocols set the host header at 40 bits so that taken
together with the leader the length was 72 bits; a nice boundary for
both 8 bit and 36 bit machines. This suggestion would result in a
prefix of 80 + 40 = 120 bits, not so nice (unless the host header is
extended to 64 bits for a total prefix of 144 bits).
2. Expanded Address Field. The address field will be expanded to 24
bit,
16 bits of IMP address and 8 bits of host address. This expansion
is more than adequate for any foreseeable ARPA Network growth.
Just a few years ago 256 seemed like a lot of hosts, perhaps, a
extensible scheme might be more appropriate. (I concede 16,
777,
216,
is big)
3. New Message Length Field. A new field will be added which will allow
the source host to optionally specify the message length (in bits) to
the IMP subnetwork. The IMP subnetwork may be able to use this
information (when available) to better utilize network buffer storage.
The destination host may also be able to use this information to better
utilize its buffer storage. This field will be 13 bits wide.
This sound very useful, but if we every want to have longer messages
than now the field should be wider, say 16 bits.
4. Expanded Handling Type Field. The handling type field which now is
used to distinguish between priority and non-priority message streams,
etc., will be expanded to eight bits. This expanded field will provide
for the possibility of a number of parallel message streams having
different handling characteristics between pairs of hosts; e.g.,
priority, non-priority, varying numbers of packets per message (see
below), unordered messages (i.e. the present type-3 messages), a message
stream requiring guaranteed capacity, etc, Note that only some of these
Although a host not implementing the new format will not be able to
address hosts on IMPs with IMP-number greater than 63, the IMPs will
wherever possible do the conversion necessary to permit hosts using the
old format to communicate with 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 knowledge of the message type.
This sounds difficult to implement, but it is all in the imp, so
fine. Of course, something along these lines is crucial in an
operating environment. But I am beginning to get concerned about
changes to host--host protocol and network control programs.
[What happened to 10?]
11. Non-blocking Host Interface. A mechanism will be provided which
allows the IMP to refuse a message from a host without blocking the host
interface. This mechanism will permit the IMP to gather the necessary
resources to send the refused message and then ask the host to resend
the message. Finally, the host will be permitted to ask to be able to
send a message and be notified when it is possible without requiring the
message to actually be sent and refused.
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.
I don't see why, but it doesn't matter much.
On the whole a fine set of suggestion, though I am concerned about
changes to host--host protocol implied here or made more desirable by
these suggestions. A rough guess is that there is 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 equals 48
person-months equals 4 person-years. And 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 ]