Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!aplcen!samsung!brutus.cs.uiuc.edu!psuvax1!psuvm!PUCC!GETTES From: GETTES@PUCC.BITNET (Michael R. Gettes) Newsgroups: bit.listserv.nodmgt-l Subject: Re: BITNET Restructuring Proposal Message-ID: Date: 9 Feb 90 16:09:22 GMT Sender: Node Management Discussion Reply-To: Node Management Discussion Organization: Princeton University, CIT Network Systems Lines: 93 Approved: NETNEWS@PSUVM Gateway In-Reply-To: Message of Thu, 8 Feb 90 11:14:00 EST from On Thu, 8 Feb 90 11:14:00 EST Mark H. Wood said: >May I point out that one of the "Core Site Guidelines" is unnecessarily >restrictive: > >> 1. The machine must run VM with FAL, VMNET, and RSCS Version 2. > >Other hardware/software combinations may be equivalent and should not be >disqualified without examination. For example, VAX/VMS systems running Jnet >V3.4, Jnet TCP NJE, and TGV MultiNet or Wollongong WIN/TCP should be able to >communicate with VMNET hosts: TCP NJE was specifically designed for this >purpose. See Joiner's press release dated 1-Nov-1989. > >I don't wish to contest the published choice of core sites. I *do* wish to >point out that other choices are feasible, and perhaps even desirable, if the >quoted condition is relaxed. Maybe I should explain some of the reasoning behind the selection of the core sites. First, considering the high volume of traffic going through the existing core sites (those that participated in the BITNETII project and to which most have been selected for the proposed core) at this time, large scale machines were needed. We figured we had to find 3081 class machines or higher. For example, PUNFSV2 (Princeton) is handling on average 85,000 files per day at about 750 million bytes of data. Figures from the NSFnet during the summer showed that BITNETII traffic accounted for 25% of the NSFnet backbone traffic. We have 2 3081s here and we use about 55% of one 3081 to support just the BITNET traffic that goes through our site. So, horsepower is a significant factor. Also, as an FYI value added fact, our system spool has a limit of 9900 files and we normally have about 7000 files on the system. We are HPO 4.2 VM which means we only have a 3000 file buffer for BITNET traffic that goes through our system. Due to the horsepower and full capability of VMNET, FAL and RSCS 2.3, we are able to work quite well with this small window. Second, all the proposed core sites will be running the same software. This has great benefits for future development of the network. As enhancements are made to the BITNETII methodologies, these can be effectively tested, proved and easily installed in the core. With a mixture of software (and vendors), this task becomes increasingly difficult and I feel detrimental to the network in general. The core of the BITNET network has been historically clogged, we do not wish to see this re-occur as BITNET expands. The listservs are an important consideration as well. At Princeton I see a 15-1 ratio of listserv traffic. This means that for every 1 file that hits listserv, 15 outbound listserv and/or mail files are produced. Since this machine is in the core and has a number of links, fan-out allows for quick distribution from our system. If listserv did not run on either proposed core node within a region then there would be a significant bottleneck effect. Third, the VMNET specification which was made available to various developers of BITNETII appears to be fully met by only VMNET. For greatest benefit and maximum transmission rates it is necessary to support multi-streams in NJE and what is known as "FASTOPEN". As for the recommendation of VMNET/FAL/RSCS V2: VMNET is suggested since it is currently the only software available for VM systems and is the software for which the BITNETII protocols were based and developed. FAL because IBM is doing a terrific job in the development of the FAL code and supporting it. We find it to be a very stable environment. There are other TCP products available for VM but we do not recommend their use with VMNET. RSCS V2 because of performance enhancements to RSCS by IBM (which show that 2.3 runs about 2-3 times faster than 2.1/1.3 as far as cycles). Additionally, 2.3 has the ability for user exits at various points in file and message processing. This allows for easy development of features for RSCS to help it do a better job in transmitting files and reducing network traffic for message load. These modifications are available from LISTSERV@PUCC. A key modification that we have developed for V2 is "Transmission Algorithm F", TAF, which allows for 1 stream in a multi-stream connection to be reserved for "large" files. This allows for large files to not be queued up behind the flurry of smaller files on the network. We feel that we should be pushing large files concurrently with small ones, and the abilities of V2 allow for this. Lastly, it was important to choose nodes that could participate in the core with minimal impact to the network. This meant simply expanding the center of the network. If we used nodes that are currently leaf nodes, then this would have inverted traffic load and most likely flooded sites that were not able or prepared to handle the traffic. It is quite possible that the future may dictate additional regions to be allocated or new core sites to be selected based on a wide variety of criteria from political decisions to BITNET network load to changes in the underlying IP connectivity which makes current core sites no longer viable. This is a proposal, and we recognize that things change... we believe the proposal addresses this issues as well. So, in short, the decisions on who should participate in the core were based on network load, development and compatibility. I hope this clarifies things a little better. /mrg