home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0068.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  4.9 KB  |  113 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           M. Elie
  8. Request for Comments #68                                        31 August 70
  9.                                                                 UCLA
  10.  
  11.              Comments on memory allocation control commands
  12.                      CEASE, ALL, GVB, RET) and RFNM
  13.  
  14. The protocol provides a scheme for buffer allocation.  This scheme is
  15. rather complicated because it necessitates two parallel mechanisms.
  16. It is not obvious that both are necessary.  In fact it is suggested
  17. that this scheme could be probably replaced by a slightly different
  18. conception of the Request for Next Message (RFNM).  Now the RFNM is
  19. sent back from the receiving imp after the message has been
  20. reconstituted and the first packet transmitted to the host.  Nothing
  21. insures that the whole message has been accepted and correctly
  22. received by the host; also the design of the host imp interface
  23. permits the host to stop accepting data from the imp during any length
  24. of time; as the link has been already unblocked by sending back the
  25. RFNM another message may be transmitted by the sending foreign host
  26. which will congest the imp's memory.  On the other hand it is prob-
  27. able that usually the host is able to accept data from the imp at a
  28. higher rate than it is transmitted on the network, e.g. 200k bits/sec;
  29. thus the time to transmit a full message from the imp to the host
  30. would be approximately 1/20th of a second which is 10 times less than
  31. the average delay of transmission of a message over the network.  This
  32. indicates that to send a RFNM after the reception of a full message by
  33. the host would not increase significantly the response time on the
  34. network.
  35.  
  36. In this case there is no reason why the RFNM could not be initiated by
  37. the receiving host as an acknowledgment of the correct reception of
  38. the message (ACK), and take the form of either a host imp or a control
  39. command message.  This RFNM could have the two forms
  40.  
  41.          ACK  (CONTINUE)
  42. or       ACK  (CEASE)
  43.  
  44. This would permit to add to the message some error detection
  45. redundancy, such as check sum bits as proposed in [DELO 69].  In the
  46. present design nothing insures that one or several bits of the text
  47. has not been altered, e.g., by an interference or a deficiency of one
  48. of the host imp interfaces.  This could have important consequences,
  49. e.g. if the text is used to update a centralized data base.  Also, if
  50. the user has a way of detecting the error, but none of correcting it,
  51. it has no way of asking for the retransmission of the message, which
  52. has probably been discarded at the sending end upon reception of the
  53. RFNM.  In fact it seems not up to the user to have to detect errors in
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. Network Working Group                                           M. Elie
  61. Request for Comments #68                                        31 August 70
  62.                                                                 UCLA
  63.  
  64. its text but rather up to the NCP: the user process must as much as
  65. possible act as if it was talking to some other local process.  So a
  66. third kind of RFNM sent by the NCP could be:
  67.  
  68.             NAK(REPEAT)
  69.  
  70. Repetition would also be initiated in case of no reply.
  71.  
  72. Thus we see that it seems worthwhile to make these slight
  73. modifications which would permit to use between the sending host and
  74. the receiving host a very simple point-to-point transmission procedure
  75. which would insure control of the data transmitted from end-to-end.
  76.  
  77. It could also replace the memory allocation mechanism: ACK (CONTINUE)
  78. would only be sent if space was available for a new message on this
  79. connection and/or ACK (CEASE) would be sent if no more space was
  80. available; it corresponds to the WABT of classic transmission
  81. procedures [USAS69]; transmission could be resumed by an ACK
  82. (CONTINUE) or a RESUME from the receiving end.  The user process is
  83. not mixed at all with this memory allocation which is a function of
  84. the system (or NCP): it only sees a varying global transmission speed
  85. of its data on a connection.  The imp programs take care of the
  86. routing of the data according to the distributed nature of the
  87. network, and neither the user nor the system (or NCP) is concerned
  88. with it.  Other improvements to the protocol may be found after
  89. experiencing it.
  90.  
  91. Finally note that this solution does not immobilize the imp memory any
  92. longer than the actual solution, because it is not the imp which has
  93. to repeat a message, but the sending host.
  94.  
  95.  
  96. ______________________________________________
  97.  
  98. DELO 69 DELOCHE G.  Implementation of the Host-Host Software
  99.         Procedures in GORDO Network Working Group RFC #11 Aug 1969
  100.  
  101. USAS 69 Proposed USA standard data communication control procedures
  102.         for USASCII CACM Vol. 12 NB 3 March 1969 PB 166-178
  103.  
  104.  
  105.        [ This RFC was put into machine readable form for entry ]
  106.         [ into the online RFC archives by Kai Henningsen 6/97 ]
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.