RFC-33

by Darius Kazemi, Feb 2 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.

New concepts for the network

RFC-33 is a big one. It's authored by Steve Crocker, Steve Carr, and Vint Cerf, although Crocker is the only author listed in the normative RFC listings. It's dated Feb 12, 1970 and is a preview of a paper that will be presented at the Spring Joint Computer Conference in May of that year. This RFC is yet another update to Déloche's RFC-11. It's titled “New HOST-HOST Protocol”.

The technical content

The introduction describes ARPANET for the uninitiated. I lays out that ARPANET is the first major computer networking attempt to connect computers using different hardware and different operating systems. I think this sentence is the shortest and best description of the network I've seen in an RFC so far:

The network is seen as a set of data entry and exit points into which individual computers insert messages destined for another (or the same) computer, and from which such messages emerge.

We get firm definitions of HOST, IMP, message, and link that are meant for outsiders. Since we as modern readers are outsiders, this is super helpful to us. We've already established firmly via these RFCs that a HOST is a computer connected to the network, and the IMP is a kind of early router-type device that does the packet switching.

A message is defined in this paper as

a bit stream less than 8096 bits long which is given to an IMP by a HOST for transmission to another HOST. The first 32 bits of the message are the leader.

The “leader” is what we'd call a “header” today and consists of

A link is, basically, a single data communication channel that can be used by an IMP or a HOST. There are 256 of them on the network.

The paper defines a design philosophy which is pithy enough that I won't quote it here (it's the section “Design Concepts” beginning at the bottom of page 4 of RFC-33) but to sum up:

The main purpose of RFC-33 is to introduce concepts that are a result of those design considerations: “connections, a Network Control Program, a control link, control commands, sockets, and virtual nets.”

A connection is a formal way of piping the output of a process on one HOST to the input of a process on another HOST. A “process” is essentially a running program. Connections only go one way (“the output of my program is the input of your program”) so for a back and forth conversation, two connections are needed.

The Network Control Program (NCP) is the program that acts as the broker between a HOST program and the network, and is used to start and stop connections.

A control link is a reserved link between two HOSTs where NCPs can handshake with one another before they begin setting up full connections on other links.

Since any HOST could be running its own operating system, and different operating systems have different internal identifiers for processes, we need to translate these processes into a common name space. This is called a socket and it says “user A on computer B would like to speak on this connection about what we are calling process Z”.

(There is a value in the socket specification called the “AEN” which stands for... wait for it... “another eight-bit number”.)

A virtual net is... well, I'm not really clear on that even after reading this document. But it seems to be a kind of fingerprint across multiple HOST systems where you can log in to, say four different computers, and have data piping back and forth between all four of them for different purposes. So like, calculate geometry on computer A but then pipe the calculations over to computer B to display it on a monitor. That kind of thing.

Further down, the term port is defined as an input/output path related to a specific process. One process can have many ports.

In a section called “Higher Level Protocol”, something called Network Interface Language (NIL) is proposed. Its purpose seems very similar to Decode-Encode Language (DEL), which I write about at length in my post about RFC-5, in that both languages were proposed to make highly interactive, rich networked applications possible. Both were not implemented.

Analysis

I'm breaking up this section for readability because there's a lot to say.

Missing figure, found

First of all, page 11 of the official normative RFC document references figure 5, which is missing. I found figure 5 when looking through some original documents at the Computer History Museum. Here is a photo I took:

A TELNET session sequence in nine steps

You log in to the local computer, you start TELNET, you set your escape character, you instruct TELNET which computer to connect to, you enter your username on the remote computer, you start up a program on the remote computer, and you move resultant files from that computer to your local one.

TELNET gets a shout out

In a section outlining user-facing software, the document recommends that early ARPANET users use TELNET (as first defined in RFC-15) as a way to get an interactive login on remote systems, but notes that it's “expected that more sophisticated subsystems will be developed in time”.

The document credits TELNET for being the main reason why the network is currently useful at all.

Deep understanding of user experience

I was struck by this statement:

a user evaluates an interactive system by comparing the speed of the system's responses with his own expectations. Sometimes a user feels that he has made only a minor request, so the response should be immediate; at other times he feels he has made a substantial request, and is therefore willing to wait for the response. Some interactive subsystems are especially pleasant to use because a great deal of work has gone into tailoring the responses to the user's expectations.

This demonstrates deep understanding of interactive systems design by twenty-something grad students in 1970 that I wish more developers possessed today.

The human factor

The introduction contains the following note:

We have found that, in the process of connecting machines and operating systems together, a great deal of rapport has been established between personnel at the various network node sites. The resulting mixture of ideas, discussions, disagreements, and resolutions has been highly refreshing and beneficial to all involved, and we regard the human interaction as a valuable by-product of the main effect.

The ARPANET project as a whole is really interesting to me because of this necessary cross-collaboration between military, private, and academic institutions. The RFC concept in general is of course a huge piece of this collaboration and examining how this kind of collaboration happens is the real reason I'm doing this project.

Further reading

The request-for-new-message is kind of an early ACK message, which is worth reading about.

The “virtual net” concept is credited to William Crowther, who five years from this time will go on to write Colossal Cave AKA Adventure, the first ever text adventure / interactive fiction game. Crowther worked on ARPANET while at BB&N. It's amazing to me, in a good way, that “helping literally invent the internet” is a minor diversion when discussing this man's legacy.

There's an excellent 2015 paper by Bradley Fidler and Amelia Acker (available free online) that goes into the history of sockets on the ARPANET and proposes that sockets are both a kind of infrastructure and metadata.

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.