BBN's Comments on NWG/RFC #33
BBN's engineer explains why an IMP's buffers must stay empty, and why hosts should do the buffering.
Postel, J. and S. Crocker, "BBN's Comments on NWG/RFC #33", RFC 47, DOI 10.17487/RFC0047, April 1970, <https://www.rfc-editor.org/info/rfc47>.
@misc{rfc47,
series = {Request for Comments},
number = 47,
howpublished = {RFC 47},
publisher = {RFC Editor},
doi = {10.17487/RFC0047},
url = {https://www.rfc-editor.org/info/rfc47},
author = {J. Postel and S. Crocker},
title = {{BBN's Comments on NWG/RFC #33}},
pagetotal = 4,
year = 1970,
month = apr,
} RFC text
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.
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.
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
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]
AI ELI5
On this page
§1Why This Note Exists
Jon Postel and Steve Crocker of UCLA introduce the note. BBN had sent comments on RFC 33 but did not want to publish them for fear of embarrassing the authors. UCLA found them useful and shared them anyway. The author is Bill Crowther.
He calls the host protocol paper otherwise excellent, but finds two substantial errors, both rooted in a misunderstanding of the IMP as a communications device.
A helpful letter from the box builders was shared with everybody, because it was too useful to keep private.
§2The IMP Is Not a Waiting Room
The criticised paper treated the network as something you push a message into, which then waits in buffers for a long time. The author says a better model is that the message pops out an instant after it is inserted. The delay that exists comes mostly from phone line hardware.
IMP buffering is minimal and is devoted to error control and momentary traffic surges. Because the IMP cannot force a Host to take a message, BBN built an elaborate RFNM mechanism that suspends new input until the Host does. The aim is that as the Host takes one message the next arrives on the phone line, with no buffering at all.
That cannot be fully achieved, so buffers exist for surges. They only help when empty: the IMP's buffers must be empty or they are not serving their communication purpose.
Think of a pipe, not a bucket. The box passes messages through right away, and its little catch-basin is only for sudden splashes, so it has to be empty.
§3The Two Errors
The first error is on page 5 of the paper, which assumed a user does not use multiple links to get a wide band. The author replies that achieving wider band is a primary purpose of links. BBN's trouble comes from an imbalance of input and output, not wide band. The paper did notice that multiple links subvert the RFNM mechanism, but it mislabeled the problem.
Page 5 also assumed the network's load comes from users sending sequences of messages rather than many users sending single messages. The author says random single messages are easy because the statistics favour BBN. The problems come from non-random coincidences, so BBN takes special precautions against bursts.
The second error is on pages 23 and 24, where four sentences imply the design could improve if the Host could choose which of several waiting inputs to accept. The author violently disagrees that the IMP can do that buffering.
Two ideas in the paper were wrong. Sending lots of messages at once is fine; what hurts is when too much arrives and too little leaves.
§4Why Hosts Should Buffer
In ideal operation there would be at most one message waiting for the Host. With more than one, the IMP urgently needs the Host to accept them, because its ability to handle surges falls below standard. At the time, an IMP allowed three full length messages for its Host before backing traffic up in the network, which the author says is not enough both to help the Host and to keep a reserve.
To the question of why not simply add memory to the IMP, the answer is that buffering is a Host function, differs in each time share system, is hard to control over a busy serial channel, might not be needed in some places, and is better done where the memory can be shared by the Host operating system.
The note closes by listing the disputed sentences by paragraph and sentence number, noting that one sentence mentions 80ms being hardware screw adjustable.
Keeping a line of waiting messages is the host computer's job, because it knows its own needs and has memory it can share.