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]
-
- 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]
-