[IMR] IMR87-09.TXT Westine [Page 1]  ~ SEPTEMBER 1987 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 participating organizations. This report is for research use only, and is not for public distribution. Each organization 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 network mail to Ann Westine (Westine@ISI.EDU) or Karen Roubicek (Roubicek@SH.CS.NET). BBN LABORATORIES AND BBN COMMUNICATIONS CORPORATION --------------------------------------------------- ARPANET PSN 7 SOFTWARE UPGRADE During the month of October software in the ARPANET packet- switching nodes (PSNs) is being upgraded from Release 6 to Release 7. This is a major software upgrade that will, when completed, introduce the "New End-to-End Protocol" into the ARPANET. The upgrade is being performed in phases. Some service disruption can be expected, as nodes must be loaded with new software and restarted. In addition, prior to the cutover of all ARPANET PSN's to the New End-to-End Protocol, groups of nodes will be switched to the New End-to-End Protocol for brief test periods. During these Westine [Page 1]  Internet Monthly Report September 1987 periods, the nodes testing the New End-to-End Protocol will be isolated from the remainder of the ARPANET. Interested users should consult DDN Management Bulletin No. 34 dated 9 September 1987 for further details. Users with questions concerning the upgrade process may send electronic mail to ARPAUPGRADE@BBN.COM. ARPANET USER DATABASE CUTOVER During October, the User Database Host (UDH) will migrate from a TOPS-20 machine at ISI (ISI-C) to a MicroVAX-II at BBN. ISI-C is being phased out at the end of October. The transition to the new UDH is planned as to minimize the impact on the TAC users. The UDH cutover can't be completely transparent, but with the cooperation of the users and administrators it can be accomplished in the time allotted. The major impact, if any, will be felt mainly by users whose passwords expire during the transition period and by new users. The ARPANET TAC Access (TACACS) System is designed to limit access to the ARPANET through Terminal Access Controllers (TACs) to authorized users. A user who dials into a TAC port through the public switched telephone network is required to give a valid user ID and password before the TAC will permit the user to open a connection to an ARPANET host. The system currently running on the ARPANET is composed of a User Database Host (UDH), three Login Hosts and a monitoring host. Software for the current User Database Host runs on a TOPS-20 system located at ISI. A new UDH system, running on a MicroVAX-II using the INGRES database system has been developed by BBN and is ready to be put into service on the ARPANET. The new UDH has been running successfully at BBN for over a year. The current plan is to transition to the new UDH on 10/26/87. We will be sending more details on the cutover to TACACS users in the next week. WIDEBAND NETWORK The implementation of a "round-robin" control slot assignment scheme in the BSAT software has been completed and is undergoing testing. Control slots are fixed size subdivisions of satellite channel time. They are primarily used by the BSATs to broadcast reservation requests for the satellite channel capacity required to transmit user data. As such, the control slots represent a component of the overhead introduced on the satellite channel by the PODA protocol. There is currently one control slot assigned to each BSAT in each PODA frame. The new round-robin scheme will allow the control slots to be assigned such that each frame will contain fewer slots than the total number of BSATs; this will give each BSAT one control slot assignment in every N frames, where N is a network parameter that can be modified by the network manager. Westine [Page 2]  Internet Monthly Report September 1987 The flexibility inherent in this scheme should allow better management of network-wide delay/throughput tradeoffs as a function of the network users' needs. A three-site video conference connection using Wideband Network packet broadcast facilities was achieved for the first time on September 29. The three sites involved in the connection were ISI, BBN, and a BBN test site (the latter sharing earth station facilities with the operational BBN site). The BBN and ISI sites used real video compression hardware. Since real video compression hardware was not available for the BBN test site, that site operated in an echo mode, returning all of the video data received from one of the other two sites. Conference participants at each site were able to view a video display which was partitioned to provide the video images received from the two other sites. SATNET The SATNET remained healthy during the month of September. From tests run by ISI, the SIMPs showed an average availability of 99.5% out of 99.5% for the month. We are continuing to see gateway resets at the SATNET sites and are waiting for the next software release. In the middle of the month, however, the Tanum site was reporting a large number of packets with errors on channel 0. No other sites were affected. The problem was isolated to the receive side of the modem. The modem from channel 1, which was not being used, was moved to channel 0. The problem disappeared. From spare hardware in the PSP terminal, channel 1 was also brought up. One of the modules used to bring channel 1 up, however, was suspected of causing a past problem. We are watching it closely for any bad behavior. INTERNET RESEARCH & DEVELOPMENT We are about half way through fielding Release 3.10 in all of the Butterfly Gateway sites. So far it looks very solid. We should have it in all of the sites in a week or two. We are also about to turn on the fragmention of EGP updates in the LSI-11 and Butterfly Gateways to support the growth in the number of networks. At last count we saw 299 networks. This will result in the EGP updates being fragmentated as soon as it is enabled in the gateways. If you have a gateway which runs EGP with the core system (Arpanet and Milnet) and does not do IP reassembly, please contact me (hinden@bbn.com) as soon as possible. Bob Hinden (hinden@PARK-STREET.BBN.COM) Westine [Page 3]  Internet Monthly Report September 1987 ISI --- Internet Concepts Project Greg Finn continues researching recent results on the Byzantine generals problem to see if they can be applied toward attack resistant routing. Three RFCs were published. RFC 1019: Arnon, Dennis "Report of the Workshop on Environments for Computational Mathematics", Sep., 1987. RFC 1025: Postel, J. "TCP and IP Bake Off", Sep., 1987. RFC 1026: Kille, S.E., "Addendum to RFC 987 (Mapping between X.400 and RFC-822)", Sep., 1987. Ann Westine (Westine@ISI.EDU) Multimedia Conferencing Project This month we established our first three-site video conference connection, using an interim implementation of the ST conference protocol in the Packet Video Program and Voice Funnel, and multicast group addressing in the Wideband Network BSATs. The three sites were ISI, BBN and Ft. Knox (the Ft. Knox site is physically located at BBN, but shares only the analog portion of the BBN earth station and is effectively the same as a separate site). Each site produced a video data stream of 230Kb/s which was delivered through the multicast mechanism to the other two sites. Since we have only two real video compression systems, the Ft. Knox copy of the Packet Video Program was put into a data-echo mode to return the data stream of the first participant connected to it. At the ISI and BBN sites, the display on the video monitor was split into top and bottom halves to show the other two sites. For example, if ISI connected to Ft. Knox first and then BBN connected to ISI, the display at ISI would show an echo-delayed (via Ft. Knox) ISI image on top, with a direct BBN image on the bottom. At BBN, the direct ISI image would be shown on top with an echo-delayed ISI image on the bottom -- an interesting effect! The roles were reversed by re-establishing the connection with the BBN to Ft. Knox link first. Westine [Page 4]  Internet Monthly Report September 1987 In the future we will replace the two prototype video compression systems with commercial hardware so the number of real sites can be expanded. Steve Casner (Casner@ISI.EDU) Brian Hung has been able to successfully incorporate TFTP into his Pascal program. This has allowed him to write a conferencing mode of his IBM-PC scanner program as described in the last monthly report. This program has been written and is undergoing tests. Brian Hung (Hung@ISI.EDU) NSFNET Project Annette DeSchon continued work on the Background File Transfer Program (BFTP). The major accomplishment was to make a version of BFTP which can be invoked with a Telnet connection to a well-known port, without login. The intent is to provide an FTP executive agent that can be accessed from anywhere, to perform third-party transfers between any pair of hosts. Specifically, Annette developed a server module "bftpd", which runs under "inetd", the standard BSD4.x well-known port dispatcher, and in turn transfers to the BFTP user interface module "bftp". When a SYN arrives for the BFTP well-known port (152), "bftpd" opens the TCP connection and performs Telnet negotiations. When it receives control, the user interface "bftp" allows the user to enter file transfer requests using a TOPS20-style command parser. The major modules of BFTP -- "bftp", "bftpd", and "fts" -- have all executed on both Sun workstations under 4.2BSD and a VAX running 4.3BSD. Bob Braden continued work on the statistics collection programs, "statspy" and "collect", described in last month's report. Bob Braden & Annette DeSchon (Braden@ISI.EDU, DeSchon@ISI.EDU) Supercomputer and Workstation Communication Project Alan Katz continued to develop some X-windows based tools using the Xt toolkit. Alan has also been writing a few lisp functions for GNU Emacs which also has an X-windows interface. Westine [Page 5]  Internet Monthly Report September 1987 Alan put together an EQN previewer which can be run from either GNU Emacs or at an Xterm window and will preview in an X-Window a selected block of EQN (the equations preprocessor for troff). Alan Katz (Katz@ISI.EDU) MIT-LCS ------- No report received. MITRE Corporation ----------------- The objective of the MITRE Internet Engineering program is twofold: 1) to address internet level performance issues for the DoD internet and 2) to address the interoperability between the DoD and OSI protocol suites as support for a planned transition from DoD to OSI protocols. During August and September, MITRE finalized the following documents: 1. Landmark Hierarchy, Description and Analysis. 2. Landmark Routing, Architecture, Algorithms, and Issues. 3. Assured Destination Binding. 4. A Model of Interadministration Network User Authentication and Access Control. 5. A Communications Protocol for User Authentication and Access Control. 6. Internetwork Performance Measurements and Analysis. 7. An Evaluation of Congestion Control Techniques for the Internet, Vol. 1: Gateway Topology. 8. An FTP/FTAM Application Bridge. 9. Name Domain in MILNET: Issues and Solutions. 10. DoD/ISO Implementation Plan. 11. DoD Protocol Engineering Plan. Ann Whitaker (Whitaker@Gateway.Mitre.Org) NTA & NDRE ---------- No report received. Westine [Page 6]  Internet Monthly Report September 1987 SRI --- Internet Research Jose Garcia-Luna organized the technical program of the ACM SIGCOMM '87 workshop on frontiers in computer communications technology, held at Stowe, Vermont on August 11-13, 1987. The workshop was sponsored by ACM with support given by the Information Sciences and Technology Center of SRI International. The proceedings of the workshop will appear as a special issue of the ACM Computer Communications Review. Jose Garcia-Luna Multimedia Conferencing/Wideband Network The Experimental Multimedia Conferencing Environment (EMCE) was installed in the CECOM WB Satnet facilities at Ft. Monmouth. An initial connectivity and routing check test suite was first used to establish an appropriate connection between Ft. Monmouth and SRI. Then, EMCE was used at site sites to communicate and discuss a simulated C2 joint operations scenerio. Digital voice, normalized pointer, and pictoral (graphic or image) display commands were exchanged using the datagram transport mode. End-to-end delays of one second were measured. This demonstration is in support of the Joint Directors Laboratories program showning technologies that can interoperate between tri-service sites. This is the first time this software has run at a service (Army) WB Satnet site. Future plans are to have similar demonstrations involving RADC (Air Force) and NOSC (Navy). Earl Craighill Zaw-Sing Su UCL --- As announced by Steve Kille, the FTAM service at UCL is available over the internet. We are also running over a **full** connection based OSI stack inside the UK. The UCL Network Service System is now totally separate from the UCL CS Networks. The advantages of this for access control to the internet are great, and the management of relay services is now greatly simpilified. Westine [Page 7]  Internet Monthly Report September 1987 One consequence of the changes is that the SAM (SATNET Access Machine) is no longer required for routing and access control, and has (sadly) been de-commissioned. We note that it's availability was rarely below 100%, and that its mean time between failure was of order weeks! We are currently expanding the UCL swamp with MAC Bridges (from a UK company called Logic Replacement Technology). These devices allow interconnection of Ethernets directly, or separated by up to a kilometre using, multiple Megastream links (n*2.048 Mbps). As a consequence of this, we are working on the problems of loop automatic load sharing, link failure resilience, and loop resolution for MAC Bridges. John Crowcroft (jon@CS.UCL.AC.UK) UNIVERSITY OF DELAWARE ---------------------- 1. A massive disruption of the NSFNET community began on 29 September and continues into October. After several days of intensive investigation, it appears that the primary cause is a shortage of virtual-circuit resources in the ACC 5250 X.25 interface of the main NSFNET gateway at the Pittsburg Supercomputing Center. Secondary causes include incorrect configurations of some alternate gateways, exceptionally noisy lines on the alternate links and instability of the EGP gateway data base observed in the core gateways and clients. The result is apparent fragmentation of the ARPANET with respect to the gateway and much lost traffic. The cure for the interface problem may be a redesigned software driver that manages virtual circuits more effectively; however, in the long run this problem can be expected to impact other gateways and PSNs as well. A series of reports on these findings was distributed to the tcp-ip list. 2. Investigation and experiment on Internet congestion control continues. An analysis of the NSFNET Backbone logs showed the new selective-preemption and timeout policies installed in June are working very well. As the result of this experience, a suite of congestion-control fairness policies was developed and implemented in the fuzzball operating system used in the NSFNET Backbone network and elsewhere. The policies, described in memos distributed to the INENG Task Force, are designed to promote equal access to buffer resources and equalize delay dispersions on the output queues. The current fuzzball implementation attempts to adjust the generation rates of individual hosts using the ICMP Source Quench message in a novel way to achieve this goal. Westine [Page 8]  Internet Monthly Report September 1987 3. The TCP implementation used in the NSFNET Backbone and elsewhere was adapted to use the new ICMP Source Quench message described above. The flow-control mechanism was rebuilt using a unified approach for retransmission, source quench, Van Jacobsen's "slow start" and John Nagle's famous algorithm. 4. The new fuzzware features were throughly tested and the results distributed to the NSFNET and INENG engineering groups. The most dramatic tests took place during the NSFNET disruption mentioned above, when massive traffic spasms occured at the MACOMNET and UMDNET fuzzballs, which serve as backups for the main NSFNET gateway. It was clear from these tests that the new ICMP Source Quench message can be effective in controlling medium-term traffic surges lasting some ten or more times the mean roundtrip delay. 5. As the result of observing the various fuzzballs and fuzzball networks scattered over the globe, the statistics collection and event monitoring systems were overhauled. A giant new fuzzware version incorporting these and the other features mentioned above is now in distribution to all known fuzzball swamps in the US, Hawaii, Norway, Germany and Italy. 6. Development continues on the Dissimilar Gateway Protocol (DGP). Woody Woodburn and Sean Brady of Linkabit have a pre- prototype simulation program running on a three Sunstation testbed. 7. Mike Minnich completed an investigation of the performance of the BBN LSI-11 core-gateway system over the last two years and found some highly interesting things, one of which is that the mean length of end-end paths is almost three core-gateway hops. Since most of these gateways are huddled on ARPANET and MILNET, this suggests either a growing level of LAN-LAN traffic via the overloaded ARPANET/MILNET gateways, increasing impact of the infamous EGP extra-hop problem or both. Unfortunately, I toss my hat in the latter ring. Dave Mills (Mills@UDEL.EDU) NSF NETWORKING -------------- UCAR/BBN LABS NSF NETWORK SERVICE CENTER (NNSC) The NNSC has been maintaining an on-line calendar of events of interest to the Internet community for several months. We want to encourage people to use the service and to contact us about meetings and conferences that we should Westine [Page 9]  Internet Monthly Report September 1987 include. Calendar entries are available by anonymous FTP from sh.cs.net (calendar/ where is the three letter abbreviation for the month) or by sending a mail message to the CSNET Info-Server (info@sh.cs.net) For information on how to use the Info Server, send a message to with the following text in the body of your message: Request: calendar Topic: help Bill Curtis and Stan Ruttenberg from UCAR and Karen Roubicek represented the NNSC at the meeting of the Federation of Regional Networks in Rochester. On October 30 at 5:00 pm EST, the NNSC hotline number will change to (617)873-3400. Because BBN Labs is changing its phone exchange from 497 to 873, the first three digits of the numbers for the NNSC staff will also become 873. By Karen Roubicek (roubicek@nnsc.nsf.net) NSFNET BACKBONE SITES CORNELL UNIVERSITY THEORY CENTER September's statistics are not yet available. Due to cable swaps, the mapping between circuits and interfaces changed at least once during the month, so the data needs cleaning up. The new release of gatedaemon software has been picked up by over 100 sites since its availability was announced last week. By Scott Brim (swb@tcgould.tn.cornell.edu) UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN Midnets lines are installed and connected to a P4200 at Illinois. The lines are usable and we are currently waiting for approval of our gated configuration to begin announcing them to NSFNET. Expect this to happen within the by 15 Oct. Rerouting of the NCAR-UIUC link directly to Urbana (bypassing an outrageously noisy T1-broadband cable hop from Chicago) has been ordered and a delivery date of the line is 15 Oct. A P4200 connection to the newly forming Minnesota State Network has Westine [Page 10]  Internet Monthly Report September 1987 been ordered with a completion date in October is also underway. Thomas Jacobson (thomas@umn-rei-uc.arpa) is the contact for MN network. We are in the middle of the test window for our ARPAnet connection to Madison. Delivery date according to the TSR is 19 Oct. We are waiting for the 24 hour in advance warning call from BBN. By Ed Krol (krol@uxc.cso.uiuc.edu) JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER This report is designed to inform the JVNC Consortium and JVNCNET network members as well as the Internet community of monthly status of the JVNCNET network. The data used on this report is collected using a number of techniques developed at JVNC, together with data from the JVNC operations group. The NSFNET data is obtained from the NSFNET NOC (Network Operations Center). NETWORK BRIEF: JVNCNET has the configuration of a "tree". The 13 Consortium Universities*, together with the 3 NRAC** schools form the 16 node network. The gateways are 15 VAX's and 6 Ungermann Bass (UB) routers, connected by 9 T1 lines, 5 56kbps lines and 2 satellite links. Locally at JVNC (center of the JVNCNET network), JVNCA (a VAX8600 running ULTRIX) serves as major router, primary name server for domain "csc.org" and primary network monitoring system, JVNCB (a VAX750, ULTRIX)is also a gateway, finally we utilize a dedicated UB router to connect to the NRAC group. NETWORK STATISTICS DATA: The network monitoring statistics are performed from "jvnca", and are affected by its down time. In order to compensate for this we multiply (in our analysis below), the numbers with the percentage of down time of jvnca thus representing the worst case. We plan to overcome this situation with the next release of the JVNC monitoring package (see "Network Monitoring Project" below). The network is polled every 10 minutes with "icmp-echo" packets, and the analysis of the data is performed on this data. The data is processed using information on the "scheduled down time table" for the systems. Therefore, if a gateway is scheduled to be down, its information is not computed during that time, whether the gateway is operational or not. The special configuration of this network together with the fact that we use different subnets for the point to point links allows Westine [Page 11]  Internet Monthly Report September 1987 us to determine very accurately the reachability for the gateways. When we receive an alarm that one node/gateway is unreachable, we proceed to determine whether the node is down or any other component of the the link is non functional. This information is not affected much by the routing. TABLE I, Gateways Reachability/Link Status -------------------------------------------------------------------------- date of report: September 30th. nde meanttr maxttr meantbf sched %Up %Dwn avail perf ias 900 1202 583306 0 99 0 99 99 mit 3399 8999 773742 0 99 0 99 99 nyu 1800 4200 777142 0 99 0 99 99 njit 51406 85779 182276 0 78 21 78 83 brown 3599 9599 580607 0 99 0 99 99 jvncb 601 601 2321825 0 99 0 99 99 jvncc 2747 7801 119485 0 97 2 97 98 jvncd 3719 11399 151108 0 96 2 97 98 jvncf 1049 1800 282510 2 96 0 99 99 umdnj 37789 85779 141966 0 78 21 78 84 arizona 3599 12000 580606 0 99 0 99 99 harvard 8397 34200 147390 0 94 5 94 96 rutgers 749 600 583456 0 99 0 99 99 stevens 48425 85779 107362 0 68 31 68 77 colorado 29435 85777 137480 0 82 17 82 81 columbia 27345 85777 66127 0 70 29 70 78 princeton 599 599 2336227 0 99 0 99 99 rochester 4365 22789 125291 0 96 3 96 97 u-of-penn 599 599 2336227 0 99 0 99 99 penn_state 1950 6000 582256 0 99 0 99 99 Total test time (min): 38947 -------------------------------------------------------------------------- The Header definitions of table I are: Nde: the gateway or host on JVNC-NET network (128.121) Meanttr:in seconds, the mean time to recover from the "down" state to the "up" state. Where "down" state is when the result of sending "icmp-echo" packets is no packets return, and the "up" state is when we receive packets back. Each test is performed 10 times, every 10 minutes, and averaged each time. Maxttr: in seconds, the maximum time to recover, from the "down" state to the "up" state (see above). Meantbf:in seconds, the mean time between failures. %Up: percentage up time considering the scheduled down time as up time. Westine [Page 12]  Internet Monthly Report September 1987 %Down: complement of "%Up" but truncating. Sched: in percent, is the time the gateways/hosts were "scheduled" to be down, respect to the total time of test. This number is truncated. Avail: in percent, is the time for which the gateways were available ("up" state) respect to the total time of test (minus the scheduled down time). Perform:in percent, is the figure of merit that considers the number of packets lost and the available time. JVNCA was up 97.84% of the time giving a worst case average for all gateways of 90.46% of uptime. ANALYSIS: The data of Table I is a product of the gateways availability together with lines/satellite status (this last including the communications equipment such as T1 muxes, CSU/DSU, etc). The following is broken down in gateways and links (lines and satellite). 1.- Gateways Availability: --------------------- Table II, Gateways Availability --------------------------------------------------------------- gateway node problems --------------------------------------------------------------- jvnca JVNC power supply, power failure jvncb JVNC power failure jvnc-njit JVNC power failure rochway ROCHESTER hardware njit-jvnc NJIT power supply super-fs RUTGERS sofware hanged iasvax IAS power failure hucsc HARVARD machine crashed egress NYU machine crashed pusuper PRINCETON software hanged colo COLORADO bad memory board stevens-njit STEVENS power failure --------------------------------------------------------------- Westine [Page 13]  Internet Monthly Report September 1987 2.- Lines Status: ------------ Table III, Line Status --------------------------------------------------------------- from to type problem --------------------------------------------------------------- NJIT STEVENS 56Kbps good in only one direction NJIT JVNC 56Kbps bad connector JVNC RUTGERS T1 preventive maintanence, bad board on T1 mux. JVNC COLUMBIA 56Kbps flaky line JVNC MIT T1 cut of major trunk of AT&T JVNC NJIT 56Kbps cut of major trunk of AT&T JVNC ROCHESTER 56Kbps cut of major trunk of AT&T MIT HARVARD T1 no sync, New England Bell --------------------------------------------------------------- 3.- Satellite Nodes Status: ---------------------- Table IV, Satellite nodes Status -------------------------------------------------------------- from to type problem -------------------------------------------------------------- JVNC COLORADO satellite storm JVNC ARIZONA satellite storm JVNC COLORADO satellite TransLAN -------------------------------------------------------------- 4.- Traffic: The traffic that transits JVNCNET is a combination of JVNC supercomputer traffic and traffic "in transit". The JVNC supercomputer traffic is the one that has the JVNC front ends (jvncc, jvncd or jvncf) as source/ destination, while the traffic in transit is the rest. The total traffic is: T = traffic on subnet 50 (T1) + traffic on subnet 51 (T2) + + traffic between the MIT node and the Harvard node (T3) * + + traffic between the MIT node and the Brown node (T4) * + + traffic between the NJIT node and the Stevens node (T5)* + + traffic between the NJIT node and the UMDNJ node (T6) * where: T1 = (jvnca + jvncb + jvncc + jvnc-njit + colo + jvax + fuzzball + + term-serv)|subnet 50 T2 = (jvnca + jvncd + jvncf + picasso + monet + iris + term-serv1 + + term-serv2 + term-serv3)|subnet 51 Westine [Page 14]  Internet Monthly Report September 1987 T3 = |coventry|subnet_3 - coventry|subnet_9| T4 = |coventry|subnet_3 - coventry|subnet_10| T5 = |njit-jvnc - njit-stevens| T6 = |njit-jvnc - njit-umdnj| * traffic not seen on subnet 50 number of packets on subnet 50 (one direction, T1) > 140,270,472 =========== NSFNET/total on JVNCNET =~ 25% ==== JVNC Supercomputer traffic / total on JVNCNET =~ 20% ===== where supercomputer traffic is the one on subnet 51 (ethernet) plus the traffic in jvncc. The data is collected from jvnca, jvncb and JVNC_fuzzball every 10 minutes automatically and compiled each month. No data from the jvnc-njit router and Colo is available this month. Table V, Traffic on JVNCNET (subnet 50 only) -------------------------------------------------------------------------- local gateway packets in packets out comments -------------------------------------------------------------------------- jvnca (subnet 50) 59,171,739 46,133,254 accurate jvnca (subnet 51) 16,208,591 14,086,199 accurate jvncb (subnet 50) 39,930,174 33,440,167 accurate jvncc (subnet 50) 14,119,720 12,061,632 accurate jvncd (subnet 51) 5,277,717 3,331,256 accurate jvncf (subnet 51) not available jvnc-njit (subnet 50) not available colo (subnet 50) not available jvax (subnet 50) 2,308,400 1,560,145 not complete (low est.) jvnc.nsf.net 24,740,439 35,289,789 fuzzball, includes icmp ------------------------------------------------------------------------- 5.- PSN Status: Again we have been delayed in our connection, which was scheduled for the week of the 27th of September. No further notice of when we will be connected. Westine [Page 15]  Internet Monthly Report September 1987 6.- Routing: UB routers: new version of the software has been running for a month now, there is a problem with the size of the updates, it will be corrected with the new release (late next week). VAXs: new version of gated has been installed on jvnca and jvncb, it seems to be working fine, and it has corrected the kill -2 problem of the last release. 7.- JVNCNET main ethernet traffic analysis: The overall traffic is high but within the capacity of the ethernet. The broadcast traffic is less than 5% of the total traffic, and the multicast traffic is negligable respect to the total traffic. The number of CRC errors is small respect to the overall traffic and so is the number of alignment errors. The distribution of traffic reflects that a significant amount of the traffic is whithin 1-81 bytes/packets (53%), another significant segment is between 82-145 bytes/packet (36%), well whithin the maximum buffer size of all interfaces of the JVNCNET network. 8.- Comments: It is interesting to note that only 20% of the total traffic that arrives to our center goes to our supercomputer front ends, the rest (80%) is in transit. Also note that the traffic has increased from the previous month for at least 14%. The network monitoring program helped us to detect a problem with the T1 mux on the line to Rutgers. Down time was scheduled for preventive maintanence on that line and after running a BERT test we found the problem to be on one card of the mux. PROJECTS: 1.- Network Monitoring: Status: On going The "netsc" monitoring package is up and running in JVNCNET and in one network member of JVNCNET in beta test. The next step is to provide backup monitoring capabilities to netsc so we can keep the network monitored even when our primary monitoring server is down. Westine [Page 16]  Internet Monthly Report September 1987 2.- Network Characterization: Status: On going The Network Characterization program is directed towards determining the parameters that characterize the JVNCNET network's diverse type of services. This effort will be utilized not only as a research subject but to find/predict network bottlenecks and problems before they are obvious to the end users. This task started two weeks ago with the collection of data and the automation of the collection, and will continue with the study of the characteristics and patterns that distinguish each point to point lines whether T1, 56kpbs or satellite. The results will be available to the community. 3.- Traffic Analysis: Status: On going The traffic data is currently being collected from JVNCA, JVNCB, and the fuzzball automatically. This will be extended to the other VAXs on the same ethernet and the other routers on the network. At the same time the data will be compiled per campus. INFORMATION: JVNCNET NOC: "net@jvnca.csc.org" (JVNCNET Network Operations Center) JVNCNET manager: "heker@jvnca.csc.org" * CSC Consortium: Princeton University, MIT, Harvard, Brown, University of Pennsylvania, Rutgers, IAS, Columbia, University of Rochester, NYU, Penn State, University of Arizona, University of Colorado. ** NRAC (Newark Remote Access): New Jersey Institute of Technology (NJIT), Stevens Institute of Technology, University of Medicine and Dentistry of New Jersey (UMDNJ). By Sergio Heker (heker@jvnca.csc.org) NATIONAL CENTER FOR ATMOSPHERIC RESEARCH AND UNIVERSITY SATELLITE NETWORK PROJECT No report received. PITTSBURGH SUPERCOMPUTING CENTER In September our network connections did not behave as well as they had for the past few months. Westine [Page 17]  Internet Monthly Report September 1987 PSC-gateway performed very well until the 25th of the month. The CMU IMP, (PSN #14) which we are connected to, was upgraded to PSN 7.0 software on Thursday, the 24th. Soon afterward we began to experience congestion and connectivity problems to other ARPANET sites. The situation worsened throughout the weekend until the gateway began crashing and we needed to disable its connection to the IMP. On Tuesday, the 29th, the PSN software was returned to version 6.0 and the problems mostly cleared up. We are still observing lack of connectivity to some ARPANET sites. These lingering problems are being investigated. During these few days our T1 connection to SURANET at the University of Maryland performed as a backup. Until the 24th, PSC-gw was putting about 1.25 million packets a day through its interfaces. The PSC Fuzzball again performed well, however we did have to reset it a few times during the month, solving problems we haven't seen much since the spring. The fuzzball has remained as one of the busiest of the NSFNET backbone nodes, pushing about 680,000 total packets daily. On September 17 and 18 the satellite dish that will serve as an interim ARPANET link for our new IMP was installed. We are waiting for the dish electronics to be installed to make it functional. The permanent leased land lines have been ordered. By David O'Leary (oleary@morgul.psc.edu) SAN DIEGO SUPERCOMPUTER CENTER Our PSN was not inconvenienced by the change to the 7.0 software. This was most likely due to its still awaiting paths to the outside world. The VSAT link has been cancelled as the equipment was needed elsewhere by DCA. The PSN's 4 trunk links are now all scheduled to be terrestrial and are coming "real soon now". Proteon has installed an old FCO in our p4200. That plus 7.3b software has caused a tremendous improvement in its reliablity. The 56k link to the p4200 at UC Berkeley is operational and carrying traffic to UCB and other schools on BARRNET. None of these are being advertised to NSFNET (we are advertising UCSD, UCSB and Salk Inst.). By Paul Love (loveep@sds.sdsc.edu) NSFNET REGIONAL AFFILIATED & CONSORTIUM NETWORKS BARRNET BARRNET continues to operate on a routine basis with only minor unscheduled service interruptions. Nearly all interruptions are Westine [Page 18]  Internet Monthly Report September 1987 the result of problems with T1 communications circuits - both leased line and private microwave - although two failures occurred in our Verilink CSU equipment this month. A class of communications circuit problems has been identified that is particularly troublesome: a T1 circuit will experience a high error rate but the problem will correct itself before telephone company personnel can respond to a service call. When the service technicians do finally respond, the T1 circuit must be taken out of service for testing. This leads to additional service outage and all too often the results of the test procedures are "no problem found". Thus the particular troubled site is left with an "unexplained" service outage, a circuit that tests out clean, and no way of recovering charges associated with lost circuit service because the common carrier can't confirm there has been any problems with its service. A mechanism needs to be found which can document T1 circuit problems, which the common carrier will acknowledge as a valid test, which can be used as a basis for measuring the performance of a T1 circuit, and which can be used as the basis for recovering circuit costs from the common carrier. It is highly desirable to be able to monitor errors on a T1 circuit without removing the circuit from service. The Proteon high speed serial I/O boards should be capable of this function, but at present do not address this issue adequately. An alternative is Extended Super Frame (ESF) CSU's, but few common carrier circuits support this functionality at the present time. The problem remains unsolved. BARRNET enabled a new connection to the San Diego Supercomputer Center (SDSC) this month, based on a 56Kb terrestrial microwave circuit and Proteon p4200 gateway. At present routing information for this connection is static and entered manually, with connectivity only between BARRNET and SDSC. A technical subcommittee is planning to meet in the near future to discuss the implications to our RIP routing configuration of enabling access to the NSFNET backbone through this same 56Kb link. Results of a one day "accidental" experiment involving NSFNET access through the link met with mixed success because of multiple routes to other networks polluting BARRNET and its member campuses. Preliminary evaluation of the specifications for release 7.4 of the Proteon gateway software lead us to believe that 7.4 will adequately address many of the most important routing issues in our regional network. In particular, it will allow us to selectively accept those routes we know to come from "trusted" sources and exclude other routes. We are anxiously awaiting the release of this new software. A area that is also of concern to BARRNET that is not addressed by the new routing software, however, is the issue of fallback routing capability. In particular, we have had several occasions where communications circuits degrade enough to be unusable for our users, but not bad enough for RIP to drop the route. Another thing Westine [Page 19]  Internet Monthly Report September 1987 that we've found is that often a T1 circuit will fail in one direction only. If it's bad enough for RIP to drop the route, it will drop it in the wrong direction. An implicit assumption with RIP is that the reception of e.g. southbound RIP packets is a useful measure of whether the line is usable for northbound traffic. This assumption is good for Ethernets and bad for T1 circuits. A general meeting among the BARRNET consortium membership was held this month to begin discussions about turning BARRNET into a self supporting network. Issues that were discussed include i) central versus distributed network management, ii) policy for new connections with other sites, iii) a mechanism to fund continued operation of the T1 circuits comprising BARRNET after the 3 year NSF funding runs out, iv) identification of resources on BARRNET connected campuses that can be used as the focus of experiments on a high bandwidth/low delay network such as that provided by the BARRNET T1 circuits. None of these issues were completely settled and these and others will be topics in our monthly administration meetings. By Thomas E. Ferrin, UCSF (tef@cgl.ucsf.edu) JVNCNET (Refer to JVNNSC backbone report) MERIT (No report received) MIDNET (No report received) NORTHWESTNET (No report received) Westine [Page 20]  Internet Monthly Report September 1987 NYSERNET As of 1 October 1987, NYSERNET had the following topology: Clarkson Syracuse--+ | | | Rochester--------Cornell---------RPI---Albany | | | Buffalo...Fredonia | | | | | Binghamton | +-------- | ------StonyBrook | | | | | | | | CUNY--NYTEL/NSMAC--Columbia======NYU-+ | |\ | | | /| | | | \ NYTEL/GC | NYNEX/S&T / | | | | \ BNL / | | | | \ / | | | | +-------------Rockefeller | | | | | | | +------------------------------+ | | | +-------------POLY-------------------+ ==== T1 \ | / 56kbits .... 9.6kbits The Columbia to NYU link has now been upgraded to T1 with Columbia/Cornell, Cornell/RPI, and RPI/NYU the next links to be upgraded to complete a "ring". A second meeting of the NYSERNET Library Group was held in New York City where recommendations were made to open up local electronic card catalog and other local services to scholars. (An example of this is by telneting to "infotrac.rpi.edu" one gains access to the RPI card catalog system). By Marty Schoffstall (schoff@nic.nyser.net) SDSCNET (Refer to SDSC backbone report) Westine [Page 21]  Internet Monthly Report September 1987 SESQUINET The complete initially proposed SesquiNet configuration has been operational now for two months. The following campus networks are being served, and are advertised via EGP to the core: Baylor College of Medicine 128.249 Houston Area Research Center 192.31.87 Rice University 128.42 Texas A&M University 128.194 Texas Southern University 192.31.101 and the University of Houston 129.7 Although the network is not yet heavily loaded, we have still experienced no gateway failures. We have had some trouble with leased lines. We have now done some analysis of the reliability of the network, based on logs written by our monitoring program. For each of the sites listed below, we note the number of (unscheduled) failures and the percent of availability (percentage of time the site was up, deducting scheduled down time). -------------------------------- Site Failures Available -------------------------------- BCM 0 100.0 % HARC 2 95.5 % RU 0 100.0 % TAMU 3 95.6 % TSU 1 99.5 % UH 0 100.0 % -------------------------------- While some of the problems at TAMU and TSU were due to leased lines, most of the unscheduled downtime was due to machine room power problems. We continue to await the completion of the connection from NSFNET/NCAR to SesquiNet/Rice via fuzzballs at the two sites. By Guy Almes (almes@rice.edu) SURANET (No report received) Westine [Page 22]  Internet Monthly Report September 1987 WESTNET 1. We as yet have not received funds from NSF, although we expect funding imminently. 2. We are in the process of preparing the paperwork to order 5 gateways for the 4 sites in New Mexico and the University of Wyoming, to be implemented as Phase II of Westnet. We are also ordering (funded by the state of Colorado) 5 cisco gateways to replace the DEC uVAX II's which will be used as domain name servers and for bulletin boards, etc. 3. Brigham Young University and the University of Utah have requested to participate in Westnet. Discussions are ensuing regarding the nature of the connection. This should be a cost effective means of service, as a 56 kbps line is already budgeted, and only two local lines need be funded. 4. We are planning a workshop for technical representatives of the Phase II sites, to be held Nov. 9 to 11, 1987, to cover Routing Issues and use of the cisco gateways. The workshop will be held at the University of Colorado. 5. David Wood attended a users group meeting at cisco, and delivered a one hour presentation on Westnet, which was very well received. A lively discussion occurred afterwards, during the general discussion period. It appears that cisco will be very responsive to the needs of users. Incidentally, HP has over 50 cisco gateways interconnecting over 4500 hosts. By Pat Burns (pburns%csugreen.bitnet@WISCVM.WISC.EDU) Westine [Page 23]  Internet Monthly Report September 1987 TASK FORCE REPORTS ------------------ APPLICATIONS -- USER INTERFACE No report received. AUTONOMOUS NETWORKS No progress to report this month. Deborah Estrin (Estrin@OBERON.USC.EDU) END-TO-END SERVICES No progress to report this month. Bob Braden (Braden@ISI.EDU) INTERNET ARCHITECTURE The Internet Architecture Task Force (INARC) studies technical issues in the evolution of the Internet from its present architectural model to new models appropriate for very large, very fast internets of the future. It is organized as a recurring workshop where researchers, designers and implementors can discuss novel ideas and experiences without limitation to the architecture and engineering of the present Internet. The output of this effort represents advance planning for a next-generation internet, as well as fresh insights into the problems of the current one. The INARC is planning a two-day retreat/workshop for 17-18 November at BBN to discuss a fresh start on advanced internet concepts and issues. The agenda for this meeting will be to explore architecture and engineering issues in the design of a next-generation internet system. The format will consist of invited presentations on selected topics followed by a general discussion on related issues. Written contributions of suitable format and content will be submitted for publication in the ACM Computer Communication Review. In order to have the most stimulating discussion possible, the INARC is expanding the list of invitees to include those researchers with agenda to plow, axe to grind, sword to wield or any other useful instrument for that matter. Contributors are invited to submit concise summaries of presentations of Westine [Page 24]  Internet Monthly Report September 1987 from fifteen to forty minutes in electronic form to mills@udel.edu or in hardcopy form to Dr. David L. Mills Electrical Engineering Department University of Delaware Newark, DE 19716 (302) 451-8247 Up to forty participants will be selected on the basis of quality, relevance and interest. Following is a list of possible areas and issues of interest to the community. Readers are invited to submit additions, deletions and amendments. 1. How should the next-generation internet be structured, as a network of internets, an internet of internets or both or neither? Do we need a hierarchy of internets? Can/must the present Internet become a component of this hierarchy? 2. What routing paradigms will be appropriate for the new internet? Will the use of thinly populated routing agents be preferred over pervasive routing data distribution? Can innovative object-oriented source routing mechanisms help in reducing the impact of huge, rapidly changing data bases? 3. Can we get a handle on the issues involved in policy- based routing? Can a set of standard route restrictions (socioecononic, technopolitic or bogonmetric) be developed at reasonable cost that fit an acceptable administrational framework (with help from the Autonomous Networks Task Force)? How can we rationalize these issues with network control and access-control issues? 4. How do we handle the expected profusion of routing data? Should it be hierarchical or flat? Should it be partitioned on the basis of use, service or administrative organization? Can it be made very dynamic, at least for some fraction of clients, to support mobile hosts? Can it be made very robust in the face of hackers, earthquakes and martians? 5. Should we make a new effort to erase intrinsic route- binding in the existing addressing mechanism of the Internet IP address and ISO NSAP address? Can we evolve extrinsic binding mechanisms that are fast enough, cheap enough and large enough to be useful on an internet basis? 6. Must constraints on the size and speed of the next- generation internet be imposed? What assumptions scale on Westine [Page 25]  Internet Monthly Report September 1987 the delay, bandwidth and cost of the network components (networks and gateways) and what assumptions do not? 7. What kind of techniques will be necessary to accellerate reliable transport service from present speeds in the low megabit range to speeds in the FDDI range (low hundreds of megabits)? Can present checksum, window and backward- correction (ARQ) schemes be evolved for this service, or should we shift emphasis to forward-correction (FEC) and streaming schemes. 8. What will the internet switch architecture be like? Where will the performance bottlenecks likely be? What constraints on physical, link and network-layer protocols will be advisable in order to support the fastest speeds? Is it possible to build a range of switches running from low-cost, low-performance to high-cost, high-performance? 9. What form should a comprehensive congestion-control mechanism take? Should it be based on explicit or implicit resource binding? Should it be global in scope? Should it operate on flows, volumes or some other traffic characteristic? 10. Do we understand the technical issues involved with service-oriented routing, such as schedule-to-deadline, multiple access/multiple destination, delay/throughput reservation and resource binding? How can these issues be coupled with effective congestion-control mechanisms? 11. What will be the relative importance of delay-based versus flow-based service specifications to the client population? How will this affect the architecture and design? Can the design be made flexible enough to provide a range of services at acceptable cost? If so, can the internet operation setpoint be varied, automatically or manually, to adapt to different regimes quickly and with acceptable thrashing? 12. What should the next-generation internet header look like? Should it have a variable-length format or fixed- length format? How should options, fragmentation and lifetime be structured? Should source routing or encapsulation be an intrinsic or derived feature of the architecture? Westine [Page 26]  Internet Monthly Report September 1987 13. What advice can we give to other task forces on the impact of the next-generation internet in their areas of study? What research agenda, if any, should we propose to the various NSF, DARPA and other agencies? What advice can we give these agencies on the importance, level of effort and probablity of success of the agenda to their current missions? Dave Mills (Mills@HUEY.UDEL.EDU) INTERNET ENGINEERING No report received. PRIVACY No reportable Privacy Task Force activity took place in September. John Linn (Linn@CCY.BBN.COM) ROBUSTNESS AND SURVIVABILITY No report received. SCIENTIFIC COMPUTING No report received. SECURITY No report received. TACTICAL INTERNET No report received. TESTING AND EVALUATION No report received. Westine [Page 27]