365 RFCs

by Darius Kazemi, Feb 17 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Plateaus

RFC-48 is by Jon Postel and Steve Crocker. It's dated April 21st, 1970 and poetically titled “A Possible Protocol Plateau”. This RFC is their attempt to synthesize the suggestions and comments from everyone in the Network Working Group over the last month or so. They have about ten days to settle the matter before they present their paper at the Spring Joint Computer Conference in Atlantic City.

The technical content

The paper tries to enumerate the various concerns brought up by the group.

The first concern is around padding of messages. The basic problem is: if my HOST's hardware is only capable of sending whole “word” messages (so perhaps messages that are multiples of 8 bits in length), what do you do when you want to send a message that is like 12 bits in length (which is halfway between 8 and 16 bits)? The IMP was built assuming that messages would be sent in these kind of round numbers, but that's not actually the case. It would be an expensive and inconvenient hardware fix to change how the IMP works so various software-level solutions are discussed. Postel and Crocker have no strong preferences as to which of these are used.

The next concern is reconnection (which is not “my modem hung up and I have to reconnect” but rather the process of connecting processes and peripherals to each other and then again and again). Specifically, Crocker's “dynamic reconnection” proposal in RFC-33 has been pushed back on very hard by multiple people at multiple institutions over the last month. The authors acknowledge this:

A very large population of networkers has beat upon us for including dynamic reconnection in the protocol. We felt it might be of interest to relate how it came to be included.

The authors then compare the standard literature on the problem of reconnection to the actual implementations, strongly implying that the theoretical literature doesn't help much in the real world.

There is a three-page defense of the idea of dynamic reconnection, along with a slight modification to how it was originally proposed. The section concludes: “We are agreed that reconnection should not be required in the initial protocol, and we will offer it later as an optional and experimental tool.”

(As a reader I was not expecting this capitulation at the end of a thorough and impassioned and long defense!)

The next issue is whether links and connections should be tightly coupled, basically whether a connection (which is a software construct) should be tied to a specific link (which is a hybrid software/hardware construct). The original proposal had them tied to one another; two working group members suggested decoupling them. The author say they can't picture a solid reason why decoupling would be useful so they suggest that the link and the connection remain coupled in the interest of simplicity.

Another issue is the error messages proposed in RFC-40. The authors agree that error messages are good and they should have them. However, they suggest some tweaks on the basis that certain things tagged as “errors” in the proposal aren't “true errors” and so should probably send a different kind of message.

They also recommend that error messages be logged locally on the server and only optionally sent back to the user. Their worry is error messages will just clog up a system that is by definition already having problems. Also they are confident that the IMPs will generate very few errors, with most errors coming from HOSTs or NCPs (the software interface between the HOST and the IMP).

The next issue is figuring out ways to debug when something goes wrong on the network. They suggest reserving link 255 (the highest link) for these messages and sending an ECO (“echo”) request to a HOST. The idea is you send a brief message, and if the HOST is online, it sends a copy of the message back (hence “echo”).

To address issues of experimentation, they suggest that links 2 through 31 be used for regular network communication, with links 32 through 255 reserved for, basically, messing around and testing new network protocol stuff. They reject the idea of typed messages proposed in RFC-42

The next part is in relation to questions about sockets and ports on HOSTs brought up by working group members. The authors remind the other implementers that they fully intend for HOSTs to be idiosyncratic and any implication that the internal systems of a HOST should work one way or another is just a convenient illustration and not meant to be taken as a requirement.

The next part is a little mind-blowing. They designed the network assuming that important signals would all be, you know, encoded as data. And therefore able to be assigned an ASCII character. Turns out that some hardware (model 37 TTY's and the IBM 2741) communicates the concept of a hardware interrupt (“drop what you are doing and pay attention to the next message”) as a “long space” AKA just 250 milliseconds of silence. I like to save my editorializing for the Analysis section of these blog posts but: WHAT??? This is so weird to me. It's like your mom saying “if I don't hear from you for 24 hours I'm going to assume you've been murdered.” Moms shouldn't do this, and neither should computers.

Anyway, this necessitates a special interrupt command, which they then propose.

They reject a broadcasting feature proposed by RAND because they fail to see the use of it. (Understandably, because RAND did not provide a use case in RFC-39.) And they reject what they see as another over-complicating feature from Meyer in RFC-46.

And finally they admit that “AEN” (Another Eight-bit Number) is probably a really bad name. They are open to replacements.

The remainder of the paper lays out a suggested implementation on the HOST side of the NCP and other entities but the authors note

that this material is offered only to provide clues as to what the implementation difficulties might be and not to impose any particular discipline.

Analysis

The authors are very clear (and have been since day one) that HOSTs are essentially allowed to do whatever they want as long as they play nice with the IMPs and the rest of the network. This is one key to what makes ARPANET different from networks that predate it, which were communications between nearly identical computers.

It shows what an experimental network ARPANET was that they suggest the group dedicate 87.5% of the network capacity to experimentation and only the remainder to basic communication!

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.