LVARIAN@PUCC.BITNET (Lee C. Varian) (02/06/90)
Dear BITNET/CREN colleague,
The enclosed proposal for a restructuring of the BITNET network was
presented to the CREN Technical Committee in early December, 1989. At
the most recent CREN Board meeting, the Committee recommended that the
proposal be more widely circulated within the BITNET/CREN community.
This mailing is an attempt to comply with that recommendation which was
accepted by the Board.
As you probably already know, several of us at Princeton have been
working on the VMNET programs which allow RSCS NJE traffic to use IP
networks. One of the motivations for this work was to have BITNET
connections over IP networks. Once the technical aspects of RSCS NJE
over IP were resolved, the questions of how to best use, deploy, and
manage this new type of BITNET connection were raised.
In an attempt to address some of these questions, we are submitting
for discussion a proposal which would reorganize the structure of the
BITNET network. A number of core sites are proposed which would play
key roles in the restructured BITNET network.
It is important to point out that this recommendation does not itself
propose the creation of new IP network connectivity, but rather suggests
how BITNET NJE traffic might be organized to utilize existing IP
connectivity. The proposal is compatible with and could utilize
any further growth of the NSFNET and regional IP networks, as well as
any CREN IP network.
We hope you will carefully consider the proposal and provide your input
on its possible implementation.
A file of the discussions which have taken place thus far on this
proposal may be gotten from the LISTSERV at PUCC. To get a copy of
the file:
TELL LISTSERV AT PUCC GET BIT2PLAN COMMENTS
Or, send mail to LISTSERV@PUCC on Bitnet with the body / text of the
mail containing the command:
GET BIT2PLAN COMMENTS
Lee Varian (LVARIAN@PUCC)
Peter Olenick (Q0239@PUCC)
Michael Gettes (GETTES@PUCC)
* * * * * *
Proposal to Restructure the Network Supporting BITNET
Historically the physical and logical networks supporting
BITNET have been structured on leased communications lines
connecting member sites. New sites connect to the network
based upon an existing BITNET member's willingness and
ability to support the request for connection. The cost of
the leased communications line, which is paid for by the new
BITNET site, is also a consideration in choosing which
existing BITNET sites are possible connection points. The
cost of the communications line may be different based on
factors of distance and tariff considerations. This method
of connecting new sites has worked quite well, but the lack
of a formal structure for the network is creating
limitations which impair the efficiency and growth of
BITNET. The lack of a structure increases the complexity of
routing table generation and hampers efforts to implement
network management tools. The ability to create BITNET
links by using the national and regional IP networks
increases the confusion over where BITNET connections should
be made.
The idea of reorganizing BITNET into a more formal structure
has been discussed for a number of years, but the costs of
the additional leased lines needed to implement such a plan
made the project economically infeasible. Now, BITNET has
the ability to use the national and regional IP networks; a
plan to restructure BITNET by using the IP networks appears
to be cost effective and implementable. This plan could
also be implemented using private communications facilities
and IP routers instead of using the national and regional
networks. The costs of an implementation using a private
IP network would need to be carefully considered.
Restructuring Proposal
The restructuring is based on the concept of
'regionalization', the separation of the network into
geographic areas or regions. Each region would have two
'core' sites. Each core site would have RSCS-over-IP
connections to every other core site. The core sites would
form a 'backbone'. The national and regional IP networks
are the physical facilities that would be used by the core
sites to form the BITNET backbone. By generating
appropriate BITNET routing tables, the number of nodes and
the amount of traffic handled by the core sites for a given
region can be statically balanced. Within a region, the
core sites could connect to a number of 'mid-level' sites,
again by use of RSCS-over-IP. This type of structure has
the ability to provide an alternate path into a region if a
core site were out of service. The member sites or 'end'
sites within a region could connect to the mid-level sites.
Traditional leased line connections may exist at any level
within the structure but these types of connections will
continue to have limitations. That is, if a host with
traditional leased lines is down, no other path may exist to
the sites supported by that leased line.
The following diagram attempts to present graphically the
structure of the regional model.
Diagram for Regional Model
(Example of a single Region)
+--------+
| end |
| site |
+---||---+
RSCS/IP
RSCS/IP +---------+ +---||---+
========== core | +---------+ BSC | end |
| site | | mid- ----------- site |
RSCS/IP | | RSCS/IP | level | +--------+
========== =========== site |
| | | | RSCS/IP +--------+
RSCS/IP | | | =========== end |
========== | +---||----+ | site |
+---||----+ || +--------+
|| ||
RSCS/IP RSCS/IP
|| ||
RSCS/IP +---||----+ || +--------+
========== core | +---||----+ BSC | end |
| site | | mid- ----------- site |
RSCS/IP | | RSCS/IP | level | +--------+
========== =========== site |
| | | | RSCS/IP +--------+
RSCS/IP | | | =========== end |
========== | +---||----+ | site |
+----|----+ RSCS/IP +--------+
| ||
| +---||---+ +--------+
| | end | BSC | end |
| | site ------------ site |
| +--------+ +--------+
|
| +--------+
| BSC | end |
|----------------------------------- site |
+--------+
In the diagram, the end site shown as a single node can be a
collection of nodes connected by a mixture of leased lines
and IP.
Benefits of the restructuring
The purpose of the regionalization is to impose a structure
on the logical network supporting BITNET. This structure
will reduce the burden on the current hub sites by
decreasing the number of files which must transit these
sites. Overall network service will be improved because the
number of 'hops' a file must take to reach its destination
will be reduced or be no greater than in the current BITNET
topology. The impact on BITNET when a key BITNET node or
Internet connectivity fails will be reduced because of the
increased number of connections between core sites. As the
intra-regional mid-level structure develops, the ability of
the core sites to dynamically reroute traffic around a
disabled core node will provide improved network access.
The three level (core, mid-level, end site) structure of the
region can be expanded to include additional levels and
paths as needed within the region, thereby providing for
dynamic rerouting within a region as well.
Implementation Plan
The current BITNET network would be divided into seven
regions. Each region would have the required two core
sites. No attempt has been made to define the mid-level
sites within the regions. The mid-level structure will
develop at different rates within the different regions.
The rate will depend on many factors including the level of
IP connectivity, amount of BITNET traffic generated, and
amount of network expertise available. The regions and core
sites can be implemented without having the mid-level
structure defined. The proposed region and associated core
sites are as follows:
Region 1 - NorthEast
BUACCA: Boston University
YALEVM: Yale University
Region 2 - MidEast
CORNELLC: Cornell University
CUNYVMV2: City University of New York
Region 3 - MidAtlantic
PUCC: Princeton University
PSUVM: Penn State University
Region 4 - SouthEast
UMDD: University of Maryland
VTVM2: Virginia Polytechnic Institute and University
Region 5 - MidWest
UICVM: University of Illinois at Chicago
UKCCB: University of Kentucky
Region 6 - MidSouth
RICEVM1: Rice University
UIUCVMD: University of Illinois at Urbana-Champaign
Region 7 - West
UCBCMSA: University of California at Berkeley
USCVM: University of Southern California
Core Site Guidelines
For a machine to be considered for use as a core site it
should meet the following requirements:
1. The machine must run VM with FAL, VMNET, and RSCS
Version 2.
2. The system must have the capacity to support the
number of RSCS-over-IP connections needed for
connectivity to other core sites. This capacity should
take into account IP connectivity capacity, processor
capacity, spool capacity and manpower requirements.
3. Core sites may need to add additional software
facilities and modifications to improve throughput and
overall network management. An example of these might be
installation of the BITNET II transmission algorithm to
improve throughput of RSCS over IP.
4. One if not both core sites in a region should run a
LISTSERV which is part of the LISTSERV backbone. Because
LISTSERV files are a large component of BITNET traffic,
having the core sites on the LISTSERV backbone will
enhance the operation of this pervasive application.
5. Core sites are encouraged to consider running NETSERV
and acting as INTERBIT sites. Running these facilities
will reduce network load and provide greater service to
the region.
6. With BITNET making use of the national and regional
IP networks, the core sites will need to establish
procedures for dealing with their IP service and its
supplier. These procedures should include out-of-hours
procedures, local operating procedures, and problem
determination procedures.
These same general guidelines can be scaled appropriately
and applied to the mid-level sites. All the suggested core
sites meet the guidelines with minor exceptions. All of the
core sites chosen are VM machines in the 308x class or
larger. All core sites chosen run FAL or WISCNET, with all
but one of the WISCNET sites planning conversion to FAL in
the near future. All of the core sites expect to run RSCS
Version 2 as soon as feasible. All core sites chosen are
accessible via the regional and national IP networks.
Clearly the BITNET core sites will assume a leadership role
in their regions. Expertise in RSCS, FAL, and TCP/IP, as
well as operating systems will be of value to the core site
in problem solving. This expertise will also be useful in
guiding the development of networking within the core site's
BITNET region.
One of the goals of this plan is to minimize the disruption
to the functioning of BITNET. Current leased line
connections would not be required to be altered. All
current BITNET sites would be assigned to one of the
regions. This is true for the international connections as
well. The international links would be associated with the
region of the host system. New RSCS-over-IP connections
would be made only within a region; inter-regional traffic
flow would be via the BITNET backbone.
Some of the current leased line connections would no longer
be used. For example, George Washington University (GWUVM)
has leased line connections to Penn State (PSUVM) and
University of Maryland (UMDD). Under this regionalization
plan, GWUVM is part of Region 4 and its outbound traffic
would flow toward the core site at UMDD. GWUVM's connection
to PSUVM would be unused. Another example of a change in
the current BITNET topology would be the RSCS-over-IP link
between Princeton (PUNFSV2) and Columbia University (CUVMB).
This link would be discontinued because it would be inter-
regional. CUVMB would be part of Region 2 and PUNFSV2 would
be part of Region 3.
Connection of Cooperating Networks
Cooperating networks, such as EARN and NetNorth, may be
connected to BITNET in different ways under this proposal.
A cooperating network might be connected to BITNET using a
traditional point-to-point connection to one BITNET site and
appearing as an extension of the region that the cooperating
network physically connects to. An example of this type of
connection would be the cooperating network EARN appearing
as an extension of Region 2 because of FRMOP22's physical
connection to CUNYVMV2.
Alternatively, a cooperating network might connect by having
multiple RSCS-over-IP connections to BITNET core sites.
This could be accomplished in three ways:
A designated cooperating network site could have multiple
connections to different core sites. An example of this
might be UTORVM of NetNorth being the designated NetNorth
site and having connections to CORNELLC in Region 1,
RICEVM1 in Region 6, and UCBCMSA in Region 7.
The second way of accomplishing the connection of a
cooperating network is to have multiple sites in the
cooperating network connected to multiple core sites. An
example of this method of connection might be to have
UTORVM of NetNorth connected to CORNELLC in Region 2,
MCGILLB of NetNorth connected to RICEVM1 in Region 6, and
UALTAVM of NetNorth connected to UCBCMSA in Region 7.
This second method of connection should provide greater
bandwidth and multiple access between BITNET and the
cooperating network. RSCS-over-IP connections between
cooperating network sites and non-core site BITNET
members would not be permitted.
The third way a cooperating network might connect to
BITNET would be as a new region or regions. An example
of this might be that NetNorth would designate UTORVM and
UALTAVM as BITNET core sites. NetNorth would form
Region 8 and all BITNET connections from NetNorth would
be via these core sites.
The connection of a cooperating network to BITNET should be
handled on a network-by-network basis because each
cooperating network has different requirements and
resources. Which implementation is chosen will depend on
the structure, traffic flow, and policies of the cooperating
network.
Conclusion
If this proposal is adopted and the implementation plan
accepted, the restructing of BITNET's network can be
complete in a short period of time, estimated at three
months. Every attempt would be made to keep the disruption
of BITNET services to an absolute minimum during the
restructuring. The restructed BITNET would provide better
service to all BITNET members and allow for orderly growth.ROTHI_P@PLU.BITNET (Paul Rothi) (02/09/90)
I have two concerns regarding the restructuring of BITNET and its effects
on small end nodes.
1. Typically we have much smaller operating budgets than the larger core
sites or mid-level sites. As a result, we may not have the same level
of expertise with all the subtleties of BITNET networking. As this
restructuring plan progresses, or is finalized, we will need to have clear
instructions telling exactly what to do to remain a functional node with
minimal disruption to our users.
Examples here include where to get routing tables, or how generate them
ourselves, and updates that may be required to our node entries at
the BITNIC.
2. If new connections must be made with regional or mid-level nodes, this
needs to known up front so budget allocations can be made.
3. Also, if any new software will be required to remain functional under
the new topology, that too must be known in advance. Software for large
platforms is not cheap and may have significant impact on a relatively
small budget.
I give my support to the overall concept! The idea of a more formal structure
and fault tollerance is appealing. Please, keep us all informed as this
progresses. Finally, when all is ready for conversion, publish a **single**
detailed list of instructions for sites at all levels to follow to remain
functional as, and after the conversion is done.
--------------------
Paul Rothi Telephone: (206) 535-7525
Pacific Lutheran University BITNET: ROTHI_P@PLU
Computer Center
Tacoma, WA 98444IMHW400@INDYVAX.BITNET (Mark H. Wood) (02/09/90)
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.
No, I don't have the authority to volunteer my site as a core gateway. :-) :-(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mark H. Wood (317)274-0749 III U U PPPP U U III
Indiana University - Purdue University at Indianapolis I U U P P U U I
IMHW400@INDYVAX.IUPUI.EDU I U U PPPP U U I
IMHW400@INDYVAX.BITNET I U U P U U I
[@disclaimer@] III UUU P UUU IIIGETTES@PUCC.BITNET (Michael R. Gettes) (02/09/90)
On Thu, 8 Feb 90 08:06:00 PST Paul Rothi said: >1. Typically we have much smaller operating budgets than the larger core > sites or mid-level sites. As a result, we may not have the same level > of expertise with all the subtleties of BITNET networking. As this > restructuring plan progresses, or is finalized, we will need to have clear > instructions telling exactly what to do to remain a functional node with > minimal disruption to our users. As for the immediate impact of restructuring as proposed, there should be no interruption of service and no impact to end or mid-level sites as the core is established. It was understood in the development of the proposal that the implementation of the core had to take place without noticeable impact. What may change is the paths that are taken to reach other nodes on the network. Creation and removal of connections with the mid-level sites can be handled in a case by case, migratory manner. > Examples here include where to get routing tables, or how generate them > ourselves, and updates that may be required to our node entries at > the BITNIC. Procedures for obtaining routing tables will not change. If a node does not know how to obtain a routing table now, I suggest they contact BITNIC. No node updates will be required to end sites. Some mid-level sites will be affected (like the example of GWUVM), but this can easily be handled in a case by case, migratory manner. The core sites will handle their own updates, most likely with coordination from BITNIC or some other coordinating committee. >2. If new connections must be made with regional or mid-level nodes, this > needs to known up front so budget allocations can be made. All new connections have been determined and outlined by the proposal. All sites proposed in the core already have IP connectivity, so they only need to acquire the VMNET software. Most already have it or have ordered it. /mrg
OWEN@AUDUCVAX.BITNET (Larry Owen) (02/09/90)
Mark Wood writes: >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. As I was reading the proposal, I initially had the same reaction; I think it tends to perpetuate the IBM/VM-centric world view of Bitnet. But, if you allow the validity of the requirement that the core sites also run a LISTSERV, then you're pretty much "stuck" with VM/RSCS machines as the core sites. I have not looked at the choice of core sites in terms of BITNET and NSF/ regional topological maps, but (being in the southeast), the choice of sites for the southeast region appears to have a strong "upper right corner" geographic bias, although intelligent choice of mid-level sites using either VM/FAL/RSCS or VMS/JNET/MULTINET(or WOLLONGONG) combos could place almost everyone "close" to the backbone. Those of us who find themselves currently 10 or 12 hops from CUNYVM have to see this as an improvement; if done right, we could end up with a network where no 2 nodes are more than, say, 8 hops from each other. If nothing else, this reduces the difficulty in following list discussions that seem to arrive in almost perfect reverse order. I don't want to volunteer Auburn as a core site either, but I would be *very* interested in being a mid-level site. Larry Owen Mgr., Network Support Auburn University Bitnet: owen@auducvax Internet: owen@ducvax.auburn.edu
GETTES@PUCC.BITNET (Michael R. Gettes) (02/10/90)
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
schafer@BRAZOS.RICE.EDU (Richard A. Schafer) (02/10/90)
While VAXen running JNET 3.4 and JNET TCP NJE can indeed participate in a VMNET link, the VM VMNET sites with RSCS V2 have a particular major advantage: it is possible to support multiple data streams. As far as I know, and we have a connection to such a JNET site, the JNET support does not include multiple streams. I don't know enough about the Wollongong or TGV versions to say whether they do or not, but I believe that one of the very important pieces of the backbone arrangement will be the ability to support multiple data streams between backbone sites. While I know that the MVS sites can support multiple streams, none of them that I know of support anything like the VMNET code. Another point that needs to be made is the amount of load those backbone sites are going to be committing to carrying; I believe that's why the careful notation was made that each of the suggested sites was a fairly good size IBM machine, not a 4361 or something like that which I sincerely doubt would be able to support the traffic. I have heard doubts expressed in the past about VAXen, but am not qualified to say how valid those are, except to doubt that any serious person would believe that a MicroVax would be acceptable. :-) Richard
SYSBJAV@VM.TCS.TULANE.EDU (John Voigt - Academic Systems Programmer) (02/10/90)
On Fri, 9 Feb 90 11:09:22 EST Michael R. Gettes said: ...... ...... >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 I'm sure Michael MEANT to say "... the decisions on who to RECOMMEND as core sites were based...." I sure would have felt better about this if it had come from the CREN board. Why haven't we heard from them on this. Why is PUCC making recommendations about reorganizing BITNET. Is there some relationship between PUCC and the VMNET developers and the CREN board/BITNET management that we don't know about? Am I the only one uncomfortable with what I've been reading here? I can't even put my finger on WHY I'm uncomfortable, something just doesn't SEEM right. John/
jeff@FERMAT.OTS.UTEXAS.EDU (Jeff Hayward) (02/10/90)
On Fri, 9 Feb 90 11:09:22 EST Michael R. Gettes said: > ... >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 Michael's fine elucidation of the logic behind the core structure struck a nerve, so I thought I'd generate some additional heat. It occurs to me, (and others, I think) that the wrong variables are being optimized here. Why should CREN build and perpetuate a structure that requires massive 3081 support, at large cost, to achieve an average 70k bits per second (750MB/day) throughput? I mean, really, a $4000 cisco router can do about three orders of magnitude better than that, 'cause that's what it's good at. It seems that if per-node connectivity, rather than per-link throughput, were optimized the whole network would be more efficient. Large scale NJE pipes wouldn't be necessary if the TCP-capable folks (that's most of us) could just talk to each other directly. We wouldn't need an NJE "core", or the techno-aristocracy that comes with it. The mainframes could go back to doing whatever it is they're good at, and the rest of us could just get on with business. Right? Don't get me wrong, VMNET is better than nothing, and much appreciated for its benefits. The core proposal should probably proceed (or has it already?), since there's nothing better at hand. I just think someone's made an error in their assessment of the fundamental problem. Well, that's my 2 cents. Just thought it ought to be said. Jeff
rogerwat@WATDCS.UWATERLOO.CA (Roger Watt) (02/12/90)
Maybe I've missed some part of the discussion; maybe there is some crucial technical point I don't understand. So I'll ask my questions and then those in the know can set me straight ... please. Why does there need to be an NJE-over-IP "backbone of core nodes"? Why don't those of us who are NJE-over-IP capable just go ahead and talk NJE-over-IP to each other, trashing the native-NJE links as we no longer need them? Why can't this NJE-over-IP thing evolve to the point where we can move to domain addresses and have a WKS of "NJE" in the DNS?
GETTES@PUCC.BITNET (Michael R. Gettes) (02/12/90)
On Fri, 9 Feb 90 21:56:18 -0600 Jeff Hayward said: >It occurs to me, (and others, I think) that the wrong variables are >being optimized here. Why should CREN build and perpetuate a >structure that requires massive 3081 support, at large cost, to >achieve an average 70k bits per second (750MB/day) throughput? I >mean, really, a $4000 cisco router can do about three orders of >magnitude better than that, 'cause that's what it's good at. My opinion is that this is an obvious goal for the future of the network. However, the smallest entity on our network is a file. Routers do not deal with files, but packets. Personally, I see VMNET as the next step in the evolution of BITNET (whatever that may be). VMNET is quite valuable in solving some very immediate problems of load. So, in the short run, I believe we are exploiting the correct variables for the interim. How long will the interim be is a different problem. /mrg This opinions are my own and do not necessarily reflect the views of my management or CREN.
GETTES@PUCC.BITNET (Michael R. Gettes) (02/13/90)
On Sun, 11 Feb 90 17:22:26 EST Roger Watt said: >Why does there need to be an NJE-over-IP "backbone of core nodes"? Why >don't those of us who are NJE-over-IP capable just go ahead and talk >NJE-over-IP to each other, trashing the native-NJE links as we no longer >need them? Why can't this NJE-over-IP thing evolve to the point where we >can move to domain addresses and have a WKS of "NJE" in the DNS? Because there are certain nodes within the center of the network that are dealing with a huge amount of traffic and devoting large amounts of computing and human resources to keeping the machines viable. Formally establishing a core of nodes will alleviate the burden from a few nodes and distribute the processing requirements. This proposal is not meant to be the solution to all problems of our network for short and long term consideration. I view it as the next step to keep things viable. Will it evolve into a WKS within DNS? I don't know. My personal feeling is that I do not believe so. But, at least now questions like this can be considered. View this as the second step in a long (possibly spiral) staircase for BITNET/CREN. I believe the establishment of a core is essential at this time and the sooner the better. /mrg Disclaimer: The usual...
CONKLIN@BITNIC.BITNET (Jim Conklin) (02/13/90)
>On Fri, 9 Feb 90 11:09:22 EST Michael R. Gettes said: >...... >...... >>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 > >I'm sure Michael MEANT to say "... the decisions on who to RECOMMEND as >core sites were based...." > >I sure would have felt better about this if it had come from the CREN >board. Why haven't we heard from them on this. Why is PUCC making >recommendations about reorganizing BITNET. Is there some relationship >between PUCC and the VMNET developers and the CREN board/BITNET >management that we don't know about? Am I the only one uncomfortable >with what I've been reading here? I can't even put my finger on WHY I'm >uncomfortable, something just doesn't SEEM right. > >John/ The CREN Board reviewed the proposal, and its Technical Committee recommended that a broad discussion was needed in order that it might benefit from the wisdom of the network. Hence the discussion in which you are participating! Jim