365 RFCs

Commenting on one RFC a day in honor of the 50th anniversary of the first RFC.

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

Some suggestions

RFC-19 is by John E. Kreznar of Systems Development Corporation, dated Oct 9, 1969.

This RFC is two suggestions from Kreznar on how to reduce network congestion, somewhat in the spirit of RFC-18.

Technical content

His first suggestion seems to be to change how IMPs work so they consider the local state of the HOST machines when sending messages. So like if user A and B are logged into a HOST machine and the IMP has messages for them both, but user B is the one who is actively being addressed by the computer's memory, it would make sense to send the message for B first while user B's processes are in memory, then the message for A which the HOST machine could swap user A into its active memory. If the messages came in the reverse order there would be extra swapping, slowing down the computing experience for the users.

This seems like a really bad idea to me, since it would require the IMPs to have knowledge of the internal state of the HOST machines to some degree. That said, the internet has existed for literally my entire life and these folks were building it for the first time so... I'll let it slide.

The second suggestion is that maybe for transfer of large files between two HOSTs, the HOST could “lock” the program that it's running for the duration of the file transfer. Basically a way for both computers to say “we are going to prioritize this file transfer over anything else happening on the computer right now so we can quickly transfer the file between the two of us”. On a timeshare machine this would result in users who aren't involved in the file transfer having to wait for the transfer to complete before they can continue using the computer. That seems... also bad.

Analysis

Both of these ideas aren't great. But again, no internet exists yet so I can forgive bad ideas! The whole point of RFCs at this early stage is to get as many ideas out there as quickly as possible. And it seems to be working.

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, Jan 18 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.

Reducing congestion

RFC-18 is another short Vint Cerf RFC from September 1969. Here is the whole thing:

It is suggested that link 1 be used for the HOST-HOST control link and link 0 be used for IMP-IMP control.

This will facilitate communication between Hosts and reduce delays due to interference with IMP-IMP communications.

Technical content

If you'll recall, link 0 has been reserved for control communications like the initial handshake between HOSTs. But IMPs need to talk to each other too, and this proposes that IMPs coordinate over link 0, HOSTs coordinate over link 1. So HOST traffic wouldn't get in the way of IMPs coordinating with each other, I guess.

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, Jan 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.

Like email but slower

RFC-17 is by John E. Kreznar of Systems Development Corporation on Aug 27, 1969. I talk about that company in more detail in my post about RFC-10, but they were the first ever dedicated software company and did a lot of early experiments in modem communication.

This is technically RFC-17 and RFC-17a. Which is weeeeird. Basically the reason for this is, RFC-17 is some questions from Kreznar about the HOST-IMP interface, and RFC-17a is a response from Bob Kahn of BB&N, who would go on to co-invent TCP/IP with Vint Cerf.

Basically this is an email thread. But you know. Two months before the first modern computer network existed and two years before the invention of email.

Technical content

Kreznar asks four questions that boil down to the same question: have we considered certain failure modes for message transmission, particularly due to the fact that it could take a long time to hear back from a remote machine?

Kahn's answer is: yes we have, it's fine.

Analysis

This is an early example of an internet person asking some questions and being told they are wrong by another internet person.

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, Jan 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.

M.I.T.

RFC-16 is a brief note adding “Abhai [sic] Bhushan” of MIT to the distribution list on August 27, 1969.

Further reading

Abhay Bhushan is an Indian computer scientist. He was a grad student at MIT at this time. He would go on to write the FTP specification and contribute to the development of e-mail.

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, Jan 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.

Proposing TELNET

RFC-15 is authored by Steve Carr, a representative of University of Utah's computer science program (UTAH in ARPANET parlance). He was present at the first Network Working Group Meetings I mentioned in my RFC-1 post. I couldn't quickly find a lot of info on him but according to this article he was a grad student of early computer graphics expert David C. Evans when he authored this. (Incidentally, Carr would have been there at the same time as one of my personal computing heroes, Alan Kay.)

Titled “Network Subsystem for Time Sharing Hosts”, this RFC is dated Sep 25th, 1969, about one month before the first message would be sent over the ARPANET.

Technical content

This RFC is really important! It proposes a program called TELNET (now called Telnet) that solves the problem of how two computers running different hardware and different operating systems can somehow talk to one another over the network.

Carr begins by pointing to RFC-11 and summarizing Déloche's list of required “network primitives” that allow a computer to talk to ARPANET:

  • Open primary connection
  • Open auxiliary connection
  • Transmit over connection
  • Close connection.

He says that these will operate at the level of system calls, “most likely a part of the resident monitor” for maximum speed/responsiveness. Both the SDS 940 and the PDP-10 offered a way for users to write their own system calls, and in the context of a time-shared computer, all users would need access to these calls.

A “resident monitor” is a tiny program that is always present in memory that is run over and over — it is resident in memory and it is generally used to monitor when critical things need to happen. Usually the available memory for this program is very small so it often is just a single instruction that says “go to this other place in memory and run the program there”. These aren't used in modern computers but similar concepts are used in the simple embedded systems you might find in a kitchen appliance.

The RFC describes how computers running different hardware and different operating systems could talk to each other in the context of a time-sharing system. The process goes:

  • log in to your local computer
  • start up the TELNET program
  • define your local escape character (so you can define “this is the button I press when I'm about to send a special command rather than just plain old typing data”)
  • TELNET makes the system call to open the network connections so the individual doesn't need to worry about it. Assuming the remote computer is accepting remote logins, we then...
  • log in to the remote computer
  • you can type like you were locally logged in on the other computer now!
  • if you want to transfer a file from your local computer, there is a special routine for sending files (make sense, since the IMPs have their own file transfer methods, which require special link connections to be opened by the system)
  • logout, presumably (never mentioned but heavily implied!)

Carr also states that Telnet needs to take up a really small amount of memory so that it's fast. Which is why it doesn't do much (there's explicitly no translating between different character sets).

Analysis

Telnet has been in continuous use since 1969, and although it began to fall out of favor in the 1990s, it's had an incredible run as far as “ways to access the internet” go. Telnet was quickly adopted although there wasn't a formal attempt to standardize it beyond this proposal until RFC-97 in 1971.

In fact, telnet was standard on all modern consumer operating systems until very very recently. Apple only stopped shipping telnet on its Macs in 2017. On a personal note, Telnet was how I first accessed the internet, via Bulletin Board Systems when I was ten years old in 1993.

In this RFC about logging in to a remote computer the word “password” is never used. In fact the only prerequisites for accessing a remote computer are: the remote computer is accepting remote logins, and the local computer has the local user cleared for connecting to remote computers. This is the modern equivalent of “if you don't want strangers logging in to your computer, deny all login attempts.” Of course, at this point all the potential users of ARPANET knew each other! So, not a big deal yet.

Carr mentions an “SPOP” on the SDS 940 system. I believe he is referring to “SYSPOP”, which functions much like a UUO does on a PDP-10. This would make sense as Carr would have been much more familiar with the PDP-10 since that's what they used at UTAH. (A PDP-10 at UTAH would eventually become the fourth node on the ARPANET.)

In a sense, Telnet is a simpler, text-only alternative proposal to the media-rich DEL system outlined in RFC-5 that was never implemented.

Further reading

A history of Telnet.

A set of notes on SDS-940 lectures given by Butler W. Lampson in June 1966. Lampson was one of the developers of the SDS 940, and would later go on to cofound Xerox PARC and help invent a million other things.

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, Jan 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.

Miss Zarves

There is no Miss Zarves. There is no fourteenth RFC. Sorry.

Further reading

Sideways Stories from Wayside School, by Louis Sachar, 1978.

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, Jan 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.

End of file

RFC-13 is by Vint Cerf. It's called “Zero Text Length EOF Message” and is dated August 20th 1969.

Vint Cerf is I think our most famous participant in these RFCs so far. Of all the names I've named here, he is probably the person who an average web developer today might have heard of. He's not a household name like a Bill Gates or Steve Jobs but for a non-billionaire he is pretty high profile! Probably for a few reasons:

  • After his ARPANET work he went on to be instrumental in the civilian internet that we all use
  • Was and is heavily involved in various important technical organizations. These include ICANN, IETF, the Internet Society, the ACM, and so on
  • He is still actively authoring RFCs! Mostly recently he's listed as co-author on RFC-7934 from 2016
  • He gets around to conferences, does a lot of speaking and generally is a kind of “face” of the internet, most recently as Google's “Chief Internet Evangelist”, a position he got in 2005 and I believe continues to hold

Of course, at the time he authored RFC-13 he was a grad student at UCLA!

The technical content

This is a very simple addendum to RFC-11 that says there ought to be a way to designate that the file you're sending over the network has reached its end. This proposes sending an empty message to communicate that to a receiving HOST.

Analysis

RFC-11 tells us what an end-of-transmission message looks like but not end-of-file, so yeah, this addendum seems needed. An empty message seems like a bad idea? But who am I to question Vint Cerf.

Further reading

I recommending just searching the web for Cerf because there is a lot out there! This Wired interview from when he was inducted into the Internet Hall of Fame (which is a thing I guess exists??) might be a decent place to start.

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, Jan 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.

Flowcharts

RFC-12 is by Michael Wingfield, and is his only RFC, dated Aug 26th, 1969. According to the Kleinrock History Center at UCLA,

Michael Wingfield designed the interface linking the SDS Sigma 7 computer at UCLA with an Interface Message Processor (IMP) in 1969 and implemented TCP/IP for Unix in 1979.

The technical content

The document is a handful of flowcharts extracted from BBN Report No. 1822. Report 1822 was BBN's documentation on how to connect a HOST to an IMP.

Analysis

Since hooking up a HOST to an IMP was literally Wingfield's job, it makes sense that he'd extract some important summary diagrams and distribute them to the RFC recipients. They probably came in handy and made sense to have as a separate reference document while you were sitting down trying to figure out the physical hookups and data interchange of these machines.

Further reading

The only available scans of BBN Report No. 1822 I can find online are from its 1976 revision, which is 7 years after this document was written and according to its own foreword varies significantly from the original. I'm going to a bunch of archives this year and I'll try to dig up a 1969 edition.

The Kleinrock History Center hosts a collection of Wingfield's documents including many from the project to hook up UCLA's Sigma 7 HOST to an IMP. A lot of these documents are electrical engineering related rather than computer science, which I think is really neat. For example, these pages contain things like impedance calculations for cables and this page has a diagram of the actual wire-by-wire connections required:

a cable crimping diagram

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, Jan 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.

GORDO and the IMP

RFC-11 is another Gérard Deloche paper. This one is dated Aug 1st, 1969 and is an extremely in-depth expansion on the contents of RFCs 7, 8, and 9. It's our longest RFC so far, clocking in at a monstrous 54 pages typewritten.

It's called “Implementation of the HOST – HOST Software Procedures in GORDO” and details how a HOST running the GORDO operating system would connect to another HOST on the network (more on that operating system in my notes on RFC-7).

The technical content

This paper has enough technical detail that if you were a programmer whose job was writing software for GORDO you could absolutely use the information here to connect a machine to ARPANET. Though remember ARPANET was still 3 months away this point and this is a spec for how you would talk to a theoretical future ARPANET.

The main goal of this document is to outline how multiple users connected to a GORDO machine via a time-sharing system could all simultaneously access ARPANET. So it's not just one user at a time; this could mean an entire department could connect to a GORDO machine at UCLA using their terminals at their desks and each make what seems like simultaneous communications with a remote computer. The paper defines a “Network program” whose job it is to manage all the input from different users, send that input over the network, receive data back from the network, and then parcel it back out to the users again. In technical terms this type of activity where you take multiple streams of information and put them into one stream and then pick them back out again is sometimes called multiplexing and demultiplexing, which is the terminology used in this paper.

The paper states up front that it “is convenient to consider the Network as a black box – a system whose behavior is known but whose mechanisms are not”. “Network” is capitalized throughout, which reminds me of early internet style where “internet” was always capitalized like a proper noun. Nobody really does that anymore, although I remember bitter fights about it.

In terms of content, this paper covers what was already covered by Deloche in RFCs 7, 8, and 9. The main difference is that it explicitly covers GORDO implementation. We learn that GORDO's file system is centered around pages. A page is basically a chunk of memory in a computer that is organized in a way so that it's very fast for us to access to it, and once we access the page we can then more slowly go through its contents. Imagine a paper book: I could tell you to count up to the 10,000th word and tell me what it is, but assuming I kept track of exactly how many words are on each page of the book it would be faster to ask you to look up page 204 and tell me the 52nd word on the page. A simple file system is basically a whole bunch of tables of data that keep track of how many words are on each page of this book so we can quickly look up the information we need!

GORDO contains concepts of processes, forks of processes, and users/jobs. If you're familiar with Unix you've certainly seen these terms before, and I am guessing GORDO borrowed these concepts from Multics, the early time-sharing operating system developed by MIT, GE, and Bell Labs. Unix draws a direct lineage to Multics which would make GORDO a kind of cousin of early Unix.

Overall this document really is just a fleshed-out version of the previous three Deloche RFCs. This is the last RFC Deloche will author and since he graduated UCLA with Ph.D. in 1970 I'm imagining that these four RFCs represent his piecemeal thesis work, which he wrapped up with this RFC and then moved on to whatever the next thing in his career was. This paper does have the smell of a Ph.D. supervisor going “look, document what you're working on and we'll call it a thesis and then you can leave the lab.” Ahem, not that I've witnessed this exact thing happen in engineering schools, heaven forbid.

Analysis

There is no mention in this RFC of Deloche's claim in RFC-9 that there are 256 links between HOSTs. But there is also no claim of 32 links like in other docs. We do see specific link numbers mentioned in examples but they only go as high as 25. Odd, though. I wonder if he's hedging after making a mistake claiming the 256 links? Or maybe “link” was already a semantically overloaded term before the internet even existed and it's referring to something totally different.

Of note was a single mention of “slave mode” for a process. There's been a lot of heated discussion around master/slave terminology in computing in the last ten years so this kind of jumped out at me.

Further reading

A history of Multics compiled by people who contributed to the operating system over the years (the whole site is worth checking out).

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, Jan 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.

Shuffling the deck

RFC-10 explicitly revises RFC-3, which you may recall was our first attempt at defining what an RFC is. This is also titled “Documentation Conventions” and is once again authored by Steve Crocker, author of the first RFC. It was published July 29, 1969.

The technical content

The main updates to this are the who of RFCs: who is in the Network Working Group and who is on the distribution list.

The list of who the NWG “seems to” consist of (still using that awesome tentative language) has changed SRI's roster from Jeff Rulifson and Bill Duvall to Elmer Shapiro (author of RFC-4) and Bill English. Gerard Deloche is removed from the UCLA reps. John Haefner of RAND is added (I mentioned RAND in my RFC-1 writeup because they published a paper in 1962 on redundant communications networks). Paul Rovner and Jim Curry of Lincoln Labs are added.

The duty of assigning serial numbers for RFCs is now passed from Bill Duvall of SRI to Steve Crocker of UCLA.

RAND, SRI, SDC, and Lincoln Lab are added to the distribution list. (Remember in RFC-3 I was wondering why SRI was left off the distribution list? Well, that injustice is now rectified.)

Analysis

The “SDC” added to the distribution list stands for System Development Corporation, considered the first dedicated computer software company in history. Based in Santa Monica, California, it was founded in 1955 as a RAND spinoff specifically to build software for the US military. SDC had a long-distance connected computer as early as 1965 talking to MIT's Lincoln Lab on the opposite coast. This wasn't packet-switched and was a 1:1 direct communication so it wasn't internet-like, but still, it's obviously impressive work and it makes complete sense why they'd be an early ARPANET participant. (The project lead on those early connected SDC/Lincoln computers was Lincoln Lab's Larry Roberts, who would eventually lead the entire ARPANET project.)

Further reading

A huge collection of System Development Corporation papers resides at the Charles Babbage Institute Archives at the University of Minnesota. They don't seem to be scanned for online browsing. I hope to make it out there to examine these myself.

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.