J. Postel
IEN 160 ISI
7 November 1980
Internet Meeting Notes -- 7-8-9 October 1980
I. INTRODUCTION
The meeting was held at the Royal Signals and Radar Establishment in
Malvern, England. John Laws was the host. Alan Fox gave a welcome
to and explanation of RSRE. John Laws described the arrangements.
II. OBJECTIVES
Vint Cerf described the objectives of the meeting. The main points
were to exchange information on the status of various projects, to
discuss plans, and to review performance and design issues.
III. STATUS REPORTS
A. ARPA
Vint reported on some changes in the ARPA IPT office. People:
(1) Dr. R. Kahn was married, (2) Col. J. Hammett is leaving the
office for an assignment in Europe, (3) Dr. B. Leiner is joining
the office to work on the Packet Radio Program, and (4) Lt. Col.
Duane Adams is now Executive Assistant to the Director of IPTO.
Equipment: Much of the equipment on the 7th floor will be moved to
the 8th floor, the current 316 TIP will be replaced by a C30 IMP
plus 316 Terminal Access Mini-Host, the XGP will be replaced by a
Penguin, and a RAPICOM 450 facsimile machine will be installed.
An important goal for protocol implementations is to eliminate the
use of NCP and completely switch over to TCP by January 1983.
ARPA is providing technical support to the National Science
Foundation (NSF) in the planning for a Computer Science Network
(CSNET) to be operated by a consortium of Universities.
L. Landwebber at the University of Wisconsin is the coordinator of
the consortium. The current plan is to use a combination of
existing networks to provide the physical support for CSNET.
ARPA intends that by the end of 1982 all existing 516 and 316 IMPs
will be replaced by C30 IMPs. The first few will go to (not in
this order) SRI, MIT, ISI, ARPA, BBN, BRAGG, and Berkeley.
Postel [Page 1]
IEN 160 Internet Meeting Notes B. BBN Dale McNeill reported on the status of SATNET. The PSP terminal provided by COMSAT has been installed and the SPADE terminal has been removed. The ARPANET line 41 between NORSAR and SDAC which is supported by a satellite is now using a military circuit and availability has been noticeably poorer. CATENET gateways attempt to split the load when routing information indicates two or more paths of equal cost. This means that traffic from the UCL gateway over the SATNET to the ARPANET will be split between the BBN gateway and the NDRE gateway. When it turns out that the ARPANET line 41 is down, half of the traffic goes into a black hole. The NDRE gateway can talk to its IMP and so reports it is connected to the ARPANET, but the ARPANET is partitioned due to line 41 being down. Due to this problem, it was agreed that communication between the NDRE Gateway and the UCL Gateway be permanently broken to avoid packet loss due to gateway load splitting when line 41 is down. There has also been an increase in the packets lost in SATNET due to an increase in the bit error rate which is due to satellite power being reduced by 1db since June 1st. Dale also reported that the VAN Gateway (an ARPANET-TELENET gateway) work has progressed to testing the Frame Level protocol. There seem to be some problems with the interface due to differing interpretations of X.25. This gateway is implemented in LSI-11. Ginny Strazisar reported on the recent development for the Gateways. The use of XNET has converted to version 4. A problem with the Redirect Message has been fixed. The implementation of fragmentation has not been completed. A problem with reinitializing the UCL gateway was discussed. It seems as if some combination of using XNET, the robustness card and LDSRV should be able to handle this case. UCL, SRI, and BBN will investigate. Jack Haverty reported that new TCP implementations are now just beginning for the VAX Unix (v.7), the HP 3000, and the new TIP (mini-host attached to a the C30 IMP). Design notes on these will be distributed as IENs. A description of the performance measurement tools developed for DCA should be available about 1 November. A local net based on the Ungerman-Bass NET-ONE equipment is being tested. A design for a TIP Login system is in progress. A gateway between the RCCNET and the ARPANET and a Postel [Page 2]
IEN 160 Internet Meeting Notes local net based on C30s is being installed. IEN 158 was issued which describes the XNET-4 protocol. David Flood Page reported that the CMCC log files are now primarily event driven and summaries are produced. If you want to receive the daily statistics, send a message to David. IEN 157 was issued which discusses some new performance measurement CMCC message formats. C. COMSAT Dave Mills reported on activities at COMSAT. COMSAT is working on a revised version of INTELPOST which will use IP and TCP. Dave described the configuration of equipment at COMSAT which consists of a number of small hosts, mainly LSI-11s. This network uses the logical host field of the Internet Address to identify the host. Some bugs were found in some ARPANET hosts treatment of this field. The local net protocol is IP. Dave has been particularly active in testing TCPs and IPs, and will discuss some of these issues in another session (see section V). COMSAT has implemented programs to send and receive computer mail on the "playpen" host. These are written in C. COMSAT has also used NIFTP to transmit files between their hosts and ISIE. The NIFTP software was provided by UCL. COMSAT and ISI have exchanged facsimile images. COMSAT plans to create a full CATENET gateway and to arrange a permanent connection to the ARPANET. D. DCA/DCEC Ed Cain reported on the status of the EDN. Fragment reassembly has not yet been implemented. The Host and IMPs have been converted to 96 bit leaders. The gateway has implemented most of the CMCC measurements reports. One problem is that many gateways and hosts do not have the EDN in their tables. E. DOD Ray McFarland noted that Ken Shotting has done further work on a formal analysis of IP and a report will be forthcoming. F. ISI Jon Postel reported on the installation of the PENGUIN laser printer and the communication of data to it via IP, UDP, and TFTP. The program that manages the input and output of facsimile data Postel [Page 3]
IEN 160 Internet Meeting Notes has been modified to use either the new or old format. Jon reported that the work on protocol verification is progressing and that Carl Sunshine may have a report at the next meeting. Jon also reviewed the IENs and RFCs produced since the last meeting. Since the whole ARPANET is to convert to IP and TCP it is appropriate for protocol specifications and implementation related memos be RFCs while research and design related memos be IENs. G. Linkabit Estil Hoversten noted that Linkabit recently merged with another company and will be setting up a private corporate satellite network. Linkabit is doing the final testing of the ESI and expects send it to ISI in mid-October. The expected review of ST protocol will not be presented. H. LL Cliff Weinstein described the structure and status of the WBCNET. The initial four stations (LL, ISI, SRI, DCEC) all have their antennas installed. Work is underway to bring the net into operation in the next few months. LL is developing a local network called LEXNET, some digital voice terminals (VTs) and traffic emulator and traffic concentrator hosts. An 11/45 is being programmed to be an WBCNET-LEXNET gateway. This will be a ST gateway but not initially a full IP gateway. I. MIT-LCS Dave Clark described the complicated collection of networks and hosts at MIT. There are several families of protocols in use and several interconnections. Things are complicated enough that Corbito has been designated czar of networks at MIT. Some things in progress are: Mail Service Programs, FTP programs, an NIFTP, X.25 interconnections for Telnet and Tymnet. The Nu machines are coming along; an IP for the Nu is being written. Multics implements an Echo and Echo Reply to do PING with COMSAT. MIT still needs an additional IMP port. Interested in IP and TCP implementations for super small machines. J. NAVELEX Frank Deckelman noted the interest of the Navy Electronics Laboratories in the ARPA Internet. Postel [Page 4]
IEN 160 Internet Meeting Notes K. NDRE Yngvar Lundh reported on the local net development at NDRE which is based on protocol processors implemented on Z80s with 65 kb of memory. Each processor has a kernel and a specialized module such as a speech packetizer, an LPCM, a TCP, or NVP. The implementation language is PLZ. A highly formalized graphical description language is being used to design the TCP. L. RSRE Brian Davies reported on the activities at RSRE. RSRE has been very active in measuring TCP performance and will report some results in another session. Some suggestions for changes to IP and TCP are: (1) If the option code could indicate by a type or class bit if the option were to be copied or not on fragmentation things would be easier for the gateway; (2) also on fragmentation it might be better to break the datagram into equal sized fragments rather than a maximum sized fragment and the left over; (3) TCP should focus more attention on the critical impact of timeouts on performance, especially noting that different destinations may vary in round trip times by an order of magnitude. The line between RSRE and UCL was recently upgraded to 4800 baud. RSRE particularly noticed the lost traffic due to the problems with line 41. M. SRI Ron Kunzelman reviewed the status of the Packet Radio networks, and discussed a problem with terminal access from Ft. Bragg TIU users at ISID. The normal TOPS-20 character-at-a-time remote echo seems to saturate the bandwidth available via TCP, the gateway, or the networks. A line-at-a-time local echo mode has been developed to reduce the traffic load. Ron also described some modifications to ACC controllers for the 1822-LSI11 interfaces: (1) 18 bit addresses (2) address incrementing (3) switch to tell (?) (4) cycle shortening (5) last bit on gather write (6) last input character (7) substitution of a part Postel [Page 5]
IEN 160 Internet Meeting Notes A PDP 11/44 has arrived. This will run Unix (v.7) and will be used for a measurement host. The antenna for WBC is installed, but some concern has been expressed about safety to passers-by. Jim Mathis reported that TIU's now do reassembly of datagram fragments. Holly Nelson described some new software development tools for use on UNIX. Also noted that the Port Expander has all the features that were discussed at the last meeting. N. UCL Robert Cole described the activities at UCL. Fragmentation is implemented for sending datagrams and reassembly for incoming fragments. Chris Bennett is developing a Unix based mail server based on MMDF and MH using TCP and IP for one underlying communication medium, and X.25 for another; there is also interest in interworking with CSNET for computer mail. Steve Treadwell has developed some programs to decode and smooth facsimile data. A Cambridge Ring local network is being installed, but the protocols have not been chosen as yet. Connections via X.25 to IPSS and EURONET are being tested. UCL has also been affected by the poor availability of SATNET. Ron Jones presented measurements on Port Expander and 1822 interface performance. The maximum achievable packet rate through the PE from a source to a sink was 65 pkts/sec (with the source and sink directly connected the rate was 255 pkts/sec). The 1822 interface performance was found by looping packets of various sizes through the PE. The interface bit rate for a PI interface connected to a DMA interface was 71 kbits/sec and for two DMA interfaces was 325 kbits/sec. The latter experiment also yielded 5.7 ms as the time for the PE to switch a packet. Postel [Page 6]
IEN 160 Internet Meeting Notes IV. ACTION ITEMS A. Internet Name Server SRI is developing an internet name server consistent with the specification in IEN 116. It was expected to be demonstrable at this meeting. The development has not reached such a state and this item is deferred until the next meeting. B. Interim Internet Mail System ISI is developing a prototype mail program for supporting text mail in the internet and between NCP and TCP hosts. It was expected to be able to demonstrate these programs at this meeting. The design of these programs has only recently been developed (see section XII). This item is deferred until the next meeting. C. FTP and MAIL Memo ISI has produced a memo on text mail for the Internet. It is RFC 772. RFCs 771 and 773 offer motivation and discussion of this approach (see section XII). D. IP and GGP Error Report Memo ISI was to produce a memo on error handling in IP and GGP. This was not done and this item is continued to the next meeting (see section XV). E. XNET Specification BBN has produced a memo on the XNET protocol. It is IEN 158. V . BAKE OFF SUMMARY Dave Mills reported on the sessions for testing the fragmentation and reassembly implementation in the IP protocol modules. The results indicate that such testing is useful in that a few problems were found and corrected, but disappointing in that a number of hosts and gateways don't implement fragmentation as yet. VI. TINY PIPE NETS Dave Mills discussed some performance problems with networks composed of low speed lines (e.g., 1200-1900 baud) and small hosts with minimal buffers. In such "tiny pipe" networks, attention must be paid to the performance effects of TCP segmentation decisions, acknowledgment strategy, window strategy, and retransmission timeout Postel [Page 7]
IEN 160 Internet Meeting Notes selection. These performance parameters must be chosen with respect to the partner at the other end of the TCP connection. For example, a connection between a tiny host in a tiny net and a large host in a large net (e.g., the playpen in COMSAT net and ISIE in ARPANET) has very different characteristics than connections between roughly equal hosts. VII. INTERNET PERFORMANCE MEASUREMENT Zaw-Sing Su presented a detailed description of some measurement ideas. The aspects of performance measurement can be identified as follows: Artificial Traffic Generation Data Registration Data Collection and Transport Experiment Preparation and Control Data Reduction and Presentation User Interface Measurements could be made at several levels: TCP Performance TCP Analysis IP Performance IP Analysis Internet Component Performance Where performance is as perceived by the user and analysis is by mechanism. The types of things studied in performance measurements are: Traffic Arrival and Departure Statistics Throughput and Delay Performance The types of things studied in analysis measurements are the mechanism used by the protocol. For TCP: Relative data efficiency Retransmission sent and received Out of order arrivals Duplicates Ack Only segments Ack Delay Zero Window periods Postel [Page 8]
IEN 160 Internet Meeting Notes For IP: Fragmentation and Reassembly statistics Use of options statistics For GGP: Routing Decisions Congestion Statistics Zaw-Sing suggested an internet delay measurement capability to be implemented as an optional header field for both TCP and IP. The TCP option would have source and a destination timestamps of 32 bits each plus the option code and length octets for a total length of 10 octets. The time would be in milliseconds. The IP option would have the type and length octets, a 16 bit id, and N stamps, where each stamp is a 32 bit IN address and a 32 bit time (in milliseconds). The maximum number of stamps would be 4 due to the limitations on the header size. Questions were raised about combining this option with the Source-Route or Return-Route options. The consensus seemed that rather than an option in the IP header the timing data ought to be accumulated in the data part of the datagram in a protocol like GGP. VIII. CATENET PERFORMANCE CONSIDERATIONS Bruce Hitson discussed the need for one-way delay measurements in the Catenet. It was stressed that these measurements would be particularly critical for performance measurement in an internet environment. The very large physical distances involved and the non-participatory (at least in performance measurement) nature of the member networks are examples of why one-delays would be very useful. Round trip measurements are of questionable value since the network may change quite a bit during the course of a single round trip (up to 10 seconds in some cases). To be able to make one-way delay measurements, synchronized clocks are needed. Bruce described several clever ways of synchronizing clocks with third party time sources. The best choice seeems to be some devices that listen to a radio station (i.e., WWVB in the United States) and have a computer interface (e.g., RS 232) to report the time to the computer on request. Postel [Page 9]
IEN 160 Internet Meeting Notes ISI (as noted in the notes of the last meeting) has already ordered 4 such devices for use in WBC and CATENET measurements. Design of experiments that will make use of these devices is being considered. For further details, see Appendix B. IX. Loader Server MEASUREMENTS Jim Mathis reported the results of some round trip measurements made using the LDSRV program. A round trip in the ARPANET between DARCOM-KA and the Ft. Bragg Gateway took about 600 ms. Similar measurements between DARCOM-KA and a host in a local PRNET took 170 ms., and between DARCOM-KA and a host in the Ft. Bragg PRNET took 800 ms. For further details see Appendix C. X. CATENET MEASUREMENTS Brian Davies discussed some suggestions for performance improvements based on the experience at RSRE. The use of an adaptive retransmission timeout seems to be very helpful. RSRE has experimented with one based on the following: 1. For each segment record the sequence number and time sent. 2. For each acknowledgment determine the round trip time (RTT) of the sequence number thereby acknowledged. 3. Compute an Integrated Ack Time (IAT) as follows: IAT = ( ALPHA * IAT ) + RTT 4. Compute a Retransmission Time Estimate (RTE) as follows: RTE = Min [ BOUND, ( BETA * IAT ) ] Where BOUND is an upper bound on the retransmission time and BETA is an adjustment to the IAT to account for variation in the delay. RSRE currently uses ALPHA = 31/32 and BETA = 1.33. [Dave Clark noted that MIT-MULTICS uses the same algorithm but with ALPHA = 4/5 and BETA = 1.5.] Brian presented some graphs of the actual RTTs and resulting RTE for TCP connections between RSRE and ISIE. Andy Bates presented data from recent measurements of double round Postel [Page 10]
IEN 160 Internet Meeting Notes trip times between RSRE and UCL, BBN Gateway, and ISIE. There are two aspects of the measurement to be explained: The absolute delay, and the variation in delay. The absolute delay (for the least delayed packets) seems to be in agreements with the expected delay given the speed of the lines, the protocols used, etc. For example, one second time for a separate reservation is required (which is the current strategy). The variation in delay is not yet satisfactorily explained. Some arises in SATNET, and a good deal arises in the ARPANET. One suggestion (by Danny Cohen) is that if the packets are far enough apart in time then new Source IMP to Destination IMP reservations are needed for each packet, this could add a large variable delay. A goal for the next meeting is to figure out the cause of the variation in the delay. XI. NBS PROTOCOL STANDARDS DEVELOPMENT Mike Wingfield discussed the standards work on protocols sponsored by NBS. Mike first noted that many standards groups are actively working on standards in the communications area. The work NBS is sponsoring at BBN is to develop service specifications, feature analysis, formal specification, and a test implementation for a transport protocol. BBN has developed a formal description language which is an extension of a finite state machine description. The language is entirely textual and so can be easily manipulated with computer tools. The basic element is a transition description which is composed of a next state, a current state, an event, and a procedure. The procedure is written in "C". The following tools for working with the language have been developed: a syntax checker, a state checker, a special editor, and a test generator. Additional work involves a feature analysis of X.75, IP, and PUP as internet protocols. NBS is also interested in the ECMA proposal for a Transport Protocol and BBN is analyzing it. XII. MAIL TRANSITION PLAN Vint Cerf described the problem arising in the exchange of computer mail between old NCP only hosts and new TCP only hosts. The plan is to provide relay or forwarding hosts that implement both transport protocols and relay the mail. Jon Postel explained some of the details of this plan. A key decision is to provide a new MAIL SERVER and a new mail protocol. Postel [Page 11]
IEN 160 Internet Meeting Notes These will be very similar to the existing protocols and servers but will have an important new feature: the address passed in the MAIL command will include the destination host as well as the user. Jon also discussed the need for hosts to add to their host tables some indication of the status of each other host: old table NCP, new table NCP, or TCP (all TCP hosts are to have new tables). These three kinds of host mean there are 9 combinations of mail exchange. These were discussed on a case by case basis. The difficult case was the old NCP host to the TCP host. In this case a relay host could receive the mail using the old mechanisms but would have no idea of which host to forward it to. One proposal is to have a list of registered users available to this relay host. Vint also discussed the idea that the hosts have unique indentifiers independent of network, and even that organization names could be used instead of host names. The discussion indicated some doubts about the practicality of registered users, especially in resolving name conflicts now resolved by host names. Also, concern was expressed about the globally unique host names. RFCs 771, 772, and 773 present the plan, the mail protocol, and a discussion of the issues. Comments are solicited. XIII. CONTROLLED ROUTING Danny Cohen discussed routing to avoid undesirable networks or to limit a route to known networks. The existing source routing option may be called loose source routing (LSR) since it allows the gateway to send the datagram on any route they choose between the specified addresses. Danny proposes another option called strict source routing (SSR), which is like LSR except that a gateway may only route a datagram to the next specified address through the network specified in the NET part of that address. This is very restrictive and would highly control the route. It would also provide a way to route things out of one network, through a second network, and back into the first network, to get around a partition or use special transmission capabilities. Vint Cerf proposed an alternative of simply a list of acceptable networks. This would be less restrictive, but might lead to problems in routing. Postel [Page 12]
IEN 160 Internet Meeting Notes Danny's proposal is described in IEN 156. XIV. PROTOCOL ISSUES Dave Clark discussed some problems in IP and TCP implementation in the MIT environment. One situation is that several hosts at MIT are on two or more networks, and have as many internet addresses. The problem is that while one interface is down, the host and the other interface may be up, but datagrams sent to the down interface address will be discarded rather than routed to the other interface address. Dave presented a scheme that would allow a two-connected host to avoid this problem with the help of nearby gateways. The gateways in the networks the hosts is connected to would have tables to map a special form of address into one of the regular address and to choose between regular addresses based on knowledge of which interfaces were up. The hosts sending to the two-connected host would always send to the special address. This scheme was not well received. The consensus seemed to be that it was too specialized and involved too much special case mechanisms. It is agreed to be an important problem, but a better solution is needed. Another situation involves very small hosts and the desire to implement TCP in them. For example, a TCP in 2K bytes of memory. What corners can be cut? For example, no data with SYN or FIN, simple ACK and window policies. One suggestion is for an option to specify a maximum receive segment size to be sent only with a SYN. This would have different effects than a consistently small window because it may allow many segments to be in transit at a time even though each is small. The consensus seemed to be that this was a good idea. XV. IP AND GGP ERROR REPORTS Jon Postel reviewed the discussion from the last meeting of error reporting in IP and GGP. They are different in that in IP an option is used and in GGP the data area is used to carry the error information. They are redundant in that most of the errors mentioned in IP are also mention in GGP. Jon proposed to put all these error reports into a new protocol and use a GGP style mechanism. The consensus seemed to be that we should continue to use GGP, and eliminate the IP error option. Postel [Page 13]
IEN 160 Internet Meeting Notes XVI. NEXT MEETING The next meeting will be hosted by ISI and will be held 28-29-30 January 1981. Attendance will be limited so if you plan to attend please clear that with Vint Cerf (CERF@ISIA). and notify Victor Brown (BROWN@ISIF). Jon Postel will be the host. A tentative schedule for subsequent meetings is: May 81 at COMSAT, September 81 at UCL, January 82 at SRI, May 82 at BBN, and September 82 at IABG/DFVLR. AGENDA ITEMS: 1. Provision for source routing in the interface between TCP and IP and in the TCP tables. How will the reverse route information be handled? 2. Further discussion on internet mail transition. Focus on alternatives to the unique name requirement which led to potential misrouting. 3. More on performance observations within the Catenet, in the Hosts. 4. MITRE report on their new 350 kb/s TCP that runs in a Z-8000. 5. Front-ending of TCP/IP. 6. Progress reports on FTP where ever it is being implemented. 7. Progress reports on the (interim internet) message system. 8. Progress reports on the protocol verification. ISI, BBN, SDC, and DoD. 9. Discussion of "worm" programs, XEROX. 10. Discussion of the IIN problem, the inter-inter-net. How and at what levels can we interoperate with other nets? 11. Report on On-Tym and Telemail relative to ARPANET mail and Internet Mail. ACTION ITEMS: 1. New text for the TCP and IP specification changes. Postel [Page 14]
IEN 160 Internet Meeting Notes APPENDIX A: INTERNET DESIGN PHILOSOPHIES & THEIR IMPLICATIONS The third day of the Internet Meeting was a seminar on the TCP/IP and Yellow Book approaches to internetting. The following notes are provided by Brian Davies of RSRE. INTRODUCTION - John Laws (RSRE). John Laws started the informal Seminar by giving some background as to its genesis: namely that with so many TCP/IP experts having come to the UK and it being the case that the UK public network users are promoting an apparently competing solution, then it seemed an ideal opportunity for parties to exchange views. It was not expected or intended that there should be any dramatic conversions of the parties vis-a-vis datagram and virtual call issues. However, it was hoped that areas of common approach might be identified even though expressed in a different language. In addition, the reasons for divergence might be mutually identified and appreciated. An "impartial" Chairman, Derek Barber (Microprocessor Applications Project, Dept. of Industry) was introduced. Many presentations of views were scheduled and firm discipline, of both presenters and the audience, was administered by the Chairman. A summary of presentations and ensueing discussion follows. OPERATIONAL REQUIREMENTS - Sqn Ldr David Stupples (RSRE). The user requirement for communications in a typical air defence scenario was presented. The data communications were provided by a common bearer network and mobile tactical networks of the JTIDS type. The data-bases and their functions were described to illustrate why they were distributed. The mobility of the users not only in a single net but across multiple tactical nets was emphasized with particular reference to the problems of maintaining connections to their associated databases. PHILOSOPHY AND ARCHITECTURE OF YELLOW BOOK TRANSPORT SERVICE (YBTS) - Peter Linington (Data Communications Protocol Unit, Dept. of Industry). To ensure that the parties to the debate were speaking a common language a set of "basic" and "obvious" axioms for internetworking were presented. The properties of a global transport service were described. Compatability for internetworking would be achieved by enhancing each underlying network to the common transport service standard. This enhancement would be within hosts and gateways; the enhancement being achieved by encapsulation of the specific Postel [Page 15]
IEN 160 Internet Meeting Notes network features within appropriate network specific protocols. Thus only the service attributes have to be agreed globally; hosts only have to implement their local network enhancing protocols; gateways at worst have only to implement neighbour network enhancing protocols. ADDRESS AND ROUTING IN THE YELLOW BOOK TRANSPORT SERVICE -Mike Guy (Computing Centre, Cambridge University). The point was made that diverse network address naming authorities will always exist and will always assert their techinical need to be different. A naming and addressing mechanism appropriate for this environment was described. This featured use of an "address" string whose component parts are addresses, titles, generic names. Traversal of connected networks was driven by successive "activation", with possible address/title expansion/transformation, of the component parts appropriate to the current address/naming domain: in effect akin to source routing. In particular, the use of titles/generic names allowed the user to be unconcerned with changes in remote network addresses or interconnection architectures. Depending on the name/address conventions of the neighbour networks, gateways would be required to have varying degrees of intelligence about name/address mappings. TRANSPORT SERVICE ARCHITECTURE FOR THE LAYMAN - Vince Hathway (National Physical Laboratory). Vince detailed his varied and long experience of implementing and working with protocols in an internetworking environment. This environment had gateways to both datagram and virtual call networks. Both approaches had used hop-by-hop techniques for some of the levels of protocols. In addition one gateway also passed high levels of protocol transparently. Neither approach could be declared as "better". The community of users associated with each of the external networks had different requirements and this had significantly determined the internetworking solutions. In analogy, domestic cars were ideal for many transportation requirements, but there are times when the virtues of tanks are appreciated! TCP AS A BASIS FOR YELLOW BOOK TRANSPORT SERVICE REALISATION - Chris Bennett (UCL) In order to incorporate an existing network into the Yellow Book framework, a 'Yellow Book protocol' must be defined locally to that network which builds on the existing network interface to bring it in line with the Yellow Book service. In the Catenet, Postel [Page 16]
IEN 160 Internet Meeting Notes the appropriate starting point is TCP which already offers the basic virtual call interface. The data stream is structured into arbitrary length data and control messages. Each control message is allied with TCP actions, where possible, to gain the appropriate effect. The TCP-based Yellow Book protocol is not complex and is mostly required to allow the transmission of connection information beyond the Catenet. Details may be found in IEN 154. A USER REQUIREMENT FOR STANDARDS - Ken Heard (Joint Networks Team, Science Research Council, Rutherford Labs.). Background was given as to some of the functions/responsibilities of the Joint Network Team; this being advising/aiding the selection/implementation of an architecture and protocols for internetworking between diverse networks sited at UK Universities and Research Establishments. The point was made that the productive functioning of this internetworking in the immediate future was urgent and, that time and resources could not be wasted on re-inventing the wheel. Hence the adoption and rapid implementation of protocols emerging as "interim" standards for use on the UK PTT public network. A review of protocol/architecture standardisation activities within national/international bodies (AFNOR, BSI, CCITT, ECMA, ISO, NBS,...) was given. As a final comment attention was drawn to the influence on standards of the pioneering research networks such as ARPANET and the European Informatics Network. THE INTERNET ARCHITECTURE - Vint Cerf (DARPA). The wide range of diverse network implementations and environments incorporated in the ARPA Catenet was described. The ARPANET itself, packet radio networks, broadcast packet satellite networks, and a variety of local networks all interwork using IP as the universal protocol. Some of the experiments and demonstrations conducted were discussed. INTERNET PROTOCOL DESIGN - Jon Postel (ISI). The architecture of the ARPA Catenet protocol family was briefly described and the services provided by the IP and by the TCP were described. The point that both protocols are available to the users and can be used to build very different kinds of applications was emphasised. END-TO-END VS HOP-BY-HOP - Danny Cohen (ISI). The difficulty of building effective communication systems by Postel [Page 17]
IEN 160 Internet Meeting Notes relying on plug-to-plug compatibility on a hop-by-hop basis was discussed. SUMMARY OF ISSUES - Brian Davies (RSRE) The advantages of harmonization of transport protocols in the civil and military fields were presented. However, the differences in emphasis in the user requirements would probably preclude this standardization in the foreseeable future. These differences included availability of resources in the face of threat, mobility of users, and the military requirement to accommodate a dynamically changing internet topology. In addition, the relative importance and costs of such properties as security, precedence and survivability had to be considered. Some of the particular architectural issues involved in the Yellow Book and TCP/IP approaches were then presented. In particular the implications of the addressing strategies, connection control and economies of use were highlighted. DISCUSSION The initial discussion was used by a number of the presenters to clarify facts or points they had made in their talks. The following paragraphs are a selection of the varied topics discussed: a) The number of "grades" of service that might be required was discussed. In the YBTS approach it had been identified that the one grade of reliable connection-oriented service was a requirement overwhelming all others. In contrast, the TCP/IP approach had identified a need fo a number of distinct "grades" of service to be realized by specific protocols (e.g. speech, user datagram etc.). b) Discussion showed that different emphasis of requirement had significant influences on the two architectures. The more commercial environment within which the YBTS has been formulated places great emphasis on the economic use of resources. However, the problems involved in maintaining connections across vulnerable or unreliable networks was an aspect not deeply considered within YBTS. The TCP/IP approach had given much greater attention to this military aspect. The two approaches could be seen to be non-competitive as they are solving different problems. c) The YBTS approach to addressing is based on the premise that all networking authorities will not agree to a global addressing strategy. The global addressing approach of the TCP/IP would seem to be in-line with the ISO recommendation on this issue. Postel [Page 18]
IEN 160 Internet Meeting Notes APPENDIX B: SYNCHRONIZED CLOCKS ISI is evaluating an absolute time clock for network measurement use. The clock is actually a radio receiver which is tuned to National Bureau of Standards station WWVB, which broadcasts on a frequency of 60kHz, and is located at Fort Collins, Colorado. WWVB provides both time and frequency information and its coverage area is effectively the continental United States. The clock is the Model 8170, made by Spectracom Corporation, 320 N. Washington St., Rochester NY 14625. The 8170 is a rack-mountable unit, 17" wide by 5.25" high by 13.5" deep. Line power is 115/230 volt 50 or 60 Hz AC at 60 watts. An external antenna is required, which is a ferrite loop antenna in a tubular plastic housing 14.8" long and 2.7" in diameter with a threaded fitting in the center which accepts a standard 1" threaded plumbing pipe (for mounting purposes only). The antenna is connected to the clock receiver via 50 ohm (RG58) coaxial cable with BNC connectors on the ends. For best accuracy, the antenna should be placed outside just above rooftop level (like a TV antenna). However, an inside location near a window facing Fort Collins may turn out to be acceptable. Overall accuracy is specified as plus or minus (.1 millisecond + noise uncertainty + propagation delay setting error), where noise uncertainty is expected to be less than plus or minus .5 millisecond worst case. This accuracy should be more than sufficient for network measurements. Time is output via a front-panel display (hours,minutes,seconds) and an RS-232 (D-15) jack on the rear panel. Also output on the back panel is a 1Hz, 10% duty cycle TTL signal called the "on time" pulse. The leading edge of the on time pulse occurs at the beginning of each second. In addition, a 1MHz standard frequency output is available on the back panel, which is a 3.4V rectangular positive pulse designed to drive a 93 ohm load, but which will drive a 50-ohm load with reduced amplitude. This 1MHz output is phase-locked to the WWVB carrier, and can be used for calibrating counters with high accuracy. The user requests the time by sending the clock an ASCII capital "T". When it receives the "T", the clock waits until the start of the next second, and sends back an ASCII string containing the time. The rising edge of the start bit of the first character in the string occurs within a few microseconds of the rising edge of the on time pulse. Postel [Page 19]
IEN 160 Internet Meeting Notes The time string is structured as: (CR)(LF)I DDD HH:MM:SS TZ=XX(CR)(LF) where: I =space if time synch lamp is on, ? if time synch lamp is off DDD =Julian day of the year (000 to 366) HH =hours MM =minutes SS =seconds (at the start of this typeout) XX =time zone setting with respect to UTC (formerly called GMT). EST is 05, PST is 08. The RS-232 port on the clock runs at a baud rate of 300 baud. The synch lamp on the front panel will be lit if the time can be expected to be reliable within plus or minus 1 millisecond. The clock contains an internal 1MHz oscillator which is kept synchronized to WWVB. If the WWVB carrier is lost, the internal oscillator will keep running, and accuracy to plus or minus 1 millisecond will be maintained for about 10 minutes, at which time the synch lamp will be turned off, although the oscillator keeps running. The back panel also contains thumb wheel switches for time zone setting, propagation delay setting, and a leap year switch. Yes, Virginia, a leap year switch. The purpose of the leap year switch is to maintain the day count properly if the WWVB carrier is lost near midnight of Dec. 30 (on a leap year) or Dec. 31 (on other years). Price is $2600 for the clock itself, $190 for the loop antenna, and $35 for a rack mount kit. APPENDIX C: LOADER SERVER MEASUREMENTS The numbers were average round-trip times calculated by the LDSRV. Each number is the average RT time seen during the load operation, which takes about 350 or so packets. RT times are not calculated for packets that are retransmitted. The average RT time to ARPANET hosts on the same IMP is around 70 msec. There were some times somewhat less and a few a bit more. To MIT, the usual average RT time is about 450 msec. To the Ft. Bragg PE or gateway, the smallest average RT time is 600 msec. The largest average RT time was 1.2 sec. The usual average RT time to SRI PRNET TIUs is 170 msec. The smallest time was not less that 100 msec and the largest is 400 msec. Postel [Page 20]
IEN 160 Internet Meeting Notes To Ft. Bragg PRNET TIUs, the smallest average RT time is a bit more than 600 msec. The usual RT time is around 800 msec and average RT times as large as 2.1 sec have been recorded. Most of the loads had average RT times less that 1.1 sec. In the graphs, the y-axis is the number of loads in which the average round trip time was within the time bucket. ARPANET Hosts 20-+ | | |XX XX |XX XX XX 10-+XX XX XX |XX XX XX XX |XX XX XX XX |XX XX XX XX XX XX XX XX |XX XX XX XX XX XX XX XX XX XX 0 -+------------------------------------ 0 .2 .4 .6 .8 1.0 1.2 secs SRI PRNET Hosts 20-+ | XX | XX | XX | XX 10-+ XX | XX XX | XX XX | XX XX | XX XX XX 0 -+------------------------------------ 0 .2 .4 .6 .8 1.0 1.2 secs Postel [Page 21]
IEN 160 Internet Meeting Notes Ft. Bragg PRNET Hosts 80-+ | XX | XX | XX | XX 60-+ XX | XX | XX XX | XX XX | XX XX 40-+ XX XX | XX XX XX | XX XX XX XX XX | XX XX XX XX XX | XX XX XX XX XX 20-+ XX XX XX XX XX | XX XX XX XX XX | XX XX XX XX XX | XX XX XX XX XX XX XX XX XX | XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 0 -+-------------------------------------------------------------- 0 .2 .4 .6 .8 1.0 1.2 1.4 1.6 1.8 2.0 secs Postel [Page 22]
IEN 160 Internet Meeting Notes APPENDIX D: RECENT DOCUMENTS Author Subject Number ------- ------ ------ IENs Postel Internet Meeting Notes - 14 & 15 May 1980 145 Perlman Flying Packet Radios and Network Partitions 146 Perlman Utilizing Internet Routes as Expressways 147 Through Slow Nets Postel Telnet Protocol Specification 148 Postel File Transfer Protocol Specification 149 Plummer TCP JSYS Calling Sequences 150 Cerf Final Report of the Stanford University 151 TCP Project Cerf DoD Protocol Standardization 152 Bennett Realization of the Yellow Book Transport 153 Service Above TCP Bennett Realization of the Yellow Book Transport 154 Service Above TCP (supersedes IEN 153) Bennett The Yellow Book Transport Service: 155 Principles and Status Cohen Controlled Routing in the 156 Catenet Environment Flood Page CMCC Performance Measurement Message Formats 157 Haverty XNET Formats for Internet Protocol 158 Version 4 RFCs Postel Internet Protocol Handbook TOC 766 Postel Structured format for Multimedia Mail 767 Postel User Datagram Protocol 768 Postel RAPICOM 450 Facsimile Format 769 Postel Assigned Numbers 770 Cerf Mail Transition Plan 771 Sluizer Mail Transfer Protocol 772 Cerf Comments on the NCP/TCP 773 Mail Service Strategy Postel Internet Protocol Handbook TOC 774 Postel [Page 23]
IEN 160 Internet Meeting Notes APPENDIX E: ATTENDEES Name Affiliation Nationality Mailbox ---- ----------- ----------- ------- Vint Cerf ARPA USA Cerf@ISIA Don Allen BBN USA Allen@BBND David Flood Page BBN British DFloodPage@BBNE Jack Haverty BBN USA JHaverty@BBND Bruce Hitson BBN USA BHitson@BBND Dale McNeill BBN USA DMcNeill@BBNE Virginia Strazisar BBN USA Strazisar@BBNA Mike Wingfield BBN USA Wingfield@BBND Gustav Fickenscher BWB.MoD Germany --- Hoi Chong COMSAT Rep. China Chong@ISIE Dave Mills COMSAT USA Mills@ISIE Ed Cain DCEC USA Cain@BBNB Hans Dodel DFVLR Germany --- Helmuth Lang DFVLR Germany --- J. Majus DFVLR Germany --- Gerry Amey DND/CANADA Canada --- Ray McFarland DoD USA McFarland@ISIA Romy Fratilla ELEX USA Deckelman@ISIA Horst Clausen IABG Austria Clausen.IABG@MIT-Multics Danny Cohen ISI USA Cohen@ISIB Jon Postel ISI USA Postel@ISIF Cliff Weinstein Lincoln Lab USA cjw@LL-11 Estil Hoversten Linkabit USA Hoversten@ISIA Dave Clark MIT USA Clark@MIT-Multics Frank Deckelman NAVELEX USA Deckelman@ISIA Oyvind Hvinden NDRE Norway Oyvind@DARCOM-KA Yngvar Lundh NDRE Norway Yngvar@DARCOM-KA Paal Spilling NDRE Norway Spilling@SRI-KL Vince Hathway NPL British --- Andrew Bates RSRE British T45@ISIE Trevor Benjamin RSRE British T45@ISIE Brian Davies RSRE British T45@ISIE Roger Edwards RSRE British T45@ISIE Alan Fox RSRE British T45@ISIE Silvia Giles RSRE British T45@ISIE John Laws RSRE British T45@ISIE Paul Masterman RSRE British T45@ISIE Jo Penley RSRE British T45@ISIE Gill Roberts RSRE British T45@ISIE Ron Kunzelman SRI USA Kunzelman@SRI-KL Jim Mathis SRI USA Mathis@SRI-KL Holly Nelson SRI USA HNelson@SRI-KL Zaw Sing Su SRI Canada ZSu@SRI-KL Postel [Page 24]
IEN 160
Internet Meeting Notes
Chris Bennett UCL British UKSAT@ISIE
Robert Cole UCL British UKSAT@ISIE
Ron Jones UCL British UKSAT@ISIE
Steve Treadwell UCL British UKSAT@ISIE
Postel [Page 25]
mirror server hosted at Truenetwork, Russian Federation.