Movatterモバイル変換

Network Working Group                                           M. ElieRequest for Comments #68                                        31 August 70                                                                UCLA             Comments on memory allocation control commands                     CEASE, ALL, GVB, RET) and RFNMThe protocol provides a scheme for buffer allocation.  This scheme israther complicated because it necessitates two parallel mechanisms.It is not obvious that both are necessary.  In fact it is suggestedthat this scheme could be probably replaced by a slightly differentconception of the Request for Next Message (RFNM).  Now the RFNM issent back from the receiving imp after the message has beenreconstituted and the first packet transmitted to the host.  Nothinginsures that the whole message has been accepted and correctlyreceived by the host; also the design of the host imp interfacepermits the host to stop accepting data from the imp during any lengthof time; as the link has been already unblocked by sending back theRFNM another message may be transmitted by the sending foreign hostwhich 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 ahigher 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 hostwould be approximately 1/20th of a second which is 10 times less thanthe average delay of transmission of a message over the network.  Thisindicates that to send a RFNM after the reception of a full message bythe host would not increase significantly the response time on thenetwork.In this case there is no reason why the RFNM could not be initiated bythe receiving host as an acknowledgment of the correct reception ofthe message (ACK), and take the form of either a host imp or a controlcommand message.  This RFNM could have the two forms         ACK  (CONTINUE)or       ACK  (CEASE)This would permit to add to the message some error detectionredundancy, such as check sum bits as proposed in [DELO 69].  In thepresent design nothing insures that one or several bits of the texthas not been altered, e.g., by an interference or a deficiency of oneof the host imp interfaces.  This could have important consequences,e.g. if the text is used to update a centralized data base.  Also, ifthe 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, whichhas probably been discarded at the sending end upon reception of theRFNM.  In fact it seems not up to the user to have to detect errors in                                                                [Page 1]

Network Working Group                                           M. ElieRequest for Comments #68                                        31 August 70                                                                UCLAits text but rather up to the NCP: the user process must as much aspossible act as if it was talking to some other local process.  So athird 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 slightmodifications which would permit to use between the sending host andthe receiving host a very simple point-to-point transmission procedurewhich 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 thisconnection and/or ACK (CEASE) would be sent if no more space wasavailable; it corresponds to the WABT of classic transmissionprocedures [USAS69]; transmission could be resumed by an ACK(CONTINUE) or a RESUME from the receiving end.  The user process isnot mixed at all with this memory allocation which is a function ofthe system (or NCP): it only sees a varying global transmission speedof its data on a connection.  The imp programs take care of therouting of the data according to the distributed nature of thenetwork, and neither the user nor the system (or NCP) is concernedwith it.  Other improvements to the protocol may be found afterexperiencing it.Finally note that this solution does not immobilize the imp memory anylonger than the actual solution, because it is not the imp which hasto 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 1969USAS 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]