365 RFCs

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

A new kind of Host

RFC-76 is called “Connection-By-Name: User-Oriented Protocol”, dated October 28th, 1970. It's authored by W. Jack Bouknight, James Madden, and Gary Grossman of the University of Illinois.

The technical content

The plan is for the University to connect to the ARPANET beginning January 1st, 1971, a little more than two months' time from the publication of this document.

This RFC describes a new kind of node on the ARPANET: a computer whose sole job is to broker with the ARPANET. This would be an extension to the current Host-Host protocol.

The basic idea is that all the actual computing is designed to happen on other computers on the internal network at the university. Their reasoning is that typical computer users at the school understand computers on the file and device level, but sockets and links and protocol stuff is totally foreign to them. They want to abstract away all of this and not even have the NCP be exposed to the user at all.

The paper talks about these protocol extensions, and also specs out what the interface computer might look like (a relatively low-power PDP-11) and how users would interact with it.

Analysis

This overall idea is really interesting: why take up resources on a computer with an NCP program constantly running when you can just offload that part to a computer on the network? It makes total sense to me.

Further reading

W. Jack Bouknight wrote a seminal paper, An algorithm for producing half-tone computer graphics presentations with shadows and movable light sources, which was published in the 1970 SJCC conference proceedings. I have mentioned those here before because they were where the first Host-Host protocol papers were published. In fact, Bouknight's paper is the very first one in the massive 700+ page conference proceedings. It's a really fun graphics paper, or at least it is if you are the kind of person who reads this blog.

I couldn't find much on Gary Grossman but he seems to have been involved with a lot of early computer music, helping Herbert Brün with a PDP-11/45 based music project in 1976.

I could find even less on James Madden, though he would co-author two more RFCs and remained on the distribution list for the Network Working Group until at least 1971.

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.

by Darius Kazemi, March 16 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.

See you in Astroworld

RFC-75 is by Steve Crocker of UCLA, dated October 14th, 1970 and titled “Network Meeting”.

The technical content

This RFC informs all recipients that there will be a Network Meeting at the Fall Joint Computer Conference in Houston at the Astroworld Hotel at 8pm on Monday November 16th, 1970.

The purpose is to discuss “practical use” of the network, including:

• accounting mechanisms

• documentation distribution

• person-to-person message sending and message storing

• access to systems by foreign users

Further reading

The Astroworld Hotel was, in 1970, arguably the most luxury hotel in the world, and according to this history of the hotel featured “the most expensive suite in the world”, part of its variety of Celestial Suites offered to rich visitors. The meeting was not held in one of these suites, but I like to imagine that it was (check out the PT Barnum Suite!!!). There's another incredible gallery here.

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.

by Darius Kazemi, March 15 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.

A working NCP

RFC-74 is titled “SPECIFICATIONS FOR NETWORK USE OF THE UCSB ON-LINE SYSTEM”, by Jim White of UCSB. It's dated October 16th, 1970. There is a PDF scan of the original documents available as well.

The technical content

This is a document that teaches programmers at other ARPANET sites how to communicate with the OLS (on-line system) at UCSB. This is the Culler-Fried On-Line System developed by Glen Culler of UCSB and Burton Fried of UCLA. It was an interactive graphical mathematics computer from the mid 1960s with features similar to a graphing calculator today. But it supported multiple users, and Jim White wrote the NCP and its associated “Interface” for it based on Dave Walden's RFC-62. This document describes how to use the Interface.

Remote users who want to log in and use the OLS functionality will need to connect to Site 3, socket x'101', and log in as user number 196, ID number 57372, and provide a name; the suggestion is to use your site ID like UCLA, MIT, BBN, RAND, etc.

Logging in is an interesting process. The NCP Interface isn't normally resident in core memory, so the way a login works is:

• you connect to socket x'101' and request to log in
• if accepted, you're in luck, the program was already in core memory by chance and you're good to go
• if rejected, you need to try and connect again, because the Host is programmed to reject any initial login attempt if the Interface isn't in core memory, and then load the NCP Interface into core memory, ready to receive a connection for real this time
• if there's a second rejection then there's something wrong with the OLS!

Then the NCP sends back 8 bits of zeroes (for “message type zero”) and then an ID of a new socket for the remote user to connect to (since x'101' is reserved for login).

Once login is complete, a connection has been established. All data is a continuous stream of single-byte key codes and operates exactly like using the OLS in person. This immediately and instantly solves all the message boundary problems that we've heard about at length for last 20 or so RFCs.

The exception to this is the first two bytes sent. One is yet another “message type zero” byte, followed by a byte with some flags set to filter out particular kinds of messages. For example, a user could request to filter our all “curvilinear output”, which is an array of vectors (X/Y coordinates) forming shapes that would normally be displayed on a Tektronix 564 model 5” storage oscilloscope. If the user didn't have that scope at hand it might make sense to suppress those graphics. The arrays are specified in section B of the RFC. In section C there is also described a kind of special character that denotes relative movement, kind of like a pen moving across a surface, essentially identical to a modern drawing function like moveTo in HTML canvas.

Analysis

Notice there is no password to log in.

I'm not at all surprised that this functional NCP (which according to Jim White's LinkedIn profile was “the Arpanet’s first operational Network Control Program”) was based on Walden's excellent and simple RFC-62.

Further reading

This interview with Glen Culler, which also has the text of a speech his son gave on behalf of his father earning the President's Science Medal, provides a lot of really interesting context about the innovations of the Culler-Fried On-Line System.

I also happened to stumble on this lovely short personal essay by Nancy Oster in October 1995 in memory of Glen Culler.

Those in or around Portland, Oregon should visit the VintageTEK museum, where you can receive tours from retired Tektronix engineers who will tell you all about their various scopes. If I recall from my last tour, the 564 scope used by the OLS was a very popular model, in part because it supported a plugin system that would allow you to physically add and remove pieces of functionality from the front panel. It is also what's referred to as a “storage oscilloscope”, which was designed to hold an image for up to one hour, useful for things like photographing experimental results. You can check out the manual for the 564 as well.

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.

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

Fifty years ago today, on April 7th, 1969, Steve Crocker published a document that would come to be known as RFC-1. Crocker was working on a piece of the ARPA Network, or ARPANET, a US military funded project to create a network of computers using a new telecommunications concept called packet switching.

Crocker, who was a 25 year old UCLA grad student in the spring of 1969, noticed a problem that will be familiar to any computer programmer who has ever worked with other people: there was a lot of important knowledge being held in people's heads that was not documented anywhere.

So Crocker decided to document what people were thinking and what people had come to tentative agreements on. RFC-1 is this documentation; RFC stands for “Request for Comments” and is intended to invite conversation rather than stand as a record of authoritative ideas. This document was typewritten and contained hand-drawn diagrams. Many modern readers assume that the early RFCs were distributed by email or something similar, but recall that email and indeed the internet didn't exist! These documents were mostly typewritten and sent by the postal service, a manually operated mailing list. (I talk more about RFC-1 and provide additional context in my blog post about RFC-1. You can see a scan of RFC-1 at the Computer History Museum's online archive).

RFCs were a way to get a geographically distributed group of programmers to collaborate fluidly and efficiently. As Elizabeth “Jake” Feinler recalls in RFC-2555,

by the time the third RFC was published, many of the concepts of how to do business in this new networking environment had been established—there would be a working group of implementers (NWG) actually discussing and trying things out; ideas were to be free-wheeling; communications would be informal; documents would be deposited (online when possible) at the NIC and distributed freely to members of the working group; and anyone with something to contribute could come to the party. With this one document a swath was instantly cut through miles of red tape and pedantic process. Was this radical for the times or what! And we were only up to RFC 3!

365 RFCs

While the technical content of early RFCs is genuinely interesting to me, it's the aspect that Feinler highlights of how they aided in collaboration and, yes, innovation (I hate that word) that fascinates me and motivated me to begin this project.

I'm lucky enough to be involved in discussions and experiments about what networked computing might look like in the future. I don't normally go into my own work here but if you would like an example of my (necessarily limited) view of these discussions you can read a blog post I made recently, Three protocols and a future of the decentralized internet.

My motivation for writing this blog is directly related to my work on what a future internet could look like: if I'm trying to work with a disparate group of people to create a new internet, it would be ridiculous of me to ignore how a similar group of people organized to build the original internet half a century earlier. And if I'm doing the reading, I might as well share it with others.

Due to work and travel I've been falling behind on my plan to read one RFC each day (I am almost 20 days behind right now), but I plan to catch up in short order.

About 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.

by Darius Kazemi, March 14 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.

Unnecessary changes

RFC-73 is by Steve Crocker of UCLA. It's titled “Response to NWM/RFC #67” and is dated September 25th, 1970.

The technical content

This is a response to Bill Crowther's RFC-67 proposal to eliminate marking. Crocker says that the suggestion was good but he wants to hold off making unnecessary changes to the protocol.

Crocker also says that he polled some Host sites and the ones that had written more code tended to favor fewer changes to the protocol; the ones that had written less code were more open to changes.

He concludes by stating that changes to the protocol are necessary, even to increase efficiency and convenience.

Analysis

The first paragraph echoes what is stated in RFC-72: splitting messages to remove marking should be delayed. But the second paragraph contradicts the reasoning from that RFC. Whereas RFC-72 stated that changes merely for efficiency were not necessary, Crocker clearly disagrees, claiming that the delay is necessary to collect more data on network performance before making major changes.

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.

by Darius Kazemi, March 13 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.

Proposed moratorium

RFC-72 is by Robert D. Bressler of MIT's Project MAC. It is titled “PROPOSED MORATORIUM ON CHANGES TO NETWORK PROTOCOL” and dated September 28th, 1970.

The technical content

Bressler is asking for a freeze on changes to the Host-Host protocol. He is asking for this because many sites have been using the old protocol for almost 6 months and have written a lot of software that uses them. He proposes that only critical changes be considered, rather than changes that would simply increase efficiency. The general gist here is: let's stick with what we have right now and measure its characteristics before redesigning it.

Analysis

I was waiting for a note like this to come along. Crocker and others were proceeding on the assumption that Host sites would simply have to make the changes necessary to their software to work with the new protocol. It was only a matter of time before someone raised an objection to this.

Further reading

Robert D. Bressler went on to be a vice president at BBN, and is quoted in this 1983 New York Times article about the splitting of the ARPANET into MILnet (military) and R&Dnet (civilian).

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.

by Darius Kazemi, March 12 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.

Enter the CCN

RFC-71 is titled “Reallocation in Case of Input Error” by Tjaart Schipper of UCLA's Campus Computing Network. It's dated September 25th, 1970.

The technical content

This is a brief note outlining a procedure for how the UCLA CCN will handle memory allocation if there's an error in the received message such that it can't tell how long the message is. The receiving computer will tell the sender, “There was an error and I was unable to allocate memory because I have no idea how long your message is. I'm disregarding everything until you have sent me a new message and we try again.”

Analysis

This seems to be a notice that the CCN will be unilaterally doing this, rather than a suggestion or a specification.

Further reading

I could not find much further information on Schipper. By August 1972, he is no longer listed as a CCN liaison to the ARPANET project, and later RFCs list him as living in the Netherlands.

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.

by Darius Kazemi, March 11 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.

Padding math

RFC-70 is titled “A Note on Padding” and is authored by Steve Crocker of UCLA on October 15th, 1970.

The technical content

This is a continuation of notes on marking and padding, kicked off by Michel Elie's RFC-64, and also addressed in RFC-65 and RFC-67.

This is mostly a math/algorithms note. It is trying to solve the problem: given a series of bits (a “word”) where it's all 0 except for a single 1, but we don't know where the 1 is in the series, how do we efficiently and conveniently determine the position of the 1 bit?

The first and most obvious solution is to simply start counting from one end; on a computer this is accomplished by shifting the word to the right until the rightmost bit is a 1, counting each time we do a shift. This is apparently “unpleasant”, although I'm genuinely unsure if it's unpleasant meaning “difficult to program or inefficient to run on a contemporary computer” or if it's unpleasant meaning “brute force and therefore not aesthetically pleasing to those of us who enjoy mathematical elegance”.

Most of the paper is detailing the algorithms to discover the position of an isolated 1 bit. I won't summarize because (1) I will mess it up, (2) it's math so it's as terse as it's going to get and if you care you should read the RFC!

Analysis

I can imagine that having to do an O(n) search on every single message received over the network would suck, so I understand the impetus to come up with a better, more efficient way in this RFC.

I would also like to commend Guillaume Lahaye and John Hewes; they transcribed this RFC in June 1997 and they did an excellent job getting all the mathematical notation correct (I checked it against an original RFC in person).

Further reading

Crocker thanks Bob Kahn and Alex Hurwitz for their help on the RFC. Kahn is of course an ARPANET fixture we've spoken of before. But Hurwitz wasn't really an ARPANET guy. He is famous for using an IBM 7090 at UCLA in 1961 to discover the largest known Mersenne prime number. Fifteen minutes later he discovered an even larger largest known Mersenne prime number! According to this article the 7090 was actually an interface to SWAC, a giant special-purpose vacuum tube computer that was kind of the math processor for the whole thing! Anyway, having a guy like Hurwitz to check your math on a paper is like having Hemingway copy-edit your short story or something. Here are some cute photos from a meeting of prime number hunters in 1996 including Hurwitz.

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.

by Darius Kazemi, March 10 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.

Please unsubscribe

RFC-69 is “Distribution List Change for M.I.T.” It is authored by Abhay Bhusan on September 22nd, 1970.

The technical content

Please delete my name from your distribution list and add that of Mr. Albert Vezza.

Analysis

Recall that the RFC series is an academic mailing list, but before email existed. This is all done via the postal service. I think what we have here is literally the first instance of an internet person doing a reply-all saying “please remove me from your list”.

Nice.

Further reading

Dave Walden interviewed Albert Vezza in 2012.

Abhay Bhusan invented FTP, which was published as RFC-114 and we will get to in another 45 days.

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.

by Darius Kazemi, March 9 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.

Acknowledging ACK

RFC-68 is titled “Comments on memory allocation control commands: CEASE, ALL, GVB, RET, and RFNM”. It's dated August 31st 1970 and authored by Michel Elie of UCLA.

The technical content

Elie proposes a modification to the Request For Next Message signal: that the receiving Host not simply say “I am ready for another message” but actually acknowledge that it's received the message. It might even send back a checksum so the sending Host can make sure it was correctly received and not modified in transit.

Aside: what's a checksum? Well, let's say I send you the message “hello” and you want to prove to me that you received “hello”. One thing you could do is echo the message back to me and say “hello” but in a system like a computer network, this could start clogging things up pretty bad and would essentially double the traffic. So you could instead send back “5”, which I understand to mean you got a 5 letter word from me. That is somewhat helpful, but it's still possible you received “boing” and not “hello”. So we could do something where we assign numbers to each letter, a = 1, b = 2, ..., z = 26. And we add up the sum of our letters. So I send you “hello”, you respond “52”, which is the sum of the letters in “hello”. If you had gotten “boing” you would have sent “47” and I'd know there was something wrong with the message you received. While there are many words that sum up to “52”, most of them are words like “gfllo” that are obviously incorrect to the receiver, so this works as a really easy but not foolproof way to confirm a message without wasting space. Of course, checksums in computers work a little differently than this, but that's the principle.

The signal for acknowledgement is abbreviated “ACK”, and non-acknowledgment is “NACK”. A “NACK” signal would be an implied request to the sending Host to repeat its message so they can try again.

There is also mention of using two different ACK messages to signal memory allocation status. An “ACK (Continue)” message would say “I got your message and I have room for more messages”, and an “ACK (Cease)” would say “I got your message and I'm out of memory right now so don't send me anything else.”

Analysis

I believe this is the earliest appearance of “ACK” in the RFC series. I'm unsure as to whether it was immediately implemented (I haven't read very far ahead) but ACK is used, more or less in the same way proposed here, in TCP, a protocol that powers much of the internet today. When I first saw the “RFNM” signal in early RFCs I thought, “huh that is like a simple proto-ACK”, and now I see this document suggesting the transformation.

This is just one of those moments where the hairs raise on the back of my neck! This ~600 word long note contains such an important suggestion that would in one way or another shape the future of the internet.

Further reading

TCP is first fully defined in RFC-675 in December 1974. You can see the mention of ACK signals clearly in the document.

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.