Browse Prior Art Database

Comments on the proposed Host/IMP Protocol changes (RFC0690) Disclosure Number: IPCOM000003738D
Original Publication Date: 1975-Jun-01
Included in the Prior Art Database: 2019-Feb-14
Document File: 3 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR

Related Documents

10.17487/RFC0690: DOI


Comments on suggestions in RFC 687; see also RFCs 692 and 696.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

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

Postel [Page 1]

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

facilities will be available in the near term.

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)...