J. Postel
IEN 121 ISI
25 October 1979
Internet Meeting Notes - 10, 11, 12 & 13 September 1979
I. INTRODUCTION TO UCL - Jones
Ron welcomed us to UCL and discussed the arrangements for facilities,
refreshments, and lunch.
II. OVERVIEW AND OBJECTIVES - Cerf
Vint reviewed the need for a working internet system and cited the
performance of the system as a key issue. The development of
procedures to measure and test the performance of the internet are
now important. Vint has pointed out that several conceptual design
issues need to be resolved, for example, protocol support for voice
conferencing in the internet.
III. STATUS REPORTS
A. DARPA - Cerf
Vint reported that the Director of the ARPA Information Processing
Techniques Office, Col. Dave Russell retired on 31 August. The
new Director is Dr. Robert Kahn.
The standardization of IP and TCP for use as the DOD networks
protocol is progressing. Dr. Robert Lyons at DCEC is the
Executive Agent. The only changes that are necessary are to
incorporate mechanisms to pass the security and precedence
information between the application program and TCP, and between
TCP and IP. There already is an IP option to carry that
information in the internet.
There is a need for a way to test TCP implementations and
applications that use TCP without taking a service machine down.
For TOPS20s this will be satisfied by using BBNF. BBNF is
currently only on the BBN RCCNET but will be connected to the
ARPANET for October through December 1979.
Vint acknowledged that there have been hardware delivery delays
that have had a substantial impact on the internet program. The
delivery schedules from manufactures are very long.
Postel [Page 1]
IEN 121 Internet Meeting Notes The program managers in the ARPA office are coordinating to have all new applications use internet protocols. B. BBN - Haverty, Plummer, Strazisar, McNeill, Flood Page Jack reported that the BBN-Unix TCP is in regular use. Currently work is in progress to provide a user interface to the IP layer. The IP support is available as a subroutine package. The interface will be similar to the TOPS20 interface documented in IEN 108. BBN is also working on a VAX UNIX with the goal of having the current 11/70 UNIX and VAX UNIX be compatible at the applications level. Bill reported on the plan to attach BBNF to the ARPANET for ease in testing TCP and TCP using applications. In doing this testing it is preferred to have one person at a time to simplify the identification of problems. Note that one will have to use new 1822 (96-bit leaders) to access BBNF since it will be on IMP 67. The latest IP and TCP and Telnet are installed at ISID and ISIE TOPS20 Systems. In the last month or two several bugs have been identified and fixed. The next major step is to complete the TENEX version of TCP-4 and to eliminate any remaining instances of TCP-2.5. It is assumed that both the Packet Radio Project and UCL have completed their conversion to version 4, and that as soon as the SATNET project completes its conversion version 2.5 can be eliminated. The LDRSRV program was converted to use IP in a few hours. An FTP on TCP, based on ARPA FTP, is in debugging. Ginny reported that several gateways are running, most are MOS based. It is planned to phase out the remaining ELF based gateways. MOS Gateways at UCL between UCLNET and SATNET at NDRE between ARPANET and SATNET at BBN between ARPANET and SATNET at SRI between PRNET and ARPANET ELF Gateways at Ft. Bragg between PRNET and ARPANET It is planned to install a gateway at COMSAT between SATNET and the COMSAT local net. There is a new monitoring system. A configuration with a port expander and a gateway in the same machine is planned, it will be a tight fit. Dale reported on the SATNET conversion to use IP. There are still Postel [Page 2]
IEN 121 Internet Meeting Notes a number of programs to be converted, but it could be completed in about a month. Most of the remaining programs are used for maintenance or error recover. A weekend test was conducted using IP only. The major event impacting SATNET will be the removal of the NORWAY-LONDON ARPANET line at the end of September. This means all the LONDON ARPANET traffic will be routed via SATNET. David noted that the scheduled GMCC demonstration will be a presentation, since there is nothing to demonstrate. C. COMSAT - Mills Dave reported that the ETAM and GOONHILLY PSPs are in the field and the TANUM PSP will be shipped soon. There have been some minor problems, for example, the software checksum and the hardware checksum do not agree. It is expected that the PSPs will be on the air next month. Much of the COMSAT activity during the last few months has been directed to the NTC Demo in November and development of the Demo Terminal software. Currently, we have made arrangements for a suitable room and are now planning installation of lines, terminals and other gear. The demo will include speech, fax and the usual interactive and bulk transfers between ARPANET hosts and the Demo Terminal. The Demo Terminal software has been checked out at UCL using an LSI-11, floppy disk, LPCM and Port Expander connected to UCLNET (net 13). TCP/Telnet was tested with ISIE via UCLNET, SATNET and ARPANET. FTP was checked out in loopback mode via the UCL Gateway. The LPCM was operated in expensive dictaphone mode only, since support is not yet complete for SATNET streams. This software will play with the Demo Terminal software at COMSAT and at the NTC Demo. At COMSAT a Dacom 450 FAX machine has been delivered. This will be connected to the Demo Terminal and taken to the NTC site. Software to support this machine is now in frenzied development. When complete an update will be distributed to UCL. For local testing we are trying to arrange a direct connection to ARPANET (avoiding the SATNET for the time being) for debugging. D. DCA - Cain Ed reported that DCEC has a small (2-page) "C" program running in an 11/34 with two 1822 interfaces which implements a gateway. Postel [Page 3]
IEN 121 Internet Meeting Notes E. DOD - McFarland Ray noted that mid October is the target date for the draft DOD Standards IP/TCP document. These documents will be rewritten to military document conventions. F. ISI STATUS - Postel Jon noted that ISI is not implementing any IP, TCP or Gateways. ISI did attempt to write a program that used TCP on TOPS20. This program did not work (TOPs'20 crashed). Debugging is in progress with Bill Plummer and the ISI systems staff. ISI is working on an Internet Message Program. This is in an early testing phase and will be using TCP for inter module communication. G. LL - Forgie Jim noted that the main Lincoln effort has been on the ST protocol to be discussed later and described in IEN 119. Experiments with ARPANET-SATNET speech have been conducted with one source/destination in the ARPANET and another in the SATNET. There have been unexpectedly large delays in the SATNET streams, and in matching the ARPANET to the SATNET in the special purpose Gateway. H. MIT - Clark, Chiappa Dave discussed the status of the LSCNET. There is a 5 node system up and running. The development of a version 2 interface is in progress. There has been difficulty getting an LSCNET/ARPANET gateway working due to low level hardware problems. A Trivial File Transfer has been implemented directly on IP. In Multics the IP layer will act as a gateway. MIT will be involved in the XEROX Grant program. Dave will be involved in integrating the Xerox equipment into the LCS environment. A PDP-11 based gateway between LCSNET and the ETHERNET is contemplated. Noel commented that he saw a need for an effort to be made to convince groups to use IP rather than invent their own protocols. I. NDRE - Stensby NDRE has been assisting in the preparations for the speech demo. The protocol status is nearly the same as last reported. This is due to VDH connection problems. Much work has been done on debugging the connection. Possible bugs have been very difficult to track down because we lack control of vital parts of the system. A couple of bugs have been found and corrected in the Postel [Page 4]
IEN 121 Internet Meeting Notes NORD-10 VDH software without any substantial effect. The real problem seems to be that at certain times when the TIP has sent a packet out of sequence, it keeps retransmitting this packet instead of retransmitting the packet that is really missing. J. RSRE - Davies Brian reported that RSRE has programmed a gateway (based on IEN 30) and attempted to bring it up as a catenet gateway between UCLNET and RSRENET. RSRE will be bringing up a host with IP and TCP in about a month. K. SRI - Kunzelman, Mathis Ron reported that SRI is now operating two PRNETs in the San Francisco bay area, and one PRNET at Ft. Bragg, North Carolina. The net at Ft. Bragg is now eight terminals on two TIUs, and will grow to forty terminals. Jim reported that the LDRSRV at SRI-KA which now uses TCP-2.5 will be changed to use version 4 soon, tested at BBNF, and installed at ISID and ISIE. Jim is also working on a Port Expander and Mini Gateway combined. L. UCL - Kirstein, Jones, Treadwell, Cole, Bennett, Higginson Peter gave a brief overview of the UCL effort, then let various members of the UCL group give reports on their activities. Ron discussed the problems of including network software in a small Unix system. There was also some discussion of port expanders and X.25/IP interfaces. Steve reported on the situation with the FAX experiment. The main problems seem to be with the timing constraints of the device, and matching these to the flow control constraints of TCP. This system currently uses TCP-2.5 but will convert to version 4 soon. Bob reported on the development of a "C" to MOS linkage. Chris discussed the prototype NIFTP service that allows FTPs from EPSS to Tenex and vice versa. A Unix version of NIFTP has been implemented. Peter discussed the many flavors of X.25 one finds when building X.25/XXX interfaces. Postel [Page 5]
IEN 121 Internet Meeting Notes M. IRIA & CELAR - Zimmerman Hubert said that IRIA and CELAR would like to explore the possibility of cooperative research on the interconnection of networks. IRIA is working on local networks and interconnection with TRANSPAC and CYCLADES. N. UNIVERSITY OF ROCHESTER - Lantz Keith gave a brief overview of the environment at the University of Rochester and indicated the interest in becoming part of the internet system. IV. ACTION ITEMS A. DOCUMENTATION STATUS - Postel Jon reviewed the IENs issued since the last meeting. IEN Author Title --- ------ ----- 108 Plummer Internet User Queues Describes the TOPS20 user interface to the IP. 109 Strazisar How to Build a Gateway Describes the messages Gateways exchange with each other and with hosts, i.e., the Gateway-Gateway protocol. The main focus is on the computation of connectivity and routing information. Replaces IEN 30. 110 Cerf Internet Addressing and Naming in a Tactical Environment Presents several addressing problems, particularly the "flying packet radio" problem. 111 Postel Internet Protocol 112 Postel Transmission Control Protocol The latest editions of the IP and TCP specifications. Not intended to be a change to the protocols but a better documentation of them. Replaces IENs 80 and 81. Postel [Page 6]
IEN 121 Internet Meeting Notes 114 Postel Protocol Options Summarizes the option available with IP and TCP. Replaces IEN 92. 115 Postel Address Mappings Shows how the addresses of various networks are carried in the Internet Address format. Replaces IEN 91. 116 Postel Internet Name Server Specifies the Internet Name Server, including same new features suggested by John Pickens. Replaces IEN 89. 117 Postel Assigned Numbers Lists the assigned number for various protocol fields, e.g. Networks, Sockets or Ports. Replaces IEN 93. 118 Postel Internet Protocol Handbook Table of Contents A one page list of the IENs that specify the current internet protocols. Replaces IEN 94. 119 Forgie ST - A Proposed Internet Stream Protocol The description of a Internet level protocol for voice conferencing. Includes features for establishing multi-addressee connections. The discussion that followed suggested several things that should be documented. For example, the higher level protocols (Telnet, FTP) should be in the internet protocol handbook, the procedure for determining parameters (e.g. retransmission timeout) should be documented, what to do in exception conditions should be described, testing procedures should be discussed (especially an acceptance test). Concern was expressed that the new editions of the IP and TCP specification were not suitably reviewed by the implementors. It was suggested that a version with changes marked would be useful (see Appendix B). Postel [Page 7]
IEN 121 Internet Meeting Notes B. EXPECTED DOCUMENTS 1. IP Generic Services - Do the two documents 1) the IP Spec by Jon (IEN 111), and 2) the Gateway Spec by Ginny (IEN 109), supply the information needed? 2. SATNET IP Services - Dale McNeill is working with Dave Mills (currently the only user). When the current experiments are completed a document will be produced. 3. Transition Plan - Vint will discuss the issues in a small group meeting and appoint a task force to prepare the plan. 4. Host IP Services - Bill Plummer will prepare a document based on his talk on How to Build a Host IP. C. XNET - It seems that XNET is not yet fixed to work with IP due to a technical disagreement between Jim Mathis and Ray Tomlinson. The solution to this is to be reported on at the next meeting. D. Hack IP at SRI-KA and LDRSRV - This is working according to Jim Mathis. V. INTERNET TRAFFIC EXPERIENCE - Davies RSRE has conducted some experiments sending messages looped back to themselves, with the loopback being located at various places, and using several input speeds and block sizes. At RSRE there is a multi-terminal TIU with some modifications to perform measurements. The TIU measures the time between the TCP segment first being sent and the acknowledgment arriving, a kind of round-trip time. The path is TIU via 2.4Kb line to PIXIE to PORT Expander to TIP into ARPANET. The input was either typing, a 1 octet segment traffic generator, or a 128 octet segment traffic generator. Histograms of performance under various inputs and loopback points were presented. The results indicate lower than expected performance and the speculation was that the limiting factor was the program interrupt 1822 interface (either in PIXIE or the Port Expander). It was noted that when two traffic generators were run sending segments to each other, ACKs were piggybacked 100% of the time both at the TCP level and at the X.25 level (recall the RSRE to PIXIE line operates the X.25 level 2 link protocol). Postel [Page 8]
IEN 121 Internet Meeting Notes VI. HOW TO BUILD A GATEWAY - Strazisar Ginny discussed the way gateways determine how to do routing. The actual messages used are documented in IEN 109. A gateway gathers information on network connectivity by polling its network interfaces and known neighbor gateways. The polling is done by sending a message, currently every 30 seconds. There is an algorithm to decide if a net or gateway is up or down based on the results of the polling. The routing algorithm is based on a distance measure, a directly connected network is zero distance, an unreachable network is infinite distance. The gateways exchange with neighbors their distance tables (substituting infinity in entries where the distance to the destination is greater than the distance from the neighbor). Routing information is sent only when something changes. A new gateway can join the system as long as old gateways can add a row to their tables dynamically. Note that "smart gateways" do all this routing and connectivity work, "dumb gateways" do not. Smart gateways try to route things to other smart gateways, but if that can't be done they may fall back to using compiled in fixed routes to dumb gateways. Danny Cohen suggested that there may be problems with this algorithm as the number of networks gets large. VII. HOW TO BUILD A HOST IP - Plummer Bill presented the general flow of processing in a Host IP. In general datagrams arrive from the connected network interfaces. Any fragmented datagrams are reassembled. Complete datagrams are entered into a queue. Datagrams addressed to other hosts may be forwarded if this host is acting as a gaweway, otherwise they are discarded. Datagrams addressed to this host are delivered to waiting protocol modules or user processes. User processes or protocol modules may create datagrams to be sent, these are queued and based on the destination address sent via one of the connected network interfaces. During the processing of arriving datagrams several checks must be made: 1. check the IP version number 2. verify the checksum 3. see that the length field and the amount received are consistent (amount received may be slightly greater due to padding) 4. check time to live 5. assemble fragments Postel [Page 9]
IEN 121 Internet Meeting Notes When sending a datagram the IP fills in several fields and makes a routing decision: 1. Insert source address 2. Insert any IP options called for 3. Insert time to live 4. Insert checksum 5. Make a routing decision, select an output interface, generate local net header and interpret type of service. 6. Queue for transmission The routing decision can be based on a table of network - gateway correspondences. For each network a gateway on a directly connected network is listed. If the host is notified to use a different gateway for that destination network the table can be updated. If a gateway breaks and the host can tell (e.g., receives a "destination dead" response) then switch to an alternate gateway. It is suggested that a heuristic for switching destination gateway is to do it when the higher level protocol (e.g., TCP) retransmits a segment. (However it is not clear the IP can tell a new transmission from a retransmission). In the area of congestion control Bill suggests that it is the rate that must be controlled which may be considered to determine an internet datagram interval. If a gateway tells a host to slow down, increase the internet datagram interval to, say, 130% of its former value. To avoid being stuck at a too large value for the internet datagram interval, reduce it to 95% of its former value every 30 seconds or so. There is an issue of fairness in any congestion control. How can the IP properly allocate the available transmission capacity among the higher level protocol modules and users? The discussion suggested the need for a "Trace Datagram" that causes each gateway and the destination host to send back a note, a kind of "multi-echo." IP modules should provide a handle on the user side to explicitly cause a new routing to be calculated. The congestion control parameters may be very critical and sensitive. Dave Clark has done some simulation experiments and will prepare an IEN on this topic. There may be some interaction between source-destination host pairs in this area. Postel [Page 10]
IEN 121 Internet Meeting Notes VIII. STREAMS AND CONFERENCING - Forgie Jim presented the proposed ST protocol which is documented in IEN 119. The goals of ST are: (1) to provide a good base for point-to-point and conference packet speech, (2) to support research on effective traffic control techniques, (3) to support a demonstration of cost-effective speech, and (4) to operate as an extension of internet protocol. Jim indicated four requirements and corresponding approaches for meeting them: (1) guaranteed data rate - know requirement in advance and assign loads to links statistically, (2) controlled delay (predictable dispersion) - prevent congestion by controlling access on a call basis, (3) small quantity of speech per packet - use abbreviated header and aggregate small packets for efficiency, and (4) efficiency equal to or better than circuit switching without TASI (packet efficiency * link utilization > 45%) - abbreviated headers for packet efficiency and high link utilization with effective traffic control. One of the key decisions is to consider ST connections to be full duplex. The claim is made that this allows faster connection setup for conferences. There was some discussion on this point and the issue will be examined further. Another issue is the sharing of transmission capacity between speech (ST) and data (IP) in the internet. Also discussed was the identification of the route by a list of gateways rather than by a list of networks. The resources to be reserved are controlled by networks not gateways. One very interesting feature of ST is its mechanism for flexible multi-addressing and routing of messages such that each addressee receives at most one copy of a message. Jim presented the message formats and worked through an example of connection setup. There was some concern expressed about the effects of delayed duplicate control messages, and how ST operates under failure conditions. Also concern that several conference setups in competion may result is a deadlock similar to reassembly lock up. Postel [Page 11]
IEN 121 Internet Meeting Notes IX. SOURCE ROUTING & PROTOCOL MULTIPLEXING - Cohen Danny reviewed the proposed source routing procedure described in IEN 95. This mechanism provides a list of addresses for the datagram to pass through. Normal routing is used to move the datagram between these points. The route information for sending a datagram from A through B and C to D is expressed by A as TO: B, SR: C,D. At B this is changed to TO: C, SR: D, and at C it is changed to TO: D. The key is that the next address must be interpretable at the point it is used. This means that local (rather than internet) addresses may be used. The discussion focused around the issue of non internet addresses in the source route and how (if at all) to mark them. It seems desirable to let a source route contain any of the following in any order: 1. Internet Address. 2. Local Address (prefixed with an escape code and a length). 3. Network Address (Network part only). 4. Here - an address value that means this host, this net (or any host, or every host). Alternately one could have each address in the source route have a prefixed "op-code" that indicates what kind of address it is. Danny did not discuss the multiplexing of protocols (due to time pressures) but urged everyone to review IEN 90. It appeared that the multiplexing protocol was accepted (at least in principle). X. GATEWAY MONITORING & CONTROL CENTER - Flood Page David described the GMCC organization and the types of information that will be reported. The operation is much like the ARPANET NCC except that gateways are the objects of interest rather than IMPs. Gateways will communicate with a set of monitoring and control processes (running on a TOPS20 somewhere). These monitoring and control processes will update a central data base. The data in this data base may be accessed by Terminal Processes (i.e., User Interface Programs). A terminal process may take control of a gateway, but a gateway may only be controlled by one terminal process at a time. Three types of controls may be exercised: start or stop reports, inquiries, enable or disable traps. The reports give throughput Postel [Page 12]
IEN 121 Internet Meeting Notes statistics and interface up/down status. The inquiries give the gateway description (name, connectivity), echo response, or routing data. The traps give changes in the interface up/down status, or neighbor gateway up/down status. The information stored for each gateway in the central data base includes: the latest regular report, the interface address, the neighbor gateways, the reporting and trap status, the gateways own up/down status, and the process currently controlling the gateway (if any). In the future the GMCC will provide summary reports on traffic and up/down status. Other future topics are Performance Measures, Higher Level Fault Diagnosis, Accounting Information, and inclusion of information from NCCs. To use the GMCC facilities one would login to the GMCC host and run a terminal process. There was some discussion of the access control on people taking control of gateways. Also some concern about the artifact introduced into the measurement by accessing the GMCC via the gateway being measured, and also the effect on other gateways (or their statistics) of relaying the measurement messages to the GMCC host. David will prepare reports on: (1) GMCC Message Formats, (2) How to use a Terminal Process. XI. DISCUSSION OF SPEECH DEMO - Forgie Jim described the configuration for the speech demo. There are four sites involved: Lincoln Laboratory and ISI on the ARPANET and NDRE and UCL on the SATNET. There is a special purpose gateway at BBN. This gateway is a PDP 11/34 ELF system. The basic data rate for one site is 5 packets/sec, at this rate the gateway must handle 15 packets/sec. In the ARPANET section of the conference the mode of operation is centralized control and distributed data. In the SATNET section the mode is distributed control and distributed data. The SATNET section uses a SATNET shared stream. XII. DISCUSSION OF FAX SYSTEM - Treadwell Steve described the configuration and operation of the FAX-Network system. The FAX machine is a DACOM 6000. It is connected to an LSI-11 (MOS operating system). The LSI-11 contains an interface to Postel [Page 13]
IEN 121 Internet Meeting Notes the DACOM, a TCP, and a controlling program. The controlling program interacts with a user at a display terminal. There is also a server FAX program on BBNC that accepts input and stores it in the file system, or on request sends stored FAX data from the file system. The operation is for the user to type on the controlling programs terminal a request to send FAX data to a file. A TCP connection is established between the LSI-11 and FAX server at BBNC. Pages are input through the DACOM and data is sent to BBNC and stored in the file. To move FAX data from the file to paper, the user enters a retrieve request on the controlling programs terminal. This system currently uses TCP-2.5. The next step will be to convert to using version 4. Also to change the address so the transmission will be through an internet gateway. There have been several problems in getting this working. Primarily the timing requirements of the DACOM and the flow control of TCP. A typical page results in 300,000 bits (with wide variance). The DACOM sends 585 bit blocks and if not accepted with in 6 seconds aborts the page. The total transmission path must support at least 100 bits/sec on the long term average. ISI is getting a RAPICOM 450 FAX machine and will use it in a similar way. (A RAPICOM 450 and a DACOM 6000 are identical machines). At ISI the FAX machine will be treated as a device (a peculiar terminal on TOPS20) rather than as a host. XIII. ADDRESSING ISSUES - Cerf Vint described several situations where a host may have several possible addresses and may wish to change between them dynamically without losing ongoing communications. A host may be dual (or multiply) homed, i.e., have two (or more) interfaces to the same net. A host may be connected to more than one net. Or a host may change nets. This last case is illustrated by a flying packet radio, passing over a series of ground PRNETs each connected to the internet via a gateway. The flying packet radio is for a time in the range of PRNET-1, then passes out of that range into the range of PRNET-2, etc. Another problem is partitioning. That is a network breaks into two (or more) parts which continue to function independently. Can a host Postel [Page 14]
IEN 121 Internet Meeting Notes in one part communicate with a host in another part via gateways and other networks? Does source routing solve the partitioning problem? Or is a scheme needed to dynamically assign unique addresses to each partition so that the ordinary gateway dynamic routing will solve the problem? Another proposal is to drop the requirement that connection be identified by the total address. By using only the pair of ports to identify a connection one could accept as a continuation of a conversation messages from a different host if it had the same pair of ports (and the expected sequence number). XIV. PARTITIONING - Plummer Bill discussed the problems of multiply connected hosts. If a host is connected to two networks, which are also interconnected via gateways, the host has alternate routes to use in sending messages. The internet gateways can exchange connectivity information. A multiply connected host cannot take full advantage of this without being a gateway itself and calling the host a network. Another problem is for a destination to answer a message from a multi- connected host. The multi-connected host would like to allow any of its interfaces to be used to receive the reply. To do this it could use a pseudo network number and act as if those interfaces were gateway connections. This use of network numbers for pseudo nets may use up the network numbers too quickly. Bill proposes what he calls host-group routing which uses a 32 bit address as if it were a network number. A host chooses one of its internet addresses as its "name". Gateways treat that name as a network name for connectivity and routing purposes. A mask can be used to allow groups of hosts to be routed based on one entry. Bill gave an example of how this might work and showed a routing table for a pseudo net at BBNC. This topic is to be discussed again at the next meeting. XV. RIG - Lantz Keith reported on the network environment at the University of Rochester. The key is a multi-machine multi-net system started in 1974. All communication between processes in this system is via messages. The system is based on Feldman's experience and other papers on message communication. The equipment involved includes: 4 Altos, 2 Eclipses, an Ethernet, 9 terminals, 1 PDP-10, 1 VAX, and an ARPANET. The applications include: editing, compiling, file management. An important Postel [Page 15]
IEN 121 Internet Meeting Notes development is the virtual terminal model, which allows several processes to interact with a terminal using multiple possibly overlapping windows. The process level communication involves a name to address conversion by lookup in a name server, and an address to route conversion supported by a local kernel and network communication modules. Three communication styles are supported: atomic transactions, connections or streams, and asynchronous messages. One problem area is protocols. There are too many: U of R Ethernet, PARC Ethernet, ARPANET, DECNET, internet. Can all these live in harmony? XVI. SUMMARY OF SMALL GROUP MEETINGS 1. PERFORMANCE MEASUREMENT SMALL GROUP MEETING - Kunzelman This group discussed the need for performance measurements of the internet protocols at all levels. The group reviewed the current work, discussed performance metrics, measurement tools, and documentation of measurement methods and results. The group recommends that specifications of performance measures for IP and TCP be written, that a set of tests for IP, TCP, and higher level protocols be defined, and that a bibliography on performance measurement be prepared. Please see Appendix C for further detail on this group meeting. 2. UNIX SMALL GROUP MEETING - Cain Three topics were addressed in the UNIX small group meeting: 1. Use of network UNIX on small PDP-11's (specifically, the 11/34 and the 11/40). 2. MOS work on UNIX systems. 3. Use of UNIX on VAX machines. For PDP-11's which do not support the separation of instruction and data space, incorporating the widely distributed NCP programs into the UNIX kernel usually produces an object which is barely small enough to boot, even after greatly reducing various system parameters. Processes like TCP and Telnet have to share the scarce remaining space, and are bound to perform poorly because of swapping. Noel Chiappa is about to obtain, from NOSC, a version of UNIX which has no disk buffers in the kernel data space, and will attempt to install the NCP kernel software. Performance of this Postel [Page 16]
IEN 121 Internet Meeting Notes version of UNIX is uncertain, but a mailing list (see Appendix A) has been established for those interested in the outcome. UCL, MIT, and BBN are all interested in doing MOS work in a UNIX environment. The problem is that there is a variety of file types (a.out, .obj, .rel, .lda) which must somehow be combined into an object which is loadable into an LSI-11, and is understandable by DDT or a similar debugger. UCL has "C" interfaces to MOS system calls and some utilities which Noel Chiappa will attempt to put in a "nice" UNIX environment, and make them available for others. A mailing list (see Appendix A) was established for those who wish to follow his progress. Keith Lantz discussed a meeting with ARPA, Rochester, CMU, and others associated with ARPA-funded research involving VAX machines. At the meeting, the decision was made to use UNIX on the VAX machines, specifically the version of UNIX modified at Berkeley to take advantage of the VAX paging hardware. The source of support for the VAX UNIX is not yet named. Rochester and CMU are both interested in implementing TCP and IP on their VAX machines. A mailing list (see Appendix A) was established for those interested. 3. TCP VERSION 4 AND TIU SMALL GROUP MEETING - Haverty The small group meeting on the status of the new TCP implementation and TIU also covered some general issues of TCP support for MOS-based systems in general. Jim Mathis reported that recent work on the MOS TCP version 4 implementation involved separating the code into individual modules, to isolate the network- and operating-system-dependent sections of the code. The major part of the TCP code is now in the TV4PRO module. Operating system support code exists in TV4MOS or TV4ELF, depending on the operating system involved. The "released" versions of this implementation are available on the SRI-KL machine in the MOS-DEVEL directory, but they will be moved soon to PKT-LSI-11. Ongoing work with the TCP involves addition of an internet layer which will be accessible to user processes using entry points to be defined. This will occur in a later release of the software, which is not expected to involve any changes to the TCP interface to user processes. The internet layer will also implement some of the gateway-gateway protocol functions. In addition, the software can be extended to support multiple hardware interfaces, to permit multi-homing of hosts on multiple networks. This work however is not yet in progress. Postel [Page 17]
IEN 121 Internet Meeting Notes The discussions which followed identified a need for two new mechanisms within the user community. The first is simply an announcement mechanism, to inform users of the SRI software of new releases, the changes which have been made, functions added, and location of the code itself. A second mechanism involves integration of changes developed at user sites into the SRI-maintained sources. For example, software to support other network types must be done at the site running the network, but should then be integrated into the standard sources. Because of the need for sites other than SRI to implement network-interface software, the internal interface between the TCP and internet layer and the local-net module must be clearly defined and stabilized. MIT is likely to be the first site to implement a new local-net module. Further discussion explored details of the functionality of the existing TCP implementation, and requirements which various user projects expect to have in the future. Some of the facilities not yet implemented include: o ability to have multiple connections in one MOS process o reassembly of internet fragments o full processing of EOL o processing of "rubber EOL" o user access to URGENT functions o full functionality at the Telnet user interface The last area explored identified the need for additional work on the Telnet implementation, to, for example, provide the ability to send remote RESETs. A short discussion of "coming attractions" followed, including the following expected changes: o internet layer in Bliss, probably by the end of 1979 o use of the internet name server by Telnet o XNET server within MOS, to debug MOS processes remotely The TCP software is currently written in MACRO-11. It is a candidate for conversion to Bliss, but this will not be done until the Port-expander software is converted. One possible performance limitation was identified during the discussion. Currently, data is ACKed when it is accepted by a user process. Since this can be significantly later than the actual receipt of the data from the network, throughput might be improved by modifying the TCP to ACK data on receipt from the network. Postel [Page 18]
IEN 121 Internet Meeting Notes A short discussion of TIU issues identified the need for determining how many terminals can be supported by a TIU at once, in two cases. In a heavy-use situation, the limitation on number of active, high-throughput terminals should be determined. This number is probably limited by the raw speed of the LSI-11, and may be increased by conversion to faster hardware such as the PDP-11/23 when it is available. A second case involves the limitation on support of low-usage terminals. This limit involves primarily how many serial interfaces can be connected to the LSI-11 and configured in the packaging. The meeting also demonstrated a need for better interchange of information among the participants and general community of users of MOS, TIUs, and related hardware and software. A mailing list is being set up, called MOS-TCP, for this kind of activity (see Appendix A). 4. LONDON-NORSAR LINE AND SATNET SMALL GROUP MEETING - McNeill Dale said that loading of the Goonhilly SIMP and the london TIP over the satellite channel is operational. Monitoring and control paths exist for all SIMPs; sufficient backup paths exist through use of the satellite channel and gateways connected to other SIMPs. Vint announced that beginning January 1, l980, the NORSAR-SDAC circuit will become a military circuit for operational data only. Seismic data traffic from the NORSAR TIP will continue to be sent on this line. Funding for the London-NORSAR circuit ceases October 1, 1979. Peter anticipates that the ARPANET direct connection circuit via SATNET (line 77 between London and SDAC) will be needed to provide ARPANET connectivity to the London TIP until some time after October l980. This circuit will continue to provide ARPANET service to the Rutherford Lab, EPSS, and the London TIP. The long-term goal is to have internet service to London only using the UCL gateway attached to SATNET. Prerequisite is a change of the London TIP to a host (TCP TIP). The mechanism of internet loading and support of London machines must be developed. In conflict with the maintenance of operational service to London is the introduction and checkout of PSP Terminals, the checkout and release of new SIMP software, and the checkout and performance of the NTC demonstration. Hardware and software development will be restricted to after 1400 EDT, while operational service will be maintained from 0200 to 1400 EDT, daily. Postel [Page 19]
IEN 121 Internet Meeting Notes 5. NTC DEMO PLANNING SMALL GROUP MEETING - Mills The principal results from that meeting were a revised plan for network connectivity and a change in the way speech would be handled. Specifically, it was decided that Jim Forgie's software would be used in the BBN and UCL gateways with the LPCM operated from Washington via appropriate data lines to the BBN Gateway. Jim has already made provision for this in the LPCM design, but it has not been operated in this mode before. Datagram traffic for the Demo is planned to be sent via Clarksburg, with a backup to Etam via a backdoor connection via the Clarksburg SIMP internal gateway and the RCC or other suitable hack. UCL will participate in the Demo from London with live speech and fax. Participation by NDRE will depend on a PSP Terminal being installed there. Jim mentioned a couple of minor problems with the LPCM hardware. Correcting these will probably involve sending ROMs to the various sites. There is a question of Gateway reliability which leaves all of us nervous 6. IP/TCP FLOW CONTROL SMALL GROUP MEETING - Clark This meeting was a fairly informal discussion among the implementors of TCP and gateways. Several topics were discussed. 1) How to manage RFNMs on internet link. 2) A simple simulation of a host responding to quench messages. 3) How to perform quenching experiments, given the current level of internet operation. 4) Should the TCP-IP or application-TCP interface be specified/standardized with respect to flow control? While the discussion was fruitful, no substantial conclusions were drawn. 7. X.25 GATEWAY SMALL GROUP MEETING - Binder The purpose of this meeting was to review various factors impacting the development of an ARPANET/X.25 gateway using an LSI-11 to provide a 50 Kbps full duplex service. The meeting basically covered only the issue of hardware interfacing to the X.25 network. Three different interfaces were discussed: a byte-interrupt device, a non-DMA packet-interrupt device, and a full DMA device. The byte-interrupt interface and related level 2 and 3 X.25 software has been developed by UCL and is now available for use. Although precise throughput measurements have not yet been made, Postel [Page 20]
IEN 121 Internet Meeting Notes experience with the LSI-11/MOS system by meeting attendees indicated that a byte-interrupt configuration would not achieve 50 Kbps full duplex operation. In particular, measurements by SRI have indicated a maximum of about 50 Kbps through a looped-back 1822 byte-interrupt interface on a MOS system running only a message generator (no gateway or second network interface). The packet-interrupt interface is being developed by RSRE, and along with level 2 software is expected to be checked out in 6-8 weeks. This interface contains 4K bytes of buffering, shared among input and output. Operation consists of copying packets between the interface memory and main memory, with a single interrupt associated with each packet. UCL plans to develop a full DMA interface, but this is not expected to be available until anywhere from 8 to 12 months from now. A framing issue presently exists in that both IPSS and Telenet X.25 networks now use bi-sync framing. However, both are expected to make HDLC bit-oriented framing available this fall. 8. PORT EXPANDER SMALL GROUP MEETING NOTES - Davies 1. Hardware Delivery Outlook. SRI has fifteen systems on its order book and enough components to build only two complete ones at this time. Some of the hardware bottlenecks are: a) Boxes from DEC - deliveries up to January '80. b) Low power Schottky chips for 1822 DMA boards. c) Cable connectors for 1822 units - Amphenol. d) Control Panels. Delivery of port expander units would continue at a slow rate at least until the end of the year with Vint Cerf nominating the recipient of each system as it rolls off the production line. A postscript on the hardware discussion concerned the robustness card which may have to be reprogrammed for automatic loading from nets which are not on the ARPANET. The robustness card uses UV erasable PROMS. Mathis said that there would be documentation supplied with the robustness card indicating how this should be done. The cards themselves were just coming back from the printed circuit facility and although one or two types of chip for this board were in short supply, it was hoped that board delivery would begin at the end of September. Postel [Page 21]
IEN 121 Internet Meeting Notes 2. Software Developments. Most of the discussion centered around the new facilities which would be offered with the SRI supported BLISS-11 version of the PORT Expander code. Some of these features are: a) Provision of NOP handling. b) Provision of IMP padding. c) Flow control facility. d) Facility to simulate RFNMs internally. There were still some open ended problems like what should a port expander do when the NCP host crashes. One possible approach is to offer two different solutions to this problem and select one at configuration time. Possible release dates for the BLISS-11 version of the port expander were mid October if Mathis can get an IMP port for debugging or up to a month after depending on the priority of the work. Finally Strazisar joined the meeting for a discussion on integrating the mini-gateway code and port expander code into the same machine. Clark suggested that this integration problem would become almost trivial if someone wrote a null 1822 driver under MOS which allowed buffers to be passed across the driver without copying. Strazisar volunteered to take a debugged copy of Mathis' port expander code and integrate it into the mini-gateway with an optimistic delivery date of the End of November. 9. TCP IMPLEMENTATION SMALL GROUP MEETING - Cerf The discussion focused on the changes to IP required by DCA to satisfy the DOD security and precedence needs. The existing IP option for S/P/T does most of what's needed, but in addition the TOS field will be redefined slightly to be: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | |S| |S|S| | PRC |/|Rel|/|P| | |D| |R|D| +-+-+-+-+-+-+-+-+ That is: Bits 0-2: Precedence Bit 3: Stream or Datagram Bits 4-5: Reliability Bit 6: Speed or Reliability Postel [Page 22]
IEN 121 Internet Meeting Notes Bit 7: Speed This information has to be passed up and down the layers of protocol. Enforcement of the security and precedence is up to each host. There needs to be a specification of how to interpret and implement these functions. Preemption rules must be specified too, for the higher level protocols. There was some discussion of the unauthorized use of security and precedence features. The basic rule is to act on it speedily now and to log the header of the message so one can ask later if the originator was authorized. 10. TCP APPLICATIONS SMALL GROUP MEETING - Postel This group discussed problems in programming application programs that use TCP. Postel had a problem figuring out how to use the user/TCP interface (JSYSs) to create a successful TCP using program. The problem may be with the documentation. Haverty has the problem that programs don't work but don't crash either. Clark said his TCP can't tell the user anything more specific than "it didn't work." What is needed is better documentation, fault isolation tools, and user level debugging aids. Also a memo on what is available, e.g., a traffic generator at BBN-UNIX. 11. ST PROTOCOL SMALL GROUP MEETING - Hoversten This group first made up a detailed agenda of issues to discuss. In general the topics included: Connectivity Routing Stability Protocol Layering Resource Allocation Information Exchange Further discussion of the role of ST in resource allocation is needed. It is agreed that ST provides a structure to support multi-addressing and a resource allocation policy. The relationship of ST to IP is that ST is experimental, will be implemented at a small number of sites, and will have IP imbedded in it. Postel [Page 23]
IEN 121 Internet Meeting Notes 12. 1822 BOARD PROBLEM SMALL GROUP MEETING - Mathis The problem with 1822 boards is being worked on at SRI. Software for the TIU which circumvents the problem will be made available. A hardware fix is being studied. Postel [Page 24]
IEN 121 Internet Meeting Notes XVII. AGENDA FOR NEXT TIME The next meeting is February 4-6 at SRI International in Menlo Park. Ron Kunzelman is the contact. Agenda Items: 1. Kirstein, Davies, Frankel - Internet Performance Experience 2. Flood Page - Longterm Gateway Statistics 3. Cerf - Schedule & Milestones Review 4. Forgie - ST Protocol 5. Cohen - ST Performance 6. McQuillan - Internet Routing 7. Cain, McFarland, Cerf - IP/TCP Acceptance Testing 8. Plummer, Tomlinson - Higher Level Protocols FTP & Integration with TCP 9. Postel - Internet Message Handling Interim FTP Based Multi Media Supporting 10. Deutsch - BBN - FAX & Text Message System 11. Cerf - Multi Homing & Partitioning 12. Plummer - Host Group Routing 13. Demos: A. GMCC Monitoring - Flood Page B. Fault Isolation in TIU - Mathis C. Internet Message Transport - Postel Action Items: 1. Milestones - each contractor is to provide a list of milestones to Cerf. The intention is to quantize tasks and identify increments in capability. The goal is to make progress easily detectable. The combined milestones will be distributed to the internet group, and will be reviewed at the next meeting. Postel [Page 25]
IEN 121 Internet Meeting Notes 2. Monthly Reports - each contractor is to provide a monthly report to Postel. The report should note accomplishments, progress on milestones, unusual events, problems. A summary of all reports will be distributed to the internet group. 3. XNET - to be converted to version 4 by Jim Mathis and Ray Tomlinson. 4. Host IP Document - Bill Plummer is to write an IEN on how to build a host IP. 5. GMCC - David Flood Page will write an IEN on GMCC message formats and an IEN on how to use a terminal process . 6. Congestion Control - Dave Clark will write an IEN on simulation experiments in IP congestion control. Future Meetings Schedule 1980 FEB - SRI MAY - MIT SEP - RSRE 1981 JAN - ISI MAY - ARPA SEP -UCL XVIII. DOCUMENTS DISTRIBUTED IEN Author Title --- ------ ----- 109 Strazisar How to Build a Gateway 110 Cerf Internet Addressing and Naming in a Tactical Environment 119 Forgie ST - A Proposed Internet Stream Protocol Postel [Page 26]
IEN 121 Internet Meeting Notes XIX. ATTENDEES Vint Cerf ARPA Cerf@ISIA Robert E. Kahn ARPA KAHN@ISIA Dick Binder BBN BINDER@BBNE Jack Haverty BBN JHAVERTY@BBND Dale McNeill BBN DMCNEILL@BBNE David Flood Page BBN DFLOODPAGE@BBNE William Plummer BBN Plummer@BBNA Virginia Strazisar BBN STRAZISAR@BBNA Hoi Y. Chong COMSAT Mills@ISIE David Mills COMSAT Mills@ISIE Chip Bumgardner CTEC CHIPS@BBNC Jack Hammett DARPA-IPT Hammett@ISIA Ed Cain DCA Cain@EDN-UNIX Ray McFarland DoD McFARLAND@ISIA Michel L. Audren French Ministry Observer Dominique A. Truchetet of Defense Observer Hubert Zimmerman IRIA HZim@BBNC Danny Cohen ISI Cohen@ISIB Jon Postel ISI Postel@ISIB Estil Hoversten Linkabit Hoversten@ISIA Noel Chiappa MIT JNC@MIT-AI Dave Clark MIT Clark@MIT-MULTICS Jim Forgie Lincoln Lab FORGIE@BBN Frank Deckelman NAVELEX DECKELMAN@ISIA Aage Stensby NDRE AAGE@SRI-KA Andrew Bates RSRE RSRE-T4@ISIA Brian Davies RSRE RSRE-T4@ISIA Allan J. Fox RSRE RSRE-T4@ISIA John Laws RSRE RSRE-T4@ISIA Ron Kunzelman SRI KUNZELMAN@SRI-KL Jim Mathis SRI Mathis@SRI-KL Robert Cole UCL UKSAT@ISIE Sunil K. Das UCL PKT-UCL@SRI-KL Peter L. Higginson UCL UKSAT@ISIE Andrew Hinchley UCL UKSAT@ISIE Ron Jones UCL UKSAT@ISIE Peter Kirstein UCL Kirstein@ISIA Alan J. Mayne UCL UKSAT@ISIE Steve Treadwell UCL UKSAT@ISIE David Lloyd UCL/UKMOD LLOYD@ISIA Keith A. Lantz U of R LANTZ@SRI-KL Postel [Page 27]
IEN 121 Internet Meeting Notes APPENDIX A The following special interest group mailing lists have been set up by Noel Chiappa at MIT-ML. To use them, send to <group>-PEOPLE at MIT-ML [or just <group> (DON'T include the "<"'s)]. If you want to be on one or more of these mailing lists please send a note to Noel, JNC@MIT-AI (not to the whole group). If you get a message from Person and to a mailing list, DO NOT send your reply to the mailing list AND Person; the MIT-ML mailer isn't smart enough to notice and will send duplicate copies to Person. MOS-UNIX MOS support on UNIX SMALL-UNIX UNIX on small machines VAX-UNIX UNIX on VAX MOS-TCP MOS, TIU and the MACRO-11 TCP MOS-PE Port expander / Minigateway NET-UNIX Network support on any UNIX Postel [Page 28]
IEN 121 Internet Meeting Notes APPENDIX B IP and TCP Specification Differences The following is a brief description of the difference between IEN-80 and IEN-111 (IP), and between IEN-81 and IEN-112 (TCP). In both cases the new documents are intended to simply be better documents, and no significant changes to the protocols are intended. There are many minor changes of wording, punctuation, or spacing, so that a source compare would catch many many paragraphs in which there is no significant change. It is intended that the text added (or in some cases deleted) lead to an easier to understand description of the protocols. IP Differences 1. A much more specific description of a fragmentation and reassembly procedure is included. 2. Some Options are changed or added: a. Three options are added for use by the BCR protocol. b. A Stream-ID option is added. c. The Source Route option is changed to conform with IEN-95. d. The Return Route option is added to conform with IEN-95. e. The Error Report option is expanded to have several specific error codes., and a standardized IP header for error reporting. TCP Differences 1. Two additional States are introduced in the connection closing sequence. 2. The EOL sequence number fixup procedure is changed to be based on remembering the sequence number of the beginning of the most recent buffer rather that the initial sequence number of the connection. 3. In many cases the RST is not required to acknowledge that segment that caused the reset to be generated, and in many cases it is not necessary to check the ACK value to verify a RST. Postel [Page 29]
IEN 121 Internet Meeting Notes APPENDIX C Minutes of Internet Subgroup Meeting for Performance Measurement Present: Ron Kunzelman (SRI) (Chairman), Noel Chiappa (MIT), Brian Davies (RSRE), Stephen Edge (UCL), David Flood Page (BBN), Andrew Hinchley (UCL), Ron Jones (UCL), Bob Kahn (ARPA), Peter Kirstein (UCL), Alan Mayne (UCL) (Minute-taker), Ray McFarland (DOD) Kunzelman pointed out that there is need for performance measurement at different levels of protocol, including measurements on Telnet and FTP at the user level, TCP at the transport level, and datagrams at the internet level. The meeting then considered various specific aspects of measurement. Measurement Work Now Being Done or Being Planned BBN (Flood Page) will do some performance measurements at the datagram level on traffic passing through gateways; no tests are envisaged. The BBN gateway will monitor IP traffic going through the gateway. BBN is looking at CPU utilization, and can also extract interface information by address pairs. BBN (Wingfield) is doing some performance tests on TCP. Throughput and delays have been investigated. SRI is measuring Telnet throughput (bits/sec) from TOPS20 and TENEX hosts. UCL is trying to time FAX transmissions, and NIFTP transmissions at the user level. UCL would like to measure individual performances end-to-end, to see if there is any destructive interference. For ARPANET-SATNET-ARPANET transmissions, there is a need to know the best ARPANET performance, the best gateway performance, and the best Satnet performance, and then compare the combination of these with the best actual ARPANET-SATNET-ARPANET performance, to see whether they are comparable or differ by an order of magnitude. RSRE (Davies) has previously measured with old PIXIE, and would now like to repeat some of these measurements with new PIXIE. Measures have been made of round-trip TCP ack times. The measurement techniques consist mainly of turning the traffic generator on for about five minutes at a time, then obtaining a delay histogram. Postel [Page 30]
IEN 121 Internet Meeting Notes Performance Metrics The following metrics have been used to measure ARPANET performance: 1. ARPANET has problems of low bandwidth, hence uses throughput metrics such as packets/sec and user-bits/sec. 2. SATNET has long delays, hence measures mean transmission time. 3. PRNET is liable to high loss, hence measures the percentage of missing packets. 4. Packet efficiency is the ratio of information packets received to total packets received (the difference being due to control and retransmission overhead). Kirstein stressed the need for better individual metrics, and then for developing algorithms for combining them. For example, both bits/sec and packets/sec are important. He also raised the question of how the performance varies when going through different combinations of networks. Measurement Tools Tools currently being used in Arpanet include: 1. At the user level, FTP + "stopwatch" for bandwidth and Telnet + "stopwatch" for measurements of remote echo time and bandwidth. 2. Timestamps in pickup packets. 3. Echo server in gateways. 4. Traffic generators and sinks. There is also a possibility of using synchronized clocks to measure one-way times and asymmetric delays as well as round trip times. Hinchley is looking at interval times between successive packet streams, as a method of measuring delays. Measurement Needs Kunzelman pointed out that there is currently no measurement at the transport level in the ARPANET. Statistics are needed for the distribution of user traffic, which can be measured on entry to Postel [Page 31]
IEN 121 Internet Meeting Notes the internet system. There is also a need to have statistics for the distribution of packet sizes. More measurement is needed of round-trip TCP ack times: so far, this has been done only by RSRE. Also in TCP, measurements are needed of retransmissions and checksum errors. TCP-specific measures should be separated from general network and gateway measures, although such separation might be difficult to achieve in practice. Mayne would be grateful to anyone who would send him empirical data that would be useful to help validate his proposed simulation and theoretical studies, especially on problems of joint ARPANET-SATNET operation. It was pointed out that McQuillan has a large amount of empirical data. Some Problem Areas Kahn pointed out the need to isolate problem areas, such as optimization and tuning, for which measurements are needed. Some of these problems relate to research and development about networks, including obtaining insights about their behavior, others are concerned with the operational control of networks, and there is also the problem of persuading some network users that they actually have problems! Kirstein said that a big problem is to put uniform methods of measurement into the internet environment; this is very difficult and requires much thought. Kahn asked if we could do absolute performance measurements, or whether they are all relative. Kahn said that measurements could contribute to the understanding of various problem areas, for example: performance tuning and other parameter optimization, retransmission strategies, alternative routing strategies, minimum delays for interactive-type traffic, cost considerations, robustness and recoverability. Mayne mentioned two important incentives for carrying out comprehensive measurements: 1. Validation of simulation runs and theoretical models. 2. Obtaining insights into what is happening, especially in network operating problems of crucial practical importance. Postel [Page 32]
IEN 121
Internet Meeting Notes
Documentation
Mayne said that is would be valuable to prepare a comprehensive
list of all documents relevant to network measurement, including
papers on methods and tools, measurement software and write-ups of
that software, and collections and summaries of actual performance
data. He suggested that each organization participating in the
internet, should contribute relevant entries, and he himself will
prepare an annotated bibliography of relevant UCL literature. He
is also willing to act as a mailbox for collecting information
from the other organizations.
It was pointed out that important documents in this area have been
written by Kleinrock, McQuillan, and Wingfield, and also at UCL.
Recommendations for Further Action
1. Study network performance in relation to types of network
subsystem, including network as a whole, gateways, hosts,
operating systems.
2. Write specifications of performance measures for TCP (it
was suggested that this might be done by Wingfield), user
level protocols, and IP.
3. Define a set of tests for IP, Datagram, TCP, higher level
protocols, etc.
4. More work needs to be done on IP, for example, using GGP
and echo packets and measuring round trip times, also
investigating loss rates including numbers of duplicate packets
and packets out of order.
5. Prepare and adequate bibliography of documents on
performance measurements, and keep it up to date.
Postel [Page 33]
mirror server hosted at Truenetwork, Russian Federation.