Comments on Host/Host Protocol document #1
Comments on the early host-to-host protocol specification.
Walden, D.C., "Comments on Host/Host Protocol document #1", RFC 65, DOI 10.17487/RFC0065, August 1970, <https://www.rfc-editor.org/info/rfc65>.
@misc{rfc65,
series = {Request for Comments},
number = 65,
howpublished = {RFC 65},
publisher = {RFC Editor},
doi = {10.17487/RFC0065},
url = {https://www.rfc-editor.org/info/rfc65},
author = {D.C. Walden},
title = {{Comments on Host/Host Protocol document #1}},
pagetotal = 2,
year = 1970,
month = aug,
} RFC text
Network Working Group Dave Walden
Request for Comments: 65 A/S Norsk Data-Elektonikk
August 29, 1970
Comments on Host-Host Protocol Document No. 1 (S. Crocker - 8/3/70)
Page 3. Eliminate marking. Instead, make all regular messages into
two message: The first containing just the leader and indicating that
the data follows in the second (next) message. Do this both from the
source Host to its IMP and from the destination IMP to its Host.
Thus, no more hunting for the beginning of the data is necessary.
Once this adjustment is made, an additional simplification is
available. If the maximum message length is a common multiple of the
word sizes of all the computers in the network (perhaps 2880*2 bits),
successive messages of long files can be dropped in place without
shifting.
Page 4. Control messages should be sent to and from the _control
socket_ -- not over the control link. The concept of the control
link causes a great big, unnecessary special case.
Page 5. Assigning sockets permanently to certain network resources
should be encouraged and a directory of the socket/resource
associations should be available somewhere in the network, perhaps in
physical book form at each site.
Page 6. Links have no Host-Host purpose other than identifying a
connection so that socket numbers don't have to be included in all
messages and to simplify table look-ups in the NCPs. However, since
there are possibly 512 links* with the same number, links don't aid
table look-ups very much. Also finding the next available link to a
particular destination is very ugly . Therefore, I suggest limiting
the number of links to a total of n (where n = 32, 64, or 256 or some
other good number) for all destinations. In other words, a
particular link is only in use to one destination at a time(actually
from one destination at a time since the receiver picks the link to
be used for a connection). This change makes picking the next
available link very simple and,I feel,is a worthwhile change if only
for this reason. The question of simplifying table look-ups is a
little more complex. It is easy to use the link directly as an index
into tables in the receive portion of the NCP since the receiver
picks the link. But a hash table or linear search or something is
still necessary in the send portion of the NCP. This too can be
fixed with the following changes. Add to STR a _pseudo link_ chosen
by the sender. This link is sent in all non-control messages in the 8
--------------------------------------
*A destination number is 9 bits.
bits to the right of the link in the leader. The IMP must preserve
these bits and return them with RFNMs and the receiver must use the
pseudo link instead of the link in RET and INR. The extra memory
necessary to store the pseudo link in the NCP receive tables (which
are indexed by link) and the link in the NCP send tables (which are
indexed by pseudo link) is certainly less than the overhead necessary
to maintain associative tables.
Page 8. The allocate mechanism seems very inconvenient for the
receive portion of the NCP to use. The receiver wants the allocation
to be used up in units of the receiver's buffer size not in units of
sender messages which may be variable length. Otherwise the receiver
has a memory compaction problem.
Page 9. The new irregular message to make the "cease" mechanism
work are unnecessary, I think. The sender can keep track (probably
with a one bit counter) of ALLs and GVBs and ignore GVB 0s for which
resume ALLs have already arrived. This the receiver need not know
whether the cease has been sent or not.
Page 15. If I implemented an NCP, all ERRs would be treated like
NOP. As an error control mechanism ERR is complicated and
insufficient. Who wants to debug a complicated mechanism which only
catches bugs due to the primary mechanism being undebugged. The one
error control mechanism I would provide is a receive process to send
process acknowledgment on every message. If this is not received for
too long, the send process can send the message again if it has been
saving it. This acknowledgment catches errors causing message loss
at the process/NCP, NCP/NCP, Host/IMP, IMP/IMP, etc. levels.
Currently the Host/IMP interface is particularly lacking in useful
error controls. I wouldn't worry about kinds of errors check-sums
are designed to pick up. If dropped and picked up bits ever become a
problem either add hardware to more interfaces or let the receive
process not send the process to process acknowledgment if a software
checksum does not check.
The page 3 and page 6 comments involve a change to the IMP program.
I feel a tiny bit guilty suggesting changes I don't have to implement
any more. However, I trust Crowther and Cosell will, as always,
resist bad changes while making sensible ones. The page 9 comment is
aimed at avoiding a change in the IMP program.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Luke Hollins 8/99]
AI ELI5
On this page
§1Overview of Feedback
Dave Walden from A/S Norsk Data-Elektronikk comments on the Host-Host Protocol document by S. Crocker. His comments address seven major areas of the specification, ranging from message format to connection management and error handling.
A network engineer reviews a draft and notes problems with how it is designed.
§2Format and Connection Issues
On marking: Walden agrees with earlier proposals to eliminate marking. He suggests sending the leader and data as two consecutive messages instead, which simplifies processing. If the maximum message length is a multiple of all machine word sizes (such as 2880 × 2 bits), successive messages can be placed directly without any shifting.
On links: Walden observes that links have no value beyond identifying a connection, since there are 512 possible links per destination and thus do not significantly speed table lookups. He proposes limiting the global link count to a fixed number (32, 64, or 256) for all destinations, making link allocation simple. To recover the multiplexing benefit, he suggests adding a 'pseudo-link' field chosen by the sender and included in all non-control messages. This allows a single link to multiplex multiple logical connections, with the NCP using the link for receive table lookups and the pseudo-link for send table lookups.
On control messages: Walden argues control messages should use a dedicated control socket rather than a special control link, which removes a special case from the protocol.
The current design has links that try to do too much. Use fewer links, and let senders tag their messages with their own numbers instead.
§3Allocation, Cease, and Error Handling
On allocation: Walden notes that the receiver wants allocations in units matching its buffer size, not in sender message units which may vary. This causes memory fragmentation problems.
On cease mechanism: Walden suggests the cease mechanism for flow control is overcomplicated. The sender can track ALLs and GVBs with a simple bit counter and ignore duplicate GVBs; there is no need for special irregular messages if the receiver is not told about cease status.
On resources: Walden encourages assigning sockets permanently to network resources and maintaining a directory of socket-to-resource mappings at each site.
On error control: Walden considers the ERR error code mechanism insufficient and complicated. He proposes replacing it with simple end-to-end acknowledgments from receiving process to sending process on every message. If an acknowledgment is not received in time, the sender retransmits. This single mechanism catches errors at any layer, whereas ERR only catches bugs from bugs in the primary mechanism.
Make allocations match how the receiver wants to organize memory. The flow-stop mechanism is too complex. And instead of special error codes, just have every message acknowledged, and the sender retries if no reply.