Comments on the proposed Host/IMP Protocol changes

J. Postel

doi:10.17487/RFC0690

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC690

UNKNOWN
Updated by: 692

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 facilities will be available in the near term.

Postel                                                          [Page 1]


RFC 690    Comments on the proposed Host/IMP Protocol Change   June 1975

This sounds like a good extension.

5. Source Host Control of Packets per Message.  The possibility will

exist for the source host to specify a message stream which will use a given number of packets per multi-packet message (e.g. two packets per message or five packets per message). Since the IMP network will not have to use eight packet-buffers for reassembly purposes, as at present, this may result in better services for such messages. This will help users who need both low delay and high throughput.

This seems strange, why not use the message length (as provided in 3 above) to determine the number of packets needed for this message.

6. Unordered (type-3) Message Change.  Unordered messages will be

indicated by a handling type rather than by a message type as at present. This is compatible with the need to check the host access control capabilities of all messages. This will provide a slight backward incompatibility for the three or so hosts which presently use type-3 messages in their research.

Good, a current special case becomes a general facility.

7. Change in Format of Fake Host Addresses.  The For/From IMP bit will

be eliminated. The fake host addresses will be the four highest host numbers (e.g. IMP Teletype will be host 252).

Another change for the better.

8. Addition of a Parameter to the IMP to Host NOP.  The IMP to host NOP

will have added to it a parameter specifying the address (IMP and host number) of the host.

Ah, a clever touch, very handy.

9. Backward Compatibility.  The old and new formats will be supported in

parallel in the IMPs for the foreseeable future to allow gradual phaseover of host software. A host will be able to specify to its IMP whether the old or new formats are to be used; thus, it will be possible for the host to specify switching back and forth between the two modes for debugging purposes. The specification of the mode to be used will be possible via a proper choice of format in the host to IMP NOP message; The IMP will use the mode of the Host to IMP NOP message the IMP has received. Further, a host may select to use either the old or new format without needing to know more about the other format message than to discard them should they arrive. The IMP will initialize by sending several NOP messages of each type to give the hosts its choice. 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.

Postel                                                          [Page 2]


RFC 690    Comments on the proposed Host/IMP Protocol Change   June 1975

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 ]

Postel [Page 3]

Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.