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]
-
- 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]
-
- 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]
-
- 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]
-