>From: Rob Reilly > >Hello All, > >I would like to take this opportunity to comment on the "K-12 Connections To >The Internet" paper submitted by Pat Burns and Dave Zachmann to the Consortium >for School Networking Working Group (COSN WG) at the Intenet Engineering >Task Force meeting in San Diego. As you may or may not know our COSN WG >subgroup was given the task of commenting on that paper. I do not know >if the paper itself is available electronically, but I am posting this >commentary here as the folks at the meeting were given copies and several >people FAXed copies back to their organizations. I apologize to those >who have not yet seen that paper. I'm sure that the "horse" will >arrive shortly, but in the meantime here is the "cart". > >I would first like to commend Pat Burns and Dave Zachmann on their work >and on their willingness to share their experiences with us. They have >done an excellent job. > >I believe that we should construct/evaluate hardware configuration >models based on four conjectures: > >1. Servers should be physically located at the school district level (or >there abouts). This will allow local control of the content of their >network feed. This will also obviate the need for current IP sites to >act as hosts. This would releive the existing Internet site of the >responsibility for implement firewalls and otherwise insulating the >school children from certain areas of USENET, the host system, and it >would prevent saturating resources (i.e. dialup lines, disk space, etc). >This would also, hopefully, place the legal responsibility for the >content of the feed on the local schools and not on the "higher level >post-high school and corporate entities". We agree. However, we note that we are blesses with a fantastic network here in the state of Colorado, Colorado SuperNet (directed by Ken Harmon). Ken has installed dial-in circuits and nodes at various locations, and until we get some school districts connected, Ken is providing Unix services to K-12 for the state. This just means that the concept of a Unix hub may be implemented at a granularity other than the school district. Becuase we have this fine situation in Colorado. we are guilty of adopting a parochial viewpoint here... > >2. The pre-college school community will rely upon the COSN WG for models >that can be cost effectively and administrivially dropped into their >district and it's schools. > >Pre-college school teachers are generally not familiar with >telecommunications, and networking - let alone the Internet. Continuuing >direct support and education to the computer person in each school as well >as to the district computer person will be needed for sometime after a >system is "dropped into" a school system. > >Therefore the models for connectivity should be standard and familar to >whatever group is tasked with supporting and educating the school >district's staff and its teachers. The model should be populated by hardware >and software that is used throughout the Internet. The hardware and >software should be usable if the system is upscaled. We concur - standard solutions which are reasonably scalable are absolutely essential. > >3. Few pre-college schools systems are capable of funding the cost of >the hardware and software that is requisite to connect to the Internet. This >suggests that great reliance on corporate partnerships will be seen. This >reliance would make it necessary to have models which do not endorse the >product of one specific company (as much as possible). We agree with the concept of remaining independent from specific vendors (we do not wish to become "captive customers"). We look to corporations to provide: (1) network mentors, and (2) school interns (especially those familiar with Unix and networking). While it is possible to ask corporations to provide funds, we do not believe that this should be done exclusively. For example, in Colorado we are marshalling support from the state Board of Education, the Governor's office, etc. to get funds allocated for network connectivity. Also, there are individual schools and individual school districts which have funds sufficient to cover these expenses of connections (however, this leaves out the geographically and economically disadvantaged, which is troublesome, but we feel as if we need to get on with connecting sites even if the model is skewed at present - we will work to fix it in time). Currently, we are exploring an NSF-like model where we will provide some or all of the network equipment (the "plug" into the Internet) if the schools deploy the network internally, and pick up line costs. > >4. The model(s) should provide for full Internet access and feature USENET >and/or store and forward capability. The level of technology necessary >required to impliment a scalable network should not be sacrificed for a >"here and now" donated system, or for a "piggy back" or "add in" ride on an >existing network which was not intended for our purposes. > We totally agree. Most donated systems are "too expensive" to accept. >Based on _some_ of these conjectures, I would like to offer some comments on >Burns and Zachmann's paper. > >Page 6, "Figure 3 Model 1: Dial-in" shows a well designed model, however, it is >_not_ one that we should recommend. This model even with as few as 4 terminals >does not provide acceptable connecivity. Using an asynchronous switch is not >desirable. The asynch switch creates a "serial race" for the data circuit >with only one winner. The authors have also indicated this on page 2. >I can not envision school situations where this model would be desirable. We agree. There is no "bad" way to connect to the Internet, but we should not recommend this one. > >The modem is designated as v.32bis Asynch. The v.32 bis modems that I have >surveyed and the two that I purchased were all capable of "asynch" and "synch". >I do not understand why the modem in this example is designated as "asynch". >The others models on pages 8 and 10 have "asynch" or "synch" labels. Again, I >don't understand why this is! This point is well taken. The hardware devices themselves are capable of running in either mode. We should have specified that the moniker refers to the style of operation, and not the hardware. > >We might consider a model that substitutes a multiplexer (stat mux(?) or a >Telebit QBlazer, etc.) with PPP (or some multiprotocol) in place of the >Asynchronous Switch. But then we would have a model similar to other models >that Burns and Zachmann offer. > >Turning to page 7, I would like to refer to "Figure 3 Model 1: Dial In (b) >MAC's Running ARA". This model is based on Appletalk Remote Access (ARA). > >ARA must be licensed which may be an administrivial problem but none the >less it does present an additional expense to the school. The lack of >general use of ARA on the Internet does pose a non-trivial problem. >If support or troubleshooting is needed one would need to consult >Apple, Inc. directly! It is critical that any model that we recommend be >efficiently and Internet-widely supportable. > >Also, ARA tends _not_ to be robust, and can be "flakey" in some instances. These are good comments. We have no direct experience with Apples (we both are of the "other" religious persuasion - IBM PC's and clones), and appreciate the feedback. Actually, we do not advocate any asynchronous dial-in, as we much prefer Model 2. > >Turning to page 8, I would now like to comment on "Figure 4 Model 2: Bring The >Network To The Site - Synchronous Dial-In". > >This is an excellent model for sites that can budget a good deal of money >to purchase an Ethernet LAN. Also, I do not believe that you need the v.35 >interface; RS-232 is workable. We agree - RS 232 is workable. See below for our comments RE Ethernet. > >Assuming that all the constituent hardware will not be donated or provided >by corporate giving or governmental funding, I would question the use of an >Ethernet. I wonder how many schools could afford an Ethernet? Also I >would reitterate that, I believe, most v.32bis modems are both synch and >asynch. The model specifically calls for a synchronous modem. We agree. However, we note that the modem must be run in synchronous mode in order that it be compatible with the router. We have found that in many cases in both schools and in school districts (at least in Colorado), there are funds sufficient to install Ethernet to at least some of their computers. Also, we feel as if Ethernet is important in that it provides a scalable LAN, and will be able to handle passing substantial visualization images across the LAN, which is where we and the Internet seem to be heading. Given what some schools and school districts are paying to Novell, an Ethernet LAN would be a cheap, robust and reliable alternative. Our concern here is the software which currently runs across IPX, and not IP - there must be a transition path (Novell's newest release does both using a powerful 386, or so we are told). Finally, an Ethernet LAN is a good way to get MANY computers connected in parallel at once (necessary for education). We are told Ethernet cards for PC's are down to $70, and for MAC's are down to $160 each. Also, running Ethernet thin is something we believe we can train school personnel to do themselves (we are planning a workshop to train them to do this). > >Next I would like to address the model on page 9, "Figure 5 Model 3: Bring >The Network To One School - Dedicated". > >This is an excellent model and it quite appropiate, as advertised, for _one_ >school. As in the previous model, I would question the reality of a schools >being able to purchase an Ethernet LAN. > We agree - one school only, but we like Ethernet, as discussed above. >Let's move onto page 10 to review "Figure 6 model 4: Bring The Network To The >School District". I would suggest that the Cisco Gateway be replaced by a >Telebit QBlazer with a 56K baud card. The QBlazer is much less expensive >and just as capable (and comes with an Ethernet). I would also question >how Unix can be optional if the intention is to "do mail". This model >is excellent if used as the central server for a school district or the like. We are not too fasmiliar with the Telebit QBlazer, and will get some information (I know they are familiar with it at Colorado SuperNet, and will "pulse" them). Our concern here is our ability to: (1) monitor the network using SNMP, (2) our ability to maintain currency in software - particularly the O/S (we have begun burning our own PROM's for our Cisco routers), (3) homogeneity (we may have Cisco's and perhaps NAT's only), and (4) robustness for routing protocols. The jury is still out on this one, but we shall continue to explore alternatives. Unix is optional in that mail and the netnews feed could be done centrally within the state, as Colorado SuperNet does for Colorado (again, Rob caught us being too parochial). > >We should consider a model that would have Figure 6 Model 4 as a central >server at the school district, and Figure 5 Model 3 as the model for >the schools to be served by Fig 6 Model 4. In addition to the comments that >I have made, I would also recommend that the model on page 9 have 14.4K baud >dialup lines (with PPP) to the server (instead of 56kbps data circuits). I >would maintain the 56K baud dedicated data circuit from the server to the >Internet even though there would be a slow down created momentarily by >4-14.4K simultaneous transactions. > >Here is a model based on the excellent work of Burns and Zachmann. > > > Individual School > ------------------- >:----: >: PC :----- 19.2K ----: >:----: serial line : > :------: > : ---:EtherNet >:----: : N : >: PC :---19.2-------: e : >:----: serial line : t : > : B : >:----: : l : >:IIe :--9600--------: a : >:----: serial line : z : > : e : School District's >:----: : r : Central Server >:MAC :--9600--------: : ------------------- >:----: serial line :------: :---: > : EtherNet:------- : > : : N : > : :-------: :-------: : e : > :--:v.32bis:--PPP--:v.32bis:----: t : > :-------: :-------: : B : > : l : > : a : > :-------: : z : > Another school site <----- PPP---:v.32bis:----: e :---56Kbps--> > :-------: : r : CSU/DSU > : : > :-------: : : > Another school site <----- PPP---:v.32bis:----: : > :-------: : : > : : > :-------: : : > Another school site <----- PPP---:v.32bis:----: : > :-------: : : > :---: > We like this model, except we want to hold out for Ethernet in the schools. Let us give them technology that they can grow with, and technology that can be used to support visualization. We agree about the 14.4 kbaud dial-in using a v.32 bis modem running in synchronous mode to connect the individual school to the school district hub. We still question the use of e Netblazer - how many ports will this support? We figure that an Ethernet LAN will support many computers, but will allow only about a dozen simultaneously doing telnet's across the 14.4 kbaud line. Again, Ethernet provides a viable growth path (in fact, it is a do nothing growth path for the LAN, but will support higher speeds form the WAN line as they become available - as they will). A NAT gateway costs only $1,600; we are told there are similar devices coming out early this summer which will market for about $1,000 or $1,200. Given the functional value and the derivative, why even consider about something like a NetBlazer? > >I would again commend Burns and Zachmann for their time and effort in >producing an excellent report on thier fine work. Their work has certainly >given me quite a bit of motivation. It was mostly the fine work of others - Michael Moravan and Bill Kamm at Colorado State University, and Dave Menges at Colorado SuperNet, and David Wood at the University of Colorado at Boulder. Theirs is the knowledge. We simply have written it down in the hopes of getting on with business, and providing a forum for agreeing upon a model - hopefully universal. > >I would welcome comments from the authors as well as from others. Hopefully >we can provide k-12 schools with a supportable, cost-effective and >caller-helpful connectivity models. > >I would like to indicate that I am, just as Burns and Zachmann (p.4) are, >"not a technologist - I just struggle with technology as a means to the >end of providing Internet connectivity to the many schools". > >Acknowledgement: I would like to thank Kurt Lidl of SURA Net for his >invaluable guidance and time. > >