RFC-231

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

Let's keep standardizing

RFC-231 is titled “Service Center Standards for Remote Usage—A User's View”. It's by Heafner and Harslem of RAND and dated September 21, 1971.

The technical content

This RFC proposes a set of standards for service centers. A service center is a computer or set of computers on the ARPANET that can be accessed remotely and provides useful services to users. RAND believes that there should be standard services offered by these centers, and that it would enable the community of users to expand.

RAND's network user community right now is research scientists and their “support programmers”. That is to say, the scientists don't access the network directly. They give marching orders to programmers who then interact with the computers and then give the data back to the scientists. RAND would like to make the system easy enough to use that programmers are removed from this loop, “eliminating the buffer”, in their words.

RAND also says that standards will save users both time and money. Keep in mind that network usage is metered! It's almost never mentioned directly in these RFCs but the primary reason each site asks for a user name when you log in is so that they can charge you money for using their computer services. (More on this in “Further reading” below.)

The authors highlight the following areas for standardization:

Remote job entry. These are the systems that let you submit general computing work to a remote computer. There are two totally different protocols, one at UCSB and one at UCLA, that do basically the same thing but require entirely different input from the user.
Login procedure. While the Initial Connection Protocol handles the technicalities of a computer connecting to a remote computer, once you're connected, every single site has a different set of questions it asks you to identify who you are.
Accounting protocol. The different sites use all sorts of measures to determine how much money they're going to charge you, usually a combination of: how much storage you're using, CPU time, time simply connected to the system, I/O, and more. It's extremely difficult for a user to understand some of these formulas, and to predict what their costs are going to look like.
Procedures for “off-line” services like printer output, tape backup, and so on.
Some kind of quality-of-service mechanism, where a user can spend extra money to bump up the priority of their computation jobs.
Documentation formats.
Schedules for when services will be available.
Long-term storage of files.

Analysis

Fifty years later, the accounting protocol problem has not been solved. It is notoriously difficult to figure out how, for example, Amazon Web Services charges for remote computer usage. Check out this 2017 article that spends 4,000 words trying to explain to you how you might figure out what Amazon is charging you money for.

This is a couple years in the future but there's an entry on the SRI ARC Journal from 1973 that demonstrates the cost issues around Network access. There's a short paper posted by Jacques Vallee, Elizabeth Michael, Linda Lane, and Kirk Kelley called “The Economics of Text-Editing Functions”, accesssible on page 76 of this PDF. They connected to several different ARPANET systems and carried out the same text entry, proofing, editing, and viewing tasks, measuring the time it took to carry out each sub task and the total time. Costs in 1973 for accessing a PDP-10 were $4/hour of connect time and $8/hour of CPU time. In 2019 dollars that is $23/hour for the connection and $46/hour for CPU usage. Other systems charged similar rates. The purpose of the paper is to identify the text-editing systems that let a user work fastest: this provides information to help current network users pick the most efficient system, but also helps text editor designers compare what's working and not working between the different systems that are out there.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.