365 RFCs

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

Accounting

RFC-136 is titled “Host Accounting and Administrative Procedures”. It's authored by Bob Kahn and dated April 29th, 1971.

The technical content

This RFC is the result of discussions held in February 1971, as detailed in RFC-101. It talks about the problem of accounting. This is a broad term that does include the question of “how do you charge money for usage of computer time on the ARPANET” but also encompasses more basic questions of keeping track of what nodes are on the network, processes for bringing new nodes online, how to account for the different resources available at different nodes, and so on.

This document doesn't provide any answers, but rather lays out a bunch of assumptions and then questions for further discussion by the accounting subcommittee and also the NWG at large.

Kahn makes a few assumptions at the outset.

First he states assumptions about the “subnets”, which refer to the layer 1 infrastructure including the IMPs, will be operated by a “government or private” entity that acts as a “cost center”, which is an accounting term that usually refers to a divison of some larger operation that does not generate revenue but only tracks expenses. In the case of the subnets, operational costs will be incurred and the idea is that the costs will be reimbursed either by contract with ARPA, or by charging the Hosts for the usage of the subnet. Kahn assumes that ARPANET subnets are not common carriers, that is to say they are a closed communications network and not meant to be sold as a utility to the general public.

Next he states his assumptions about the Host sites. Host sites are expected to pay for their own servers via ARPA money or by charging other Host sites for usage. Host sites are expected to provide usage prices based on things like “cpu, storage, connect time, peripherals”.

He also states that there won't be any standardized automated accounting procedures until the manual accounting procedures are figured out. Basically, he is suggesting that they shouldn't walk before they learn to crawl.

All of this means that there is going to need to be good traffic measurement and record keeping.

I won't detail every question posed (you can read the RFC itself for that) but some that stand out to me are:

• How do we currently account and charge for network usage?
• What kind of security and authentication is in place so we know who is using what services?
• How should pricing be approached? On a service-by-service basis or something more generic?
• Should there be standard pricing across the network?

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Correspondence models

RFC-135 is titled “Response to NWG/RFC #110” and is authored by Wayne Hathaway of NASA Ames on April 29th, 1971.

The technical content

This is a response to RFC-110, which discussed ways to handle the IBM 2741 teletype terminal. The main issue of that RFC was that there are some characters on the 2741 that aren't supported in ASCII, and there are some ASCII characters that have no key on the keyboard for the 2741.

This RFC exists because RFC-110 was apparently written with one model of the 2741 in mind. As explained in the Wikipedia article for the 2741, there were two models manufactured: a “correspondence coding” model and a “PTT/BCD coding” model. The solutions proposed by RFC-110 only apply to the PTT/BCD coded 2741.

Most of the document generalizes the information in RFC-110 to apply to both kinds of 2741 terminal.

The author recommends using the cent sign (¢) on the 2741 as an escape character (recall that the cent sign was not supported in the first revision of ASCII, but it exists on the 2741 keyboard). He also recommends an interesting method of sending ASCII control characters: you would type ¢, then @, and then you would type the English abbreviated mnemonic for an ASCII control character. So for example, if you wanted to send “escape” (ESC), you'd type ¢, then @, then the letters E, S, C.

Analysis

The last part about sending control characters via mnemonics is really interesting to me! Some of you might have had to do things like enter special characters by looking up or remembering their actual hexadecimal ASCII values, which are a pain in the ass to remember. Supporting mnemonics seems like it would be pretty helpful.

Further reading

Modern operating systems have many ways to support entering keys that are not present on the keyboard but are present in the Unicode character set. It's pretty haphazardly implemented across operating systems and operating system versions so it seems like not much has changed since 1971. (Now that I think of it, “not much has changed since 1971” might be the central thesis of this blog.)

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Endicott House

RFC-134 is titled “Network Graphics Meeting” and it's authored by Al Vezza of MIT, dated April 29th, 1971.

The technical content

This RFC informs readers that Project MAC at MIT (the home of Multics) is holding a meeting to discuss graphics over the network at MIT's Endicott House (more on that below). It's a 1.5 day long meeting spanning over two nights in July 1971.

The meeting itself was already outlined in RFC-87 back in January, though it was originally planned for April, not July. They suggest submitting papers and working notes ahead of time through the RFC mechanism, and a month before the meeting they will publish a list of reading material that attendees are asked to review before attending.

Analysis

I wish more technical meetings I attended were planned this far in advance with suggested reading material and all that kind of stuff.

Further reading

The MIT Endicott House is an estate located in Dedham, Massachusetts. It's been an MIT conference center since 1955. One important note is its location relative to the main MIT campus: it's actually about 12 miles to the west. This puts it on Route 128 (now also I-95) which some people refer to as America's original “tech corridor”. This would have made Endicott house extremely easily accessible to Lincoln Laboratory, DEC, and BBN personnel. The house is on a relatively secluded estate so this particular meeting would have had an “country retreat” type of feeling to it.

This brief history of the Route 128 tech corridor is a good overview, and there is a 1993 book by Lampe and Rosegrant that seems promising. This paper by Hulsink et al. is a comparison of Route 128 and Silicon Valley as high-technology “clusters” (it should be freely readable since it's an SSRN paper).

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Sorry, forget it

RFC-133 is titled “File Transfer and Error Recovery”. It's authored by R. L. Sunberg of Harvard, and is his only RFC.

The technical content

This document is three broad commentaries, one on File Transfer (RFC-114), one on error recovery in general, and one on NCP version identification.

It also contains some lovely “conversations” between server and client.

The author wants the server to have the “last work” in all file transfers, and all messages sent should prompt a response from the receiver. So there should be no such thing as a “fire and forget” message. Here's an example conversation between local and remote server file transfer, with the server notably at the end saying “All done”.

• Establish a connection
• Identify self
• Ok, ready
• Retrieval request
• I've got your file
• Send it
• Here's the first part
• Got it
• All done
• Store request
• Ok, go ahead
• Here's some protection stuff
• Ok
• Here's the file
• Got it. All done.

The author also recommends that there be mechanisms in FTP for addressing individual pieces of a file, which will be useful for extremely large files. He provides a formal mechanism to do so, which he recommends be added to the FTP spec.

In the next section, Sunberg notes that “[e]rror recovery procedures have been noticeably lacking to date” and mostly involve restarting the entire connection and trying the whole thing from the start if an error is detected at any point. He proposes a way to recover from a one-sided error that doesn't involve restarting the connection.

Here's his conversation that he uses to illustrate this:

• Send me this file
• Ok, I've got it
• Ready
• Here it is (with an error)
• No. (data) error
• Sorry, forget it
• Send the file (again)
• Ready (doesn't get there)
• (waiting)
• Error, timeout
• Sorry, forget it
• Send the file (third time)
• Got it
• Ready
• There it is
• Got it
• Done (finally)

If that doesn't work, then there should be a way to clear the link without closing any sockets. So it would be starting over but not completely, as an ICP would not need to be re-negotated. Finally, if that fails, the closing and opening the socket should be the last resort.

He also recommends that NCPs provide their version number so that a remote connection can tell what version of the NCP a host has implemented and can adjust accordingly.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Off by one

RFC-132 is titled “Typographical Error in RFC 107”. It's authored by Jim White of UCSB and dated April 28, 1971.

The technical content

This RFC provides a correction to RFC-107. It corrects an off-by-one error.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

VIEWs on the network

RFC-131 is titled “Response to RFC #116 (May NWG Meeting)”, authored by Harslem and Heafner of RAND and dated April 1971.

The technical content

This RFC provides a general status update on RAND's ARPANET work.

They are making progress in implementing the new Host-Host Protocol and estimate completion by the end of May.

They're working on an experimental log-in system.

They are waiting on a TELNET specification, at which point they will implement a TELNET client and server, which they estimate will be about two weeks of work.

They are moving their network operations from an IBM 360/65 to a PDP-10. These are very different machines so the task is a pretty big one. The 360/65 will remain in legacy service but will receive no software updates after September.

The climate dynamics work being conducted between UCSB and RAND over the Network proceeds apace and they expect heavier usage in the future, along with a local graphics program that can render charts using remote data from UCSB.

RAND continues work on the Data Reconfiguration Service (more on this in my post on RFC-128). They also tease something called a Protocol Manager which will be coming soon in an RFC. However, this does not appear to have ever actually been released.

Finally, there is some criticism of Steve Crocker in his role as Network Working Group Chairman. This is mostly because subcommittees aren't acting fast enough to produce specifications that the network can use. The authors fully admit that their own subcommitte on Data Reconfiguration is in fact one of these laggards.

They also believe that the NWG is good for short and medium term goal-setting but for long range planning there should be a smaller group consisting of just the Principal Investigators at various primary ARPANET sites. This group could undertake long range Network planning.

Further reading

Here is the 1972 paper that describes the resulting system for building charts from remote data. It's called VIEW (Video Information Exchange Window).

There is also a 1974 paper that provides a broader overview of the Climate Dynamics Project and its use of computing, but I can't find an electronic version readily online.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Waiting on Telnet

RFC-130 is titled “Response to RFC #111 (Pressure from the Chairman)”. It's authored by John Heafner of RAND and dated April 22nd, 1971.

The technical content

This is a response to Steve Crocker's RFC-111, which I referred to as “an ultimatum”. In that RFC, John Heafner of RAND was given the duty of project manager to check in on how each site is progressing towards a full implementation of the new Host-Host Protocol. This was about 3 weeks prior to this RFC. Heafner is the author of this RFC.

Heafner says he can't really do this job until TELNET is finished. Once TELNET is done (as in, once there is a full specification in an RFC), then he will commence coordinating tests of the new protocol with remote sites.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Socket names

RFC-129 is titled “A Request for Comments on Socket Name Structure”. It's dated April 22nd, 1971, and it's authored by Harslem and Heafner of RAND, and Meyer of MIT's Project MAC.

The technical content

This RFC proposes two structures for socket names. Recall that a socket is a thing that the NCP can talk to, and the socket is connected to a process on the local host. The reason that you don't just connect to a process ID directly via the ARPANET is that process IDs can change. The idea is that the socket number remains constant throughout the duration of the connection and then the host itself can have a changing/arbitrary process ID behind the socket. This means the connecting host doesn't need to know about the internals of the remote computer.

The idea in this RFC is to propose more stringent limitations on what a socket number means.

There is already a convention that even sockets (where the least significant bit is a 0) are always receive sockets, and odd ones (LSB of 1) are send sockets. This RFC calls this the “gender” of a socket, which is a longstanding term that goes back, as many of these things do, to mechanical engineering terminology. And yeah it's basically because in actual mechanical device interfaces there is often a phallic looking thing going into a yonic looking thing.

Anyway, they set up this example that they're going to use to work through implications of the different socket naming conventions.

User A at Host A has agreed (by letter, telephone, etc.)
with User B at Host B for their respective processes to
establish a connection through the Network at a particular
time.  User B is to be waiting for the connection attempt
initiated by User A.  The issues to be faced are those of
addressing (how is User A to know to which socket to connect?),
and of security (how are both users to be confident that
they are talking each other, and not some interloper?).

One thing I love about this is that it's explicit that so much of this involves calling someone by phone at a different university and saying “okay I'm going to connect to you now”. (This is not that different from when you're having trouble connecting to a video conference call today and you need to call someone on their telephone to make sure you're connecting to the right video call.)

Arbitrary socket numbers

First they discuss “arbitrary” socket values, where aside from “gender” there is not any intrinsic meaning to the number of a socket.

One way to approach socket names is that, “gender” of the socket aside, the users on either side can pick any number they want for their socket as long as it's not currently in use. They coordinate ahead of time so that user A knows to send a request to B on the correct socket, and that B is sure to be listening on the correct socket for a connection from the remote socket pre-determined by user A. This unfortunately can result in socket conflicts because, for example, the socket chosen by user B might, by the time they make the connection, be in use by someone else. Also it requires private out-of-band communication ahead of time.

Another way to approach arbitrary socket numbers is for the user to attempt a connection to host at a predetermined socket, which then routes them to a new arbitrary socket that they then connect to permanently. There is a proposed “Network Directory service” that handles this routing to sockets. The scheme is admittedly “rather cumbersome”.

Socket numbers with user IDs encoded

Another way to approach socket numbers is to effectively give each user a range of available sockets that they can access. This is accomplished by giving each user a permanent ID number on the local host and hard-coding that into the most significant bits of the socket number. The idea here is increased security – for example if sockets 256 through 512 are only accessible by User A on the local computer, then User B can be sure that a request from socket 294 is definitely coming from someone logged in as User A, and can immediately reject it if it is not from the expcted range. This removes any socket conflict between users, and is more secure. But it makes things more complex for the operating system and requires the NCP to understand more about what is happening in the OS.

No sockets at all

The authors also propose a socketless scheme, where processes simply connect to processes without the intermediary of sockets. This would require a special encoding system for process numbers though.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Bytes

RFC-128 is titled “Bytes” and is authored by Jon Postel of UCLA. It's dated April 21st, 1971.

The technical content

Postel discusses the issue of mismatching byte size between hosts. What if a sending host specifies a 5-bit byte and the receiving host specifies a 3-bit byte? He says that this could be considered an invalid connection and immediately terminated, or it could be considered valid and there would have to be some kind of translation that takes place.

Postel says that UCLA thinks asymmetry in byte sizes should be allowed and that the way they would be handled would be by essentially considering everything to be a bit stream. This removes the need for padding-based algorithms on the NCP side in the case where you insist that “your” byte is always a full byte and must be considered such by the receiver (though he doesn't rule out using this system as well).

Postel suggests that RAND's Data Reconfiguration Language might be used for padding-based case.

Analysis

Handling things on the bit level seems to have the effect of pushing the byte-level translation work from the NCP to the end-users instead, which is probably a good idea. I think the NCP should be as simple as possible.

Further reading

There are a couple papers on the Data Reconfiguration Service floating out there. This 1971 paper is co-authored by a bunch of ARPANET regulars is a kind of high level overview, and this 1972 paper by Harslem, Heafner, and Wisniewski is far more in-depth and essentially a technical manual including source code.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Missing algorithm

RFC-127 is titled “Comments on RFC 123” authored by Jon Postel of UCLA. It's dated April 20th, 1971.

The technical content

Postel is commenting on the official Initial Connection Protocol submitted by his colleague Crocker in RFC-123. This is not plain-English commentary but rather his timeline/algorithm for what an ICP handshake would look like.

Analysis

This is a case of Postel filling in what is probably necessary information that was missing from RFC-123.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.