[IMR] IMR86-12.TXT Westine [Page 1]  ~ DECEMBER 1986 INTERNET MONTHLY REPORTS ------------------------ The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the task forces and contractors in the ARPA Internet Research Program. This report is for research use only, and is not for public distri- bution. Each task force and contractor is expected to submit a 1/2 page report on the first business day of the month describing the previous month's activities. These reports should be submitted via ARPANET mail to Westine@ISI.EDU. Reports are requested from BBN, ISI, LL, MIT-LCS, NTA, SRI, UCL, and UDEL. Other groups are invited to report newsworthy events or issues. BBN LABORATORIES AND BBN COMMUNICATIONS CORPORATION --------------------------------------------------- ARPANET STATUS As members of the Internet community know, the ARPANET is at the core of the Internet. Performance of the ARPANET impacts perfor- mance seen by the entire Internet community, just as behavior of users of, and the performance of, other networks impacts the Westine [Page 1]  Internet Monthly Report December 1986 traffic carried by the ARPANET. In late summer and early fall of 1986, the ARPANET experienced severe performance problems. The occurrence of these problems led DARPA, DCA, and BBNCC to focus greater attention on the ARPANET, with a view towards taking steps to correct the immediate problems as well as towards making longer-term improvements to the network. As a part of this increased attention to the ARPANET, we will now include a brief ARPANET status update in its Internet monthly reports. In order to bring the community "up to speed" on the ARPANET situation, our first report is necessarily a lengthy one. Over the past year and a half, traffic carried by the ARPANET has increased approximately 33%. However, the topology and capacity of the ARPANET is essentially the same as it was at the time of the ARPANET/MILNET split in late 1984. The user community is moving strongly towards a pattern of LAN and Gateway attachment of hosts to the network, resulting in increased concentration of traffic through a proportionately smaller number of ARPANET PSNs and PSN host ports than was formerly the case. In fact, fully 85% of the traffic handled by the ARPANET has an Internet Gateway as its source or destination. In addition, a topology change in the net- work stemming from the relocation of a network node at USC in August resulted in a 19.2 kb/s circuit on the USC campus being placed at the West Coast end of one of the ARPANET's three cross- country routes. All of these factors contributed to the severe congestion experienced by users in September and October. Since that time, the ARPANET has had some "ups" and some "downs". The topology of the network was rearranged to remove the 19.2 kb/s circuit from the cross-country path, and a line between Purdue and Wisconsin was restored to the network. C/30 PSN parameters were adjusted to equalize propagation delay across the three cross- country routes, and PSN and TAC software was brought up to current releases. In addition, routing parameters in the Wideband Net But- terfly Gateways were adjusted so that inter-LAN traffic would favor the Wideband Net over the ARPANET. These steps, taken together, produced a significant improvement in ARPANET performance between early October and early November. Mean Round Trip delay was halved from 625ms in early October to approxi- mately 300ms. "Traps" indicating congestion reported by the C/30s to the ARPANET Monitoring Center dropped by an order of magnitude. ARPANET capacity remains critical, however. This was demonstrated in late November and through most of December, when two key cir- cuits, one between CMU and DCEC, and the other between TEXAS and BRAGG, were out of service for extended periods. During this time, delays and congestion were once again prevalent, and congestion traps increased nearly to the levels seen in October. Both of these lines were restored to service shortly before the Westine [Page 2]  Internet Monthly Report December 1986 holidays. This, coupled with the light traffic normally experi- enced during the holidays, has resulted in the return of good net- work performance. We will be monitoring network performance closely as traffic returns to normal levels in January. Finally, on December 12, the ARPANET experienced a significant outage due to an AT&T transmission failure between Newark, NJ and White Plains, NY. During this period, over ARPANET 30 nodes were isolated from the Monitoring Center, and the Northeast corner of the network became fragmented. The outage lasted approximately two hours, and the normal operation was restored with the restoral of the transmission facilities. This incident illustrated the fact that common carrier communications circuits are heavily multi- plexed, and that the trunk circuits of the ARPANET are not as spa- tially diverse as the Logical Map of the network might suggest. We will continue to work with DARPA and DCA to improve ARPANET per- formance. We have made, and will continue to make, specific recom- mendations for the enhancement of network performance, and will report on ARPANET status, albeit more briefly, in future Internet monthly reports. WIDEBAND NETWORK Problems in the Earth Station Interface at the ISI Wideband site were corrected using ESI hardware shipped from BBN. These problems had adversely affected the ongoing MIT-ISI NETBLT protocol experi- ments by causing unusually high bit error rates in traffic received from the Wideband channel at ISI. BBN is currently investigating an equipment problem at the Lincoln Laboratory Wideband site that is causing brief outages of local satellite channel connectivity on a periodic basis, primarily occurring at night. The Wideband Butterfly Gateway software was modified to request a higher reliability level for datagrams traversing the Wideband Net. The stronger error-correcting code that is now being used should result in fewer packets lost due to Wideband channel errors. The Ft. Monmouth Wideband equipment was returned to satellite chan- nel operations at the end of the month. It had been temporarily de-activated due to frequent scheduled power outages caused by work on nearby facilities. On December 11, the Wideband Net supported a coast-to-coast IAB meeting held via the multimedia conferencing facilities at BBN and ISI. The meeting's packet video and packet voice traffic was sent over the Wideband channel. The participants' reactions to their experience were solicited to help determine which aspects of the Westine [Page 3]  Internet Monthly Report December 1986 conferencing facility require further improvement. BSAT software development work focused this month on continuing design and implementation of stream scheduling synchronization code. In addition, work on the new Butterfly Satellite Modem Interface (BSMI) hardware progressed with delivery of the first production run of BSMI boards to BBN. GATEWAYS We installed new software (Rel 3.6) in all of the Wideband But- terfly Internet Gateways which fixed a bug that was causing them to frequently restart. Since the new software was installed ARPA-WB, BBN-WB, CMU-WB, ISI-WB, and MIT-WB have been very stable. MIT-WB had a broken I/O board which was fixed. SRI-WB and RADC-WB currently have hardware problems which are being worked on. This was made more difficult by the holidays. The CSS, NTA, and CNUCE Satnet gateways were very stable over the month. RSRE was plagued by two solid hardware failures. We sent someone to England to work on the machine who replaced two boards. UCL was isolated by the RSRE failure. The other Butterfly Gateways (ARPA, BBN, BBN-EN1, BBN-EN2, ISI, MIT) were working very well during the month with only a few short outages. Just to show that even PDP-11's break too, the DCEC PDP-11 Gateway also had hardware problems toward the end of the month. DEC field service was called in to fix it. During the outage, we used EGP to allow the UCL PDP-11 gateway to get access, via the CSS Butterfly Gateway, to the rest of the Internet. SATNET We are continuing to experience some problems with channel 1 (errors and some lost hellos). We have been waiting for spare modems from Linkabit before attempting to work on the network. In January we will try to go ahead with the work to improve perfor- mance on channel 1. Channel 0 has remained healthy so problems with channel 1 have not seriously affected the overall performance of the SATNET. Early in the month the problems with channel 1 caused several SIMP crashes. The SIMPs were reloaded and looped off channel 1. A long standing bug would cause a SIMP to crash if a channel was lost for over 30 minutes. The bug has been found and fixed. We now expect the SIMPs to remain stable in spite of problems with channel 1. Westine [Page 4]  Internet Monthly Report December 1986 We realize that there have been interruptions in the overall ser- vice provided by the SATNET. There have been problems with the gateways and some line problems between the SIMPs and the gateways. VAX NETWORKING In the month of December, the first successful cross-country Inter- net multicast tests were conducted, with the 4.3bsd multicast software running on a Microvax at Stanford University and a Vax at BBN, and the V System multicast implementation running on Sun workstations at Stanford. The first beta version of the 4.3bsd multicast software (both IGMP implementation and multicast agent) was shipped to Eric Cooper, of Carnegie-Mellon University. Eric is supervising the porting of the multicast software into the MACH operating system. Survivable Radio Network (SURAN) Since this is the first contribution from the Survivable Radio Net- work (SURAN) project at BBN, this note will include some informa- tion on project goals, background, etc. The goal of SURAN is to create a large (1000s to 10,000s of nodes) distributed network with a control structure that is capable of surviving the loss of components, jamming and active attacks on the network control structure. BBNs role in SURAN to date has consisted of three main efforts: the development of a network architecture that is capable of supporting a very large number of nodes, the development of a security archi- tecture that can protect control traffic and support efforts to defend the network, and the development of a network manager which allows the operator to display both global overviews of the network and detailed views of specific nodes. The network architecture that has been developed is a hierarchic one. Nodes are organized into clusters, and clusters into super- clusters; nodes keep track of routes to nodes in their cluster, to clusters in their supercluster and to all superclusters in the net- work. Protocols have been developed for clustering, for computing routes, for forwarding packets and for address service. (Address servers provide source nodes with the hierarchical address of a destination node. This address is used to determine the destina- tion cluster and supercluster and in routing the packet to its des- tination.) While our eventual goal is to develop a network without specialized nodes (as this is the most robust), to expedite the research into these algorithms we have adopted an intermediate architecture in which special hardware is used to implement Westine [Page 5]  Internet Monthly Report December 1986 clusterheads and superclusterheads. (These nodes are used to form the clusters and to compute and distribute the hierarchic routes. They play no special role with respect to forwarding packets and routes are no more likely to go through a clusterhead than through any other node.) Most recently we have been implementing the clus- terhead software and have been studying caching algorithms for the address servers. The security architecture will be responsible for protecting con- trol traffic from unauthorized disclosure, authenticating nodes, preventing the undetected mutilation of control traffic, and for allowing over-the-air rekeying of nodes. We are currently in the midst of a study which will more precisely define the requirements of SURAN, evaluate alternative architectures and consider the issues involved in integrating the selected security architecture with the other SURAN protocols. The network manager (NM) will be useful in both developmental and operational situations as it can be used for remote debugging of nodes and for displaying integrated views of the state of the net- work. These views are expected to assist an operator in determin- ing the source of problems (congestion, jamming, attacks, etc.) and in dealing with them. The NM is currently capable of displaying information from "old" packet radios (developed under the PRNET project). We are currently writing software to allow the NM to monitor the packet radios being built for the SURAN project, and are developing AI tools to assist an operator in detecting prob- lems. Bob Hinden ISI --- Internet Concepts Project RFC 993 was published: Clark, D., "PCMAIL: A Distributed Mail System for Personal Computers", RFC 993, MIT, December 1986. Greg Finn began looking into high speed fiber optic connec- tions for ISI to nearby Universities. Multimedia Conferencing Project Joyce Reynolds presented a BBN Diamond Multimedia Mail demo to Dave Taylor of Hewlett Packard December 15. Brian Hung tested out the validity of the Multimedia messages he had generated on the IBM-PC AT and was partially Westine [Page 6]  Internet Monthly Report December 1986 successfull. After some modifications to the Multimedia mes- sage format on the IBM-PC, he was able to deliver the messages to the BBN's Diamond Multimedia System. However, the Diamond System was unable to present the bitmap data on the Sun works- tation. The problem is in the Multimedia Message Content Pro- tocol generated by the IBM-PC which the Diamond System was unable to interpret. Further tests will be conducted after some modifications to the Multimedia messages generated by the IBM-PC. Brian Hung A second bi-coastal meeting of the Internet Activities Board was held on December 11th. The six participants at each of the two sites ISI and BBN communicated through packet voice and video teleconferencing for the seven-hour meeting. This time all conference traffic was carried over the Wideband Net- work, whereas for the previous bi-coastal meeting in August a commercial telephone circuit carried the voice signal. The packet voice system provided a true "4-wire circuit" between the two sites so we were able to test different methods of conference room echo suppression. More work is needed on the audio system, but the participants generally agreed that the video teleconference provided an effective and convenient means for the group to meet. Steve Casner NSFNET Project On December 16-17, Bob Braden attended a two-day meeting at the University of Delaware on NSFNET technical and administra- tive issues. Jon Postel and Bob Braden began work on the next revision to the Gateway Spec RFC (RFC985). As part of its NSFNET protocol coordination activities, we have started looking at user-level protocol issues which are likely to be relevant to the NSFNET user community but have not been of interest to the Internet research community. Good examples of such issues are background file transfer and remote job entry. Bob Braden is preparing a draft RFC updat- ing the ARPANET RJE protocol to match current requirements. Annette DeSchon is building an experimental background file transfer server on a Sun workstation. This server will allow a user to submit a request for a reliable file transfer to take place in the future, thus insulating the user from prob- lems such as temporary host and network outages. The server will allow a user to interactively specify sets of file transfer parameters -- source and destination hosts, logins, and file names. In addition ,the user may specify the time to Westine [Page 7]  Internet Monthly Report December 1986 start the file transfer, the number of times to retry the transfer, the retry interval, and a mailbox where a message reporting the results will be sent. The actual transfer will be performed using the third-party model of FTP (RFC959). Bob Braden Supercomputer and Workstation Communication Project Alan Katz started to experiment with X-Windows and did a com- parison of equations in Xerox Viewpoint, Interleaf, EQN/Troff, and TEK (Alan liked EQN best). Alan Katz LINKABIT ------- Multiple Satellite System (MSS) MSS will be a global low-altitude satellite network, currently in the preliminary design phase. The present design is for 240 satel- lites uniformly distributed over the globe, at an altitude of about 400 NMiles. Their orbits are effectively random wrt each other as a function of time, since they do not have station-keeping (no onboard propulsion). Support for up to 10,000 earth terminals (ETs) will be provided. Needless to say, MSS will be a packet switched network supporting prioritized data and voice. The key motivation is survivability through satellite proliferation. The present effort involves 11 contractors for a 1-year preliminary design effort which will end next February; Phase II, detailed design and prototype development, is expected to start around next August. Dual awards exist for the three major satellite hardware elements: satellite bus is RCA and Ball; radio is Harris and Cin- cinnati Electronics; antenna is Rockwell Anaheim and Harris. Also under contract are Qualcomm for protocols, Spacecom and COMSAT for system issues, and ourselves (M/A-COM Govt Systems, aka Linkabit) as SETD. The comm architecture which has evolved as a result of the present and past efforts consists of a beam-hopped time-shared approach. All satellites and ETs operate on the same frequency with a single half-duplex transmitter and receiver. Each has an electronically steered directional antenna (eg, phased aray), which is time-hopped synchronously on each link. A new protocol has evolved to achieve efficient multiple accessing, ie, which minimizes RF power and spectrum requirements (power is the major cost driver for the satellite). The access protocol is called ARNS (Adaptive Receive Westine [Page 8]  Internet Monthly Report December 1986 Node Scheduling), developed by Qualcomm. Robust link establishment and antenna pointing techniques are planned which do not require knowledge of absolute position or satellite motion (the satellite will use a simple gravity gradient boom for vertical stabilization, providing a 3-sigma motion about the nadir of about 10 degrees). The major protocol effort now get- ting underway is in the development of a routing protocol. We are also evaluating an autonomous position estimation approach (no ground tracking) which could provide absolute position info if that proves useful for routing and/or link acquisition under jamming conditions. Dick Binder MIT-LCS ------- December Report from MIT-LCS This month we have seen more wonderful examples of the fragility of the Internet mail system: one in which a reply with a malformed "Cc:" field looped repeatedly between two mailers, and one in which a malformed mailer interaction caused 157 copies of a 30 Kbyte mes- sage to be delivered. The disk at the receiving end overflowed when the mail file hit 16 Mbytes. Continued research into the robustness of distributed systems is clearly justified. Lixia Zhang NTA & NDRE ---------- No report received. ROCKWELL INTERNATIONAL ---------------------- Introduction Rockwell International has participated sporadically in the Internet Research Program during the past couple of years. Until recently, our participation has been limited mostly to Internet task force meetings: John Jubin participated in all three of the Robustness and Survivability Task Force meetings, and Jim Stevens participated in the June 1985 and May 1986 Tactical Internet Task Force meetings. Over the past three months, however, our participation has grown to Westine [Page 9]  Internet Monthly Report December 1986 the point that we decided we should report our activities in the Internet Monthly Report. Our recent activities have consisted mostly of David Young's investigation into Internet multicast protocols, as applied to tactical scenarios, and Jim Stevens' design of a Transaction Transport Protocol. These activities are described below. Tactical Internet Multicast Protocols This past summer, a multicast routing protocol for packet radio networks was designed under the auspices of the Army/DARPA Distributed Communication and Processing Experiment (ADDCOMPE). As an outgrowth of this activity, David Young investigated the work that was being done by the Internet Research Group to develop a multicast capability within the Internet. David reviewed two RFCs - RFC 966, "Host Groups: A Multicast Extension to the Internet Protocol", and RFC 988, "Host Extensions for IP Multicasting" - and established DDN-mail discussion with the authors. We assessed that these protocols would be inefficient for limited-bandwidth, multi-hop networks such as the ARPANET and packet radio networks, and that they would not support the rapid forming and disbanding of multicast groups envisioned for tactical scenarios. David suggested extensions to the manner in which host groups are formed and deleted. In particular, he specified the capability for a host to form a (multicast) host group, enumerating the (initial) membership of the group. This capability would provide for much more efficient dissemination of the required control information throughout the internetwork and throughout the participating networks. Transaction Transport Protocol (TTP) Jim Stevens designed a transaction-oriented transport-level protocol for the Internet which he called the Transaction Transport Protocol (TTP). He wrote a draft RFC and made it available to Bob Braden and the SUrvivable RAdio Networks (SURAN) Implementers Group for preliminary review. TTP evolved from the Simple Network Acknowledging Protocol (SNAP), the transport-level control protocol implemented as part of the SURAN Protocol suite. As originally conceived, TTP would have provided features to support client/server applications such as correlation of server response to client request. However, while doing the detailed design, Jim discovered that providing these special features along with the basic transaction/message reliability would have added complexity without supporting all of the desired client/server application requirements - requirements that arise, for example, from remote procedure calls or Westine [Page 10]  Internet Monthly Report December 1986 sensor monitoring. Thus Jim simplified the protocol down to providing the basic services for reliable message/transaction delivery: o message orientation, including fragmentation/reassembly of large messages; o reliable delivery, that is positive indication that the message arrived at the destination without errors (from lost, out of order, or duplicate packets, or from packets with bit errors), and that the messages arrived in correct sequence; o low delay from minimum number of packets due to piggybacking of acknowledgments and data, selective acknowledgement, and no explicit connection setup or teardown phases; o TCP-port-like addresses. Jim also described how some of the different client/server application requirements can be provided on top of TTP. John Jubin SRI --- The Functional Summary of the DARPA SURAP1 Network has been pub- lished. This document describes the functionality of the first protocol release - - SURAP1 (SUrvivable RAdio Protocol) of the DARPA SURAN (SUrvivable RAdio Network) program. It describes the physical components, features and size of the network and illus- trates briefly how data is forwarded through the network. This paper is intended to provide a high level description of the SURAP1 network. A large number of other papers have also been written during the course of the SURAN program. This documentation includes algorithm design, user guides and software specifications. The SURAN bibliography identifies all the documentation which currently exists for the SURAN program and briefly describes the contents of those documents. Janet Tornow Westine [Page 11]  Internet Monthly Report December 1986 UCL --- UCL has now said goodbye to Peter Lloyd, who has just finished his PhD thesis. We wish him well in the future. Peter has just written up his most recent work on the measurements we have been making over the UCL-SATNET path to the US, and the following reports are available. Internal notes 2057,2058: Bottleneck Tests on the UCL-Goonhilly Path Testing for Anomalous SATNET Delays Work has continued on protocols for distributed computing, with a pilot implementation of the sequential exchange protocol for the PC_IP environment. The UCL RPC mechanism now runs under several flavours of UNIX (4.2/4.3/SysV), MS-DOS and CMOS. Interoperation of the UDP version has been tested, but a full RPC/ESP system is only available for Sun 4.2BSD so far. An implementation of a high-performance low-cost ethernet-ethernet IP bridge with per-host access control has been started. This runs under CMOS on a Q68 (MDB) Board with a Q-Bus and two DEC Deqna eth- ernet interfaces. The use of PEPY as an alternative to Courier and Glue (the UCL XDR language) is being looked at for various applications, especially directory and authentication services. (PEPY is the presentation specification parser from Marshall Rose's ISO-Stack implementation) Jon Crowcroft UNIVERSITY OF DELAWARE ---------------------- 1. I continued to collaborate with Linkabit staff on the design of the Dissimilar Gateway Protocol (DGP) for Ford Aerospace and RADC. I designed an authentication procedure suitable for the initial acquistion phase and distributed a draft proposal to the task forces. I also continued working on a comprehen- sive architecture document for DGP. Linkabit staff are working on architectural models, state descriptions and requirements analyses. 2. The Network Time Protocol (NTP) network has been expanded by Westine [Page 12]  Internet Monthly Report December 1986 the addition of a new WWVB primary radio clock at the National Center for Atmospheric Research (NCAR) in Boulder, CO. The clock, kindly furnished by Steve Casner at ISI, is connected to the NCAR fuzzball on the NSFNET Backbone, so that its ticks can be heard throughout the Internet community. The two pri- mary radio clocks that keeled last month have returned to ser- vice, making a total of four (Vienna, VA, College Park, MD, Dearborn, MI, and Boulder, CO). 3. A new X.25 port came up on the University of Delaware IMP for the UDELNET swamp. Wiring was completed for an 1822 port allo- cated to the fuzzball gateway as well. We anticipate moving the DCNET (128.4) from Linkabit to here shortly and leaving a new class-C net behind for Linkabit use. 4. A new gateway TERP.UMD.EDU came up between the University of Maryland UMDNET and ARPANET using an ACC 5250 interface and driver. I attempted to repeat the experiment reported last month with the PSC-GW.PSC.EDU gateway at CMU, but could not get any reliable data at all. It seems something seriously is wrong at both sites with the interface, driver or IMP. A new ACC 5250 interface is to be installed here shortly, so we are very concerned to get to the bottom of this. 5. The University of Delaware hosted two NSF meetings on 16-17 December. One was attended by about two-dozen wizards from the technical staffs of the various NSFNET Backbone sites and cam- puses, while the other was attended by about the same number of buzzards from the administrational and operational staffs. The meetings proved a fine forum to air many of the issues being faced by these creatures now and surely by many others in the Internet community in future. 6. I attended a two-day National Academy of Sciences committee meeting on telephone network reliability, an IAB telemeeting at ISI and an interesting and useful meeting on gateway and routing issues with the ANSII and Internet buzzards at SRI International. 7. I also added a simple, UDP-based, network-statistics query/response feature for the NSFNET fuzzballs, rebuilt the serial device drivers for greater reliability, implemented a Unix-compatible SLIP driver and rebuilt the kernel storage- management system. Dave Mills Westine [Page 13]  Internet Monthly Report December 1986 TASK FORCE REPORTS ------------------ APPLICATIONS No report received. END-TO-END SERVICES No progress to report this month. Bob Braden INTERNET ARCHITECTURE 1. Activity continued at a good clip on the TCP/IP and NSF- ROUTING lists, as well as in ad-hoc exchanges, but the INARC- TF list remained relatively quiet. A proposed authentication scheme was distributed to the INARC-TF list for advice and comment. 2. Current issues under discussion include the explosive growth of the NSFNET community with the inauguration of the SURANET and NYSERNET regional nets. These nets now provide many, diverse paths between a surprising number of campus nets form- erly connected only by ARPAnet and MILnet. For instance, thirty-one campus and regional nets now share backup gateways to the ARPANET at Cornell, Maryland, CMU and Linkabit (Vienna, VA), as well as their own gateways. At a recent meeting of campus network operators it was estimated that an additional fifty networks will become operational within the next six months. There is a crucial need to study and resolve issues in load sharing, type-of-service routing and interoperability with existing and proposed routing architectures and proto- cols. 3. There were no other submissions on activity areas as requested last month. Dave Mills Westine [Page 14]  Internet Monthly Report December 1986 INTERNET ENGINEERING No report received. INTEROPERABILITY No progress to report this month. Deborah Estrin PRIVACY During December, John Linn distributed a revised draft of the Privacy Task Force's RFC, "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encipherment and Authentica- tion Procedures" to the task force membership for final review prior to dissemination to the Internet community. John Linn ROBUSTNESS AND SURVIVABILITY No report received. SCIENTIFIC COMPUTING No report received. SECURITY No report received. TACTICAL INTERNET No report received. Westine [Page 15]  Internet Monthly Report December 1986 TESTING AND EVALUATION No report received. Westine [Page 16]