Browse Prior Art Database

Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM (RFC0068)

IP.com Disclosure Number: IPCOM000003729D
Original Publication Date: 1970-Aug-31
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Elie: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 56% of the total text.

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

Network Working ...