GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien160
                                                             J. Postel

IEN 160 ISI

                                                       7 November 1980
            Internet Meeting Notes -- 7-8-9 October 1980

I. INTRODUCTION

 The meeting was held at the Royal Signals and Radar Establishment in
 Malvern, England.  John Laws was the host.  Alan Fox gave a welcome
 to and explanation of RSRE.  John Laws described the arrangements.

II. OBJECTIVES

 Vint Cerf described the objectives of the meeting.  The main points
 were to exchange information on the status of various projects, to
 discuss plans, and to review performance and design issues.

III. STATUS REPORTS

 A.  ARPA
    Vint reported on some changes in the ARPA IPT office.  People:
    (1) Dr. R. Kahn was married, (2) Col. J. Hammett is leaving the
    office for an assignment in Europe, (3) Dr. B. Leiner is joining
    the office to work on the Packet Radio Program, and (4) Lt. Col.
    Duane Adams is now Executive Assistant to the Director of IPTO.
    Equipment: Much of the equipment on the 7th floor will be moved to
    the 8th floor, the current 316 TIP  will be replaced by a C30 IMP
    plus 316 Terminal Access Mini-Host, the XGP will be replaced by a
    Penguin, and a RAPICOM 450 facsimile machine will be installed.
    An important goal for protocol implementations is to eliminate the
    use of NCP and completely switch over to TCP  by January 1983.
    ARPA is providing technical support to the National Science
    Foundation (NSF) in the planning  for a Computer Science Network
    (CSNET) to be operated by a consortium of Universities.
    L. Landwebber at the University of Wisconsin is the coordinator of
    the consortium.  The current plan is to use a combination of
    existing networks to provide the physical support for CSNET.
    ARPA intends that by the end of 1982 all existing 516 and 316 IMPs
    will be replaced by C30 IMPs.  The first few will go to (not in
    this order) SRI, MIT, ISI, ARPA, BBN, BRAGG, and Berkeley.

Postel [Page 1]

                                                               IEN 160

Internet Meeting Notes

 B.  BBN
    Dale McNeill reported on the status of SATNET.  The PSP terminal
    provided by COMSAT has been installed and the SPADE terminal has
    been removed.  The ARPANET line 41 between NORSAR and SDAC  which
    is supported by a satellite is now using a military circuit and
    availability has been noticeably poorer.
    CATENET gateways attempt to split the load when routing
    information indicates two or more paths of equal cost.  This means
    that traffic from the UCL gateway over the SATNET to the ARPANET
    will be split between the BBN gateway and the NDRE gateway.  When
    it turns out that the ARPANET line 41 is down, half of the traffic
    goes into a black hole.  The NDRE gateway can talk to its IMP and
    so reports it is connected to the ARPANET, but the ARPANET is
    partitioned due to line 41 being down.  Due to this problem, it
    was agreed that communication between the NDRE Gateway and the UCL
    Gateway be permanently broken to avoid packet loss due to gateway
    load splitting when line 41 is down.
    There has also been an increase in the packets lost in SATNET due
    to an increase in the bit error rate which is due to satellite
    power being reduced by 1db since June 1st.
    Dale also reported that the VAN Gateway (an ARPANET-TELENET
    gateway) work has progressed to testing the Frame Level protocol.
    There seem to be some problems with the interface due to differing
    interpretations of X.25.  This gateway is implemented in LSI-11.
    Ginny Strazisar reported on the recent development for the
    Gateways.  The use of XNET has converted to version 4.  A problem
    with the Redirect  Message has been fixed.  The implementation of
    fragmentation has not been completed.
    A problem with reinitializing the UCL gateway was discussed.  It
    seems as if some combination of using XNET, the robustness card
    and LDSRV should be able to handle this case.  UCL, SRI, and BBN
    will investigate.
    Jack Haverty reported that new TCP implementations are now just
    beginning for the VAX Unix (v.7), the HP 3000, and the new TIP
    (mini-host attached to a the C30 IMP).  Design notes on these will
    be distributed as IENs.  A description of the performance
    measurement tools developed for DCA should be available about 1
    November.   A local net based on the Ungerman-Bass NET-ONE
    equipment is being tested.  A design for a TIP Login system is in
    progress.  A gateway between the RCCNET and the ARPANET and a

Postel [Page 2]

                                                               IEN 160

Internet Meeting Notes

    local net based on C30s is being installed.  IEN 158 was issued
    which describes the XNET-4 protocol.
    David Flood Page reported that the CMCC log files are now
    primarily event driven and summaries are produced.  If you want to
    receive the daily statistics, send a message to David.  IEN 157
    was issued which discusses some new performance measurement CMCC
    message formats.
 C.  COMSAT
    Dave Mills reported on activities at COMSAT.  COMSAT is working on
    a revised version of INTELPOST which will use IP and TCP.  Dave
    described the configuration of equipment at COMSAT which consists
    of a number of small hosts, mainly LSI-11s.  This network uses the
    logical host field of the Internet Address to identify the host.
    Some bugs were found in some ARPANET hosts treatment of this
    field.  The local net protocol is IP.
    Dave has been particularly active in testing TCPs and IPs, and
    will discuss some of these issues in another session (see
    section V).  COMSAT has implemented programs to send and receive
    computer mail on the "playpen" host.  These are written in C.
    COMSAT has also used NIFTP to transmit files between their hosts
    and ISIE.  The NIFTP software was provided by UCL.  COMSAT and ISI
    have exchanged facsimile images.
    COMSAT plans to create a full CATENET gateway and to arrange a
    permanent connection to the ARPANET.
 D.  DCA/DCEC
    Ed Cain reported on the status of the EDN.  Fragment reassembly
    has not yet been implemented.  The Host and IMPs have been
    converted to 96 bit leaders.  The gateway has implemented most of
    the CMCC measurements reports.  One problem is that many gateways
    and hosts do not have the EDN in their tables.
 E.  DOD
    Ray McFarland noted that Ken Shotting has done further work on a
    formal analysis of IP and a report will be forthcoming.
 F.  ISI
    Jon Postel reported on the installation of the PENGUIN laser
    printer and the communication of data to it via IP, UDP, and TFTP.
    The program that manages the input  and output of facsimile data

Postel [Page 3]

                                                               IEN 160

Internet Meeting Notes

    has been modified to use either the new or old format.  Jon
    reported that the work on protocol verification is progressing and
    that Carl Sunshine may have a report at the next meeting.
    Jon also reviewed the IENs and RFCs produced since the last
    meeting.  Since the whole ARPANET is to convert to IP and TCP it
    is appropriate for protocol specifications and implementation
    related memos be RFCs while research and design related memos be
    IENs.
 G.  Linkabit
    Estil Hoversten noted that Linkabit recently merged with another
    company and will be setting up a private corporate satellite
    network.  Linkabit is doing the final testing of the ESI and
    expects send it to ISI in mid-October.  The expected review of ST
    protocol will not be presented.
 H.  LL
    Cliff Weinstein described the structure and status of the WBCNET.
    The initial four stations (LL, ISI, SRI, DCEC) all have their
    antennas installed.  Work is underway to bring the net into
    operation in the next few months.  LL is developing a local
    network called LEXNET, some digital voice terminals (VTs) and
    traffic emulator and traffic concentrator hosts.  An 11/45 is
    being programmed to be an WBCNET-LEXNET gateway.  This will be a
    ST gateway but not initially a full IP gateway.
 I.  MIT-LCS
    Dave Clark described the  complicated collection of networks and
    hosts at MIT.  There are several families of protocols in use and
    several interconnections.  Things are complicated enough that
    Corbito has been designated czar of networks at MIT.  Some things
    in progress are: Mail Service Programs, FTP programs, an NIFTP,
    X.25 interconnections for Telnet and Tymnet.  The  Nu machines are
    coming along; an IP for the Nu is being written.  Multics
    implements an Echo and Echo Reply to do PING with COMSAT.  MIT
    still needs an additional IMP port.  Interested in IP and TCP
    implementations for super small machines.
 J.  NAVELEX
    Frank Deckelman noted the interest of the Navy Electronics
    Laboratories in the ARPA Internet.

Postel [Page 4]

                                                               IEN 160

Internet Meeting Notes

 K.  NDRE
    Yngvar Lundh reported on the local net development at NDRE  which
    is based on protocol processors implemented on Z80s with 65 kb of
    memory.  Each processor has a kernel and a specialized module such
    as a speech packetizer, an LPCM, a TCP, or NVP.  The
    implementation language is PLZ.  A highly formalized graphical
    description language is being used to design the TCP.
 L.  RSRE
    Brian Davies reported on the activities at RSRE.  RSRE has been
    very active in measuring TCP performance and will report some
    results in another session.  Some suggestions for changes to IP
    and TCP are: (1) If the option code could indicate by a type or
    class bit if the option were to be copied or not on fragmentation
    things would be easier for the gateway; (2) also on fragmentation
    it might be better to break the datagram into equal sized
    fragments rather than a maximum sized fragment and the left over;
    (3) TCP should focus more attention on the critical impact of
    timeouts on performance, especially noting that different
    destinations may vary in round trip times by an order of
    magnitude.
    The line between RSRE and UCL was recently upgraded to 4800 baud.
    RSRE particularly noticed the lost traffic due to the problems
    with line 41.
 M.  SRI
    Ron Kunzelman reviewed the status of the Packet Radio networks,
    and discussed a problem with terminal access from Ft. Bragg TIU
    users at ISID.  The normal TOPS-20 character-at-a-time remote echo
    seems to saturate the bandwidth available via TCP, the gateway, or
    the networks.  A line-at-a-time local echo mode has been developed
    to reduce the traffic load.
    Ron also described some modifications to ACC controllers for the
    1822-LSI11 interfaces:
       (1) 18 bit addresses
       (2) address incrementing
       (3) switch to tell (?)
       (4) cycle shortening
       (5) last bit on gather write
       (6) last input character
       (7) substitution of a part

Postel [Page 5]

                                                               IEN 160

Internet Meeting Notes

    A PDP 11/44 has arrived.  This will run Unix (v.7) and will be
    used for a measurement host.  The antenna for WBC is installed,
    but some concern has been expressed about safety to passers-by.
    Jim Mathis reported that TIU's now do reassembly of datagram
    fragments.
    Holly Nelson described some new software development tools for use
    on UNIX.  Also noted that the Port Expander has all the features
    that were discussed at the last meeting.
 N.  UCL
    Robert Cole described the activities at UCL.  Fragmentation is
    implemented for sending datagrams and reassembly for incoming
    fragments.  Chris Bennett is developing a Unix based mail server
    based on MMDF and MH using TCP and IP for one underlying
    communication medium, and X.25 for another; there is also interest
    in interworking with CSNET for computer mail.  Steve Treadwell has
    developed some programs to decode and smooth facsimile data.
    A Cambridge Ring local network is being installed, but the
    protocols have not been chosen as yet.  Connections via X.25 to
    IPSS and EURONET are being tested.
    UCL has also been affected by the poor availability of SATNET.
    Ron Jones presented measurements on Port Expander and 1822
    interface performance.  The maximum achievable packet rate through
    the PE from a source to a sink was 65 pkts/sec (with the source
    and sink directly connected the rate was 255 pkts/sec).  The 1822
    interface performance was found by looping packets of various
    sizes through the PE.  The interface bit rate for a PI interface
    connected to a DMA interface was 71 kbits/sec and for two DMA
    interfaces was 325 kbits/sec.  The latter experiment also yielded
    5.7 ms as the time for the PE to switch a packet.

Postel [Page 6]

                                                               IEN 160

Internet Meeting Notes

IV. ACTION ITEMS

 A.  Internet Name Server
    SRI is developing an internet name server consistent with the
    specification in IEN 116. It was expected to be demonstrable at
    this meeting.  The development has not reached such a state and
    this item is deferred until the next meeting.
 B.  Interim Internet Mail System
    ISI is developing a prototype mail program for supporting text
    mail in the internet and between NCP and TCP hosts.  It was
    expected to be able to demonstrate these programs at this meeting.
    The design of these programs has only recently been developed (see
    section XII).  This item is deferred until the next meeting.
 C.  FTP and MAIL Memo
    ISI has produced a memo on text mail for the Internet.  It is
    RFC 772.  RFCs 771 and 773 offer motivation and discussion of this
    approach (see section XII).
 D.  IP and GGP Error Report Memo
    ISI was to produce a memo on error handling in IP and GGP.  This
    was not done and this item is continued to the next meeting (see
    section XV).
 E.  XNET Specification
    BBN has produced a memo on the XNET protocol.  It is IEN 158.

V . BAKE OFF SUMMARY

 Dave Mills reported on the sessions for testing the fragmentation and
 reassembly implementation in the IP protocol modules.  The results
 indicate that such testing is useful in that a few problems were
 found and corrected, but disappointing in that a number of hosts and
 gateways don't implement fragmentation as yet.

VI. TINY PIPE NETS

 Dave Mills discussed some performance problems with networks composed
 of low speed lines (e.g., 1200-1900 baud) and small hosts with
 minimal buffers.  In such "tiny pipe" networks, attention must be
 paid to the performance effects of TCP segmentation decisions,
 acknowledgment strategy, window strategy, and retransmission timeout

Postel [Page 7]

                                                               IEN 160

Internet Meeting Notes

 selection.  These performance parameters must be chosen with respect
 to the partner at the other end of the TCP connection.  For example,
 a connection between a tiny host in a tiny net and a large host in a
 large net (e.g., the playpen in COMSAT net and ISIE in ARPANET) has
 very different characteristics than connections between roughly equal
 hosts.

VII. INTERNET PERFORMANCE MEASUREMENT

 Zaw-Sing Su presented a detailed description of some measurement
 ideas.
 The aspects of performance measurement can be identified as follows:
    Artificial Traffic Generation
    Data Registration
    Data Collection and Transport
    Experiment Preparation and Control
    Data Reduction and Presentation
    User Interface
 Measurements could be made at several levels:
    TCP Performance
    TCP Analysis
    IP Performance
    IP Analysis
    Internet Component Performance
 Where performance is as perceived by the user and analysis is by
 mechanism.
 The types of things studied in performance measurements are:
    Traffic Arrival and Departure Statistics
    Throughput and Delay Performance
 The types of things studied in analysis measurements are the
 mechanism used by the protocol.  For TCP:
    Relative data efficiency
    Retransmission sent and received
    Out of order arrivals
    Duplicates
    Ack Only segments
    Ack Delay
    Zero Window periods

Postel [Page 8]

                                                               IEN 160

Internet Meeting Notes

 For IP:
    Fragmentation and Reassembly statistics
    Use of options statistics
 For GGP:
    Routing Decisions
    Congestion Statistics
 Zaw-Sing suggested an internet delay measurement capability to be
 implemented as an optional header field for both TCP and IP.
 The TCP option would have source and a destination timestamps of 32
 bits each plus the option code and length octets for a total length
 of 10 octets.  The time would be in milliseconds.
 The IP option would have the type and length octets, a 16 bit id, and
 N stamps, where each stamp is a 32 bit IN address and a 32 bit time
 (in milliseconds).  The maximum number of stamps would be 4 due to
 the limitations on the header size.
 Questions were raised about combining this option with the
 Source-Route or Return-Route options.
 The consensus seemed that rather than an option in the IP header the
 timing data ought to be accumulated in the data part of the datagram
 in a protocol like GGP.

VIII. CATENET PERFORMANCE CONSIDERATIONS

 Bruce Hitson discussed the need for one-way delay measurements in the
 Catenet.  It was stressed that these measurements would be
 particularly critical for performance measurement in an internet
 environment.  The very large physical distances involved and the
 non-participatory (at least in performance measurement) nature of the
 member networks are examples of why one-delays would be very useful.
 Round trip measurements are of questionable value since the network
 may change quite a bit during the course of a single round trip (up
 to 10 seconds in some cases).  To be able to make one-way delay
 measurements, synchronized clocks are needed.
 Bruce described several clever ways of synchronizing clocks with
 third party time sources.  The best choice seeems to be some devices
 that listen to a radio station (i.e., WWVB in the United States) and
 have a computer interface (e.g., RS 232) to report the time to the
 computer on request.

Postel [Page 9]

                                                               IEN 160

Internet Meeting Notes

 ISI (as noted in the notes of the last meeting) has already ordered 4
 such devices for use in WBC and CATENET measurements.  Design of
 experiments that will make use of these devices is being considered.
 For further details, see Appendix  B.

IX. Loader Server MEASUREMENTS

 Jim Mathis reported the results of some round trip measurements made
 using the LDSRV program.  A round trip in the ARPANET between
 DARCOM-KA and the Ft. Bragg Gateway took about 600 ms.  Similar
 measurements between DARCOM-KA and a host in a local PRNET took 170
 ms., and between DARCOM-KA and a host in the Ft. Bragg PRNET took 800
 ms.  For further details see Appendix C.

X. CATENET MEASUREMENTS

 Brian Davies discussed some suggestions for performance improvements
 based on the experience at RSRE.
 The use of an adaptive retransmission timeout seems to be very
 helpful.  RSRE has experimented with one based on the following:
    1.  For each segment record the sequence number and time sent.
    2.  For each acknowledgment determine the round trip time (RTT) of
    the sequence number thereby acknowledged.
    3.  Compute an Integrated Ack Time (IAT) as follows:
       IAT = ( ALPHA * IAT ) + RTT
    4.  Compute a Retransmission Time Estimate (RTE) as follows:
       RTE = Min [ BOUND, ( BETA * IAT ) ]
          Where BOUND is an upper bound on the retransmission time and
          BETA is an adjustment to the IAT to account for variation in
          the delay.
 RSRE currently uses  ALPHA = 31/32 and BETA = 1.33.
 [Dave Clark noted that MIT-MULTICS uses the same algorithm but with
 ALPHA = 4/5 and BETA = 1.5.]
 Brian presented some graphs of the actual RTTs and resulting RTE for
 TCP connections between  RSRE and ISIE.
 Andy Bates  presented data from recent measurements of double round

Postel [Page 10]

                                                               IEN 160

Internet Meeting Notes

 trip times between RSRE and UCL, BBN Gateway, and ISIE.  There are
 two aspects of the measurement to be explained:  The absolute delay,
 and the variation in delay.  The absolute delay (for the least
 delayed packets) seems to be in agreements with the expected delay
 given the speed of the lines, the protocols used, etc.  For example,
 one second time for a separate reservation is required (which is the
 current strategy).  The variation in delay is not yet satisfactorily
 explained.  Some arises in SATNET, and a good deal arises in the
 ARPANET.  One suggestion (by Danny Cohen) is that if the packets are
 far enough apart in time then new Source IMP to Destination IMP
 reservations are needed for each packet, this could add a large
 variable delay.
 A goal for the next meeting is to figure out the cause of the
 variation in the delay.

XI. NBS PROTOCOL STANDARDS DEVELOPMENT

 Mike Wingfield discussed the standards work on protocols sponsored by
 NBS.  Mike first noted that many standards groups are actively
 working on standards in the communications area.  The work NBS is
 sponsoring at BBN is to develop service specifications, feature
 analysis, formal specification, and a test implementation for a
 transport protocol.
 BBN has developed a formal description language which is an extension
 of a finite state machine description.  The language is entirely
 textual and so can be easily manipulated with computer tools.
 The basic element is a transition description which is composed of a
 next state, a current state, an event, and a procedure.  The
 procedure is written in "C".  The following tools for working with
 the language have been developed: a syntax checker, a state checker,
 a special editor, and a test generator.
 Additional work involves a feature analysis of X.75, IP, and PUP as
 internet protocols.  NBS is also interested in the ECMA proposal for
 a Transport Protocol and BBN is analyzing it.

XII. MAIL TRANSITION PLAN

 Vint Cerf described the problem arising in the exchange of computer
 mail between old NCP only hosts and new TCP only hosts.  The plan is
 to provide relay or forwarding hosts that implement both transport
 protocols and relay the mail.
 Jon Postel explained some of the details of this plan.  A key
 decision is to provide a new MAIL SERVER and a new mail protocol.

Postel [Page 11]

                                                               IEN 160

Internet Meeting Notes

 These will be very similar to the existing protocols and servers but
 will have an important new feature:  the address passed in the MAIL
 command will include the destination host as well as the user.
 Jon also discussed the need for hosts to add to their host tables
 some indication of the status of each other host: old table NCP, new
 table NCP, or TCP (all TCP hosts are to have new tables).  These
 three kinds of host mean there are 9 combinations of mail exchange.
 These were discussed on a case by case basis.  The difficult case was
 the old NCP host to the TCP host.  In this case a relay host could
 receive the mail using the old mechanisms but would have no idea of
 which host to forward it to.  One proposal is to have a list of
 registered users available to this relay host.
 Vint also discussed the idea that the hosts have unique indentifiers
 independent of network, and even that organization names could be
 used instead of host names.
 The discussion indicated some doubts about the practicality of
 registered users, especially in resolving name conflicts now resolved
 by host names.  Also, concern was expressed about the globally unique
 host names.
 RFCs 771, 772, and 773 present the plan, the mail protocol, and a
 discussion of the issues.  Comments are solicited.

XIII. CONTROLLED ROUTING

 Danny Cohen discussed routing to avoid undesirable networks or to
 limit a route to known networks.  The existing source routing option
 may be called loose source routing (LSR) since it allows the gateway
 to send the datagram on any route they choose between the specified
 addresses.
 Danny proposes another option called strict source routing (SSR),
 which is like LSR except that a gateway may only route a datagram to
 the next specified address through the network specified in the NET
 part of that address.
 This is very restrictive and would highly control the route.  It
 would also provide a way to route things out of one network, through
 a second network, and back into the first network, to get around a
 partition or use special transmission capabilities.
 Vint Cerf proposed an alternative of simply a list of acceptable
 networks.  This would be less restrictive, but might lead to problems
 in routing.

Postel [Page 12]

                                                               IEN 160

Internet Meeting Notes

 Danny's proposal is described in IEN 156.

XIV. PROTOCOL ISSUES

 Dave Clark discussed some problems in IP and TCP implementation in
 the MIT environment.
 One situation is that several hosts at MIT are on two or more
 networks, and have as many internet addresses.  The problem is that
 while one interface is down, the host and the other interface may be
 up, but datagrams sent to the down interface address will be
 discarded rather than routed to the other interface address.
 Dave presented a scheme that would allow a two-connected host to
 avoid this problem with the help of nearby gateways.  The gateways in
 the networks the hosts is connected to would have tables to map a
 special form of address into one of the regular address and to choose
 between regular addresses based on knowledge of which interfaces were
 up.  The hosts sending to the two-connected host would always send to
 the special address.
 This scheme was not well received.  The consensus seemed to be that
 it was too specialized and involved too much special case mechanisms.
 It is agreed to be an important problem, but a better solution is
 needed.
 Another situation involves very small hosts and the desire to
 implement TCP in them.  For example, a TCP in 2K bytes of memory.
 What corners can be cut?  For example, no data with SYN or FIN,
 simple ACK and window policies.
 One suggestion is for an option to specify a maximum receive segment
 size to be sent only with a SYN.  This would have different effects
 than a consistently small window because it may allow many segments
 to be in transit at a time even though each is small.  The consensus
 seemed to be that this was a good idea.

XV. IP AND GGP ERROR REPORTS

 Jon Postel reviewed the discussion from the last meeting of error
 reporting in IP and GGP.  They are different in that in IP an option
 is used and in GGP the data area is used to carry the error
 information.  They are redundant in that most of the errors mentioned
 in IP are also mention in GGP.
 
 Jon proposed to put all these error reports into a new protocol and
 use a GGP style mechanism.  The consensus seemed to be that we should
 continue to use GGP, and eliminate the IP error option.

Postel [Page 13]

                                                               IEN 160

Internet Meeting Notes

XVI. NEXT MEETING

 The next meeting will be hosted by ISI and will be held 28-29-30
 January 1981.  Attendance will be limited so if you plan to attend
 please clear that with Vint Cerf (CERF@ISIA). and notify Victor Brown
 (BROWN@ISIF).  Jon Postel will be the host.
 A tentative schedule for subsequent meetings is: May 81 at COMSAT,
 September 81 at UCL, January 82 at SRI, May 82 at BBN, and September
 82 at IABG/DFVLR.
 AGENDA ITEMS:
    1.  Provision for source routing in the interface between TCP and
    IP and in the TCP tables.  How will the reverse route information
    be handled?
    2.  Further discussion on internet mail transition.  Focus on
    alternatives to the unique name requirement which led to potential
    misrouting.
    3.  More on performance observations within the Catenet, in the
    Hosts.
    4.  MITRE report on their new 350 kb/s TCP that runs in a Z-8000.
    5.  Front-ending of TCP/IP.
    6.  Progress reports on FTP where ever it is being implemented.
    7.  Progress reports on the (interim internet) message system.
    8.  Progress reports on the protocol verification. ISI, BBN, SDC,
    and DoD.
    9.  Discussion of "worm" programs, XEROX.
    10.  Discussion of the IIN problem, the inter-inter-net.  How and
    at what levels can we interoperate with other nets?
    11.  Report on On-Tym and Telemail relative to ARPANET mail and
    Internet Mail.
 ACTION ITEMS:
    1.  New text for the TCP and IP specification changes.

Postel [Page 14]

                                                               IEN 160

Internet Meeting Notes

APPENDIX A: INTERNET DESIGN PHILOSOPHIES & THEIR IMPLICATIONS

 The third day of the Internet Meeting was a seminar on the TCP/IP and
 Yellow Book approaches to internetting.  The following notes are
 provided by Brian Davies of RSRE.
 INTRODUCTION - John Laws (RSRE).
    John Laws started the informal Seminar by giving some background
    as to its genesis: namely that with so many TCP/IP experts having
    come to the UK and it being the case that the UK public network
    users are promoting an apparently competing solution, then it
    seemed an ideal opportunity for parties to exchange views.  It was
    not expected or intended that there should be any dramatic
    conversions of the parties vis-a-vis datagram and virtual call
    issues.  However, it was hoped that areas of common approach might
    be identified even though expressed in a different language.  In
    addition, the reasons for divergence might be mutually identified
    and appreciated.
    An "impartial" Chairman, Derek Barber (Microprocessor Applications
    Project, Dept. of Industry) was introduced.  Many presentations of
    views were scheduled and firm discipline, of both presenters and
    the audience, was administered by the Chairman.  A summary of
    presentations and ensueing discussion follows.
 OPERATIONAL REQUIREMENTS - Sqn Ldr David Stupples (RSRE).
    The user requirement for communications in a typical air defence
    scenario was presented.  The data communications were provided by
    a common bearer network and mobile tactical networks of the JTIDS
    type.  The data-bases and their functions were described to
    illustrate why they were distributed.  The mobility of the users
    not only in a single net but across multiple tactical nets was
    emphasized with particular reference to the problems of
    maintaining connections to their associated databases.
 PHILOSOPHY AND ARCHITECTURE OF YELLOW BOOK TRANSPORT SERVICE (YBTS) -
 Peter Linington (Data Communications Protocol Unit, Dept. of
 Industry).
    To ensure that the parties to the debate were speaking a common
    language a set of "basic" and "obvious" axioms for internetworking
    were presented.  The properties of a global transport service were
    described.  Compatability for internetworking would be achieved by
    enhancing each underlying network to the common transport service
    standard.  This enhancement would be within hosts and gateways;
    the enhancement being achieved by encapsulation of the specific

Postel [Page 15]

                                                               IEN 160

Internet Meeting Notes

    network features within appropriate network specific protocols.
    Thus only the service attributes have to be agreed globally; hosts
    only have to implement their local network enhancing protocols;
    gateways at worst have only to implement neighbour network
    enhancing protocols.
 ADDRESS AND ROUTING IN THE YELLOW BOOK TRANSPORT SERVICE -Mike Guy
 (Computing Centre, Cambridge University).
    The point was made that diverse network address naming authorities
    will always exist and will always assert their techinical need to
    be different.  A naming and addressing mechanism appropriate for
    this environment was described.  This featured use of an "address"
    string whose component parts are addresses, titles, generic names.
    Traversal of connected networks was driven by successive
    "activation", with possible address/title
    expansion/transformation, of the component parts appropriate to
    the current address/naming domain: in effect akin to source
    routing.  In particular, the use of titles/generic names allowed
    the user to be unconcerned with changes in remote network
    addresses or interconnection architectures.  Depending on the
    name/address conventions of the neighbour networks, gateways would
    be required to have varying degrees of intelligence about
    name/address mappings.
 TRANSPORT SERVICE ARCHITECTURE FOR THE LAYMAN - Vince Hathway
 (National Physical Laboratory).
    Vince detailed his varied and long experience of implementing and
    working with protocols in an internetworking environment.  This
    environment had gateways to both datagram and virtual call
    networks.  Both approaches had used hop-by-hop techniques for some
    of the levels of protocols.  In addition one gateway also passed
    high levels of protocol transparently.  Neither approach could be
    declared as "better".  The community of users associated with each
    of the external networks had different requirements and this had
    significantly determined the internetworking solutions.  In
    analogy, domestic cars were ideal for many transportation
    requirements, but there are times when the virtues of tanks are
    appreciated!
 TCP AS A BASIS FOR YELLOW BOOK TRANSPORT SERVICE REALISATION -
 Chris Bennett (UCL)
    In order to incorporate an existing network into the Yellow Book
    framework, a 'Yellow Book protocol' must be defined locally to
    that network which builds on the existing network interface to
    bring it in line with the Yellow Book service.  In the Catenet,

Postel [Page 16]

                                                               IEN 160

Internet Meeting Notes

    the appropriate starting point is TCP which already offers the
    basic virtual call interface.  The data stream is structured into
    arbitrary length data and control messages.  Each control message
    is allied with TCP actions, where possible, to gain the
    appropriate effect.  The TCP-based Yellow Book protocol is not
    complex and is mostly required to allow the transmission of
    connection information beyond the Catenet.  Details may be found
    in IEN 154.
 A USER REQUIREMENT FOR STANDARDS - Ken Heard (Joint Networks Team,
 Science Research Council, Rutherford Labs.).
    Background was given as to some of the functions/responsibilities
    of the Joint Network Team; this being advising/aiding the
    selection/implementation of an architecture and protocols for
    internetworking between diverse networks sited at UK Universities
    and Research Establishments.  The point was made that the
    productive functioning of this internetworking in the immediate
    future was urgent and, that time and resources could not be wasted
    on re-inventing the wheel.  Hence the adoption and rapid
    implementation of protocols emerging as "interim" standards for
    use on the UK PTT public network.  A review of
    protocol/architecture standardisation activities within
    national/international bodies (AFNOR, BSI, CCITT, ECMA, ISO,
    NBS,...) was given.  As a final comment attention was drawn to the
    influence on standards of the pioneering research networks such as
    ARPANET and the European Informatics Network.
 THE INTERNET ARCHITECTURE - Vint Cerf (DARPA).
    The wide range of diverse network implementations and environments
    incorporated in the ARPA Catenet was described.  The ARPANET
    itself, packet radio networks, broadcast packet satellite
    networks, and a variety of local networks all interwork using IP
    as the universal protocol.  Some of the experiments and
    demonstrations conducted were discussed.
 INTERNET PROTOCOL DESIGN - Jon Postel (ISI).
    The architecture of the ARPA Catenet protocol family was briefly
    described and the services provided by the IP and by the TCP were
    described.  The  point that both protocols are available to the
    users  and can be used to build very different kinds of
    applications was emphasised.
 END-TO-END VS HOP-BY-HOP - Danny Cohen (ISI).
    The difficulty of building effective communication systems by

Postel [Page 17]

                                                               IEN 160

Internet Meeting Notes

    relying on plug-to-plug compatibility on a hop-by-hop basis was
    discussed.
 SUMMARY OF ISSUES - Brian Davies (RSRE)
    The advantages of harmonization of transport protocols in the
    civil and military fields were presented.  However, the
    differences in emphasis in the user requirements would probably
    preclude this standardization in the foreseeable future.  These
    differences included availability of resources in the face of
    threat, mobility of users, and the military requirement to
    accommodate a dynamically changing internet topology.  In
    addition, the relative importance and costs of such properties as
    security, precedence and survivability had to be considered.  Some
    of the particular architectural issues involved in the Yellow Book
    and TCP/IP approaches were then presented.  In particular the
    implications of the addressing strategies, connection control and
    economies of use were highlighted.
 DISCUSSION
    The initial discussion was used by a number of the presenters to
    clarify facts or points they had made in their talks.  The
    following paragraphs are a selection of the varied topics
    discussed:
    a)  The number of "grades" of service that might be required was
    discussed.  In the YBTS approach it had been identified that the
    one grade of reliable connection-oriented service was a
    requirement overwhelming all others.  In contrast, the TCP/IP
    approach had identified a need fo a number of distinct "grades" of
    service to be realized by specific protocols (e.g. speech, user
    datagram etc.).
    b)  Discussion showed that different emphasis of requirement had
    significant influences on the two architectures.  The more
    commercial environment within which the YBTS has been formulated
    places great emphasis on the economic use of resources.  However,
    the problems involved in maintaining connections across vulnerable
    or unreliable networks was an aspect not deeply considered within
    YBTS.  The TCP/IP approach had given much greater attention to
    this military aspect.  The two approaches could be seen to be
    non-competitive as they are solving different problems.
    c)  The YBTS approach to addressing is based on the premise that
    all networking authorities will not agree to a global addressing
    strategy.  The global addressing approach of the TCP/IP would seem
    to be in-line with the ISO recommendation on this issue.

Postel [Page 18]

                                                               IEN 160

Internet Meeting Notes

APPENDIX B: SYNCHRONIZED CLOCKS

 ISI is evaluating an absolute time clock for network measurement use.
 The clock is actually a radio receiver which is tuned to National
 Bureau of Standards station WWVB, which broadcasts on a frequency of
 60kHz, and is located at Fort Collins, Colorado.  WWVB provides both
 time and frequency information and its coverage area is effectively
 the continental United States.
 The clock is the Model 8170, made by Spectracom Corporation, 320 N.
 Washington St., Rochester NY 14625.  The 8170 is a rack-mountable
 unit, 17" wide by 5.25" high by 13.5" deep. Line power is 115/230
 volt 50 or 60 Hz AC at 60 watts.  An external antenna is required,
 which is a ferrite loop antenna in a tubular plastic housing 14.8"
 long and 2.7" in diameter with a threaded fitting in the center which
 accepts a standard 1" threaded plumbing pipe (for mounting purposes
 only).  The antenna is connected to the clock receiver via 50 ohm
 (RG58) coaxial cable with BNC connectors on the ends.
 For best accuracy, the antenna should be placed outside just above
 rooftop level (like a TV antenna).  However, an inside location near
 a window facing Fort Collins may turn out to be acceptable.
 Overall accuracy is specified as plus or minus (.1 millisecond +
 noise uncertainty + propagation delay setting error), where noise
 uncertainty is expected to be less than plus or minus .5 millisecond
 worst case.  This accuracy should be more than sufficient for network
 measurements.
 Time is output via a front-panel display (hours,minutes,seconds) and
 an RS-232 (D-15) jack on the rear panel.  Also output on the back
 panel is a 1Hz, 10% duty cycle TTL signal called the "on time" pulse.
 The leading edge of the on time pulse occurs at the beginning of each
 second.  In addition, a 1MHz standard frequency output is available
 on the back panel, which is a 3.4V rectangular positive pulse
 designed to drive a 93 ohm load, but which will drive a 50-ohm load
 with reduced amplitude.  This 1MHz output is phase-locked to the WWVB
 carrier, and can be used for calibrating counters with high accuracy.
 The user requests the time by sending the clock an ASCII capital "T".
 When it receives the "T", the clock waits until the start of the next
 second, and sends back an ASCII string containing the time. The
 rising edge of the start bit of the first character in the string
 occurs within a few microseconds of the rising edge of the on time
 pulse.

Postel [Page 19]

                                                               IEN 160

Internet Meeting Notes

 The time string is structured as:
    (CR)(LF)I DDD HH:MM:SS TZ=XX(CR)(LF)
       where:
       I      =space if time synch lamp is on,
               ? if time synch lamp is off
       DDD    =Julian day of the year (000 to 366)
       HH     =hours
       MM     =minutes
       SS     =seconds (at the start of this typeout)
       XX     =time zone setting with respect to UTC
               (formerly called GMT).  EST is 05, PST is 08.
 The RS-232 port on the clock runs at a baud rate of 300 baud.
 The synch lamp on the front panel will be lit if the time can be
 expected to be reliable within plus or minus 1 millisecond.  The
 clock contains an internal 1MHz oscillator which is kept synchronized
 to WWVB.  If the WWVB carrier is lost, the internal oscillator will
 keep running, and accuracy to plus or minus 1 millisecond will be
 maintained for about 10 minutes, at which time the synch lamp will be
 turned off, although the oscillator keeps running.
 The back panel also contains thumb wheel switches for time zone
 setting, propagation delay setting, and a leap year switch.  Yes,
 Virginia, a leap year switch.  The purpose of the leap year switch is
 to maintain the day count properly if the WWVB carrier is lost near
 midnight of Dec. 30 (on a leap year) or Dec. 31 (on other years).
 Price is $2600 for the clock itself, $190 for the loop antenna, and
 $35 for a rack mount kit.

APPENDIX C: LOADER SERVER MEASUREMENTS

 The numbers were average round-trip times calculated by the LDSRV.
 Each number is the average RT time seen during the load operation,
 which takes about 350 or so packets.  RT times are not calculated for
 packets that are retransmitted.
 The average RT time to ARPANET hosts on the same IMP is around 70
 msec. There were some times somewhat less and a few a bit more.  To
 MIT, the usual average RT time is about 450 msec.  To the Ft. Bragg
 PE or gateway, the smallest average RT time is 600 msec.  The largest
 average RT time was 1.2 sec.
 The usual average RT time to SRI PRNET TIUs is 170 msec.  The
 smallest time was not less that 100 msec and the largest is 400 msec.

Postel [Page 20]

                                                               IEN 160

Internet Meeting Notes

 To Ft. Bragg PRNET TIUs, the smallest average RT time is a bit more
 than 600 msec.  The usual RT time is around 800 msec and average RT
 times as large as 2.1 sec have been recorded.  Most of the loads had
 average RT times less that 1.1 sec.
 In the graphs, the y-axis is the number of loads in which the average
 round trip time was within the time bucket.
 ARPANET Hosts
 20-+
    |
    |
    |XX          XX
    |XX          XX XX
 10-+XX          XX XX
    |XX XX       XX XX
    |XX XX       XX XX
    |XX XX    XX XX XX XX XX XX
    |XX XX    XX XX XX XX XX XX    XX XX
 0 -+------------------------------------
    0   .2    .4    .6    .8    1.0  1.2  secs
 SRI PRNET Hosts
 20-+
    |   XX
    |   XX
    |   XX
    |   XX
 10-+   XX
    |   XX XX
    |   XX XX
    |   XX XX
    |   XX XX XX
 0 -+------------------------------------
    0   .2    .4    .6    .8    1.0  1.2  secs

Postel [Page 21]

                                                               IEN 160

Internet Meeting Notes

 Ft. Bragg PRNET Hosts
 80-+
    |                  XX
    |                  XX
    |                  XX
    |                  XX
 60-+                  XX
    |                  XX
    |               XX XX
    |               XX XX
    |               XX XX
 40-+               XX XX
    |               XX XX XX
    |               XX XX XX XX XX
    |               XX XX XX XX XX
    |               XX XX XX XX XX
 20-+               XX XX XX XX XX
    |               XX XX XX XX XX
    |               XX XX XX XX XX
    |               XX XX XX XX XX XX XX          XX    XX
    |               XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
 0 -+--------------------------------------------------------------
    0   .2    .4    .6    .8    1.0  1.2   1.4   1.6   1.8   2.0 secs

Postel [Page 22]

                                                               IEN 160

Internet Meeting Notes

APPENDIX D: RECENT DOCUMENTS

 Author     Subject                                  Number
 -------    ------                                   ------
                                IENs
 Postel     Internet Meeting Notes - 14 & 15 May 1980   145
 Perlman    Flying Packet Radios and Network Partitions 146
 Perlman    Utilizing Internet Routes as Expressways    147
                      Through Slow Nets
 Postel     Telnet Protocol Specification               148
 Postel     File Transfer Protocol Specification        149
 Plummer    TCP JSYS Calling Sequences                  150
 Cerf       Final Report of the Stanford University     151
              TCP Project
 Cerf       DoD Protocol Standardization                152
 Bennett    Realization of the Yellow Book Transport    153
              Service Above TCP
 Bennett    Realization of the Yellow Book Transport    154
              Service Above TCP (supersedes IEN 153)
 Bennett    The Yellow Book Transport Service:          155
              Principles and Status
 Cohen      Controlled Routing in the                   156
              Catenet Environment
 Flood Page CMCC Performance Measurement
               Message Formats                          157
 Haverty    XNET Formats for Internet Protocol          158
              Version 4
                                RFCs
 Postel     Internet Protocol Handbook TOC              766
 Postel     Structured format for Multimedia Mail       767
 Postel     User Datagram Protocol                      768
 Postel     RAPICOM 450 Facsimile Format                769
 Postel     Assigned Numbers                            770
 Cerf       Mail Transition Plan                        771
 Sluizer    Mail Transfer Protocol                      772
 Cerf       Comments on the NCP/TCP                     773
              Mail Service Strategy
 Postel     Internet Protocol Handbook TOC              774

Postel [Page 23]

                                                               IEN 160

Internet Meeting Notes

APPENDIX E: ATTENDEES

 Name                 Affiliation  Nationality   Mailbox
 ----                 -----------  -----------   -------
 Vint Cerf              ARPA        USA          Cerf@ISIA
 Don Allen              BBN         USA          Allen@BBND
 David Flood Page       BBN         British      DFloodPage@BBNE
 Jack Haverty           BBN         USA          JHaverty@BBND
 Bruce Hitson           BBN         USA          BHitson@BBND
 Dale McNeill           BBN         USA          DMcNeill@BBNE
 Virginia Strazisar     BBN         USA          Strazisar@BBNA
 Mike Wingfield         BBN         USA          Wingfield@BBND
 Gustav Fickenscher     BWB.MoD     Germany      ---
 Hoi Chong              COMSAT      Rep. China   Chong@ISIE
 Dave Mills             COMSAT      USA          Mills@ISIE
 Ed Cain                DCEC        USA          Cain@BBNB
 Hans Dodel             DFVLR       Germany      ---
 Helmuth Lang           DFVLR       Germany      ---
 J. Majus               DFVLR       Germany      ---
 Gerry Amey             DND/CANADA  Canada       ---
 Ray McFarland          DoD         USA          McFarland@ISIA
 Romy Fratilla          ELEX        USA          Deckelman@ISIA
 Horst Clausen          IABG        Austria
                                          Clausen.IABG@MIT-Multics
 Danny Cohen            ISI         USA          Cohen@ISIB
 Jon Postel             ISI         USA          Postel@ISIF
 Cliff Weinstein        Lincoln Lab USA          cjw@LL-11
 Estil Hoversten        Linkabit    USA          Hoversten@ISIA
 Dave Clark             MIT         USA          Clark@MIT-Multics
 Frank Deckelman        NAVELEX     USA          Deckelman@ISIA
 Oyvind Hvinden         NDRE        Norway       Oyvind@DARCOM-KA
 Yngvar Lundh           NDRE        Norway       Yngvar@DARCOM-KA
 Paal Spilling          NDRE        Norway       Spilling@SRI-KL
 Vince Hathway          NPL         British      ---
 Andrew Bates           RSRE        British      T45@ISIE
 Trevor Benjamin        RSRE        British      T45@ISIE
 Brian Davies           RSRE        British      T45@ISIE
 Roger Edwards          RSRE        British      T45@ISIE
 Alan Fox               RSRE        British      T45@ISIE
 Silvia Giles           RSRE        British      T45@ISIE
 John Laws              RSRE        British      T45@ISIE
 Paul Masterman         RSRE        British      T45@ISIE
 Jo Penley              RSRE        British      T45@ISIE
 Gill Roberts           RSRE        British      T45@ISIE
 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

Postel [Page 24]

                                                               IEN 160

Internet Meeting Notes

 Chris Bennett          UCL         British      UKSAT@ISIE
 Robert Cole            UCL         British      UKSAT@ISIE
 Ron Jones              UCL         British      UKSAT@ISIE
 Steve Treadwell        UCL         British      UKSAT@ISIE

Postel [Page 25]

/data/webs/external/dokuwiki/data/pages/rfc/ien/ien160.txt · Last modified: 2001/06/25 19:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki