RFC 1
Host Software
RFC 1: Host Software 🦋
okay bestie, this is literally the very first RFC ever 😭🎀 Here's the title block:
- Network Working Group: the group this is for
- Request for Comments: 1
- Title: Host Software
- Author: Steve Crocker
- Installation: UCLA
- Date: 7 April 1969
The original doesn't list a category or status, and it doesn't say what it obsoletes or updates, so there's nothing to report there 💅
Contents 🧚
- Introduction
- I. A Summary of the IMP Software
- Messages
- Links
- IMP Transmission and Error Checking
- Open Questions on the IMP Software
- II. Some Requirements Upon the Host-to-Host Software
- Simple Use
- Deep Use
- Error Checking
- III. The Host Software
- Establishment of a Connection
- High Volume Transmission
- A Summary of Primitives
- Error Checking
- Closer Interaction
- Open Questions
- IV. Initial Experiments
- Experiment One
- Experiment Two
Introduction 🌸
okay so the software for the ARPA Network is split up 💖 part of it lives in the IMPs and part of it lives in the respective HOSTs. BB&N specified the IMP software, and it's the HOST groups' job to agree on the HOST software ✨
During the summer of 1968, reps from the initial four sites met a bunch of times to talk about HOST software and early experiments on the network. Out of those meetings came a working group of three: Steve Carr from Utah, Jeff Rulifson from SRI, and Steve Crocker of UCLA. They met during the fall and winter, and the most recent meeting was in the last week of March in Utah. Bill Duvall of SRI also showed up, since he'd recently started working with Jeff Rulifson 🫶 Meanwhile, Gerard DeLoche of UCLA has been working on the HOST-IMP interface 🧚
Here I share some of the tentative agreements and open questions we ran into. Very little of this is firm, so we really want your reactions 🙈
I. A Summary of the IMP Software ✨
Messages
info moves from HOST to HOST in bundles called messages 💌 A message is any stream of not more than 8080 bits, together with its header. The header is 16 bits and looks like this:
Destination 5 bits
Link 8 bits
Trace 1 bit
Spare 2 bitsThe destination is the numerical code for the HOST the message is headed to. The trace bit tells the IMPs to record status info about the message and send it back to the NMC (Network Measurement Center, i.e., UCLA) 🔍 The spare bits are unused 🤷
Links
okay the link field is a special device the IMPs use to limit certain kinds of congestion 🚦 Here's how it works. Between every pair of HOSTs there are 32 logical full-duplex connections, and messages can be passed over them in either direction. The IMPs put this restriction on the links: no HOST can send two successive messages over the same link before the IMP at the destination has sent back a special message called an RFNM (Request for Next Message). This keeps one HOST from clogging up another if the sender is trying to shove too much down one link 😤 But ngl, the destination IMP doesn't have enough capacity to handle all 32 links at once, so the links only help if the overload is coming from one or two of them. That means the HOSTs have to cooperate here too 🫶
The links have these primitive characteristics. They're always functioning, and there are always 32 of them.
By "always functioning," we mean the IMPs are always ready to transmit another message over them. The IMP software has no notion of starting or ending a conversation, so you can't query an IMP about the state of a link (though you might be able to ask an IMP about a link's recent history, which is a whole different thing 👀).
The other primitive thing is that there are always 32 links, whether they're in use or not. So each IMP has to maintain 18 tables, each with 32 entries, no matter how much traffic there actually is 📊
Even with those objections, the links are easy to program within the IMPs and are probably a better option than fancier arrangements, just because they're simpler 💅
IMP Transmission and Error Checking
After an IMP gets a message from a HOST, it splits the message into one or more packets. Packets are not more than 1010 bits long and are the unit of data transmission from IMP to IMP 📦 A 24 bit cyclic checksum is computed by the transmission hardware and tacked onto each outgoing packet. The receiving hardware recomputes the checksum and checks it against the transmitted one. Packets get reassembled into messages at the destination IMP 🧩
Open Questions on the IMP Software
- An 8 bit field is provided for link specification, but only 32 links are provided, why? 🤔
- The HOST is supposed to be able to send messages to its IMP. How does it do this?
- Can a HOST, as opposed to its IMP, control RFNMs?
- Will the IMPs perform code conversion? How is it to be controlled?
II. Some Requirements Upon the Host-to-Host Software 💖
Simple Use
As with any new facility, there'll be a stretch of very light usage until the community experiments with the network and starts depending on it 🌱 One of our goals has to be getting a wide class of users to start using it easily and right away. So it seems natural to let people use any remote HOST as if it had been dialed up from a TTY (teletype) terminal 📟 We'd also like some ability to transmit a file in a somewhat different way, maybe not just simulating a teletype.
Deep Use
Here's one of the inherent problems with the network: every response from a remote HOST takes on the order of a half-second or so, no matter how simple it is 🐢 For teletype use we could switch to a half-duplex local-echo setup, but that would wreck some of the network's usefulness. The 940 Systems, for example, have a very specialized echo 🤓
When we think about graphics stations or other sophisticated terminals controlled by a remote HOST, the problem gets even worse. We need a method that lets us use our most sophisticated equipment as much as possible, as if we were connected directly to the remote computer 🖥️✨
Error Checking
Jeff Rulifson at SRI makes the point that error checking at major software interfaces is always a good thing 🙌 He points to some SRI experience where it saved a lot of dispute and wasted effort. So we'd like to see some HOST to HOST checking. On top of checking the software interface, it would also check the HOST-IMP transmission hardware. (BB&N claims the HOST-IMP hardware will be as reliable as the internal registers of the HOST. We believe them, but we still want the error checking 🧐)
III. The Host Software 🎀
Establishment of a Connection
The simplest connection we can imagine is where the local HOST acts like a TTY that dialed up the remote HOST 📞 After a lot of thought about the problems of starting and ending such a connection, it's been decided to reserve link 0 for communication between HOST operating systems. That leaves the remaining 31 links to be used as dial-up lines.
Each HOST operating system must provide its user level programs with a primitive to establish a connection with a remote HOST, and a primitive to break the connection. When these primitives are invoked, the operating system must select a free link and send a message over link 0 to the remote HOST requesting a connection on the selected link. The operating system in the remote HOST must agree and send back an accepting message over link 0.
If both HOSTs select the same link to start a connection and both send request messages at essentially the same time, a simple priority scheme kicks in: the lower priority HOST gives way and selects another free link 🥺 One usable priority scheme is just ranking HOSTS by their identification numbers. Note that both HOSTs know simultaneous requests were made, but they take complementary actions. The higher priority HOST disregards the request, while the lower priority HOST sends both an acceptance and another request 👑
The connection that gets set up is a TTY-like connection in the pre-log-in state. That means the remote HOST operating system will initially treat the link as if a TTY had just called up. The remote HOST will generate the same echos, expect the same log-in sequence, and look for the same interrupt characters 💬
High Volume Transmission
Teletypes acting as terminals have two special drawbacks when it comes to transmitting a large file 📁 First, some characters are special interrupt characters. Second, special buffering techniques are often employed, and those are only appropriate for low-speed character-at-a-time transmission.
So we define another class of connection for transmitting files or other large volumes of data 🚚 To start this kind of link, user level programs at both ends of an established TTY-like link have to request the establishment of a file-like connection parallel to the TTY-like link. The priority scheme comes into play again: the higher priority HOST sends a message over link 0 while the lower priority HOST waits for it. The user level programs aren't concerned with any of this, of course 😌 Selection of the free link is done by the higher priority HOST.
File-like links are distinguished by the fact that no searching for interrupt characters takes place, and buffering techniques suited to the higher data rates do take place 💨
A Summary of Primitives
Each HOST operating system must provide at least the following primitives to its users. This list is not known to be necessary, but it is not sufficient 🧃
- a) Initiate TTY-like connection with HOST x.
- b) Terminate connection.
- c) Send/Receive character(s) over TTY-like connection.
- d) Initiate file-like connection parallel to TTY-like connection.
- e) Terminate file-like connection.
- f) Send/Receive over file-like connection.
Error Checking
We propose that each message carry a message number, bit count, and a checksum in its body, and that this is transparent to the IMP 🔢 For the checksum we suggest a 16-bit end-around-carry sum computed on 1152 bits, and then circularly shifted right one bit. The right circular shift every 1152 bits is designed to catch errors in message reassembly by the IMPs 🕵️♀️
to be continued: part 1 of 2 is done! 🦋 Part 2 picks up with the rest of Section III (Closer Interaction and Open Questions) and Section IV (Initial Experiments) 💖
Closer Interaction 🫶
okay so the stuff we just covered shows how a user can make simple use of a remote facility 💅 but it says nothing about how much more intricate use of the network is gonna get. ngl this part is my fave. at some sites, people have put a LOT of work into making the computer super responsive to a sophisticated console, like Culler's consoles at UCSB and Englebart's at SRI 🔥. but if you get a delay of a half-second or so for trivial echo-like responses, the whole interaction gets so laggy that the sophistication of the console becomes irrelevant 😭
We believe most console interaction can be split into two parts: an essentially local, immediate and trivial part, and a remote, more lengthy and significant part ✨. picture a user at a console with a keyboard and a refreshing display screen. the program they're typing into collects a string of characters until a carriage return shows up, and then it processes the string. while characters are being typed, it shows them on the screen. when a rubout character gets typed, it deletes the previous non-rubout character. so if the user types H E L L O <- <- P <CR> (where <- is rubout and <CR> is carriage-return), that's nine keystrokes 🙈. if each one of those keystrokes sends a message that then invokes instructions to our display station, we will quickly become bored 💀
a better solution is to have the front-end of the remote program (aka the part scanning for <- and <CR>) be resident in our computer 🧚. in that case, only one five character message gets sent, i.e., H E L P <CR>, and the screen gets managed locally 🎀
we propose to make this happen by creating a language for console control. it's called DEL for now 💜. subsystem designers would use it to specify what components are needed in a terminal, and how the terminal is supposed to respond to inputs from its keyboard, Lincoln Wand, etc. then, as part of the initial protocol, the remote HOST sends the local HOST the source language text of the program that controls the console. that program would have been written by the subsystem designer in DEL, but it gets compiled locally 🌈
the specifications of DEL are still under discussion. the following diagrams show the sequence of actions 🦋
A. Before Link Establishment
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ +-----------+ |
| | | | Request connection | | | |
UCLA { | | | -> over link 25 | | | } SRI
| | +-+-+ | +-+ +-+ | +-+-+ | |
| | | OS|---+-=|I|----------|I|=-+---| OS| | |
| | +-+-+ | +-+ +-+ | +---+ | |
| | | | | |
| | | | | |
| +-----------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /b. After Link Establishment and Log-in
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ "Please send front"+-----------+ |
| | | | end control" | | | |
UCLA { | | | -> | | | } SRI ___
| | +-+-+ | +-+ +-+ | +--+---+ | | / |
| | | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---| |
| | +-+-+ | +-+ +-+ | +------+ | | |___/
| | | DEL prog. | | | | |
| | | <- | | | |____|
| +-----------+ +-----------+ |
| HOST: UCLA HOST:SRI |
\ /c. After Receipt and Compilation of the DEL program
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| |Trivial | |
| |Responses | |
| | | |
| +-----+------+ +-----------+ |
| | | | | | | |
UCLA { | | | Major Responses | | | } SRI ___
| | +--+--+ | +-+ +-+ | +--+---+ | | / |
| | |DEL |---+-=|I|----------|I|=-+--|OS|NLS| +---+---| |
| | |front| | +-+ +-+ | +------+ | | |___/
| | | end | | | | | | |
| | |prog.| | | | | |____|
| | +-----+ | | | |
| | | OS | | | | |
| | +-----+ | | | |
| | | | | |
| +------------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /Open Questions 💅
- If the IMPs do code conversion, the checksum will not be correct.
- The procedure for requesting the DEL front end is not yet specified.
IV. Initial Experiments ✨
Experiment One 🍓
SRI is currently modifying their on-line retrieval system, which will be the major software component on the Network Documentation Center, so that it can be operated with model 35 teletypes. the control of the teletypes will be written in DEL. all sites will write DEL compilers and use NLS through the DEL program 👑
Experiment Two 🌸
SRI will write a DEL front end for full NLS, graphics included. UCLA and UTAH will use NLS with graphics 🎀
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Celeste Anderson 3/97 ]📦 where this page comes from
- ietf: rfc1 1969-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms