home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc47.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  5.4 KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group
  8. Request for Comments #47                                    J. Postel
  9.                                                             S. Crocker
  10.                                                             UCLA
  11.                                                             20 April 70
  12.  
  13.  
  14.                      BBN's Comments on NWG/RFC #33
  15.  
  16. BBN has given us the attached comments on NWG/RFC 33, but wouldn't
  17. publish them being relectant to embarrass us.  Embarrassment notwith-
  18. standing, we found the comments particularly useful and decided to share
  19. them with our friends.  Bill Crowther is the author.
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. RFC 47               BBN's Comments on NWG/RFC #33            April 1970
  61.  
  62.  
  63. I found two substantial errors in the Host Protocol Paper, which was
  64. otherwise an excellent paper.  Both concern a misunderstanding of the
  65. nature of the IMP as a communications device, and in particular the
  66. nature of buffering an IMP must do.  The authors consider the network as
  67. a device into which one pushes a message which travels around some,
  68. waits in buffers for substantial lengths of times, and then emerges at
  69. the destination.  In fact a better model would be that the message pops
  70. out again an instant after it is inserted.  While it is true there is a
  71. delay, it is imposed by phone line hardware for the most part.  The IMP
  72. buffering is minimal, and devoted to error control and momentary traffic
  73. surges.
  74.  
  75. Since we cannot force a Host to take a message, we have built an elab-
  76. orate RFNM mechanism to suspend new input until he does.  This mech-
  77. anism is an imperfect attempt to solve a very hard communications
  78. problem.  The desire is to regulate traffic in such a way that as the
  79. Host takes its message from the IMP the next message is arriving on the
  80. phone line, and no buffering occurs at all.
  81.  
  82. In fact we cannot achieve this, and therefore have included buffering to
  83. handle traffic surges.  These buffers are useless for their intended
  84. purpose unless they are empty.  Only empty buffers are available to soak
  85. up a traffic surge.
  86.  
  87. The two specific errors occur on pages 5 and 23.  On page 5 the authors
  88. say "Implicit in this purpose is the assumption that a user does not use
  89. multiple links to achieve a wide band."  In fact one of the primary
  90. purposes of links is to achieve a wider band.
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.                                                                 [Page 2]
  115.  
  116. RFC 47               BBN's Comments on NWG/RFC #33            April 1970
  117.  
  118.  
  119. We wish to allow as much band width as possible.  Our troubles occur not
  120. with wide band but with an imbalance of input and output.  The authors
  121. have rightly noticed that multiple links subvert the RFNM mechanism,
  122. making our job harder, but have wrongly labeled the nature of the
  123. problem.
  124.  
  125. Again on page 5 "An even more basic assumption, of course, is that the
  126. network's load comes from some users transmitting sequences of messages
  127. rather than many users transmitting single messages coincidentally."  We
  128. are in great shape against single message users when their messages are
  129. randomly related.  The statistics are all in our favor and we have
  130. special procedures for the (rare) coincedences.  Our problems come with
  131. the non-random coincidences, and we have taken special precautions
  132. against users transmitting bursts (sequences) of messages.  We assume
  133. all kinds of users, and protect ourselves accordingly.
  134.  
  135. On pages 23 and 24 there are 4 critical sentences which imply that the
  136. system design could have been improved by allowing the Host to specify
  137. which of several waiting inputs he might wish to accept.  We grant that
  138. the Host needs to buffer these messages for its users, but violently
  139. disagree that the IMP has the capability to do this buffering.
  140.  
  141. If we are operating in ideal mode, we would have at most one message for
  142. the Host at any time.  If we have more than one we urgently need the
  143. Host to accept these messages, because our ability to handle traffic
  144. surges is now below standard.  At present we allow three full
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.                                                                 [Page 3]
  171.  
  172. RFC 47               BBN's Comments on NWG/RFC #33            April 1970
  173.  
  174.  
  175. length messages in an IMP for its Host before we start backing traffic
  176. up in the network.  "Three" is not enough to help the Host in addition
  177. to keeping a reserve for the traffic surges.
  178.  
  179. But if buffering is needed why not get more memory and do it in the IMP?
  180. Because buffering is a Host function, is different in each time share
  181. system, is hard to control over a busy serial channel, might not be
  182. needed at all in some places, and is better done where the extra memory
  183. can be efficiently shared by the Host operating system.
  184.  
  185. I repeat:  the IMP's buffers must be empty or they are not serving their
  186. communication purpose.
  187.  
  188. The offending sentences are:
  189.  
  190.      Paragraph 2 sentence 3
  191.            "   3 all
  192.            "   4 sentences 1 and 2 (80ms is hardware screw adjustable)
  193.            "   4 sentence last
  194.  
  195.  
  196.           [ This RFC was put into machine readable form for entry ]
  197.       [ into the online RFC archives by Jeff & Christy McClellan 2/98]
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.                                                                 [Page 4]
  227.  
  228.