rfc101.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                  Richard W. Watson
Request for Comments: 101                                        SRI-ARC
NIC: 5762                                              February 23, 1971


              NOTES ON THE NETWORK WORKING GROUP MEETING

Wednesday Evening, February 17

   Mike Sher opened by welcoming the group to Urbana and briefly
   indicated that ILLIAC IV was expected to be running this summer.  The
   ILLIAC IV Project has been split into two projects; one on basic
   system hardware and software, and the other on applications.  Their
   IMP is not yet connected to their PDP-11.

   Steve Crocker asked for topics to be discussed at this meeting; these
   are indicated below.

   Peggy Karp of Mitre has been summarizing the old RFC's.  She has a
   list of about 30 topics and is summarizing their present status.  She
   expects to finish around the end of February.  See RFC #100,
   NIC(5761).  It was suggested that someone write an RFC indicating
   which ones are obsolete.  It was also suggested that the Network
   Information Center (NIC) help sites in organizing their hardcopy
   material.

   There then followed brief discussions of experiences in using the
   Network.  John Melvin (SRI-ARC) summarized SRI's experience in using
   the Utah PDP-10 to help in SRI's transfer from an XDS 940 to a PDP-
   10.  In April-May 1970 it was clear that SRI was headed toward a
   PDP-10 in order to have the capacity and reliability to fulfill their
   role as the Network Information Center.  They had had some previous
   experience in connecting with Utah, and so it seemed logical to try
   to use the Utah 10 to aid the transfer.

      In June use of the Network began.  SRI uses higher level languages
      extensively, so the first task was to transfer the compiler-
      compiler Tree Meta.  Source code was generated on the 940 to run
      on the PDP-10.  Binaries were then transmitted to Utah and run and
      debugged.  Patches were performed where possible, and source
      changes accumulated.  A new source and binaries would then be made
      periodically.









Watson                                                          [Page 1]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


      Once Tree Meta was running, a new high level language (called L-
      10) for programming the On-Line System (NLS) was implemented in
      the same way.  When L-10 was running the core device independent
      parts of NLS were rewritten and debugged.  NLS was completely
      reorganized during the transfer.

      At the SRI and Utah ends a control program allowing three users to
      connect to Utah was written, which ran as a user process and
      allowed character interaction and files to be transmitted.  The
      scheme worked well and much useful work was accomplished in the
      July--December period with some people on 4-5 hours per day.  The
      voice link was used when something would go wrong in trying to
      determine where the problem existed and to reset.  At times they
      would go 2 weeks with no problems.  SRI has an IMP interface
      diagnostic which ran as a T/S process.

      Generally, echoing was handled at the SRI end.  DDT was used at
      Utah end.  Round trip character delays of 4 seconds were not
      uncommon, and at certain points delays of 8 or 10 minutes were
      experienced.  These delays were the result of the implementation
      used which involved multiple processes at each end, each to be
      scheduled.  Utah was heavily loaded at 2:00 PM and the SRI people
      took to running at night and on weekends.

      When the SRI PDP-10 came in in December, use of the Network
      slowed.

      Users would have liked a more constant response time instead of
      the widely varying one so that their work habits could adapt to it
      even if it was slow.

   Gerry Cole reported on some results of measurements made during the
   SRI-Utah work.  Measurements were also made at SRI to help in
   interpreting the data obtained by UCLA.  Gerry wrote a paper
   summarizing these statistics which is available from him care of SDC.

      Gerry requested that when people are set up to use the Network,
      they inform him so that he can gather statistics.  UCLA will
      eventually have a program to scan the Network for utilization, but
      if people could tell him when they were going to use the Network,
      it would be easier to measure meaningful things and interpret the
      data from a knowledge of type of usage.

   Bob Kahn indicated that BBN is interested in the Statistics on
   overall flow to see if the Network is configured properly.  Gerry
   said that UCLA is interested in the statistics for Network modeling
   studies.  Measurements are taken by remote control by use of a
   feature designed into the IMP's by BBN for such a function.



Watson                                                          [Page 2]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


   Jim White of UCSB said that UCSB and RAND had begun to experiment in
   use of the Network for the climate study at RAND.  The UCSB NCP has
   been up the last 3 or 4 weeks during the day.  A document, NIC (5480)
   is available in the NIC collection describing it.  UCSB is also using
   their NCP for local interprocess communication experiments.  RAND is
   using the Remote Job Entry facility of the UCSB 360-75.  They are
   using UCSB to check out their NCP.  Now that UCSB is running their
   NCP during normal usage hours, they have uncovered some bugs in their
   hardware interface to their IMP.  The software at both UCSB and RAND
   seems to be working.  Typical jobs being sent back and forth are just
   test jobs of a few source statements.  The UCSB NCP is about 39K
   bytes and runs in a 60K byte partition.  Users access it through
   assembly language, Fortran or PL/I calls.

   Steve Crocker now returned to the discussion of the agenda for the
   meeting and longer range organization of the NWG.  Steve felt that
   Working committees on various topics were required as the open
   meeting was good for bringing up problems, general discussion and
   education, but was too large to prepare detailed specifications on
   various topics.

   The following topics requiring work were listed:

      1. Graphics

      2. Data Transformation Languages

      3. Host-Host Protocol -- long range study

      4. Host-Host Protocol -- Short term maintenance and modifications

      5. Accounting

      6. Logger Protocol

      7. Typewriter connection protocol

      8. Documentation

      9. Data Management

   In #1 Al Vezza of MIT is organizing an NWG meeting in graphics April
   25-27 which can accommodate 31 people.  People desiring to come
   should prepare for their institution a working paper.  Al sees three
   classes of problems:

      i)  two hosts, each with computing and graphics facilities,
      wanting to use special facilities at the other



Watson                                                          [Page 3]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


      ii)  one host with graphic facilities but no number crunching
      facilities wanting to use computing capabilities of a second host

      iii)  a node with a graphic terminal not having picture processing
      or computing capability desiring to obtain these from other nodes.

   With respect to #2 John Heafner of RAND indicated RAND wants to
   provide data rearrangement services of the type indicated in RFC #83,
   NIC (5621).  More on this topic below.

   With respect to #3 a group under A. N. Habermann of CMU has been
   formed to look at the Host-Host protocol.  Toward the end of March
   they are planning a paper discussing their ideas.  The group consists
   of:

      A. N. Habermann, CMU

      G. B. Hansen, CMU

      W. Wulf, CMU

      R. Chen, CMU

      R. Kalin, Lincoln Lab

      The group welcomes suggestions of topics.

   With respect to #4 a group is to be set up to evaluate present
   protocol and produce needed changes to the protocol.  The group is to
   be conservative and produce only changes needed to solve known
   problems and leave esthetic changes until later.

   With respect to the other problems discussion was put off until later
   (see below).

   Two people interested in the Network who were observers at the
   meeting spoke briefly.

      C. D. (Terry) Shepard of the Computer Communication Task Force,
      Canadian Government, outlined the goals of his group.  These goals
      are:

      1)  establish a plan to link up various Canadian computers and
      establish a network

      2)  develop what the needs of Canada are for such a network





Watson                                                          [Page 4]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


      3)  see that the benefits of such a network are distributed
      throughout Canada

      4)  prevent control of computing in Canada from being totally
      dependent on foreign sources.

      5)  see that critical computer facilities exist in Canada.

      Doug McKay of IBM then described briefly a network project started
      in IBM about 2 years ago.  Basic network is completed.  Users are
      coming on.  The network is to be used heavily to send files back
      and forth for program updating.  IBM is trying to look at the
      network as a multiprocessor machine.  They are trying to handle
      all IBM system possibly heterogeneous such as 360's, 370's, CP '
      67, the 91, a 44, and a NYU CDC 6600.

      There is another project linking TSS systems using a 91 for remote
      job entry.  IBM has taken a centralized control point of view
      using one central machine for control and flow distribution.  They
      are not entirely happy with this approach and are moving toward a
      more decentralized approach like the ARPA Network.  IBM presently
      has about 14 people involved in the project.

Thursday morning, February 18

   Thursday morning started with the various sites reporting their
   status.  Alex McKenzie of BBN prepared a status form later in the day
   which was filled out by the representatives of the sites Thursday
   evening.  BBN and NIC will prepare a procedure for keeping this
   information at the sites and up to date.

   STATUS

   BBN, TENEX PROJECT:  Final stage of incorporating NCP in TENEX.  A
   connection was attempted to Utah, but some bugs were found.  The NCP
   treats the network as a file in a way integral with other types of
   files.  The NCP includes a teletype interface.  They hope to
   incorporate the NCP in SRI'S TENEX system by the end of the month.

   BBN, NETWORK GROUP:  reported that they were working on three areas

      1. Improving the current network

      2. Working on a 316 version of the IMP and as a Terminal Interface
      Processor (TIMP)

      3. Accounting




Watson                                                          [Page 5]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


   There are currently 15 IMPs connected to the network.  A new software
   system with minor changes is expected by March.

   The TIMP uses the 316.  A hardware design exists, but they are still
   defining the software.  A TIMP can handle up to 64 variable speed
   terminals both sync and assync.  The first machine is to go to MITRE
   in September.

   BBN emphasized that there are 3 products:  a 516 IMP, a 316 IMP, and
   a 316 TIMP.  The 316 IMP is less expensive than the 516 IMP and can
   connect to one host.  BBN is not planning at the moment to exchange
   316 IMPs for 516 IMPs.  The two are plug-plug compatible.

   SDC:  In the debug phase for their NCP and expect it up in 4 to 6
   weeks.  Maybe by 8 weeks their T/S available for network use.  Their
   T/S is a 360/65 running the ADEPT system.

   CASE WESTERN RESERVE UNIVERSITY:  The IMP has been connected for
   about one month, but as yet have no NCP.  They are planning to use
   the NCP implemented at Harvard.  Case has a PDP-10/50 system.  They
   expect to be up in two to three months.

   HARVARD:  Harvard has a PDP-1 and PDP-10 connected to the IMP.  The
   NCP for the 10 is in final debugging.  The PDP-1 is for refreshing
   displays.  The PDP-10 is for linguistic research and students.
   Expect to be up in one to two months.

   SRI-ARC:  SRI has been in the final stage of conversion from an XDS
   940 to a PDP-10.  They plan to use the BBN TENEX NCP and should be up
   in three or four weeks.

   MIT DYNAMIC MODELING - PDP-10:  They expect an NCP to be working by
   March.

   MIT MULTICS:  They are connected to the IMP and expect their NCP to
   be in the final debug stage in four weeks.  As Multics is a service
   machine, they don't have unlimited access and must perform checkout
   at off hours.  They expect to offer regular service to the network in
   three or four months.

   UTAH:  PDP-10/50 probably going to be running TENEX in the fall.
   Their NCP is being written in a higher level language (Euler run
   interpretively) and are debugging in conjunction with BBN.  They have
   connected to and logged into themselves and expect a debugged version
   within a month.






Watson                                                          [Page 6]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


   LINCOLN LABORATORY, TX-2:  They are testing the IMP interface, found
   errors in Lincoln hardware.  Currently, no data errors, but have
   errors with message IDs.  They expect their NCP with logger to be up
   by April 15.  They indicated that for testing purposes, they would
   like to bring up their IMP without being open to network traffic.
   BBN says that there is a way to echo to yourself without being open
   to the network (contact BBN for details).

   LINCOLN LABORATORY, 360/97:  Running CP/CMS.  The IMP interface was
   completed last month.  The NCP and Logger are working.  They are
   planning to put up the NCP as a regular service in April.  On request
   experiments with them can be run sooner.

   UCSB:  Has had their NCP since October.  The NCP runs as independent
   batch job.  They plan to provide service to their On-Line System (a
   manual is in the NIC collection at each site NIC (5480).  They plan
   to be on the air morning to evening on a regular basis.  There are
   some interface bugs as indicated earlier.

   RAND:  360/65.  Their NCP is a user process and can be resident.  It
   requires 8K bytes and does not have a logger.

   UCLA, Sigma-7:  Their NCP is in final debugging.  They expect to be
   up by March 1 with NCP, logger, and typewriter connection program.

   COMPUTER CORPORATION OF AMERICA (CCA):  Has just started a project to
   create a node for the 10-12 bit laser store.  They are going to use a
   PDP-10 as a front end.  They are developing a language for data
   manipulation.  The store will also be connected to the B-6500-ILLIAC
   IV.  They are planning data compression as part of their language to
   ease the problems in use of the network's 50 kilobit line.  They are
   concentrating on security and privacy measures.  Initial emphasis
   will be on shared files.  Installation is planned during 1972.

   The following projects did not have representatives at the meeting.
   Steve Crocker reported on their status.

      CMU:  PDP-10/50:  Their IMP is connected, and they are planning to
      use the Harvard NCP.

      SRI-AI PROJECT:  PDP10.  They are planning to run TENEX in the
      fall.

      STANFORD-AI:  They are not connected yet, but expect to be on by
      summer.






Watson                                                          [Page 7]