doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc89.txt b/doc/rfc/rfc89.txt
new file mode 100644
index 0000000..ecd5aa2
--- /dev/null
+++ b/doc/rfc/rfc89.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        B. Metcalff
+Request for Comments: 89                                           MITDG
+NIC: 5697                                                19 January 1971
+
+
+                  SOME HISTORIC MOMENTS IN NETWORKING
+
+   While awaiting the completion of an interim network control program
+   (INCP) for the MIT MAC Dynamic Modeling/Computer Graphics PDP-6/10
+   System (MITDG), we were able to achieve a number of 'historic moments
+   in networking' worthy of some comment.  First, we were able to
+   connect an MITDG terminal to a Multics process making it a Multics
+   terminal.  Second, we successfully attached an MITDG terminal to the
+   Harvard PDP-10 System thereby enabling automatic remote use of the
+   Harvard System for MIT.  Third, we developed primitive mechanisms
+   through which remotely generated programs and data could be
+   transmitted to our system, executed, and returned.  Using these
+   mechanisms in close cooperation with Harvard, we received graphics
+   programs and 3D data from Harvard's PDP-10, processed them repeatedly
+   using our Evans & Sutherland Line Drawing System (the E&S), and
+   transmitted 2D scope data to Harvard's PDP-1 for display.
+
+The IINCP
+
+   Our experiments were run on the MITDG PDP-6/10 using what we have
+   affectionately called our 'interim interim NCP' (IINCP).  Under the
+   IINCP the IMP Interface is treated as a single-user I/O device which
+   deals in raw network messages.  The software supporting necessary
+   system calls includes little more than the basic interrupt-handling
+   and buffering schemes to be used later by the NCP.  In short, the
+   user-level programs which brought us to our historic moments were
+   written close to the hardware with full knowledge of IMP-HOST
+   Protocol (BBN 1822).  When the INCP and NCP are completed, these
+   programs can be pruned considerably (80%).  The exercise of writing
+   programs which conform to IMP-HOST Protocol was not at all wasted.
+   Only now can those of us who are not writing the NCP begin to grasp
+   the full meaning of RFNM's and their use 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.
+
+The Multics Connection
+
+   Our quest for historic moments began with the need to demonstrate
+   that the complex hardware-software system separating MITDG and
+   Multics was operative and understood.  A task force (Messrs. Bingham,
+
+
+
+
+
+Metcalff                                                        [Page 1]
+
+RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971
+
+
+   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.  In that
+   Multics is presently predisposed toward 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 was permitted 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 did not 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, thus
+   providing 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 manner in which 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' and thus fell to the bottom of Multics
+   queues giving us slow response.  This problem can be easily fixed.
+
+The Harvard Connection
+
+   Connecting MITDG terminals to Multics proved to be easy in that the
+   character-oriented MITDG system easily assembled lines for the
+   Multics line-oriented system.  We (Messrs. Barker, Metcalfe) decided,
+
+
+
+Metcalff                                                        [Page 2]
+
+RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971
+
+
+   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 Harvard system through MITDG causes the right thing to
+   happen - 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,
+   leaving 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 which wakes up on a set of 'break characters' (e.g., return,
+   altmode) affording us an opportunity for an interesting experiment.
+   The use of DDT (Dynamic Debugging Tool) is thereby restricted (though
+   not prevented) in that break characters must be scattered throughout
+   a DDT interaction to bring the PTY to life to cause 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) 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, it was found that 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.
+
+
+
+
+Metcalff                                                        [Page 3]
+
+RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971
+
+
+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 - to give Harvard access to the E&S at MITDG via the
+   network.  The protocol for such use of the network was 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, 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 which caused our network connection to
+   be totally shut down by the system during bi-directional
+   transmission.  This problem is currently under investigation.
+
+
+
+
+
+Metcalff                                                        [Page 4]
+
+RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971
+
+
+   Third, the response of the total system was slow compared to that
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Metcalff                                                        [Page 5]
+
+RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971
+
+
+36-Bit Words Transmitted
+From Harvard's PDP-10 to
+MITDG's PDP-10
+                     +---------------+---------------+ Image control
+                     |     -count    |    origin-1   | word.
+                     +---------------+---------------|-
+        Image:       |    start address of results   | | Filled in by
+                     +-------------------------------+  -Harvard's
+        Image+1:     |     end address of results    | | program during
+                     +-------------------------------+-  its execution.
+        Image+2:     |   ---------unused-----------  |  +--        -+
+                     +-------------------------------+  |Filled in  |
+        Image+3:     |      program stop address     |<-|by MITDG   |
+                     +-------------------------------+  |for return |
+        Image+4:     |     program start address     |  |of control.|
+                     +-------------------------------+  +--       --+
+        Image+5:     |                               |
+                     +-------------------------------+
+Image control word   |                               |
+and image arrive in  |                               |
+network size buffers |                               |
+which are stripped of|                               |
+marking and padding  |                               |
+and concatenated.    |                               |
+                     +-------------------------------+
+
+
+36-Bit Words Transmitted
+From MITDG's PDP-10 to
+Harvard's PDP-1
+                      +---------------+---------------+
+                      |               |    count      |
+                      +---------------+---------------+
+First word of results |                               |
+Specified in Image+0. |                               |
+                      |      results                  |
+                      |                               |
+                      |                               |
+                      |                               |
+                      |                               |
+                      |                               |
+                      |                               |
+Last word of results  |                               |
+specified in Image+1. |                               |
+                      +-------------------------------+
+
+
+
+
+
+
+Metcalff                                                        [Page 6]
+
+RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971
+
+
+General Comments
+
+   In producing 'network ASCII messages' we were required to bend over
+   backwards to insert marking so that our last data bit could fall on a
+   word boundary.  Surely there must be a better way.  The double
+   padding scheme and its variants with or without marking should be
+   considered.  Given the current hardware, it would seem that double
+   padding with marking would be an improvement.  A simple(?) fix to
+   host IMP interfaces enabling them to send only good data from a
+   partially filled last word would permit a further improvement:
+   marking and host-supplied single padding.
+
+   In these initial experiments Harvard used the IMP-Teletype message
+   convention or what are call 'IMP ASCII messages' (without marking)
+   because it would allow them to use IMP-Teletypes for logging in and
+   testing.  Multics, on the other hand, used the standard network
+   message format (with marking) to have Host-Host compatibility as per
+   accepted protocols.  Both approaches have merit.  The IMP-Teletype
+   message format should be changed to conform with the network standard
+   - it should have marking.
+
+   Finally, we would like to announce our readiness to participate in
+   experiments which will further extend our confidence and competence
+   in networking, especially experiments which, like the preceding, will
+   have very large returns with relatively small investment.
+
+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]
+
+
+
+
+
+
+
+
+Metcalff                                                        [Page 7]
+