Index Journeys
RFC 692 UNKNOWN ARPANET · IMP · HEADERS

Comments on IMP/Host Protocol changes (RFCs 687 and 690)

A 1975 note arguing that a 104-bit IMP leader is better than changing every host's protocol leader.

On rfc-editor.org ↗
PUBLISHED
June 1975
AUTHORS
S.M. Wolfe
STREAM
Legacy
BUILDS ON
RFC 690 — Comments on the proposed Host/IMP Protocol changes
COMBINED LEADER LENGTH IN QUESTION
120 bits
ALTERNATIVE WITH HOST LEADER LONGER
144 bits
SUGGESTED IMP LEADER
104 bits instead of 80
IRREGULAR MESSAGE DATA LENGTHS
96, 104 or 112 bits
DOI
10.17487/RFC0692
LINEAGE · FROM THE RFC INDEXOpen full graph →
'75RFC 690Comments on the proposed Host/IMP Protocol changes'75RFC 692Comments on IMP/Host Protocol changes (RFCs 687 and 690)

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
Network Working Group                                      Stephen Wolfe
RFC # 692                                                  UCLA CCN
NIC # 32734                                                June 20, 1975


       COMMENTS ON IMP/HOST PROTOCOL CHANGES, (RFCS 687 AND 690)

Basically, the proposed set of changes in RFC 687 seems reasonable, as
are the comments in RFC 690.

The major problem, as pointed out by Postel, is the change in the
combined length of the IMP and Host leaders to a total of 120 bits,
which is not a multiple of both 8 and 36 bits.

The suggested solution is to increase the length of the host to host
protocol leader by 24 bits, creating a total length of 144 bits.  The
problem, however, is that the only way of compatibly changing this
length would be to have the IMP either insert or delete the extra 24
bits when converting to/from the old format leader.  The problems with
this solution are obvious.

The better solution is to change the length of the new proposed IMP
leader. I suggest 104 bits instead of 80 bits.  The complaint that 104
is not a multiple of an IMP word is valid, but it should not be that
difficult if the following rules are observed.

    1.  The last 8 bits are never used to convey information.

    2.  The network is not required to pass them from source to
        destination, or to return them to the source.

    3.  When sending messages of types other than zero, (irregular
        messages), the IMP is allowed to send either 96, 104 or 112 bits
        of data, the choice being at the IMP's convenience.

    4.  Also, if desired, either 96 or 112 could be used as the new
        leader length for irregular messages.

It must be faster (and cheaper) to just change the IMP program to handle
a 104 bit leader, than to force additional changes in all hosts using
the standard protocol.

Another suggested extension to the protocol would add a new type of IMP
to Host message.  This message has a table of Host names (people type
character strings) and Host network addresses.  Send this message(s) to
the Host after each interface reset, or alternatively, it could be a
response to a new Host to IMP request for this information.

       [ 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.            10/99 ]

AI ELI5

On this page
PROBLEMThe changes in RFC 687 would make the combined IMP and Host leaders 120 bits, which is not a multiple of both 8 and 36 bits.
MECHANISMStephen Wolfe suggests making the new IMP leader 104 bits instead of 80, with rules that let the IMP ignore the last 8 bits, and also proposes a new IMP-to-Host message carrying Host names and addresses.
THE ARGUMENTThis is a short comment, not a specification. It argues that changing the IMP program is faster and cheaper than forcing changes in all hosts.

§1The Leader Length Problem

Wolfe, at UCLA CCN, finds the changes proposed in RFC 687 and the comments in RFC 690 basically reasonable. The major problem, pointed out by Postel, is that the combined length of the IMP and Host leaders becomes 120 bits, which is not a multiple of both 8 and 36 bits.

One suggestion is to lengthen the host-to-host protocol leader by 24 bits, for a total of 144 bits. But the only compatible way would be for the IMP to insert or delete the extra 24 bits when converting to or from the old format, and Wolfe says the problems with that are obvious.

Two headers stuck together come out to a size that does not fit nicely in either of the two kinds of computer word. Making one longer by a lot is messy.

§2A 104-Bit IMP Leader

Wolfe prefers to change the new IMP leader itself, to 104 bits instead of 80. He accepts that 104 is not a multiple of an IMP word, but says it should not be difficult if four rules are followed.

  • The last 8 bits are never used to convey information.
  • The network is not required to pass them from source to destination, or to return them to the source.
  • For message types other than zero (irregular messages), the IMP may send 96, 104 or 112 bits of data, at its convenience.
  • If desired, 96 or 112 could instead be the new leader length for irregular messages.

His reasoning is that it must be faster and cheaper to change the IMP program to handle a 104-bit leader than to force additional changes in all hosts using the standard protocol.

Make the one piece the network controls a bit longer, and agree that the last few bits are just filler. That is easier than asking everyone to change.

§3A Host Name Table Message

Wolfe also suggests a new type of IMP-to-Host message. It would carry a table of Host names (character strings that people type) and Host network addresses.

The message or messages would be sent to the Host after each interface reset. Alternatively, it could be a response to a new Host-to-IMP request for this information.

The network would hand each computer a phone book of names and numbers when it connects, or whenever it asks for one.

§4References

RFC 687RFC 687RFC 687, proposed changes to the IMP/Host protocol.June 1975RFC 690RFC 690RFC 690, comments on the proposed changes.June 1975