1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc47.txt b/doc/rfc/rfc47.txt
new file mode 100644
index 0000000..9079d30
--- /dev/null
+++ b/doc/rfc/rfc47.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group
+Request for Comments #47                                    J. Postel
+                                                            S. Crocker
+                                                            UCLA
+                                                            20 April 70
+
+
+                     BBN's Comments on NWG/RFC #33
+
+BBN has given us the attached comments on NWG/RFC 33, but wouldn't
+publish them being relectant to embarrass us.  Embarrassment notwith-
+standing, we found the comments particularly useful and decided to share
+them with our friends.  Bill Crowther is the author.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+RFC 47               BBN's Comments on NWG/RFC #33            April 1970
+
+
+I found two substantial errors in the Host Protocol Paper, which was
+otherwise an excellent paper.  Both concern a misunderstanding of the
+nature of the IMP as a communications device, and in particular the
+nature of buffering an IMP must do.  The authors consider the network as
+a device into which one pushes a message which travels around some,
+waits in buffers for substantial lengths of times, and then emerges at
+the destination.  In fact a better model would be that the message pops
+out again an instant after it is inserted.  While it is true there is a
+delay, it is imposed by phone line hardware for the most part.  The IMP
+buffering is minimal, and devoted to error control and momentary traffic
+surges.
+
+Since we cannot force a Host to take a message, we have built an elab-
+orate RFNM mechanism to suspend new input until he does.  This mech-
+anism is an imperfect attempt to solve a very hard communications
+problem.  The desire is to regulate traffic in such a way that as the
+Host takes its message from the IMP the next message is arriving on the
+phone line, and no buffering occurs at all.
+
+In fact we cannot achieve this, and therefore have included buffering to
+handle traffic surges.  These buffers are useless for their intended
+purpose unless they are empty.  Only empty buffers are available to soak
+up a traffic surge.
+
+The two specific errors occur on pages 5 and 23.  On page 5 the authors
+say "Implicit in this purpose is the assumption that a user does not use
+multiple links to achieve a wide band."  In fact one of the primary
+purposes of links is to achieve a wider band.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+
+RFC 47               BBN's Comments on NWG/RFC #33            April 1970
+
+
+We wish to allow as much band width as possible.  Our troubles occur not
+with wide band but with an imbalance of input and output.  The authors
+have rightly noticed that multiple links subvert the RFNM mechanism,
+making our job harder, but have wrongly labeled the nature of the
+problem.
+
+Again on page 5 "An even more basic assumption, of course, is that the
+network's load comes from some users transmitting sequences of messages
+rather than many users transmitting single messages coincidentally."  We
+are in great shape against single message users when their messages are
+randomly related.  The statistics are all in our favor and we have
+special procedures for the (rare) coincedences.  Our problems come with
+the non-random coincidences, and we have taken special precautions
+against users transmitting bursts (sequences) of messages.  We assume
+all kinds of users, and protect ourselves accordingly.
+
+On pages 23 and 24 there are 4 critical sentences which imply that the
+system design could have been improved by allowing the Host to specify
+which of several waiting inputs he might wish to accept.  We grant that
+the Host needs to buffer these messages for its users, but violently
+disagree that the IMP has the capability to do this buffering.
+
+If we are operating in ideal mode, we would have at most one message for
+the Host at any time.  If we have more than one we urgently need the
+Host to accept these messages, because our ability to handle traffic
+surges is now below standard.  At present we allow three full
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 3]
+
+RFC 47               BBN's Comments on NWG/RFC #33            April 1970
+
+
+length messages in an IMP for its Host before we start backing traffic
+up in the network.  "Three" is not enough to help the Host in addition
+to keeping a reserve for the traffic surges.
+
+But if buffering is needed why not get more memory and do it in the IMP?
+Because buffering is a Host function, is different in each time share
+system, is hard to control over a busy serial channel, might not be
+needed at all in some places, and is better done where the extra memory
+can be efficiently shared by the Host operating system.
+
+I repeat:  the IMP's buffers must be empty or they are not serving their
+communication purpose.
+
+The offending sentences are:
+
+     Paragraph 2 sentence 3
+           "   3 all
+           "   4 sentences 1 and 2 (80ms is hardware screw adjustable)
+           "   4 sentence last
+
+
+          [ This RFC was put into machine readable form for entry ]
+      [ into the online RFC archives by Jeff & Christy McClellan 2/98]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 4]
+