RFC 89

SOME HISTORIC MOMENTS IN NETWORKING ✨

okay bestie, this is RFC 89 🦋, and it's giving 1971 hardware drama. It's titled SOME HISTORIC MOMENTS IN NETWORKING, written by B. Metcalff from MITDG, with NIC number 5697, dated 19 January 1971. The header doesn't say what category it is, and it doesn't list anything it obsoletes or updates, so there's no more to it than that 💅

While we were waiting for the interim network control program (INCP) for the MIT MAC Dynamic Modeling/Computer Graphics PDP-6/10 System (MITDG) 💖, we got a bunch of 'historic moments in networking' that are honestly worth talking about. First, we connected an MITDG terminal to a Multics process, making it a Multics terminal. Second, we attached an MITDG terminal to the Harvard PDP-10 System, which enabled automatic remote use of the Harvard System for MIT. Third, we developed primitive mechanisms so remotely generated programs and data could be sent to our system, executed, and returned. Working closely with Harvard using these, we received graphics programs and 3D data from Harvard's PDP-10, processed them repeatedly on our Evans & Sutherland Line Drawing System (the E&S), and sent 2D scope data to Harvard's PDP-1 for display. Iconic behaviour, honestly 🔥

The IINCP 🎀

Our experiments ran on the MITDG PDP-6/10 using what we affectionately call our 'interim interim NCP' (IINCP) 🧚. Under the IINCP, the IMP Interface is treated as a single-user I/O device that deals in raw network messages. The software supporting the necessary system calls is basically just the basic interrupt-handling and buffering schemes that the NCP will use later. The user-level programs that got us our historic moments were written close to the hardware, with full knowledge of IMP-HOST Protocol (BBN 1822). Once the INCP and NCP are completed, these programs can be pruned considerably (80%). Writing programs that conform to IMP-HOST Protocol was totally not wasted 😭 Only now can those of us who aren't writing the NCP really begin to grasp the full meaning of RFNM's and how they're used in flow control. The penalties for ignoring an impatient IMP, for failing to send NOOPS (NO-OPS) when starting up, and for blasting data onto the Network without regard for RFNM's are now well understood. Lesson learned, no cap 💀

The Multics Connection 💅

Our quest for historic moments started with needing to demonstrate that the complex hardware-software system separating MITDG and Multics was operative and understood. A task force (Messrs. Bingham, Brodie, Knight, Metcalfe, Meyer, Padlipsky and Skinner) was commissioned to establish a 'polite conversation' between a Multics terminal and an MITDG terminal 🌸

It was agreed that messages would be what we call 'network ASCII messages': 7-bit ASCII characters right-adjusted in 8-bit fields having the most significant bit set, marking, and padding. Since Multics is currently set up for line-oriented half-duplex terminals, it was decided that all transmissions would end with the Multics EOL character (ASCII <LINE FEED>). To avoid duplicating much of the INCP in our experiment, the PDP-10 side of the connection was freed by convention from arbitrary bit-stream concatenation requirements, and it was allowed to associate logical message boundaries with network message boundaries (sic). The 'polite conversation' was thus established and successful 🎉

Multics then connected the conversation to its command processor, and the PDP-10 terminal suddenly became a Multics terminal. But, not quite 🙈

First, in the resulting MITDG-Multics connection there was no provision for a remote QUIT, which in Multics is not an ASCII character. This is a problem for Multics. It would seem that an ASCII character or the network's own interrupt control message could be given QUIT significance.

Second, our initial driver program didn't provide for RUBOUT. Because the Multics network input stream bypassed the typewriter device interface module (TTYDIM), line canonicalization was not performed. In a more elegant implementation, line canonicalization could be done at Multics, providing the type-in editing conventions familiar to Multics users. We fixed this problem hastily by having our driver program do local RUBOUT editing during line assembly, which provided type-in editing conventions familiar to MITDG users. It is clearly possible to do both local type-in editing and distant-host type-in editing 🧠

Third, we found that because of the way our type-in entered the Multics system under the current network interface (i.e. not through TTYDIM), our remotely controlled processes were classified 'non-interactive'. They fell to the bottom of Multics queues, giving us slow response 😩 This problem can be easily fixed, though.

The Harvard Connection 🌈

Connecting MITDG terminals to Multics proved to be easy, since the character-oriented MITDG system easily assembled lines for the Multics line-oriented system. We (Messrs. Barker, Metcalfe) decided, therefore, that it would be worthwhile to connect the MITDG system to another character-oriented system, namely Harvard's PDP-10. This move was also motivated by MITDG's desire to learn more about Harvard's new language system via MITDG's own consoles 👑

It was found that Harvard had already provided an ASCII network interface to their system, which accepted IMP-Teletype style messages as standard. We quickly rigged up an IMP-Teletype message handler at MITDG and were immediately compatible and connected. But not quite 💅

First, Harvard runs the Digital Equipment Corporation (DEC) time-sharing system on their PDP-10, which has <control-C> as a QUIT character and <control-Z> as an end-of-file (EOF). MITDG runs the MAC Incompatible Time-sharing System (ITS), which has <control-Z> as a QUIT character and <control-C> as an EOF. This control character mismatch is convenient in the sense that typing <control-C> while connected to the Harvard system through MITDG causes the right thing to happen. It causes the execution of programs at Harvard to QUIT, as opposed to causing the driver program at MITDG to QUIT. If, however, a Harvard program were to require that an EOF be typed, typing <control-Z> would cause ITS to stop the driver program in its tracks. That leaves the Harvard EOF wait unsatisfied and the MITDG-Harvard connection severed 💀

Second, the Harvard system has temporarily implemented this remote network console interface feature using a DEC style pseudo-teletype (PTY). This device, vis-a-vis the DEC system, behaves as a half-duplex terminal that wakes up on a set of 'break characters' (e.g., return, altmode), which gave us an opportunity for an interesting experiment 🧪 The use of DDT (Dynamic Debugging Tool) is thereby restricted (though not prevented), because break characters must be scattered throughout a DDT interaction to bring the PTY to life and get DDT to do the right thing. For example, to examine the contents of a core location, one needs to type addr<altmode> (address slash altmode), with the altmode being only a call-to-action to the PTY. To alter the contents of the opened location, one must then type <rub-out>contents<return>. The <rub-out> character deletes the previous action <alt-mode>, the contents are stashed in the open address, and the <return> signals the close of the address and PTY wake-up. It would seem that DDT is a program that will separate the men form the boys in networking 😤

Third, the response from the Harvard system at MITDG was seemingly as fast as could be expected from one of their own consoles. This fact is particularly exciting to those who don't have a feel for network transit times, when it is pointed out that such response was generated through two time-sharing systems, three user level processes, and three IMPs, all connected in series ⭐

The Harvard-MIT Graphics Experiment 🦋

At Harvard are a PDP-10 Time-sharing System and a graphics oriented PDP-1, both connected to Harvard's IMP. At MITDG are a PDP-6/10 Time-sharing System and an E&S Line Drawing System. It was felt (Messre. Barker, Cohen, McQuillan, Metcalfe, and Taft) that the time had come to demonstrate that the network could make remote resource available, giving Harvard access to the E&S at MITDG via the network 🌸 The protocol for this use of the network went as follows:

1. MITDG starts its network monitor program listening.
2. Harvard starts its PDP-10 transmitting a core image containing an arbitrary PDP-10 program (with an embedded E&S program in this case).
3. MITDG receives the core image from Harvard and places it in its memory at the starting address specified, collecting messages and concatenating them appropriately. (There was no word-length mismatch problem.)
4. Upon collecting a complete image (word count sent first along with starting address), MITDG stashes its own return address in a specified location of the transmitted program's image and transfers control to another image location.
5. Upon getting control at MITDG, the transmitted program executes (in this case sets up and runs an E&S program), and before returning to the MITDG network monitor, stashes in specified locations of its image the beginning and ending addresses of its result.
6. With control returned, the MITDG monitor program then transmits the results to a listening host, which makes good use of them (in this case a PDP-1, which displays them).
7. Then the MITDG program either terminates, returns control back to the image (as in this case), or waits for more data and/or program.

The protocol was implemented in the hosts and used to run a Harvard-assembled version of the E&S Aircraft Carrier Program (written originally by Harvard's Prof. Cohen) at MITDG, and to display the resulting dynamic display on Harvard's PDP-1 driven DEC scopes 🛩️ The Carrier Program was 'flown' from MITDG, and the changing views thus generated appeared both at MITDG and Harvard. The picture was observed to change (being transmission limited) on the order of twice each second (perhaps less often). But all was not rosey 🥀

First, it was observed that during the experiment, prompting messages to the IMP-Teletypes were often garbled. Most of the garbling can be attributed to the ASR-33 itself, but some cannot. There were no errors detected during data transmissions not involving the IMP-Teletypes.

Second, during attempts to fly the Carrier from Harvard, we stumbled across a yet undiagnosed intermittent malfunction of (presumably) the MITDG hardware and/or software. It caused our network connection to be totally shut down by the system during bi-directional transmission. This problem is currently under investigation 🔍

Third, the response of the total system was slow compared to what's required to do real-time dynamic graphics. One would expect that if this limitation is to be overcome, higher bandwidth transmission lines, faster host response to network messages, and/or perhaps a message priority system will be required 🚀

36-Bit Words Transmitted
From Harvard's PDP-10 to

General Comments 💅

Okay bestie, so back when we were making those 'network ASCII messages' 😩 we had to go absolutely above and beyond, inserting marking so our last data bit would land exactly on a word boundary. Surely there has to be a better way, right? ✨ The double padding scheme and its variants, with or without marking, should be considered. With the hardware we've got right now, double padding with marking would seem like a real upgrade 🎀. And a simple(?) fix to the host IMP interfaces, so they only send the good data from a partially filled last word, would open the door to an even better move: marking plus host-supplied single padding 🧚. The question mark is doing a lot of work there, ngl 🙈.

Now the message formats. Harvard went with the IMP-Teletype message convention, also called 'IMP ASCII messages' (without marking), because it let them use IMP-Teletypes for logging in and testing 💖. Multics went the other way and used the standard network message format (with marking) so they'd have Host-Host compatibility with the accepted protocols 🦋. Both approaches have merit, and honestly, we love that they both get a shoutout 🫶. Still, the IMP-Teletype message format should be changed to conform with the network standard. In other words, it should have marking 👑.

And finally, we'd love to announce that we're ready to join the next experiments 🚀. We want experiments that keep building our confidence and competence in networking, especially the ones that, like the earlier ones, give very large returns for a relatively small investment 💜. Iconic energy, fr fr ✨.

Roster of those participating 🌸

Ben Barker              Harvard, BBN
Grenville Bingham       MITDG
Howard Brodie           MITDG
Dan Cohen               Harvard
Tim Knight              MITDG, MIT/AI
John McQuillan          Harvard
Bob Metcalfe            MITDG, Harvard
Ed Meyer                Multics
Mike Padlipsky          Multics
Tom Skinner             Multics
Ed Taft                 Harvard

          [This RFC was put into machine readable form for entry]
          [into the online RFC archives by Lorrie Shiota, 10/01]