by Darius Kazemi, Feb 16 2019
RFC-47 is by Jon Postel and Steve Crocker, although the author of the actual content is William Crowther. It's titled “BBN's Comments on NWG/RFC #33” and it does what it says on the tin. It's dated April 20th, 1970 (b-blaze it?).
The technical content
The document opens with a note from Postel and Crocker:
BBN has given us the attached comments on NWG/RFC 33, but wouldn't publish them being relectant [sic] to embarrass us. Embarrassment notwithstanding, we found the comments particularly useful and decided to share them with our friends. Bill Crowther is the author.
The remainder of the document is Crowther's commentary. He is a designer of the IMP (Interface Message Processor, the router-like thing on the network) and he's pointing out some misunderstandings in Crocker's RFC-33 paper about how the IMP works.
He first establishes that they want to make it so that traffic jams (my term) don't happen on the network, but it's really hard to do so they've had to resort to some complicated signaling about when messages are ready to be sent (the RFNM, request-for-new-message). They've also reluctantly had to add buffers to hold network packets temporarily in place, which slows down the transmission but can clear up a traffic jam.
The RFC-33 paper states that a single HOST or process shouldn't take up multiple links on the IMP, but actually the IMP is designed for that use case. If you need more links for more bandwidth, you are welcome to grab those.
The IMP has a memory buffer for its dedicated HOST but the buffer can only hold three full length messages at once. So the HOST needs to empty out the buffer as fast as possible, to the point where Crowther “violently” insists that “the IMP's buffers must be empty or they are not serving their communication purpose.”
Crowther also corrects a complaint in RFC-33 that the communication channels lock up for 80 milliseconds at a time. He notes that the 80 milliseconds is a hardware default, which can be changed (and presumably shortened) by using a screwdriver to adjust a screw in the IMP!
Because of the way RFCs are filed, sometimes the “author” of an RFC only wrote a small percentage of the text. This is why I try to say so-and-so “authored” an RFC rather than “wrote” an RFC unless it's obvious to me that the author is also the writer of the document. For example, this RFC may have Postel and Crocker listed as the author, but the bulk of the content was written by Crowther.
What I'm getting from Crowther's insistence on the IMP buffers needing to be essentially empty at all times is that they really aren't much of a buffer at all. It's almost more like a little swap space that happens to look and act like a buffer but has other primary uses. I imagine the mechanic's repair pit at a car race: while it is a flat asphalt area where a small number of cars can park, it is not a parking lot. Cars are supposed to go in and out of there as quickly as possible and get back into the race.
On the note that opens the RFC: I spoke with Steve Crocker a little bit about this, and he related that the BBN folks were essentially a lot more formal in what they published and tended to not just throw out ideas to see what stuck (at least externally; internally there was lively exchange of ideas from what I've read of their own accounts). Crowther sent him the notes privately because he didn't think they were appropriate for a public channel but really they were in the exact spirit of the RFC project. Recall the ground rules from RFC-3:
The content of a NWG note may be any thought, suggestion, etc. related to the HOST software or other aspect of the network. Notes are encouraged to be timely rather than polished. Philosophical positions without examples or other specifics, specific suggestions or implementation techniques without introductory or background explication, and explicit questions without any attempted answers are all acceptable. The minimum length for a NWG note is one sentence.
I found this BBN quarterly technical report for January 1st 1970 through March 31st 1970.
On page 7 of the report we see exactly what Crowther was relating to the Network Working Group in his notes:
The network can be described as a taut communication system in the sense that each message entering the net proceeds directly to its destination. We observed that messages do not wander about the net, even at high traffic loads. The net easily handles sequences of single-character messages typed at the IMP teletype.
Interestingly, there is a further note on page 8 that states that buffers get really full during
the use of multiple links by a Host (for fanning messages), which causes a large part (or all) of the source IMP's store and forward buffers to be filled.
This seems to somewhat contradict Crowther's insistence that the IMP is absolutely meant to support multiple links per host! And this is from a report written right around the same time this RFC was.