GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien175
                                                             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]

/data/webs/external/dokuwiki/data/pages/rfc/ien/ien175.txt · Last modified: 2001/06/25 20:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki