Browse Prior Art Database

BBN's Comments on NWG/RFC #33 (RFC0047)

IP.com Disclosure Number: IPCOM000003616D
Original Publication Date: 1970-Apr-20
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

W.R. Crowther: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 58% of the total 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 coinciden...