1 files changed, 112 insertions, 0 deletions
diff --git a/doc/rfc/rfc68.txt b/doc/rfc/rfc68.txt
new file mode 100644
index 0000000..8c0cbfa
--- /dev/null
+++ b/doc/rfc/rfc68.txt
@@ -0,0 +1,112 @@
+
+
+
+
+
+
+Network Working Group                                           M. Elie
+Request for Comments #68                                        31 August 70
+                                                                UCLA
+
+             Comments on memory allocation control commands
+                     CEASE, ALL, GVB, RET) and RFNM
+
+The protocol provides a scheme for buffer allocation.  This scheme is
+rather complicated because it necessitates two parallel mechanisms.
+It is not obvious that both are necessary.  In fact it is suggested
+that this scheme could be probably replaced by a slightly different
+conception of the Request for Next Message (RFNM).  Now the RFNM is
+sent back from the receiving imp after the message has been
+reconstituted and the first packet transmitted to the host.  Nothing
+insures that the whole message has been accepted and correctly
+received by the host; also the design of the host imp interface
+permits the host to stop accepting data from the imp during any length
+of time; as the link has been already unblocked by sending back the
+RFNM another message may be transmitted by the sending foreign host
+which will congest the imp's memory.  On the other hand it is prob-
+able that usually the host is able to accept data from the imp at a
+higher rate than it is transmitted on the network, e.g. 200k bits/sec;
+thus the time to transmit a full message from the imp to the host
+would be approximately 1/20th of a second which is 10 times less than
+the average delay of transmission of a message over the network.  This
+indicates that to send a RFNM after the reception of a full message by
+the host would not increase significantly the response time on the
+network.
+
+In this case there is no reason why the RFNM could not be initiated by
+the receiving host as an acknowledgment of the correct reception of
+the message (ACK), and take the form of either a host imp or a control
+command message.  This RFNM could have the two forms
+
+         ACK  (CONTINUE)
+or       ACK  (CEASE)
+
+This would permit to add to the message some error detection
+redundancy, such as check sum bits as proposed in [DELO 69].  In the
+present design nothing insures that one or several bits of the text
+has not been altered, e.g., by an interference or a deficiency of one
+of the host imp interfaces.  This could have important consequences,
+e.g. if the text is used to update a centralized data base.  Also, if
+the user has a way of detecting the error, but none of correcting it,
+it has no way of asking for the retransmission of the message, which
+has probably been discarded at the sending end upon reception of the
+RFNM.  In fact it seems not up to the user to have to detect errors in
+
+
+
+
+                                                                [Page 1]
+
+Network Working Group                                           M. Elie
+Request for Comments #68                                        31 August 70
+                                                                UCLA
+
+its text but rather up to the NCP: the user process must as much as
+possible act as if it was talking to some other local process.  So a
+third kind of RFNM sent by the NCP could be:
+
+            NAK(REPEAT)
+
+Repetition would also be initiated in case of no reply.
+
+Thus we see that it seems worthwhile to make these slight
+modifications which would permit to use between the sending host and
+the receiving host a very simple point-to-point transmission procedure
+which would insure control of the data transmitted from end-to-end.
+
+It could also replace the memory allocation mechanism: ACK (CONTINUE)
+would only be sent if space was available for a new message on this
+connection and/or ACK (CEASE) would be sent if no more space was
+available; it corresponds to the WABT of classic transmission
+procedures [USAS69]; transmission could be resumed by an ACK
+(CONTINUE) or a RESUME from the receiving end.  The user process is
+not mixed at all with this memory allocation which is a function of
+the system (or NCP): it only sees a varying global transmission speed
+of its data on a connection.  The imp programs take care of the
+routing of the data according to the distributed nature of the
+network, and neither the user nor the system (or NCP) is concerned
+with it.  Other improvements to the protocol may be found after
+experiencing it.
+
+Finally note that this solution does not immobilize the imp memory any
+longer than the actual solution, because it is not the imp which has
+to repeat a message, but the sending host.
+
+
+______________________________________________
+
+DELO 69 DELOCHE G.  Implementation of the Host-Host Software
+        Procedures in GORDO Network Working Group RFC #11 Aug 1969
+
+USAS 69 Proposed USA standard data communication control procedures
+        for USASCII CACM Vol. 12 NB 3 March 1969 PB 166-178
+
+
+       [ This RFC was put into machine readable form for entry ]
+        [ into the online RFC archives by Kai Henningsen 6/97 ]
+
+
+
+
+                                                                [Page 2]
+