RFC68 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB,RET, and RFNM

0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB,RET, and RFNM. M. Elie. August 1970. (Format: TXT=5041 bytes) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

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]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

キガシラペンギン

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る