home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 00s / rfc37.txt < prev    next >
Text File  |  1997-03-12  |  9KB  |  272 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        S. Crocker
  8. Request for Comments: 37                                           UCLA
  9.                                                           20 March 1970
  10.  
  11.                      Network Meeting Epilogue, etc.
  12.  
  13. The Meeting
  14. -----------
  15.  
  16.   On Tuesday, March 17, 1970, I hosted a Network meeting at UCLA.
  17.   About 25 people attended, including representatives from MIT, LL,
  18.   BBN, Harvard, SRI, Utah, UCSB, SDC, RAND and UCLA.  I presented a
  19.   modification of the protocol in NWG/RFC #33; the modifications are
  20.   sketchily documented in NWG/RFC #36.  The main modification is the
  21.   facility for dynamic reconnection.
  22.  
  23.   The protocol based on sockets and undistinguished simplex
  24.   connections is quite different from the previous protocol as
  25.   documented in NWG/RFC #11.  The impetus for making such changes came
  26.   out of the network meeting on December 8, 1969, at Utah, at which
  27.   time the limitations of a log-in requirement and the inability to
  28.   connect arbitrary processes was seriously challenged.  Accordingly,
  29.   the primary reason for the recent meeting was to sample opinion on
  30.   the new protocol.
  31.  
  32.   Recollections may vary, but it is my opinion that the protocol was
  33.   widely accepted and that the criticism and discussion fell into two
  34.   categories:
  35.  
  36.   1.  Questioning the complexity and usefulness of the full protocol,
  37.       especially the need for dynamic reconnection.
  38.  
  39.   2.  Other topics, particularly character set translation, higher
  40.       level languages, incompatible equipment, etc.
  41.  
  42.   Notably lacking was any criticism of the basic concepts of sockets
  43.   and connections.  (Some have since surfaced.)  The following
  44.   agreements were made:
  45.  
  46.   1.  By April 30, I would be responsible for publishing an
  47.       implementable specification along lines presented.
  48.  
  49.   2.  Any interested party would communicate with me (at least)
  50.       immediately if he wished to modify the protocol.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. RFC 37             Network Meeting Epilogue, etc.         20 March 1970
  61.  
  62.   3.  If major modifications come under consideration, interested
  63.       parties would meet again.  This would happen in two to three
  64.       weeks.
  65.  
  66.   4.  Jim Forgie of Lincoln Labs tentatively agreed to host a meeting
  67.       on higher level network languages, probably near Spring Joint
  68.       time.
  69.  
  70. Mailing List Changes
  71. --------------------
  72.  
  73.   Paul Rovner of LL is replaced by
  74.  
  75.                    James Forgie
  76.                    Mass. Institute of Technology
  77.                    Lincoln Laboratory C158
  78.                    P.O. Box 73
  79.                    Lexington, Mass. 02173
  80.  
  81.                    telephone at (617) 862-5500 ext. 7173
  82.  
  83.   Professor George MEaly is added
  84.  
  85.                    George Mealy
  86.                    Rm. 220
  87.                    Aitken Computation Lab.
  88.                    Harvard University
  89.                    Cambridge, Massachusetts 02138
  90.  
  91.                    telephone at (617) 868-1020 ext. 4355
  92.  
  93. Process
  94. -------
  95.  
  96.   In all of our writing we have used the term process, to mean a
  97.   program which has an assigned location counter and an address space.
  98.   A program is merely a pattern of bits stored in some file.  A new
  99.   process is created only by an already existing process.  The
  100.   previous process must execute an atomic operation (forc, attach,
  101.   etc.) to cause such a creation.  Processes may either cause their
  102.   own demise or be terminated by another (usually superior) process.
  103.  
  104.   The above definition corresponds to the definition given by
  105.   Vyssotsky, et al on pp.  206, 207 of "Structure of the Multics
  106.   Supervisor" in the FJCC proceedings, 1965.
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113. RFC 37             Network Meeting Epilogue, etc.         20 March 1970
  114.  
  115.   Because a process may create another process, and because in general
  116.   the two processes are indistinguishable when viewed externally, I
  117.   know of no reasonable way for two processes to request connection
  118.   directly with each other.  The function of sockets is to provide a
  119.   standard interface between processes.
  120.  
  121. The Days After
  122. --------------
  123.  
  124.   In the time since the meeting I have had conversations with Steve
  125.   Wolfe (UCLA-CCN), Bill Crowther (BBN), and John Heafner and Erick
  126.   Harslem (RAND).  Wolf's comments will appear as NWG/RFC #38 and fall
  127.   into a class I will comment on below.
  128.  
  129.   Crowther submitted the following:
  130.  
  131.   "A brief description of two ideas for simplifying the host protocol
  132.   described at the March meeting.  These ideas have not been carefully
  133.   worked out.
  134.  
  135.   Idea 1. To Reconnect.
  136.   --------------------
  137.  
  138.   "A NCP wanting to Reconnect tells each of his neighbors "I want to
  139.   reconnect".  They wait until there are no messages in transit and
  140.   respond "OK".  He then says "Reconnect as follows" and they do it.
  141.   In the Rare condition, the NCP gets back an "I want to reconnect
  142.   instead of an "OK", then one must go and one must stop.  So treat a
  143.   "reconnect" from a higher Host user etc. as an ok and from a lower
  144.   as a "No-wait until I reconnect you" and do the connection.
  145.  
  146.   Idea 2
  147.   ------
  148.  
  149.   "Decouple connections and links.  Still establish connections, but
  150.   use any handy link for the messages.  Don't send another message on
  151.   a connection until a FRNM comes back.  Include source and
  152.   destination socket numbers in the packet.
  153.  
  154.   "To reconnect, say to each of neighbors "please reconnect me as
  155.   follows...".  Hold onto the connect for a short time (seconds) and
  156.   send both packets and connection messages along toward their
  157.   destinations.  I haven't worked out how to keep the in-transit
  158.   messages in order, but probably everything works if you don't send
  159.   out a reconnect when RFNM's are pending."
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166. RFC 37             Network Meeting Epilogue, etc.         20 March 1970
  167.  
  168.   Bill's first idea does not seem to me to be either decisively better
  169.   or (after some thought) very different, and I am considering it.  I
  170.   have no strong feelings about it yet, but I am trying to develop
  171.   some.
  172.  
  173.   Bill's second idea seems contrary to my conception of the role of
  174.   links.  An argument in favor of decoupling connections and links
  175.   that the number of connections between two hosts might want to
  176.   exceed 255, and that even if not, it is sounder practice to isolate
  177.   dependancies in design.  On the other hand, the newly provided Cease
  178.   on Link facility* (page 22 of the soon to be released BBN report
  179.   #1822 revised Febuary 1970) becomes useless.  (Bill, who just put
  180.   the feature in, doesn't care.)  Another objection is that it seems
  181.   intuitively bad to waste the possibility of using the link field to
  182.   carry information.  (Note the conflict of gut level feelings).
  183.  
  184.   In a conversation with John Haefner and Eric Harslem of RAND, the
  185.   pointed out that the current protocol makes no provision for error
  186.   detection and reporting, status testing and reporting, and expansion
  187.   and experimentation.  Error detection and status testing will
  188.   require some extended discussion to see what is useful, and I expect
  189.   that such discussion will take place while implementation proceeds.
  190.   Leaving room for protocol expansion and experimentation, however, is
  191.   best done now.
  192.  
  193.   I suggest that two areas for expansion be reserved.  One is that
  194.   only a fraction of the 256 links be used, say the first 32.  The
  195.   other area is to use command codes from 255 downward, with permanent
  196.   codes assigned from the number of links in use to 32, I feel that it
  197.   is quite unlikely that we would need more than 32 for quite some
  198.   time, and moreover, the network probably wouldn't handle traffic
  199.   implied by heavy link assignment.  (These two things aren't
  200.   necessarily strongly coupled:  one can have many links assigned but
  201.   only a few carrying traffic at any given time.)
  202.  
  203.   Some of Heafner's and Harslen's other ideas may appear in NWG/RFC
  204.   form.
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.                                                                 [Page 4]
  218.  
  219. RFC 37             Network Meeting Epilogue, etc.         20 March 1970
  220.  
  221.   Immediate Interaction
  222.   ---------------------
  223.  
  224.   During the next several days, I will still be interested in those
  225.   editicisms of current protocol which might lead to rejection or
  226.   serious modification of it.  Thereafter, the focus will be a
  227.   refinement, implementation, extension, and utilization.  I may be
  228.   reached at UCLA through my secretary Mrs. Benita Kristel at (213)
  229.   825-2368.  Also, everyone is invited to contribuet to the NWG/RFC
  230.   series.  Unique numbers are assigned by Benita.
  231.  
  232.   * The Cease on Link facility is a way a receiving host modifies
  233.     RFNM's so as to carry a flow-quenching meaning.  An alternative
  234.     proceedure is to use a host-to-host control command.
  235.  
  236.        [ This RFC was put into machine readable form for entry ]
  237.         [ into the online RFC archives by Ron Fitzherbert 1/97 ]
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.                                                                 [Page 5]
  271.  
  272.