doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc60.txt b/doc/rfc/rfc60.txt
new file mode 100644
index 0000000..78d7b71
--- /dev/null
+++ b/doc/rfc/rfc60.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                           R. Kalin
+Request for Comments: 60                                             MIT
+                                                            13 July 1970
+
+
+                       A Simplified NCP Protocol
+
+Abstract
+
+   This RFC defines a new NCP protocol that is simple enough to be
+   implemented on a very small computer, yet can be extended for
+   efficient operation on large timesharing machines. Because worst case
+   storage requirements can be predicted, a conservative implementation
+   can be freed of complicated resource allocation and storage control
+   procedures. A general error recovery procedure is also defined.
+
+Overview and Rational
+
+   The central premise of this proposal is an insistence that all user-
+   to-user connections be bi-directional. For those familiar with
+   communication theory, this appears most reasonable. All communication
+   requires a cyclical flow of information. To deny a simple association
+   between a message and its reply makes protocol unnecessarily
+   complicated and turns simple mechanisms of flow control into
+   nightmares.
+
+   It is proposed that a bi-directional connection, or duplex link, be
+   identified by a pair of socket numbers, one for each end. This is
+   half the number presently required. Associated with the connection
+   are some number of "crates" or message containers. These crates
+   travel back and forth over the link carrying network messages from
+   one side to the other. Buffers are allocated at each end of the link
+   to hold crates and the messages that they carry. Worst case buffer
+   requirements are equal to the number of crates in circulation, or the
+   "capacity" of the link.
+
+Details
+
+   A message buffer has four states which follow one another cyclically.
+   They are:
+
+   1) empty,
+
+   2) filled with a message-laden crate to be unloaded,
+
+   3) filled with an empty crate, and
+
+   4) filled with a message-laden crate to be sent.
+
+
+
+Kalin                                                           [Page 1]
+
+RFC 60                  A Simplified NCP Protocol           13 July 1970
+
+
+   Normally state transitions correspond to message arrival, message
+   removal, message insertion and message transmission.
+
+   For a process to be an NCP it must:
+
+   1) be able to make initial contact with foreign hosts via the control
+   link and, if necessary, delete user-to-user links left over from the
+   previous system incarnation.
+
+   2) be able to create user-to-user links.
+
+   3) be able to interface users with these links.
+
+   4) be able to delete user-to-user links.
+
+   The first of the four functions shall not be discussed here except to
+   point out that it contains critical races that can not be resolved
+   without making assumptions about maximum message propagation delays.
+   Since within the ARPA network, bounds on message turnaround time do
+   not exist, the approach chosen must necessarily be tender. The other
+   three functions are discussed first from the viewpoint of one
+   interested in implementing a minimal NCP. Then extensions and
+   improvements are proposed that are suitable for larger machines.
+
+   Any NCP must be capable of creating a duplex link between a local
+   user process and a remote one. The current protocol accomplishes this
+   by queuing a potentially unbounded number of RFC's and waiting for
+   the user to examine the queue to determine with whom he wishes to
+   talk.  There is no guarantee that the user will ever look at the
+   queue and there is no way to limit the size of the queue. The
+   overflow error message suggested fails in the respect because it
+   admits that the RFC will only be sent again. The picture need not be
+   this bleak. The following network conversation demonstrates how
+   connections can be made without using queues or relying on user
+   process attention.
+
+   Suppose that a local user process and a remote user process wish to
+   establish a new connection. The remote process asks its NCP to listen
+   for a connection request and gives it the socket identifier for its
+   end. Optionally it can give both socket identifiers. The user process
+   at the local end asks its NCP to send a request for a duplex link
+   (RFDL). It specifies both socket identifiers of the proposed link.
+   The local NCP sends a RFDL over the control link with the following
+   format:
+
+   RFDL <my socket> <your socket> <max number buffers> <spare>
+
+
+
+
+
+Kalin                                                           [Page 2]
+
+RFC 60                  A Simplified NCP Protocol           13 July 1970
+
+
+   The third argument is normally supplied by the local NCP and
+   indicates the maximum number of buffers the NCP will consider
+   allocating to this duplex link. If buffers are in user storage the
+   count may be given by the user in a call made to the NCP.
+
+   The RFDL is received at the remote host and the remote NCP compares
+   <my socket> and <your socket> against the socket identifiers supplied
+   by unmatched listens issued to it. For listens in which just a single
+   identifier was given only <your socket> must match. If both socket
+   identifiers were given, they both must match. If a match is found an
+   acknowledgement message with the following format is sent back by the
+   NCP:
+
+   ACDL <your socket> <my socket> <number buffers> <spare>
+
+   The <number buffers> parameter is equal to the smaller of <max number
+   buffers> as specified in the RFDL and the number of message buffers
+   agreeable to the remote NCP. If no match is found the error message
+   returned is an ACDL in which <number buffers> equals zero. Note that
+   the RFDL mechanism is similar to a RFC mechanism in which the bound
+   on queue size is one and connection acceptance is done entirely by
+   the NCP.
+
+   The two varieties of a listen correspond to two modes of channel
+   operation. The single parameter variety, as typified by a LOGIN
+   process, is to be used by programs that will "talk with anyone who
+   happens to dial their number". Screening of contacts for
+   appropriateness is left to the user process. The double parameter
+   listen is used by user programs who know with whom they will
+   communicate and do not wish to be bothered by random RFDL's from
+   other sources. Given the way in which socket name space is
+   partitioned, it is impossible to get a matching RFDL from any process
+   but the one intended.
+
+   Message buffers for the connection are allocated in the remote host
+   before it sends the ACDL and in the local host at the time the ACDL
+   is received. The number of buffers at each end is equal to the
+   <number buffers> parameter in the ACDL. The state of all remote
+   buffers is "empty" and of all local buffers "filled with empty
+   crate". After buffers are allocated the local user process is
+   notified that it is able to start sending messages.
+
+   The type of interface presented by the NCP between the user process
+   and the newly created duplex link is a decision local to that host. A
+   simple but complete interface would provide two calls to be made to
+   the NCP. GETMESSAGE would return the next message from the link
+   complete with marking, text and padding. PUTMESSAGE would take a
+
+
+
+
+Kalin                                                           [Page 3]
+
+RFC 60                  A Simplified NCP Protocol           13 July 1970
+
+
+   message, marking and text only, and buffer it for transmission. The
+   obvious logical errors would be reported.
+
+   We suggest that message alignment be left to the user. On most
+   machines it is a simple but time consuming operation. If done in the
+   NCP there is no guarantee that the user will not have to readjust it
+   himself. It is usually not possible to know a priori whether the text
+   portion should be right adjusted to a word boundary, left adjusted to
+   a word boundary, aligned to the end of the last message, or
+   fragmented in some exotic way.
+
+   Within this protocol message boundaries are used to provide storage
+   allocation information. If not required by the user this information
+   can be forgotten and the user interface can be made to appear as a
+   bit stream. Though welcomed by purists, such a strategy may produce
+   complications when attempting to synchronize both ends of a link.
+
+   Links are deleted by removing empty crates from them and reclaiming
+   the buffers allocated to the crates removed. Only buffers with crates
+   in can be reclaimed; empty buffers must remain available to receive
+   messages that may arrive. When no crates are left, no buffers remain,
+   and the socket identifiers can be forgotten. When empty crates are
+   removed, a decrement size message is sent to the foreign NCP to allow
+   it to reduce its buffer allocation:
+
+   DEC <my socket> <your socket> <number of buffers dropped>
+
+   A reply is solicited from the foreign NCP to affirm the deletions or
+   to complain of an error. Possible errors include "no such link" and
+   "impossible number of buffers dropped".
+
+   The option to close a link can be given to a user process by
+   providing either of two system calls. NOMOREOUTPUT declares that no
+   more messages will be sent by the local user process. All local
+   buffers for the link that contain empty crates are reclaimed by the
+   NCP. DEC messages are sent to the foreign NCP. As crates are emptied,
+   via GETMESSAGE calls, their buffers are reclaimed too. As an
+   alternative, the call KILLMESSAGE can be implemented. This call can
+   be used in place of a PUTMESSAGE. Instead of filling an empty crate
+   with a message to be sent, KILLMESSAGE will cause the crate to be
+   reclaimed and a DEC control message sent.
+
+   In situations where the user process has died, or for some other
+   reason can not close the link, more drastic measures must be taken.
+   For these situations, the ABEND control message is defined:
+
+   ABEND <my socket> <your socket>
+
+
+
+
+Kalin                                                           [Page 4]
+
+RFC 60                  A Simplified NCP Protocol           13 July 1970
+
+
+   After sending an ABEND the issuing NCP starts to close the link. All
+   buffers containing input are destroyed. A DEC is issued for these and
+   the previously empty buffers. If messages arrive on the link, they
+   are destroyed and a DEC is issued. Any ABEND received for the link is
+   ignored.
+
+   When the remote NCP receives the ABEND, it stops sending messages
+   over the link and refuses new messages from the user process at its
+   end.  Empty buffers are reclaimed. Pending output messages are
+   destroyed and their buffers reclaimed. Input messages are fed to the
+   user process as long as it will accept them. Buffers are reclaimed as
+   input is accepted. DEC's are issued to cover all buffers reclaimed.
+   When the user process will take no more input, input messages are
+   destroyed and their buffers reclaimed. Eventually all buffers will be
+   reclaimed at both ends of the link. At such time the connection can
+   be considered closed and the socket numbers used can be reassigned
+   without ambiguity.
+
+   Under this proposed protocol the above four functions constitute all
+   that must be part of a network NCP. If buffers are allocated only
+   when free ones exist there can be no "overflow" errors nor is there
+   any need to place further constraints on message flow. For any user
+   message that arrives buffer room is guaranteed. All control messages
+   can be processed without requiring additional storage to be
+   allocated.  Attempts by a user process to issue too many listens can
+   be thwarted by local control procedures.
+
+   Inefficiencies in storage will result when the number of outstanding
+   connections gets large. One price of coding simplicity is a fifty
+   percent utilization of buffer space. On large hosts it may prove
+   advantageous to implement some of the following NCP extensions. With
+   more complicated flow control procedures, it becomes possible for an
+   NCP to allocate more buffer space than actually exists and still not
+   to get into trouble. Other extensions provide message compression,
+   improved throughput and user transparent error recovery.
+
+   Because some extensions require the cooperation of foreign hosts and
+   assume that they have implemented more than the minimal NCP it is
+   proposed that an inquiry control message be used to find out what
+   extensions the foreign host has implemented. The response to an INQ
+   will be a control message defining a host profile. If an "undefined
+   error" message is returned, the foreign host is assumed to have only
+   a minimal NCP.
+
+   A simple extension is to define a control message that will replace
+   user RFNM's. A user RFNM is a null text message sent, for example, as
+   a reply when a file is transferred via a duplex link. They are
+   inefficient since they tie up an entry in the IMP's link assignment
+
+
+
+Kalin                                                           [Page 5]
+
+RFC 60                  A Simplified NCP Protocol           13 July 1970
+
+
+   table and degrade network throughput. A more efficient solution is to
+   send a special message over the control link. In this way one short
+   message can replace several user messages.
+
+   URFNM <my socket> <your socket> <number of user RFNM's>
+
+   Because the control link is concurrent with the return side of the
+   user link, URFNM's can not be substituted for user RFNM's when there
+   are other messages to be sent on the return link. Otherwise ordering
+   will be lost and with it user transparency.
+
+   Throughput can also be increased with a mechanism to add additional
+   crates on a duplex link. This might be at user instigation or be a
+   decision of the NCP.
+
+   INC <my socket> <your socket> <number buffers desired>
+
+   The foreign host replies to an increase request by returning an INCR.
+
+   INCR <my socket> <your socket> <number buffers to be added>
+
+   If the foreign NCP is unable to meet the additional buffer demand,
+   <number buffers to be added> will be less than <number buffers
+   desired> and possibly zero. The initial state of all local buffers
+   added is "filled with empty crate" and of all foreign buffers
+   "empty".
+
+   The spare argument in the RFDL and ACDL could be used to declare the
+   maximum sized message that will actually be sent in that direction. A
+   perceptive NCP could observe this information and allocate smaller
+   buffers. A lesser NCP could ignore it and always assume maximum
+   length messages. For example, if the field were zero then only user
+   RFNM's would be sent. A smart NCP would allocate no storage at all.
+
+   If the NCP retains a copy of each user message sent over the network
+   until a reply is returned, an automatic error recovery procedure can
+   be implemented. Because the capacity of the link is always known, an
+   NCP can determine whether there are messages in transit. This is done
+   by first sending a STOP message to the foreign NCP:
+
+   STOP <my socket> <your socket>
+
+   The STOP message tells the foreign NCP to temporarily stop
+   transmitting messages over the selected link. Unlike CEASE-ON-LINK
+   there is no guarantee as to how many messages will be sent before the
+   STOP takes effect. The local NCP then sends a link inquiry message:
+
+   LINQ <my socket> <your socket>
+
+
+
+Kalin                                                           [Page 6]
+
+RFC 60                  A Simplified NCP Protocol           13 July 1970
+
+
+   The reply gives the number of crates at the foreign end of the link.
+   The LINQ message is repeated until this number plus the number of
+   local crates equals the capacity of the link. At this time no
+   messages are in transit and the two ends of the link have been
+   synchronized.  Messages can now be identified relative to the
+   synchronization point.  Thus the local NCP can send a control message
+   asking, for example, that the third to last message be retransmitted.
+   The foreign NCP is able to identify which message this is and to
+   retransmit it. Once all errors have been recovered a START control
+   message, similar in format to the STOP, is sent to the foreign NCP
+   and normal operation continues. The entire recovery procedure can be
+   transparent to both user processes.
+
+   It is expected that the larger hosts will not adhere strictly to the
+   worst case storage allocation requirements. Rather they will allocate
+   more buffers than they have and reply on statistics to keep them out
+   of trouble most of the time. Such conduct is perfectly permissible as
+   long as it is transparent to foreign hosts. The protocol allows an
+   NCP to lie about storage allocation as long as he is not caught. In
+   situations where detection appears imminent some of the following
+   control mechanisms will need to be applied. They are listed in
+   increasing order of power.
+
+   a) Do not send out any user RFNM's or other short messages. There is
+   a good chance that they will be replaced by longer messages that will
+   strain buffer capacity even more.
+
+   b) Try not to accept any new messages from the IMP. Block local
+   processes attempting to issue messages.
+
+   c) Issue DEC's to free up buffer space. Do not allocate more than one
+   buffer to RFDL's and refuse INC's.
+
+   d) Fake errors in messages waiting for local user action. Do this
+   only if the host that sent it has implemented error recovery. This
+   will free buffer space and allow you to recover later. This final
+   measure is admittedly a last resort, but it should be powerful enough
+   to control any emergency.
+
+   It is the hope of the author that the above protocol presents an
+   attractive alternative to that proposed by RFC 54 and its additions.
+   Although it appears at a late date, it should not be more than a
+   minor jolt to implementation efforts. It is simple enough to be
+   implemented quickly. If adopted, a majority of the present sites
+   could be talking intelligently with one another by the end of the
+   summer.
+
+
+
+
+
+Kalin                                                           [Page 7]
+
+RFC 60                  A Simplified NCP Protocol           13 July 1970
+
+
+References
+
+   [1] Crocker, S.D., Postel, J., Newkirk, J. and Kraley, M., "Official
+   protocol proffering", RFC 54, June 1970.
+
+Author's Address
+
+   Richard Kalin
+   MIT Lincoln Laboratory
+
+
+
+
+
+
+
+         [ This RFC was put into machine readable form for entry ]
+           [ into the online RFC archives by Ian Redfern 4/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalin                                                           [Page 8]
+