RFC 48

A Possible Protocol Plateau 🎀

okay bestie, quick header tea ☕: RFC 48 is from the Network Working Group, written by J. Postel and S. Crocker at UCLA, and it's dated April 21, 1970. The header doesn't list a category or status, and it doesn't say it obsoletes or updates anything 🌸

I. Introduction ✨

so the two of them were busy after the network meeting of March 17, 1970, and as promised, they're reporting back 💅

First, they went through all the modifications everyone suggested from every direction and formed preferences about each one. Section II is where they give those preferences for each issue, plus their reasoning 🧠

Second, they tried to formalize the protocol and algorithms for the NCP, and they did it with very little specification of any particular implementation 🦋 Honestly, their attempts so far are still seriously incomplete, but they've led to a better understanding, and that's growth 🌱 Here they only include a brief sketch of the structure of the NCP. Section III covers their assumptions about the environment of the NCP, and Section IV describes the components of the NCP.

II. Issues and Preferences 🌈

in this section they go through each of the several questions that have come up in recent NWG/RFCs and in private conversations. For every issue, they suggest an answer or policy. A lot of the time, good ideas get turned down because, in their estimation, they should be incorporated at a different level 🫶

A. Double Padding 🎀

As BBN report #1822 explains, the Imp side of the Host-to-Imp interface concatenates a 1 followed by zero or more 0's to fill out a message to an Imp word boundary while still preserving the message length. On top of that, the Host side of the Imp-to-Host interface extends a message with 0's to fill it out to a Host word boundary 🧩

BBN's mechanism works fine if the sending Host wants to send an integral number of words, or if the sending Host's hardware can send partial words. But if the sending Host wants to send an irregular length message and its hardware can only send word-multiple messages, then some extra convention is needed 😩

One of the simplest solutions is to modify the Imp side of the Host-to-Imp interface so that it appends only 0's. That would mean the Host software has to supply the trailing 1. BBN rejected the change, and understandably so, because they have a strong bias against hardware changes 🔧 It was also suggested that a five instruction patch to the Imp program would remove the interface-supplied 1. This was rejected too, on the new grounds that it seemed more secure to depend only on the Host hardware to signal message end, and not on the Host software at all 🔐

There are two other solutions. One is to have "double padding," where the sending Host supplies 10* and the network also supplies 10*. On input, a receiving Host then strips the trailing 10* 10*. The other solution is to make use of marking. Marking is a string of the form 0*1 inserted between the leader and the text of a message. The original intent of marking was to extend the leader so the sending Host could begin its text on a word boundary. It's also possible to use marking to expand a message so that it ends on a word boundary ✨

Notice that double padding could replace marking altogether by abutting the text beginning against the leader. For 32 bit machines, this is convenient and marking is not. For other lengths, particularly 36 bit machines, marking is much more convenient than double padding 💖

They have no strong preference, partly because they can send word fragments. Shoshani, et al in NWG/RFC #44 claim that adjusting the marking doesn't cause them any problems, and they have a 32 bit machine. Since the idea of marking has been accepted for some time, they suggest that double padding not be used and that marking be used to adjust the length of a message. They also note that if BBN ever does remove the 1 from the hardware padding, only minimal change to Host software is needed on the send side 🦋

A much prettier (and more expensive) arrangement was suggested by W. Sutherland. He suggested that the Host/Imp interfaces be smart enough to strip padding or marking, and might even parse the message upon input 👑

B. Reconnection 🌸

A very large population of networkers has beat upon them for including dynamic reconnection in the protocol. They felt it might be interesting to explain how it came to be included 💅

After thinking about connections and their uses for a while, they wondered how the mechanism of connections compared to existing forms of intra-Host interprocess communication. Two aspects are of interest here: what formalisms have been presented in the literature, and what mechanisms are in use. The formalisms are interesting because they lead to uniform implementations and parsimonious design. The existing mechanisms are interesting because they point out which problems need solving and sometimes hint at what an appropriate formalism might be. In particular, they noticed that the mechanisms for connecting a console to the logger upon dial in, the mechanisms for creating a job, and the mechanisms for passing a console around to various processes within a job all tend to be highly idiosyncratic and distinct from every other structure and mechanism within an operating system 🤔

With respect to the literature, it appears there is only one idea with several variations, namely that processes should share a portion of their address spaces and cooperatively wake up each other. Semaphores and event channels are handy extensions of wake up signals, but the intent is basically the same. (Event channels could probably function as connections, but it seems that's not their intended use. In small systems, the efficiency and capacity of event channels are inversely related 🙈)

With respect to existing implementations, they note that several systems allow a process to appear to be a file to another process. Some systems, e.g. the SDS-940 at SRI, impose a master/slave relationship between two processes so connected. Other systems provide a coequal relationship, e.g. the AI group's PDP-6 system at MAC. The PDP-6 system also has a feature where a superior process can "surround" an inferior process with a mapping from device and file names to other device and file names. Consoles have nearly the same semantics as files, so it's quite reasonable for an inferior process to believe it's communicating with the console when it's actually communicating with another process 🎭

The similarity between network connections and existing sequential interprocess connections supports their belief that network connections are probably the correct structure for using the network. Moreover, the structure is clean enough and compatible with enough machines to pass as a formalism or theory, at least to the extent of the other forms of interprocess communication presented in the literature 🧚

They believe any new formalism must meet at least the following two tests:

1. What outstanding problems does it solve?
2. Is it closed under all operations?

For network connections, the candidates for the first test are the ones given above, i.e. all operations involving connecting a console to a job or a process. Also of interest is modeling sequential devices such as tape drives, printers and card readers, and modeling their buffering (spooling, symbiont) systems 📼

The second question mentions closure. When they applied the connection formalism to the dial-in and login procedures, they felt the need to include some sort of switching or reconnection. An extremely mild form is presented in an SJCC paper, which is also NWG/RFC #33. This mild form only permits the substitution of AEN's, and even then only at the time of connection establishment. However, it's a common experience that if an operation has a natural definition on an extended domain, it eventually becomes necessary, or at least desirable, to extend its definition. So they considered the following extensions:

1. Switching to any other socket, possibly in another Host.
2. Switching even after data flow has started.

There's even some precedent for thinking these extensions might be useful. In one view of an operating system, all available phone lines belong to a live process known as the logger. The logger answers calls, screens users, and creates jobs and processes. One feature of most telephone answering equipment is that many phone lines can serve the same phone number by using a block of sequential numbers and a rotary answering system. In their quest for accurate models of practical systems, they wanted to provide equivalent service to network users, i.e. they should be able to call a single advertised number and get connected to the logger. Thus a prima facie case for switching is established 📞

Next, after the logger interrogates a prospective user, it must connect the user to a newly created job. Data flow between the user and the logger has already commenced, so flow control has to be meshed with switching if it's desired not to lose or garble data in transit 🌊

With respect to inter-Host switching, they find it easy to imagine a utility service distributed throughout the network that passes connections from one socket to another without the knowledge of the user. It's also similar to the more sophisticated telephone systems, to standard facilities of telephone company operators, and to distributed private systems 🌐

These considerations led them to look for one type of reconnection that provided a basis for all known models. The algorithm did not come easily, probably because of their inexperience with finite state automata theory, but eventually they produced the algorithm presented in NWG/RFC #36. A short time later, Bill Crowther produced an equivalent algorithm that takes an alternate approach to race conditions 🏁

Networkers seem to have one of two reactions. Either it was pretty and (perhaps ipso facto) useful, or it was complex and (again perhaps ipso facto) unnecessary. The second group was far more evident to them, and they were put into the defensive position of admitting that dynamic reconnection was only:

1. pretty
2. useful for login and console passing

In response to persistent criticism, we've made a change to the login protocol 💅. Instead of calling socket <O,H,O> to log in, you now use sockets <U,H,O> and <U,H,1>. These are the input and output sockets of a copy of the logger, or, if a job has been started with user id U, they're the console sockets 🎀. So the login protocol is just connecting to <U,H,O> and <U,H,1> ✨. If user U isn't in use, a copy of the logger responds and interrogates the caller. If user id U is already in use, the call gets refused 🙈. Barry Wessler suggested this recently 🫶. Others suggested it way earlier, but we said no back then, oops 💀.

The logger may require the caller to be from the same virtual net, so the caller might have user id U on some other Host. It may require the user to supply a password matched to user id U, or it may require both 🔐. Some systems might even let anybody log into any user id 🌈.

After login, AEN's 0 and 1 are still the console AEN's 🖥️. Each system presumably has its own way of passing the console, and those mechanisms would be extended to know about AEN's 0 and 1 for network users. Passing the console is basically reconnecting sockets to ports, and it happens inside the Host, not over the network 🧚.

After we heard from Meyer and Skinner about NWG/RFC #46, they suggested a login scheme that was different from both Meyer's and ours in section above. Their new scheme seemed a little better, and we're excited for their next note 💌.

Everyone's pretty much agreed that login should be "third-level", meaning above the NCP level 👑. Honestly, we're kinda indifferent about which login scheme wins. They all seem ok, but none really impress us 🥱. We suggest trying several. Yes, modifying the local login procedure is some burden, but dealing with diverse login procedures doesn't add much extra hardship. The text sequences and interrupt conventions are already so heterogenous that doing our scheme on our system and Meyer's on Multics is barely any extra work 💅.

We all agree that reconnection shouldn't be required in the initial protocol. We'll offer it later as an optional and experimental tool 🧪. We also want to be on record predicting that general reconnection facilities will become useful and will provide a unifying framework for the currently ad hoc operating system structures 🔮.

C. Decoupling Connections and Links

Bill Crowther (BBN) and Steve Wolfe (UCLA) each suggested that links not be assigned to particular connections. Instead, they say, include the destination socket as part of the text of the message and then send messages over any unblocked link 📨.

We talked about this a little in NWG/RFC #37, and honestly there's still an argument for either side 🤷. With the current emphasis on simplicity, speed and small core requirements, keeping links and connections coupled seems more efficient. So that's what we recommend 💖.

D. Error Reporting

J. Heafner and E. Harslem of RAND pointed out that it's important to treat errors that might occur 🚨. A good philosophy is to guard against any input that destroys the consistency of the NCP's data base 🛡️.

The specific error command that Heafner and Harslem gave in NWG/RFC #40, and that Meyer gave in NWG/RFC #46, seems reasonable, and we recommend adopting it. Some comments are in order, though 📝.

First, a distinction should be made between resource errors and other types of errors. Resource errors are just the detection of overload conditions. Overload conditions are well-defined and valid, even if they're perhaps undesirable 🌊. Other types of errors reflect errant software or hardware. We feel resource errors shouldn't be handled with error mechanisms, but with mechanisms specific to the problem. So the <CLS> command may be issued when there's no more room to save waiting <RFC>'s. Flow control is designed solely to handle buffering overload.

As for true errors, we're not sure what the <ERR> command is worth to the recipient. Presumably their NCP is broken, and bombarding it with error commands may only make the problem worse 😬. So we recommend that error generation be optional, that all errors be logged locally in a chronological file, and that received <ERR> commands also be logged in a chronological file. No corrective action is specified at this time.

In the short time the network has been up at UCLA, we've become convinced that the network itself will generate very few errors. We watched the BBN staff debug and test the IMP program, and most of the errors seemed to affect timing and throughput rather than validity 🔍. Hence, most errors will probably come from broken Hosts and/or buggy NCP's 🐛.

E. Status Testing and Reporting

Being able to get info about what a foreign NCP thinks is happening is a valuable debugging aid 🔎. A convenient way to do this is to let NCP's send status whenever they wish, but always have them do it whenever they receive a request.

Since this is primarily a debugging tool, we suggest that a distinct link, like 255, be used. The idea is that processing status requests and generating status messages should use as little of the normal machinery as possible 🧰. So we suggest link 255 be used to send "request status" and "status is" commands. The form follows the suggestion on page 2 of NWG/RFC #40.

Meyer's <ECO> command is easy to implement, and it does the more basic job of testing whether a foreign NCP is alive 💓. We suggest that the length of the <ECO> command be variable, since 48 bits don't seem to mean anything in this context. Also, the value of a (presumably) 8 bit binary switch is unclear, so we recommend a pair of commands:

<ECO>   <length>   <text>
and
<ERP>   <length>   <text>
where
<length> is 8 bits.

When an NCP receives an <ECO> command, it echoes back with the <ERP> command 🪞.

F. Expansion and Experimentation

As Meyer correctly points out in NWG/RFC #46, network protocol is a layered affair 🍰. Three levels are apparent so far:

1. IMP Network Protocol
2. Network Control Program Protocol
3. Special user level or Subsystem Level Protocol

This last level should stay idiosyncratic to each Host (or even each user) 🦋. The first level is well-specified by BBN, and our focus here is on level 2. We'd like to keep level 2 as neutral and simple as possible. We agree that login protocol should be as much on level 3 as possible 🧁.

Simple as it is, there will still be times when the level 2 protocol should change or be experimented with 🧪. To allow for experimentation and change, we recommend that only link numbers 2 through 31 be assigned to regular connections, with the remaining link numbers, 32 to 255, used experimentally. We've already suggested link 255 for status requests and replies, which fits with our view of the experimental side of that feature 🌸.

We also recommend that control command prefixes from 255 downward be used for experimentation.

We feel these two conventions are enough to allow convenient experimentation with new protocol among any subset of the sites ✨. So we don't favor including Ancona's suggestion in NWG/RFC #42 for a message data type code as the first eight bits of a message's text 🙅.

G. Multiplexing Ports to Sockets

Wolfe in NWG/RFC #38 and Shoshani et al in NWG/RFC #44 suggest that it should be possible to attach more than one port to a socket 🔗. Our diagrams and example system calls have all shown a one-to-one match between sockets and ports, but that's strictly a matter of local implementation. Sockets form a network-wide name space whose sole purpose is to interface between the idiosyncratic structures of each operating system 🌐. Our references to ports are only meant to be suggestive, and they should be ignored if no internal structure corresponds to them. Most systems do have such structures, though, so we'll keep using them for illustration 🎨.

H. Echoing, Interrupts and Code Conversion

1. Interrupts

We used to think all operating systems scanned for a reserved character from the keyboard to interpret it as an interrupt signal 🤔. Tom Skinner and Ed Meyer of MIT let us know that model 37 TTY's and IBM 2741 generate a "long space" of 200-500 milliseconds. The I/O channel hardware detects this and passes it to the operating system as an interrupt ⚡. The "long space" isn't a character. It has no ASCII code and can't be program generated 🙃.

Well over a year ago, we considered simulating console interrupts and rejected the <INT> type command, because it didn't correctly model any system we knew. We now reverse our position and recommend implementing an INTERRUPT system call and an <INT> control command, as Meyer suggested in NWG/RFC #46 🔄.

There are two restrictions on the interrupt facility to keep in mind 🚧. First, when communicating with systems that scan for interrupt characters, this feature should not be used. Second, non-console-like connections probably shouldn't have interrupts. We recommend that systems follow their own conventions. If an <INT> arrives for a connection where it shouldn't, the <INT> should be discarded and optionally returned as an error 🗑️.

2. Echoing and Code Conversion

We believe each site should continue its current echoing policy, and that code conversion should be done by the using process 💬. Standardization in this area should await further development.

Ancona's suggestion of a table-driven front-end transducer seems like the right thing, but we believe those techniques are part of a larger discussion about higher-level languages for the network 🧠.

I. Broadcast Facilities

I. Heafner and Harslem suggest in NWG/RFC #39 a broadcast facility, i.e. <TER> and <BDC>. ngl, we don't fully get the value of this one, so we're kinda against it 🙃. We suspect we'd understand it better with more OS/360 experience 💭. It's probably true in general that sites running OS/360 or similar systems will find our network protocol suggestions less relevant than sites running time-sharing systems 🖥️. We'd really appreciate any cogent statement on how OS/360 relates to the concepts and assumptions underneath the network protocol 🙏.

J. Instance Numbers

Meyer in NWG/RFC #46 suggests extending a socket to include an instance code that identifies the process attached to the socket 👀. We carefully arranged things so that processes would be indistinguishable 🫣. We did this because we believe that, both formally and practically, it only matters inside a Host whether a computation is done by one process or many ✨. So we think all processes within a job should cooperate in allocating AEN's 🤝. If an operating system has facilities for passing a console from process to process within a job, those facilities mesh nicely with the current network protocol, even within the reconnection protocol 💅. Instance numbers interfere with that procedure though 😤.

We suggest this matter be discussed fully, because it's basically tied to the core philosophy of sockets and connections 🧠. For now we recommend 40 bit socket numbers without instance codes 🔢.

K. AEN's

Nobody, including us, is particularly happy with our name AEN for the low order 8 bits of the socket 😭. We rejected socket number, and we're similarly unhappy with Meyer's socket_code 🙈. The word socket should not be used as part of the field name, and we're open to suggestions 💡🫶.

III. Environment ✨

We assume that the typical host will have a time-sharing operating system, where the cpu is shared by processes 🖥️💖.

Processes

We envision that each process is tagged with a user_number 🏷️. There may be more than one process with the same user number, and if so, they should all be cooperating with respect to using the network 🤝.

We envision that each process contains a set of ports which are unique to that process 🎀. These ports are used for input to or output from the process, from or to files, devices or other processes 📥📤.

We also envision that each process has an event channel, where it can receive very short messages (several bits) 📨. We'll use this mechanism to notify a process that some action external to the process has occurred 🔔.

To engage in network activity, a process attaches a local_socket to one of its ports 🔌. Sockets are identified by user number, host and AEN, and a socket is local to a process if their user numbers match and they're in the same host 👯. A process need only specify an AEN when it's referring to a local socket 🦋.

Each port has a status which is modified by system calls and by concurrent events outside the process 🚦. Whenever the status of a port changes, the process is sent an event over its event channel, and that event specifies which port's status has changed 📣. The process may then look at a port's status 👀.

These assumptions are used descriptive material which follows. However, these assumptions are not imposed by the network protocol, and the implementation suggested by section IV is in no way binding 🙅‍♀️.

We really wish to make it very clear that this material is offered only to provide clues as to what the implementation difficulties might be, and not to impose any particular discipline 🫶🌸.

For example, we treat <RFC>'s which arrive for unattached local sockets as valid and queue them 📬. If desired, an NCP may reject them, as Meyer suggests, or it might hold them for awhile and reject them if they're not soon satisfied ⏳. The offered protocol supports all these options 🎉.

Another local option is the one mentioned before, of attaching multiple ports to a socket 🔗. We have shown one-one correspondence, but this may be ignored 🙃. Similarly, the system calls are merely suggestive 💭.

System Calls

These are typical system calls which a user process might execute 💻. We show these only for completeness, since each site will undoubtedly implement whatever equivalent set is convenient 🧁.

We use the notation below 📝:

Syscall ( arg , arg ...; val ... )
             1     2        1

where

Syscall is the system call
arg  etc. are the parameters supplied with the call, and
val etc. are any values returned by the system call.

Init

Init (P,AEN,FS,Bsiz;C)

     P      Specifies a port of the process.
     AEN    Specifies a local socket.  The user number of this
            process and host number of this host are implicit.
     FS     Specifies a socket with any user number in any host,
            with any AEN.
     Bsiz   Specified the amount of storage in bits the user wants
            to devote to buffering messages.
     C      The condition code returned.

Init tries to attach the local socket specified by AEN to the port P and to start a connection with socket FS 🔥. Possible returned values of C are 👇:

C = ok      The Init was legal and the socket FS is being
            contacted.  When the connection is established or
            when FS refuses, the process will receive an event.

C = busy    The local socket was in use by a port on this or
            some other process with the same user number.  No
            action was taken.

C = homosex The AEN and FS were either both send or both receive
            sockets.

C = nohost  The host designated within FS isn't known.

C = bufbig  Bsiz is too large.

Listen

Listen (P,AEN,Bsize;C)

     P     Specifies a port of the process.
     AEN   Specifies a local socket.
     Bsiz  Specified a buffer size.
     C     The returned legality code.

Codes for C are 🧾:

C = ok
C = busy
C = bufbig

The local socket specifies by AEN is attached to P 🔗. If there's a waiting call, it gets processed; otherwise no action is taken 🫥. When a call comes in, a connection will be established and the process gets notified via an event 💌.

Close

Close (P)

     P Specifies a port of the process.

Any activity is stopped, and the port becomes free for other use 🧹✨.

Transmit

Transmit (P,M,L1;L2,C)

     P     Specifies port with an open connection.
     M     The text to be transmitted.
     L1    Specifies the length of the text.
     L2    The length actually transmitted.
     C     The error code.

Transmission between the processes on either side of the port takes place 📤📥💞.

Codes for C are 👇:

C = ok
or
C = not open     if no connection is currently open and
                 otherwise uninhibited

Status

Status (P;C)

The status of port P is returned as C 🚦💅.

IV. The NCP 🎀

Okay bestie, the NCP is made of five component programs, three associative tables, some queues and buffers, and a link assignment table ✨ Every site will tweak this design to fit its own needs, so what you're seeing is just an illustration, not the one true layout 💅

The Component Programs

1. The Input Handler 📥 This one is an interrupt-driven input routine. It kicks off Imp-to-Host transmission into a resident buffer, then wakes up the Input Interpreter once that transmission is done.
2. The Output Handler 📤 Also interrupt-driven, but for output. It kicks off Host-to-Imp transmission out of a resident buffer, then wakes up the Output Scheduler when it's finished.
3. The Input Interpreter 🧠 This program decides what the input actually is: a regular message meant for a user, a control message, an Imp-to-Host message, or an error. Then it takes the right action for each class 🫶
4. The Output Scheduler 🗓️ Three classes of message get sent to the Imp:
   • (a) Host-to-Imp messages
   • (b) Control messages
   • (c) Regular messages

We believe a priority should be imposed among these classes. The priority we suggest is the ordering above. The Output Scheduler picks the highest priority message and hands it to the Output Handler. Main character energy 👑

5. The System Call Interpreter 📞 This program handles requests from the user.

The two interesting components are the Input Interpreter and the System Call Interpreter, and they're kinda twins 🦋 The Input Interpreter services foreign requests, while the System Call Interpreter services local requests.

Associative Tables

We picture most of the NCP's data base living in three associative tables. When we say "associative," we mean there's a lookup routine that gets handed a key. It either returns successfully with a pointer to the matching entry, or it fails because no entry matches the key 🔍

1. The Rendezvous Table 💌 "Requests-for-connection" and other attributes of a connection live in this table. It's accessed by local socket, but the other tables have pointers to existing entries.

The components of an entry are:

(a) local socket   (key)
(b) foreign socket
(c) link
(d) queue of callers
(e) text queue
(f) connection state
(g) flow state
(h) pointer to attached port

An entry gets created when a user runs either an Init or a Listen system call, or when a <RFC> is received. Some fields stay empty until the connection is established. For example, if the user did a Listen, the foreign socket isn't known until a <RFC> shows up 🌸

2. The Input Link Table 🔗 The Input Interpreter uses the foreign host and link as a key to get a pointer to the entry in the rendezvous table for the connection using the incoming link.
3. The Output Link Table 🔁 To interpret RFNM's, the Input Interpreter needs a table shaped like the Input Link Table, but built around outgoing links.

Link Assignment Table

This one is super simple 🍓 It just keeps track of which links are in use for each host. One word per host probably does the job.

The following diagram is our idea of the Network Control Program 🧚 Boxes stand for tables and buffers. Boxes with angled corners and a double bottom are queues. Jagged boxes are component programs. The arrows show data paths.

The abbreviated names mean the following:

ILT   - Input Link Table

OLT   - Output Link Table

LAT   - Link Assignment Table

RT    - Rendezvous Table

HIQ   - Host to Imp Queue

OCCQ  - Output Control Command Queue

ORMQ  - Output Regular Message Queue

IHBuf - Buffer filled by the Input Handler from the IMP and
        emptied by the Input Interpreter

OHBuf - Buffer of outgoing messages filled from the Queues
        by the Output Scheduler and emptied by the Output
        Handler.

Here's the diagram itself 🦋

                              +---------+
                              |  I M P  |
                              +---------+
                                v     ^
                                |     |
    +---------------------------|-----|------------------------------+
    |                           |     |                              |
    |   /\/\/\/\/\/\/\          |     |     /\/\/\/\/\/\/\           |
    |   \            / <--------+     +---< \            /           |
    |   /  Input     \                      /  Output    \           |
    |   \   Handler  /                      \   Handler  / <----+    |
    |   /            \ >------+             /            \      |    |
    |   \/\/\/\/\/\/\/        |             \/\/\/\/\/\/\/      ^    |
    |                         v                              +-----+ |
    |                      +-----+                           | OH  | |
    |                      | IM  |                           | Buf | |
    |                      | Buf |                           +-----+ |
    |                      +-----+          /\/\/\/\/\/\/\/\    ^    |
    | /\/\/\/\/\/\/\/\        v      +----> \              /    |    |
    | \              /        |      |      /  Output      \ >--+    |
    | /              \ <------+      ^      \              /         |
    | \  Input       /           /-----\    /   Scheduler  \         |
    | /              \ >-------->| HIQ |    \              /         |
    | \  Interpreter /           |_____|    /              \         |
    | /              \ >----+    \_____/    \/\/\/\/\/\/\/\/         |
    | \/\/\/\/\/\/\/\/      |                ^     v    ^            |
    |   ^   ^    ^   \      |    /-----\     |     |    |    /-----\ |
    |   |    \    \   \     |    |  O  |     |     |    |    |  O  | |
    |   |     \    \   \    +--->|  C  |>----+     |    +---<|  R  | |
    |   v     v     v   \        |  C  |           |         |  M  | |
    | +---+ +---+ +---+  \       |  Q  |           v         |  Q  | |
    | |   | |   | |   |   \      |_____|      +---------+    |_____| |
    | |ILT| |LAT| |OLT|    \     \_____/      |         |    \_____/ |
    | |   | |   | |   |     \       ^         |   R T   |       ^    |
    | +---+ +---+ +---+      +------|-------->|         |       |    |
    |         v                     |         +---------+       |    |
    |         |                     ^              ^            |    |
    |         |            /\/\/\/\/\/\/\/\        |            |    |
    |         |            \              /        |            |    |
    |         +----------->/    System    \<-------+            |    |
    |                      \     Call     /                     |    |
    |                      /  Interpreter \>--------------------+    |
    |                      \              /                          |
    |                  +-->/              \>--+                      |
    |                  |   \/\/\/\/\/\/\/\/   |                      |
    +------------------|----------------------|----------------------+
                       |                      |
                       +---< system calls <---+

   [ This RFC was put into machine readable form for entry ]
   [ into the online RFC archives by Donald and Jill Eastlake 1999 ]

[Editor's note: The original hand-drawn diagram represented
Queues by cylinders and component programs by "squishy ameoba
like things".]