Comments on Protocol Re: NWG/RFC #36
RAND's suggested additions to the early host-to-host protocol: errors, queries, termination and broadcast.
Harslem, E. and J.F. Heafner, "Comments on Protocol Re: NWG/RFC #36", RFC 39, DOI 10.17487/RFC0039, March 1970, <https://www.rfc-editor.org/info/rfc39>.
@misc{rfc39,
series = {Request for Comments},
number = 39,
howpublished = {RFC 39},
publisher = {RFC Editor},
doi = {10.17487/RFC0039},
url = {https://www.rfc-editor.org/info/rfc39},
author = {E. Harslem and J.F. Heafner},
title = {{Comments on Protocol Re: NWG/RFC #36}},
pagetotal = 3,
year = 1970,
month = mar,
} RFC text
Network Working Group E. Harslem
Request for Comments: 39 J. Heafner
RAND
25 March 1970
COMMENTS ON PROTOCOL RE: NWG/RFC #36
We offer the following suggestions to be considered as additions to
the April 28th 1970 protocol grammar specifications.
ERROR MESSAGES
<ERR> <Code> <Command in error>
It is desirable to include debugging aids in the initial protocol for
checking out Network Control Programs, etc.
There are three classes of errors--content errors, status errors, and
resource allocation or exhaustion. <Code> specifies the class and the
offending member of the class. The command is returned to the
sending NCP for identification and analysis.
Examples of status errors are: messages sent over blocked links and
attempts to unblock an unblocked link. Examples of content errors
are: an invalid RFC complete; a message sent on a link not connected;
closing of an unconnected link; and an attempt to unblock an
unconnected link. Examples of resource errors are: a request for a
non-existent program and connection table overflow, etc. Resource
errors should be followed by a <CLS> in response to the <RFC>.
QUERIES
<QRY> <My Socket> < >
or <QRY> <Your Socket> <Text>
Queries provide an extension to the <ERR> facility as well as limited
error recovery, thus avoiding re-initialization of an NCP.
The first command requests the remote NCP to supply the status of all
connections to the user specified by the user number in <My socket>.
The second is the reply; <Text> contains the connection status
information. If an NCP wants the status of all connections to a
remote HOST, the <My Socket> is zero.
PROGRAM TERMINATION NOTIFICATION
<TER> <My Socket>
This command supplements rather than replaces <CLS>. It severs all
communication between a program and those programs in a given HOST to
which it is connected. This command performs what would otherwise be
handled by multiple <CLS> commands. <My Socket> contains the sender's
user number.
HOST STATUS
<HCU>
<HGD>
These messages (HOST coming up and HOST voluntarily going down) are
compatible with asynchronous, interrupt-driven programs, as opposed
to the more conventional post/poll method.
TRANSMIT AND BROADCAST
<TRN> <Body>
<BDC> <Body>
Unlike the previous commands, these are not sent over the control
link, but rather over links assigned to user programs. The prefix of
<TRN> or <BDC> indicates, to the receiving NCP, the disposition of
the message body. <TRN> indicates a message to be passed to a single
process. <BDC> specifies to the destination NCP that the message is
to be distributed over all receiving connections linked to the
sender. In response to a system call by the user to an NCP
requesting <BDC>, the NCP generates one <BDC> to each HOST to which
the sender is connected.
RFC AND DYNAMIC RECONNECTION
This protocol is complex; it proliferates control messages; it causes
queues (to become associated with re-entrant procedures) that are
artificially imposed via the protocol (remote AEN assignment); and
discounts the situation where only controlling process "A" has
knowledge that slave process "B" should be "rung out" in a dynamic
reconnection.
The <ERR>, etc., are suggestions for inclusion as additions in the
April 28th protocol specifications. The above criticism is, of
course, not intended to affect modification of the RFC structure by
April 28th, nor to reflect on those who planned it. We have not
studied the problem. It is meant, however, to voice our concern
about complexity and resulting response times. This is a difficult
problem and it deserves more study after we have exercised the
current RFC specifications. We hope to offer constructive
suggestions with respect to the RFC in the future.
JFH:hs
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Mario Vitale 08/99 ]
AI ELI5
On this page
§1Suggestions for the April 28th Protocol
RAND authors E. Harslem and J. Heafner offer suggestions to be considered as additions to the April 28th 1970 protocol grammar specifications. The protocol is the one described in RFC 36, and this note updates it.
The additions are small new commands, written in angle brackets in the style of the grammar: <ERR>, <QRY>, <TER>, <HCU>, <HGD>, <TRN> and <BDC>. The note ends with a criticism of the request-for-connection structure.
Some people read a draft rulebook and wrote back with a list of extra rules they would like to add, plus a worry that part of it is too complicated.
§2Error Messages and Queries
The <ERR> <Code> <Command in error> message is meant as a debugging aid for checking out Network Control Programs. There are three classes of error: content errors, status errors, and resource allocation or exhaustion. The code names the class and the offending member of it, and the bad command is returned to the sending NCP for analysis.
Examples given include messages sent over blocked links (status), closing an unconnected link (content), and connection table overflow (resource). Resource errors should be followed by a <CLS> in response to the <RFC>, the protocol's own connection-request command.
Queries extend this with limited error recovery, avoiding re-initialization of an NCP. <QRY> <My Socket> asks the remote NCP for the status of all connections to the user given in My Socket. The reply form <QRY> <Your Socket> <Text> carries the status in its text. To ask about all connections to a remote HOST, My Socket is zero.
If a computer sends a message that does not make sense, the other one hands it back with a note saying what kind of mistake it was. A computer can also ask, what is going on with our connections.
§3Termination, Host Status and Broadcast
<TER> <My Socket> supplements <CLS>. It severs all communication between a program and the programs in a given HOST that it is connected to, doing what would otherwise take multiple <CLS> commands. My Socket holds the sender's user number.
The pair <HCU> (HOST coming up) and <HGD> (HOST voluntarily going down) suit asynchronous, interrupt-driven programs, as opposed to the more conventional post and poll method.
<TRN> <Body> and <BDC> <Body> are not sent over the control link but over links assigned to user programs. The prefix tells the receiving NCP what to do with the body: <TRN> passes it to a single process, while <BDC> distributes it over all receiving connections linked to the sender. For a broadcast request, the NCP generates one <BDC> to each HOST the sender is connected to.
There would be one command to hang up on everyone at once, a message that says, I am turning on, or I am shutting down, and a way to send one note to one friend or to a whole group.
§4Concerns About Connection Setup
The authors criticize the request-for-connection (RFC) and dynamic reconnection scheme. They say it is complex, proliferates control messages, causes queues to be artificially imposed by the protocol (remote AEN assignment), and ignores the case where only controlling process A knows that slave process B should be rung out in a dynamic reconnection.
The criticism is not meant to hold up changes to the RFC structure by April 28th, nor to reflect on those who planned it. The authors say they have not studied the problem. They raise concern about complexity and response times, say it deserves more study after the current specifications have been exercised, and hope to offer constructive suggestions later.
They also say, nicely, that one part of the draft seems to need too many steps and may be slow. They promise to help find something simpler once people have tried it.