J. Postel
IEN 175                                                              ISI
                                                           13 March 1981



            Internet Meeting Notes -- 28-29-30 January 1981




I.  WELCOME

   The meeting was held at USC Information Sciences Institute.  The host
   was Jon Postel.  Jon opened the meeting and gave the usual
   explanations about the arrangements.

   Vint Cerf extended the welcome and called special attention to the
   participation of representatives from CSNET, Canada, and Germany.

II.  OBJECTIVES

   Vint Cerf described the main objective of the meeting to be to put
   issues on the table.  Problems could be resolved by subsequent
   arrangements between ARPA and the contractors.  In particular, the
   topics of performance, addressing, and documentation are of special
   interest.

III.  STATUS REPORTS

   A.  UCLA

      Charley Kline gave a report on the activities at UCLA.  Bob Braden
      from the UCLA Computer Center is on a one year visit to UCL.
      Charley is involved in a research project in the Computer Science
      Department.  This report is about the work Charley is involved in.
      UCLA is building a system called LOCUS.  It is based on Unix and a
      ring network.  The ringnet hardware is the LNI developed by UCI
      and modified by MIT.  A UCLA developed private protocol is used on
      the ring.  The current work is on the distributed operating
      system.  The goal is for the users of the system and for remote
      hosts to see the collection of hosts and the ring net as one
      system.  The most recent effort is on file system aspects.  Very
      good results have been obtained yielding essentially equal access
      times for local and remote files.

   B.  UCL

      Peter Kirstein gave most of the presentation with some help from
      Ron Jones.  Peter noted that with Bob Braden visiting at UCL use
      of the UCLA 3033 from London has increased and the service is


Postel                                                          [Page 1]


                                                                 IEN 175
Internet Meeting Notes



      quite good.  However, he has observed random outages of line 77
      lasting 5 to 15 minutes several times per week.  Bob has installed
      echo servers both at the TCP and IP levels at UCLA for use with
      UCL measurements and tests.  Peter described UCL's work on:  (1) a
      protocol converter for service between SATNET and SRCNET for
      terminal access, SRCNET is an X.25 network; (2) a cambridge ring
      at UCL where terminal access is now working via UMCZ80 interfaces;
      (3) a local message system is up on the UCL Unix using the MMDF
      system developed by Dave Crocker; (4) the NIFTP will be upgraded
      to match the latest document; and (5) UCL has worked over the TIU
      TCP and made some parameter changes and installed a dynamic
      retransmission timeout procedure, also MOS was revised, and a
      document is available on this.

   C.  RSRE

      John Laws gave the RSRE report.

      Gateway Status:  The line between the UCL gateway and the RSRE
      gateway, known as net 35, was upgraded from 4.8Kb/s to 9.6Kb/s in
      November 1980.  The gateway machine is still an LSI-11.   Local
      performance measurements on the gateway were instrumented by
      writing a process timer for the MOS system which showed how long
      and how often individual processes ran for and the total time
      spent idling in the scheduler.  These measurements showed that the
      gateway did handle 50Kb/s lines and would give the expected
      throughput on these lines for large data packets ( >128 user data
      bytes).  The switching capability was 50 packets per second using
      the RSRE line cards.  The time taken to switch packets from one
      interface to another was 4.8msecs.  This includes use of hashing
      tables to determine the route of the packets.  Although
      fragmentation has been implemented and tested as reported at the
      last meeting no use has yet been made of this facility.  Source
      routing code awaits a final imprimatur of the doctrine to be
      employed.

      Service Availability:  A comparison between ARPANET availability
      from the PPSN for one month periods before the last meeting and
      this meeting show that although the outages total a similar total
      time the ones for the Nov-Dec 80 period are mostly due to
      developments in the UCL gateway rather than to SATNET as was the
      case for the Aug-Sep 80 period.  Two points are worth noting: (1)
      Some of the longer outages were due to debuging sessions on the
      UCL gateway.  These are difficult because they require personnel
      at RSRE, UCL and BBN to be available simultaneously.  They often
      require loading software at the RSRE gateway for the tests and
      reloading software after the tests.  (2) The large number of short
      outages were traced to resetting of the Host-SIMP interface by the


Postel                                                          [Page 2]


                                                                 IEN 175
Internet Meeting Notes



      UCL gateway caused by shortage of buffers.  Ginny alleviated this
      to a large extent in January by removing code from the gateway.
      However if UCL and RSRE are heavily using the gateway we can still
      get up to 20 resets a day.

      Local Network Status:  The PPSN (net 25) now has three network
      access protocols available to users, these are datagram type (with
      multi-address), virtual call (PPSN type with multi-address), and
      X.25 virtual call.  We have developed a flexible evaluation host
      both for use on the PPSN and the British Post Office PSS network
      which we hope to be connected to in February.  This evaluation
      host supports 2 DTEs and includes a command console for setting up
      multiple calls from one terminal, traffic generators, and a
      measurement package.  The protocols employed are the Network
      Independent Transport Service (NITS) [formerly "Yellow Book"], and
      X.25 level 3 with BPO options and the RSRE X.25 level 2 line
      units.

      TCP and IP:  The CORAL implementation of IP with fragmentation and
      reassembly is complete.  The design for the CORAL TCP including
      full state machine representation is complete and coding is in
      progress.  We have obviously gained a lot of useful experience for
      this from using the Mathis TCP.  Besides TCP measurements we now
      have the capability to perform measurements of IP using echoers on
      ISIE and EDN Unix as well as GGP echo packets.  The IP
      measurements package has the capability to make single round trip
      measurements at a user settable protocol type, packet length, and
      packet rate of 1 to 50 packets per second.

      Action Items from RSRE:

         1.  Dynamic timeouts for retransmission.

         2.  Flag bit for copied options in IP fragments.

         3.  Specification for strict source routing.

         4.  Standard addresses for Echo, Discard, and
             Character Generator servers.

         5.  Techniques for preventing silly window syndrome
             (name due to Dave Clark).

         6.  No changes to addressing for a while.






Postel                                                          [Page 3]


                                                                 IEN 175
Internet Meeting Notes



   D.  SRI

      Holly Nelson reported that the TIU with fragmentation and
      reassembly is in progress, that a new version of the port expander
      program was delivered, that a measurement host being installed is
      version 7 Unix with IP separate from TCP, and that Ron Kunzelman
      will be leaving SRI in mid February.

   E.  NDRE

      Yngvar Lundh reported that progress at NDRE continues to be
      hampered by the lack of people.  In spite of this, progress is
      being made and speech now runs in the local net.  Paal Spilling
      has returned to NDRE after a one year visit to SRI.  Paal will be
      trying speech experiments with Lincoln.

      The agreement with the Norwegian Telecommunications Authority is
      being renegotiated for 2-3 years.  NDRE has had discussions with
      the German group.

      Action Items from NDRE:

         1.  A HDLC port on the SATNET gateway is needed.

         2.  ARPANET availability must be improved.

   F.  MITRE

      Anita Skelton discussed the development by MITRE of a Z8000 based
      TCP.  The program is written in C and cross compiled on Unix.  The
      system is a modified C MOS.  The TCP is about 600 lines of C code.
      This TCP has been tested talking to itself, but not against any
      other TCP.  The data rate measured is 350 Kb/sec.  Later in the
      meeting Steve Holmgren gave a presentation on this.

   G.  MIT

      Dave Clark described developments at MIT.  Planning for a computer
      network architecture at MIT is being formulated in terms of a
      system involving 52 buildings and 10,000 hosts.  As Dave noted, he
      reported again that the version 2 ring net (10 Mb/s) is almost
      working.  The development is a joint project with PROTEON.  Some
      interfaces are prototyped in multiwire.  The use of IP and TFTP
      based services is spreading.  A Unix on the CHAOS net uses IP to
      communicate with a Unix on the Ring net.  Fragmentation and
      Reassembly is used widely in the MIT environment.  MIT did its own
      reworking of MOS -- this time to make it easy to bind with
      programs from other source languages.


Postel                                                          [Page 4]


                                                                 IEN 175
Internet Meeting Notes



      On the multics front Dave reports that IP/TCP was used over a HASP
      connection on a 9.6 Kb/s line between Cambridge and Phoenix with a
      round trip time of 8 seconds.  Various investigations suggest
      hosts should be careful about also being gateways, for example,
      the gateway echo traffic could be more than the host could handle.
      In one experiment a routing loop was detected and datagrams would
      have looped forever except for Multics decrementing the time to
      live.  Multics is being connected to TYMNET and TELENET, initially
      as a server for remote terminal access.  A NIFTP server is being
      developed, and a MTP server is up on both NCP and TCP for RFC 772
      style mail.

      The TOPS20 system, MIT-XX, still has trouble with the IP
      implementation crashing the system, and the performance is poor
      otherwise.

      Dave put together a minimal IP/TCP/Telnet in BCPL for an Alto.
      The total package is about 3000 words of code.

      The Swallow Distributed Computing Project is basing its
      communication primitives on IP/UDP.  A C-30 IMP is scheduled for
      delivery to MIT in early February.

      Action Items from MIT:

         1.  A maximum segment size TCP option is needed.

   H.  Lincoln Laboratory

      Jim Forgie described the work Lincoln has done on the Voice
      Terminal (VT) and the ST Gateway.  Several VTs now exist and are
      functioning on the LEXNET.  Two modes of speech data are supported
      64Kb/s PCM and 2.4Kb/s LPC.  A ST gateway is partially implemented
      in an 11/45 running EPOS and experiments are being done via the
      ARPANET with ISI.  The gateway currently supports only the
      point-to-point ports of the ST protocol (no conference support
      yet).  The measured gateway throughput is about 100
      packets/second.  The next few milestones on the Lincoln schedule
      are:

         1.  Move the gateway from the 11/45 to the 11/44.

         2.  Demo speech over the WBCNET.

         3.  Deliver a LEXNET and VTs to ISI.

         4.  Add source routing to ST and the gateway.



Postel                                                          [Page 5]


                                                                 IEN 175
Internet Meeting Notes



         5.  Add conferencing features.

   I.  Linkabit

      Estil Hoversten discussed Linkabit's role in the support for
      SATNET and WBCNET.  Linkabit provides clever modems to make the
      most of the channel.  Estil pointed out that when Germany and
      Italy join the SATNET the channel will be more shared and less
      capacity will be available to existing communication partners.
      For the WBCNET Estil reviewed the state of installation.  All the
      equipment is in place at ISI and LL, but the RF and power
      equipment needs tuning up.  The DCEC and SRI equipment should be
      fully in place before the next IN MTG.  Something called "Remote
      Control and Alarming" is needed to make the operation legal.  The
      FCC requires that an operator (FCC licensed) be able to control
      the transmitter (shut it off) if something goes wrong.  Western
      Union is installing the remote control mechanism so their operator
      in New Jersey can satisfy this requirement.

      Estil also mentioned that Linkabit has some communication between
      two sites in San Diego several miles apart to support terminal
      access for terminals at one site to TOPS20s at the other site.
      They use dumb multiplexors and a 45 Mb/s microwave link.  Also
      Linkabit is part of M/A-COM which is planning to link its four
      major sites via a satellite channel in the 800 Kb/s to Mb/s range.

   J.  ISI

      Jon Postel reported on the activities at ISI.  The Internet
      Project has three areas of interest:  Protocol Verification,
      Protocol Design, and Protocol Applications.  In the verification
      area Carl Sunshine made a presentation later in the meeting.  In
      the design area Danny Cohen has led our efforts primarily in
      discussion of addressing issues (see IEN 165).  In the application
      area we are developing two computer mail applications:  the MPM
      and the MTP.  The MPM is a multimedia mail delivery system
      following the specification of RFC 759.  This is now working on
      TOPS20, and was demonstrated at the end of the meeting.  The MTP
      is a text only mail server for multinetwork operation and follows
      the specification of RFC 772.  This is partially implemented on
      TOPS20.  It can now accept mail via TCP connections and leave it
      for distribution via mailer and NCP connections.  MTP was
      demonstrated at the end of the meeting.  Another program was
      developed to better understand using TCP and can be used as a user
      Telnet.  This program is called TT.  A description was distributed
      at the meeting and TT was demonstrated at the end of the meeting.

      Other work at ISI included the development and installation of


Postel                                                          [Page 6]


                                                                 IEN 175
Internet Meeting Notes



      code in the TOPS20s to guard against sending the 9th outstanding
      message to the same destination in the ARPANET and thus be blocked
      by the IMP.  This has been installed in the five TOPS20s at ISI.
      The PDP-11 which is the front end for the Penguin printer has been
      modified to also route internet datagrams to other hosts on the
      ARPANET or the local Ethernet.  The WBC project has participated
      with Lincoln in the Speech experiments reported on by Lincoln.
      Also the WBC project has interfaced a radio clock to the speech
      host so that the operating system (EPOS) gets the time from the
      radio clock.

   K.  DoD

      Ray McFarland mentioned that questions are being raised about the
      Internet Addressing and its implications for Network
      Architectures, and on the relationship between Internet
      Architectures and Distributed Processing Systems.  Later in the
      meeting Ken Shotting discussed his work on specification of IP.

   L.  DCEC

      Ed Cain gave the report on DCEC activities.  The hosts in the EDN
      now do reassembly.  There are two gateway programs.  The old
      gateway does fragmentation, talks GGP, and sends in CMCC reports.
      The new gateway performs well.  There was some confusion about GGP
      routing messages.

      It seems that a type 11 message was used in the BBN-built gateways
      to avoid confusing a new routing message format with the one
      documented in IEN 109 (How to Build a Gateway). The DCEC gateway
      used the type 11 message in order to exchange routing information
      with its neighbors. However, since the agreed-upon resolution is
      to modify IEN 109 to show the new format, the BBN-built gateways
      have been gradually reverting back to the new-format type 1
      message.  During the transition, the DCEC gateway has kept track
      of which gateways use the two routing types, and serves as a
      routing "bridge" between the two communities.  The right type code
      for routing messages is Type 1, and no Type 11 messages should be
      used anymore.

      DCEC also implements the security and precedence features of IP.
      A TIU for AUTODIN II is being developed by DCEC, and an
      implementation of MTP is in progress.  DCEC coordinated a seminar
      on IP and TCP at NBS in November which 405 people attended.






Postel                                                          [Page 7]


                                                                 IEN 175
Internet Meeting Notes



      Action Items from DCEC:

         1.  How do we provide testing facilities to companies that
         develop TCP products?

         2.  How do we control transit traffic?

   M.  COMSAT

      Dave Mills gave a brief review of the configuration at COMSAT.
      The most important new development is the idea of virtual hosts
      which are processes with internet address and move from one real
      host to another within the DCNET.  Another idea being developed is
      the maintenance of synchronized clocks in the hosts of the DCNET.
      This is done with time stamps in routing update messages between
      the hosts.  Dave reported some interesting results about clocks
      and time variations that came to light in this work (see IEN 173).
      Also at COMSAT a MTP mail server is working.  The FAX program now
      handles multipage documents.  NIFTP works between COMSAT and ISIE
      -- 5 million bytes of RFCs and IENs were transferred.  The
      INTELPOST project conversion to IP/TCP continues.  A copy of the
      DCNET software has been installed at FORD research center at
      Dearborn with a 1200 baud dial up connection between Dearborn and
      Washington.

   N.  BBN

      Jack Haverty reported on the development of three new TCPs: for
      the TAC, the HP3000, and the VAX Unix.  In the TAC, the TCP
      connection opening and closing has been completed, and work
      continues on the data handling code.  In the HP3000 version the
      TCP is done and work is in progress on Telnet while waiting for a
      hardware interface.  The VAX Unix (and C70) version is passing
      packets but work on TCP continues.  The work on the VAN gateway
      (ARPANET/TELENET) continues; testing of X.25 level 3 is being done
      with an Applied Data Communications Pro/Tester.  The TIP Login
      design is just about done; it is being designed as a special case
      of resource allocation.  BBN is modifying CMOS for use in the C50
      environment.  The CMCC data has shown some anomalous behavior.
      For example short periods (5-10 minutes) with a high percentage of
      dropped datagrams and at the same time NCC data showing very busy
      IMP's.  Hard to track this down -- better fault isolation tools
      are needed.

      Ginny Strazisar reported on the developments in the BBN-built
      gateways.  A new version of the gateway code was distributed to
      all sites (except Ft. Bragg) which will do fragmentation (but not
      with options).  The gateway at UCL was modified to only use small


Postel                                                          [Page 8]


                                                                 IEN 175
Internet Meeting Notes



      (SATNET size) buffers and remove local operator support to improve
      performance.  The fragmentation routine will send on fragments as
      large as the network can handle.  Work is in progress to change to
      a routing procedure which detects partitioned networks.

      Dale McNeill reported on SATNET.  After several months of poor
      performance, on November 6 there was a significant decrease in
      packets received with checksum errors on the SATNET channel.
      Performance is consistent with a change in the BER from about
      10**-4 to about 10**-6. No information on the potential cause has
      been given by INTELSAT.  In any case, SATNET channel protocol
      stability and the ARPANET direct connection via SATNET performance
      (ARPANET line 77 to the London TIP) are much improved.  The
      US-Norway ARPANET satellite circuit (ARPANET line 41 between the
      SDAC IMP and the NORSAR TIP), which was changed last spring from
      commercially-controlled to military-controlled, continues to
      provide poor service.  This line is composed of a military
      satellite hop and a number of commercial circuits.  Hence, NDRE
      gateway to UCL gateway traffic is still disallowed in the Tanum
      Satellite IMP, thereby breaking internetwork traffic between the
      two gateway sites.  A bug in the Host-SATNET protocol was found,
      and a fix was installed in the Satellite IMPs.  The same fix needs
      to be inserted in the gateway to provide complete protection in
      the protocol.  A major milestone was passed in MATNET, the secure
      shipboard copy of SATNET being built for the Department of the
      Navy; namely, a Satellite IMP successfully transmitted packets
      through a Navy FLTSAT satellite for the first time.  The test
      setup was at the plant facility of E-Systems, ECI Division, where
      preliminary integration is being done between the network
      controllers and the radio equipment.

      Action Items from BBN:

         1.  Rubber EOL and Buffer Size has implementation impact in
         TAC.

   O.  ARPA

      Vint Cerf reported that the ARPANET switched over to 96-bit
      headers on January 1st.  Bill Carlson is leaving ARPA to join
      Western Digital and plans to build ADA machines.  Vint mentioned a
      project at CCNY which is encoding video using adaptive delta
      modulation.  ARPA plans to make a pair of these devices available
      to ISI and DCEC in July 1981.  ARPA plans to replace all the 316
      TIPS by TACs plus C30 IMPs.  TIP Login will be used for access
      control.  Germany and Italy are likely to join SATNET soon, Canada
      is in the discussion stage.



Postel                                                          [Page 9]


                                                                 IEN 175
Internet Meeting Notes



   P.  CSNET

      Dave Farber gave a brief overview of CSNET.  The idea is to
      provide network services to a group of university computer science
      departments.  It is a 5 year NSF grant.  The contractors are
      University of Wisconsin, University of Utah, Purdue University,
      The RAND Corporation, and 9 others.  There is a steering committee
      (Chair Bill Kerns, NSF) and a technical committee (Chair Dave
      Farber, UDEL).  CSNET will use Telenet, ARPANET, and telephones to
      connect the universities.  The services to be provided are:
      Computer Mail, File Transfer, Terminal Access, and Distributed
      Processing Applications.  More information is available from Dave
      (FARBER@UDEL).

   Q.  DTI

      Gary Grossman gave an overview of DTI's work on a front end for
      the WWMCCS H6000 hosts.  The INFE (interim network front end) has
      been up for some time, and has had some testing.  It implements
      the January 80 IP and TCP and has been tested with the EDN
      systems.  DTI is now working on the COS/NFE which is to be
      multi-level secure and will be based on DTI's HUB (TM) operating
      system.  The COS/NFE is to be verified by SDC.

   R.  NAVELEX

      Frank Deckelman described the interests and activities of NAVELEX
      Code 330.  There are four areas:  DBMS, Distributed Processing,
      Decision Aids, and Networking.  In Networking the focus is on:
      Global networks (e.g., MATNET), local networks (e.g., CCN - uses
      Ungerman-Bass hardware), and C2 work stations (multimedia and AI).
      One current program that involves all four areas of responsibility
      is the ACCAT at NOSC and the Remote Site Modules at NPS, FNOC,
      CINCPACFLT, NRL, and other sites.

   S.  XEROX

      John Shoch gave a brief status report on networking at XEROX.
      There are between 30 and 40 networks in operation, connected with
      20 to 30 gateways.  The new 10 Mb Ethernet is up.  The XEROX
      series 8000 products are based on the Ethernet.  There is a Print
      Server, a File Server, and a Communication Server (gateway), as
      well as work stations.  John also mentioned that a paper on
      "Measured Performance of the Ethernet Local Network" appears in
      the December 1980 issue of the Communications of the ACM.





Postel                                                         [Page 10]


                                                                 IEN 175
Internet Meeting Notes



IV.  ACTION ITEMS

   A.  The problem reinitializing UCL gateway was resolved.

   B.  The design notes on the VAX, HP3000, and TAC TCPs were done [see
       IENs 166,167,168].

   C.  The memo on IP Errors and GGP style messages was distributed in
       DRAFT form.

   D.  The demonstration of the SRI Name Server was postponed
       indefinitely.

   E.  The MTP was demonstrated at the meeting.

V .  PROTOCOL SPECIFICATION AND VERIFICATION

   A.  Overview

      Carl Sunshine gave a well-received presentation on formal models
      for protocol analysis.  Carl presented a basic model of a protocol
      and identified the aspects that need to be specified and verified.
      Then he described the methods for specifying protocols and
      identified particular programs or techniques that implement each
      method.  Finally, Carl reviewed the verification methods and again
      identified particular systems which implement each method.

      The specification methods are:

         Programs
            inductive assertions
         State Machines
            FSA
            Abstract Machines
            Petri Nets
            Sequence Expressions

      The verification methods are:

         Program verification
         State Exploration
         Structural Induction
         Symbolic Execution
         Design Rules

      A DRAFT version of a report on "Formal Modeling of Communication
      Protocols" was distributed.  The final version is ISI RR-81-89.



Postel                                                         [Page 11]


                                                                 IEN 175
Internet Meeting Notes



   B.  Three Way Handshake

      Danny Schwabe presented an analysis of the three way handshake
      made in the SPEX language.  A description of a protocol in SPEX is
      a "spexification."  Spexifications can be translated into an
      AFFIRM abstract data type.  Proofs of properties of this abstract
      data type can be done using AFFIRM.  The analysis revealed a
      possible problem in the three way handshake.  As currently
      described in the TCP specification (IEN 129), a connection may
      become established on one side and potentially may accept data
      from a previous incarnation of the connection.  This is a very low
      probability case and would be quickly detected, but the analysis
      showed it was possible in principle.

      The problem is that the document is in error in allowing an ACK to
      be accepted before a SYN has been received.

      A DRAFT report "Formal Specification and Verification of a
      Connection Establishment Protocol was distributed.

   C.  IP Specification

      Ken Shotting described his specification of IP using SRI's HDM and
      SPECIAL.  Ken broke down IP into several mini-layers to make use
      of the methodology.  There was some difficulty making assertions
      about global behavior since several fields are changed between the
      source and destination, e.g., Time-to-Live.  This also causes
      problems with the checksum field.  The order of processing assumed
      for various features has an impact on the formal specification.
      Ken's evaluation of HDM for protocol analysis is that it provides
      good support for developing a hierarchy of abstract functions and
      for state machine transitions, but is weak in data representation,
      exception handling, and concurrency.  Ken's work is documented in
      a University of Maryland Technical Report "On the Formal
      Specification of Computer Communication Protocols," Computer
      Science TR-973, December 1980.

   D.  NBS Work

      Jack Haverty gave an overview of the work BBN is doing for the
      NBS.  The work is being done by Tom Blumer (TPB@BBN-Unix) and
      Richard Tenney (RTenney@BBN-Unix).  This protocol specification
      system is based on a finite state machine model, augmented so that
      there are variables, and arbitrary program segments may be
      associated with each transition.  These program segments are
      written in a Pascal-like language.  There is a syntax checker for
      specifications, a specification editor, a FSM analyzer, a compiler
      that produces C and a test generator.


Postel                                                         [Page 12]


                                                                 IEN 175
Internet Meeting Notes



      For further information contact Tom Blumer or see BBN Report 4581.

   E.  DCA Work

      Dave Kaufman reported on the work SDC is doing for DCA.  The main
      emphasis is on developing complete specifications of existing
      protocols based upon the original design intent and upon a set of
      specification guidelines being prepared in parallel by SDC.  These
      guidelines include the following sections:  Introduction, Service
      Specification, Lower Level Service Specification, Interface
      Specifications, Peer Level Mechanism Specification, and Execution
      Environment.  These sections correspond with the basic protocol
      model presented by Sunshine.  A distinction is made between the
      service specification which is the global view of the service and
      the interface specification which is the user/service local
      interface.  The execution environment section describes protocol
      requirements of the operating system (or more correctly of the
      protocols runtime environment) such as timers and interprocess
      communication.  IP is currently being specified according to these
      guidelines and during this effort several areas have been
      uncovered which require further definition.

      Example areas noted by SDC were:

         1. Who supplies the "protocol" field for the IP header, IP or
         the transport protocol?

         2. What is the nature of the interaction between IP and GGP?

         3. Is source routing loose or strict?

         Jack Haverty raised an additional related issue:

         4. How does IP interact with the local net, on errors, on flow
         control,etc.?

   F.  NDRE Work

      Yngvar Lundh noted that a graphical technique had been used to
      produce an augmented state machine description of TCP for use in
      an NDRE implementation effort.









Postel                                                         [Page 13]


                                                                 IEN 175
Internet Meeting Notes



VI.  FRONT ENDS

   A.  Overview

      Vint Cerf introduced the subject of Front Ends for protocols and
      TCP in particular.  The idea seems to be that in some cases IP/TCP
      etc. may be too complex to put into the existing operating system,
      so the protocol modules are put into a small front end machine.
      Then there must be a communication procedure between the host and
      the front end.  This communication procedure is called Host-Front
      End protocol (HFP).  The argument is that HFP is much simpler for
      the host than IP/TCP would be.  Note that not everyone shares this
      view.

   B.  WWMCCS HFP

      Gary Grossman gave a detailed presentation on the HFP developed
      for the WWMCCS H6000 machines.  DTI has developed a protocol for
      use between the host and the front end based on the notions of
      "services" and "channels."  The lowest level of the HFP is the
      link level which provides a single channel with flow and error
      control.  The function of the link level corresponds to the
      functions of an HDLC connection.  The middle level is the channel
      level.  This is the level where separate logical streams appear
      and are multiplexed based on logical channel number.  At the top
      level are services (i.e. applications).  Typical services would be
      Telnet and FTP.  Gary gave quite a bit of detail on the protocol
      formats and control procedures.

      Gary also talked about the specification technique used to
      describe the HFP.  For each message type the following points are
      described:  function, when sent, sending state (and next state),
      receiving state (and action to take), subsequent actions by sender
      and receiver.  For the service protocols, a specification includes
      a "specification" and an "adaptation."  The specification gives
      the semantics of the fields used and the procedure for
      communicating via the channels.  The adaptation gives the format
      details and any restrictions due to the particular machine
      environment.

      DTI and MITRE have done a fair amount of performance testing.  The
      comparison of an old implementation of NCP in the H6000 versus an
      NCP implementation in the Front End show the Front End about 2 to
      1 better in throughput.  There are many differences in the two
      configurations.  Some testing recently showed that from the H6000
      through the FE and over the ARPANET to DTI a data rate of 18Kb/s
      was achieved.  In local tests, 64Kb/s was measured over the
      H6000-->FE-->I path; and with a source and sink in the FE, 84Kb/s


Postel                                                         [Page 14]


                                                                 IEN 175
Internet Meeting Notes



      was measured for source-->I-->sink.  Finally using a "mirror"
      program in the FE instead of sending to the IMP, 125Kb/s was
      measured for source-->mirror-->sink.  An analysis of the CPU time
      in the TCP code in the FE revealed that about 20% of the time was
      spent on TCP functions and 80% on interprocess communication and
      other "system" functions in the monitor.

      Gary noted that details of the HFP are described in DTI report
      DTI-80043.C-INFE.18, and DTI-78012.C-INFE.14, and the measurements
      are described in the papers "Control Structure Overhead in TCP,"
      NBS Computer Networking Symposium, May 1980, and "A Performance
      Study of a Network Front End," Sixth Data Communication Symposium,
      November 1979.

   C.  Z8000

      Steve Holmgren of MITRE described a Z8000 based TCP.  The goal is
      to provide network communication for very small hosts which might
      otherwise be peripheral devices of a computer.  The Z8000 actually
      supports a Network Access Protocol (NAP).  The NAP is a layered
      protocol with an option approach.  The layers are:  link,
      transport, service, and user.  The option approach allows the
      users of the protocol to select the features they need and to
      ignore others.

      Steve gave some details of the protocol functions and formats.
      The access to the protocol is via a system call style mechanism,
      and the user is allowed to pass parameters and select options.

   D.  Discussion

      John Shoch said he questioned the desirability of Front Ends, and
      wondered, if aside from communication efficiency and pragmatics,
      there was a good technical principle for front ends?

      It was noted that we often excuse the current work of computing
      checksums by saying we will someday have a checksum instruction in
      our machines.  Steve Holmgren asked "Why not a TCP instruction?"

      When does a "front end" become an "instruction?"










Postel                                                         [Page 15]


                                                                 IEN 175
Internet Meeting Notes



VII.  PERFORMANCE

   A.  Multics

      Dave Clark discussed his measurements of TCP performance in
      Multics.  Dave described some detailed timing studies made of the
      different TCP functions.  The IP implementation is 5.3 K
      instructions, and the TCP implementation is 9.0 K instructions.

      Dave also discussed throughput in TCP when there is a lot of data
      to send (e.g., in file transfers).  A problem, previously pointed
      out by Dave Mills, can arise where many small segments are sent.
      This is due to the receiver reporting additional window each time
      a small amount of the data has been processed, and the sender
      immediately sending a segment to fit that additional window.  Dave
      Clark proposes to call this phenomena "Silly Window Syndrome"
      (SWS).  One way to prevent SWS is for the receiver not to report
      new window unless the increase is a reasonable size.  The receiver
      can acknowledge incoming segments at any time, but limit window
      updates to points when a reasonable increase can be made.  It is
      up to the receiver to decide what is reasonable, perhaps something
      like 20% of the total buffer space for this connection.  The
      sender can also try to stay out of SWS by only sending big
      segments and waiting until the window is large enough to allow it.
      If the sending user indicates an end of letter then a smaller
      segment may be sent.

      Dave suggests that sending a segment with one octet of new data
      into a zero window as a probe may lead to SWS.  It may be better
      to send an octet of old data.

      Dave suggested that a performance measure might be the size of
      bursts of segments the net, gateway, or host could handle.  For
      example, can a gateway handle a burst of 10 datagrams of 576
      octets at the network input speed?  Could measures be devised and
      feedback control be exercised in terms of bursts?  Wild idea
      number one:  the receiver can tell the sender the maximum burst
      size it should send.  Wild idea number two:  have gateways turn on
      a bit in the IP header if they are busy, and have the receiving
      hosts integrate this information for use in determining a burst
      size to feedback to the source.

   B.  UCL

      Ron Jones reported on measurements of datagram traffic between UCL
      and ISIE.  The source of the traffic was an LSI-11 host.  This was
      connected to a port expander.  The PE was in turn connected to the
      UCL Gateway.  The UCL Gateway communicates via the Goonhilly SIMP,


Postel                                                         [Page 16]


                                                                 IEN 175
Internet Meeting Notes



      the SATNET, and the ETAM SIMP, to the BBN Gateway.  The BBN
      Gateway sends the datagrams through the ARPANET to ISIE.

      Ron had a number of measurements which he described, but interest
      focused on the discovery that in some tests from 25% to 90% of the
      datagrams were lost between the ETAM SIMP and the BBN Gateway.
      Some of the tests showed a significant step in the throughput
      graph at the single-packet/multi-packet threshold.

   C.  BBN

      BBN believes that the problem originated because the ARPANET
      IMP 40 would not accept packets from the BBN gateway fast enough.
      The packet loss is manifest as multiple packet retransmissions
      from the Etam SIMP to the BBN gateway, until the packet eventually
      times out and is discarded in the SIMP.  This behavior underscores
      two inadequacies in the system.  First, the BBN gateway should
      discard the packet and send the appropriate message to the Etam
      SIMP; the machinery is already present in Host-SATNET protocol to
      accommodate this.  Second, the Etam SIMP should notify the
      Goonhilly SIMP which should notify the UCL gateway that problems
      are arising.  Unfortunately, a flow control mechanism like source
      quenching was never developed within SATNET, although its need has
      been known for some time; hence, when packets are dropped in
      SATNET, gateways are never informed and therefore cannot generate
      internet source quenching messages.

   D.  RSRE

      John Laws presented some findings of measurements performed by
      Andrew Bates.  These are datagram measurements of a single round
      trip (at earlier meetings RSRE has reported on TCP measurements of
      double round trip times).  The source/sink is a TIU connected to
      the RSRE gateway.  One set of measurements seems to show that the
      round trip time to the ETAM SIMP is about 2 seconds with very
      little spread, but the round trip time to the BBN Gateway is also
      about 2 seconds but with about 25% of the datagrams delayed (a
      bimodal Histogram).  The measurements were made at different times
      of day, and may be due to a difference in the load on SATNET.

   E.  CMCC

      David Flood Page told of tracking down the cause of some looping
      datagrams.  In December the CMCC data showed that in the course of
      a day one of the PRNET/ARPANET gateways had processed several
      million datagrams.  When the people who normally use that gateway
      were asked what experiment they were conducting, they replied
      "What experiment?  We aren't doing anything."  Several instances


Postel                                                         [Page 17]


                                                                 IEN 175
Internet Meeting Notes



      of this incredibly high traffic level in at least two different
      PRNET/ARPANET gateways were detected over the next several weeks.
      David began investigating and eventually found the cause.

      The loader server that loads the port expanders attached to the
      PRNET gateways uses XNET 2.5, with Internet 2.5 headers, to do the
      loading.  The loader server sends the packets to logical host 15
      (decimal) on the port expanders ARPANET address, which is the
      address recognized by the bootstrap (obviously). The last packet
      sent by the loader server is the one that says "go" to the
      bootstrap; this causes the bootstrap to send out an acknowledgment
      and then start up the port expander software. One of the first
      things the PE does is to flip the ready line to the IMP.  Now if
      the acknowledgment from the bootstrap is still in the IMP, and the
      IMP sees the ready line down, it will drop the ack (and any other
      outstanding packets from that host).  So the loader server gets no
      ack, and retransmits the "go" command.

      The "go" command arrives at the port expander addressed as before,
      i.e.  to logical host 15 on the PE; but the PE doesn't have a
      logical host 15.  It is set to hand off any packets which it
      doesn't know how to route to its logical host 0, which is the
      gateway; the gateway sees that it is a packet destined for
      somewhere on the ARPANET that is not itself, so sends it back out
      its ARPANET interface, i.e.  to the PE.  The PE has the same
      trouble as before, so we get a loop.  Because the packet is an
      Internet 2.5 packet, it does not have a time to live field, so the
      packet loops indefinitely until either the PE goes down, the
      gateway goes down, or a flood of real packets causes enough
      congestion to result in the dropping of the looping packet.

      This didn't happen every time the PE was loaded, because some of
      the time, the acknowledgment got out of the IMP fast enough not to
      be dropped when the ready line was flipped.  It was largely a
      matter of luck.

      The problem will disappear either when the new gateway version,
      which drops all Internet 2.5 packets, goes into the PRNet
      gateways; or when the V4 bootstrap goes into the PEs.  In fact I
      think the new gateway version may already be in place. Holly did
      put a fix in the PE as well, but I'm not sure what it was.  One
      important point to note is that the port expander is on the
      ARPANET side of the gateway, not the PRNet side.

      David says the lesson that should be learned from this is that
      more remote access to debugging tools is needed.  The key piece of
      evidence in solving this problem was provided by a "packet



Postel                                                         [Page 18]


                                                                 IEN 175
Internet Meeting Notes



      printer" trace program that could only be run locally at the
      gateway/port expander site - which is normally unmanned.

   F.  Radio Clocks

      Steve Casner described (actually showed) one of the Radio Clocks.
      Since we are about to start doing coordinated measurements of one
      way times we must have an agreement on what size and precision of
      time stamps to carry around in datagrams and programs.  The "no
      thought" proposal is 32 bits of milliseconds since 1 January 1980.
      Others suggested that we might want more precision later so maybe
      we should have micro seconds and more bits.  This was not
      resolved.

VIII. WORM PROGRAMS

   John Shoch briefly described an experiment in distributed computing.
   Programs were constructed to operate in segments with each segment
   allocated to a personal computer.  The total program is called a
   worm.  The basic version of the program simply maintains its
   existence.  If a segment dies the remaining segments cooperate to
   find a free machine, load it with the segment code, and start it
   running as part of the worm.  John described some of the interesting
   things which can go wrong, and ways to prevent them.  The experiment
   is discussed in more detail in IEN 159.  One comment to the internet
   group is that this experiment showed the usefulness of
   multidestination or group addresses.  The conclusion is that with
   datagram style communication, high speed local networks, and new
   control procedures, the tools are in hand to begin some very
   interesting multi-machine applications.

IX. IP ERRORS

   Jon Postel distributed a draft memo on error reports in IP.  The memo
   is titled "What every host should know about GGP".  The intention is
   to use the GGP messages on routing advice and destination dead as a
   base and to add a few other messages to cover the host-to-host error
   conditions.  The discussion focused on whether or not this should
   remain part of GGP or be in a separate protocol.  From an
   implementation point of view there seems to be little difference,
   from an administrative point of view it seems to be cleaner for it to
   be separate.  There were some strong difference of opinions.  The
   matter was not resolved.







Postel                                                         [Page 19]


                                                                 IEN 175
Internet Meeting Notes



X.  ADDRESSING DISCUSSION

   A.  Overview

      Vint Cerf opened the topic with a call for a very general
      discussion of the issues and spent some time developing a list of
      goals for the the addressing and routing procedures.  The goals
      were:

         1.  Keep routing simple.

         2.  Keep routing tables small.

         3.  Keep computation costs small.

         4.  Most datagrams should be delivered.

         5.  Use any available connectivity.

         6.  Multidestination delivery.

         7.  Handle mobile hosts.

         8.  Efficiently use constituent networks.

         9.  Support multi-homing.

         10. Dumb hosts should be included.

         11. Pantheism should be dealt with.

         12. Degradation should be automatically fixable.

         13. The system should scale up.

         14. The system should be measurable.

         15. Ability to use hierarchy.

      There was some discussion of these points and it was noted that
      some are service specifications while others are "good job"
      criteria.

   B.  Presentation

      Noel Chiappa described the MIT complex which includes 9 networks
      and three major protocol families (IP, PUP, and CHAOS).  All these
      networks share one "Internetworkly known" network number.  Noel


Postel                                                         [Page 20]


                                                                 IEN 175
Internet Meeting Notes



      listed a number of problems and made some observations.  One
      possible long term development may be that all hosts are on local
      networks and only gateways are attached to long haul networks.
      The thrust of Noel's remarks seems to be that things are going to
      grow in a complex, but generally hierarchical, way; and any
      workable system will have to be prepared to grow, probably by
      taking advantage of the structure.

   C.  Discussion

      Vint Cerf led a further discussion on addressing.  The main focus
      was on the tradeoff between a flat address space and a
      hierarchical one.  In a flat address system there is no relation
      between the address and the location, and routing has to be by
      central knowledge or broadcast.  In a hierarchical address system
      the address is composed of fields which identify the location in a
      routing tree.

      Vint suggests that we have both in one!  Let an address be
      composed of two parts: a hierarchical address (called an address)
      and a flat address (called an identifier).  The address can be
      used as a routing guide or hint, but the identifier must match for
      a message to be delivered.  The identifiers are globally unique
      names for hosts and do not change when hosts move.

      There are many questions to be answered in this scheme.  For
      example, How does source routing work?  Or Multi-homing?

XI.  FILE TRANSFER IMPLEMENTATION STATUS

   Vint Cerf took a survey of the implementers present to find out the
   status of FTP implementations.  There are four different FTP systems
   being used: ARPA FTP (RFC 765), AUTODIN II FTP (IEN 101), NIFTP (IEN
   99), and TFTP (IEN 133).  The first three use TCP, and the last
   (TFTP) uses UDP.

   ARPA FTP

      DCN (COMSAT)        now
      TOPS20 (BBN)        April 81
      EDN-Unix (DCEC)     June 81
      Multics (MIT)       after June 81

   AUTODIN II FTP

      BBN-Unix (BBN)      now
      EDN-Unix (BBN)      now



Postel                                                         [Page 21]


                                                                 IEN 175
Internet Meeting Notes



   NIFTP

      TOPS20 (UCL)        now
      DCN (COMSAT)        now
      Multics (MIT)       June 81
      UCL-Unix (UCL)      now

   TFTP

      Multics (MIT)       now
      TOPS20 (MIT)        now
      ALTO (MIT)          now
      Unix (MIT)          now
      TOPS20 (ISI)        March 81
      EPOS (ISI)          April 81

XII.  COMPUTER MAIL

   A.  Mail Facilities

      Peter Kirstein discussed the problems of providing mail services
      between users in the UK and the US.  Within the UK, computer mail
      will almost certainly be based on NIFTP and will likely be as
      proposed in IEN 169.  One major concern for the US/UK
      transmission is cost.  It is quite important that a minimum number
      of transmissions be made and especially that only one copy of a
      message destined for multiple users be sent across the Atlantic.

      Peter raised the issue of an interface between NIFTP mail and MTP
      mail, since it seems that the Internet will use the MTP mail.

   B.  Mail Transfer Protocol

      Jon Postel discussed the MTP mail plan and indicated that a
      revised document would be issued soon which will describe the MTP
      in a network independent style.

      Jon agreed with Peter that a NIFTP-mail/MTP interface data
      structure should be defined soon, and promised to do so.

      There are several working (or partly working) MTPs already:
      Multics, COMSAT, DCEC, and ISI.

   C.  TELEX/TWX Gateway

      Geoff Goodfellow described a system that is under development at
      SRI to connect Telex and Computer mail.  A user at a computer
      terminal runs a program like SNDMSG or MM and simply adds some


Postel                                                         [Page 22]


                                                                 IEN 175
Internet Meeting Notes



      additional fields to the header of the message to give the
      information needed for sending a telex.  The message is routed to
      a special host which checks the telex information and if it is
      acceptable sends a telex.  When a telex arrives at SRI it is
      processed by the special host and if the required keywords and
      information are found it is sent as a RFC 733 style message to the
      recipients computer mail mail box.  A small percentage of the
      incoming telexes must be handled by a human operator because they
      do not contain the required information in a computer parsable
      form.

   D.  Discussion

      There was some discussion of mailbox addresses and the problem of
      sending (and answering) mail to (from) mailboxes in other systems
      (e.g., Internet, TELEMAIL, ONTYME).

XIII.  NEXT MEETING

   The next meeting will be held 1-2-3 June 1981 at COMSAT in Washington
   D.C.  Dave Mills (Mills@ISIE) is the host.  Please send agenda items
   to Jon Postel (Postel@ISIF).  If you plan to attend please register
   with Linda (Linda@ISIF).  Local arrangements information will be sent
   only to those registering.

   The fall meeting will be held at UCL on 21-22-23 September 1981.  The
   winter meeting will be held at SRI in mid January 1982.























Postel                                                         [Page 23]


                                                                 IEN 175
Internet Meeting Notes



DOCUMENTS DISTRIBUTED

   Author     Subject                                  Number
   ------     -------                                  ------

   Cerf       INFOCOM82 Call for Papers                   ---
   Postel     AGENDA                                      ---
   Postel     Recent Document List                        ---
   Postel     IEN INDEX                                   ---
   Postel     Assigned Numbers                            776
   Farber     CSNET Description                           ---
   Postel     TT                                          ---
   Chase      TTLUSR                                      ---
   Postel     What Every Host Should Know About GGP       ---
   Cohen      On IP-Addressing                            170
   Cohen      Addressing in the ARPANET, another visit    171
   Sunshine   Formal Modeling of Communication            ---
                Protocols (DRAFT)
   Schwabe    Formal Specification and Verification of    ---
                a Connection Establishment Protocol (DRAFT)
   Bennett    A Simple NIFTP-Based Mail System            169





























Postel                                                         [Page 24]


                                                                 IEN 175
Internet Meeting Notes



RECENT DOCUMENTS

   Author     Subject                                  Number
   ------     -------                                  ------

                                  IENs

   Shoch      Notes on the "Worm" Programs - Some Early   159
                Experience with a Distributed Computation
   Postel     Internet Meeting Notes - 7-8-9 October 1980 160
   Jones      A Proposal for Simple Measurement Support   161
                for Users Through Slow Nets
   Pershing   Transport, Addressing, and Routing in the   162
                Wideband Net
   Jones      Echo Delay Measurements with GGP Packets    163
   Stern      CMOS System Overview                        164
   Cohen      About Addressing in the WBnet               165
   Hinden     Design of TCP/IP for the TAC                166
   Sax        HP3000 TCP Design Document                  167
   Gurwitz    VAX-UNIX Networking Support Project         168
                Implementation Description
   Bennett    A Simple NIFTP-Based Mail System            169
   Cohen      On IP-Addressing                            170
   Cohen      Addressing in the ARPAnet, Another Visit    171
   Mills      Time Synchronization in DCNET Hosts         173

                                  RFCs

   Postel     Internet Protocol Handbook                  774
                 Table of Contents
   Mankins    Directory Oriented FTP Commands             775
   Postel     Assigned Numbers                            776


















Postel                                                         [Page 25]


                                                                 IEN 175
Internet Meeting Notes



ATTENDEES

   Name              Affiliation  Nationality   Mailbox
   ----              -----------  -----------   -------
   Vint Cerf           ARPA        USA          Cerf@ISIA
   Robert Kahn         ARPA        USA          Kahn@ISIA
   David Flood Page    BBN         British      DFloodPage@BBNE
   Jack Haverty        BBN         USA          JHaverty@BBND
   Robert Hinden       BBN         USA          Hinden@BBNE
   Charles Lynn        BBN         USA          CLYNN@BBNA
   Dale McNeill        BBN         USA          DMcNeill@BBNE
   Paul Santos         BBN         USA          Santos@BBNE
   Virginia Strazisar  BBN         USA          Strazisar@BBNA
   Gerry Amey          Canada-DND  Canadian     Amey@ISIA
   Hoi Chong           COMSAT      Rep. China   Chong@ISIE
   David Mills         COMSAT      USA          Mills@ISIE
   Marvin Solomon      CSNET       USA          UWVAX!Solomon@BERKELEY
   Ed Cain             DCEC        USA          Cain@EDN-UNIX
   Wayne Shiveley      DCEC        USA          Shiveley@BBNB
   Hans Dodel          DFVLR       Germany      ---
   Helmuth Lang        DFVLR       Germany      ---
   Gary Grossman       DTI         USA          grg@DTI
   Horst Clausen       IABG        Austria      Clausen.IABG@Mit-Multics
   Ray McFarland       DoD         USA          McFarland@ISIA
   Ken Shotting        DoD         USA          Shotting@SRI-kl
   W. Bradbury         I.P. Sharp  Canadian     ---
   Stephen Casner      ISI         USA          Casner@ISIB
   Danny Cohen         ISI         USA          Cohen@ISIB
   Randy Cole          ISI         USA          Cole@ISIB
   Dan Lynch           ISI         USA          Lynch@ISIB
   Bill Overman        ISI         USA          Overman@ISIF
   Jon Postel          ISI         USA          Postel@ISIF
   Danny Schwabe       ISI         Brazil       Schwabe@ISIF
   Carl Sunshine       ISI         USA          Sunshine@ISIF
   Estil Hoversten     Linkabit    USA          Hoversten@ISIA
   Jim Forgie          LL          USA          Forgie@BBNC
   Noel Chiappa        MIT         British      JNC@XX
   Dave Clark          MIT         USA          Clark@MIT-Multics
   Steve Holmgren      MITRE       USA          Steve@MITRE
   Anita Skelton       MITRE       USA          Anita@MITRE
   Frank Deckelman     NAVELEX     USA          Deckelman@ISIA
   Oyvind Hvinden      NDRE        Norway       Oyvind@DARCOM-KA
   Yngvar Lundh        NDRE        Norway       Yngvar@DARCOM-KA
   Merle Neer          NOSC        USA          Neer@ISIA
   Mike Wahrman        RAND        USA          Mike@RAND-UNIX
   Derek Barnes        RSRE        British      T45(ATTN.Barnes)@ISIE
   John Laws           RSRE        British      T45@ISIE
   Dave Kaufman        SDC         USA          Kaufman@ISIE


Postel                                                         [Page 26]


                                                                 IEN 175
Internet Meeting Notes



   Geoff Goodfellow    SRI         USA          Geoff@SRI-ka
   Ron Kunzelman       SRI         USA          Kunzelman@SRI-KL
   Jim Mathis          SRI         USA          Mathis@SRI-KL
   Holly Nelson        SRI         USA          HNelson@SRI-KL
   Zaw Sing Su         SRI         Canada       ZSu@SRI-KL
   Ken Biba            SYTEK       USA          Biba@SRI-KL
   Ron Jones           UCL         British      UKSAT@ISIE
   Peter Kirstein      UCL         British      PKirstein@ISIA
   Charles Kline       UCLA        USA          CSK@UCLA-Security
   Dave Farber         UD/CSNET    USA          Farber@UDEL
   John Shoch          Xerox       USA          Shoch@PARC







































Postel                                                         [Page 27]