RFC47 BBN's Comments on NWG/RFC #33

0047 BBN's Comments on NWG/RFC #33. J. Postel, S. Crocker. April 1970. (Format: TXT=5343 bytes) (Updates RFC0033) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

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]

一覧

 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 

スポンサーリンク

Windows10で自動更新を停止させる方法(Windows Updateの停止)

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

上に戻る