Revision: 2.1 Student Computing: Access and Connectivity Team
This project has grown since its start from one that was to provide 2500 students access to computing and Internet services to providing 5000 and then just recently 8000 students access to a wide range of information services. Since the connectivity team has been provided little in the way of requests for more than just getting students connected to the Internet, providing those basic services are those that we have concentrated on in this report.
The implementation of a project of this magnitude will require us to plan for significant loads to be placed on many areas of ITS including the Help Desk, general support services, Hardware Services and the Store. In addition, central network servers like those that provide the Mail, News, Gopher, Web and Directory services will have to be scaled up to handle the massive numbers of new users. Failing to scale these common background services will mean a significant deterioration of service for our existing faculty and staff users. The connectivity team hasn't concentrated on these issues but wishes to point out that any implementation will have to involve virtually the entire Division -- much more than a core student computing implementation team as described in these pages.
In this paper we discuss and make recommendations on a wide range of issues. We have summarized the major recommendations here for easy reference. They are organized according to the sections of the paper.
The following table summarizes some of the the expected costs for student computing over the first three years.
Within the initial ``Terms of Reference'', kicking off the Connectivity and Access team, there was the suggestion to prepare an environment to support approximately 2,500 students in this first year. The members of the team spent a few hours considering whether or not this starting level would be sufficient given the rush to embrace Information Technology exhibited by the current ``compute-aware'' student population. Our current mix of students have been exposed to the popularization of E-mail, ``surfing the Internet'' and hitching a ride on the Information Superhighway from virtually every media source. The effect was to generate a significant ``me too'' demand which hit ITS squarely in the Accounting department. ITS saw staggering growth in the demand for access and the services which back up those accesses; in the coming year we can expect additional increases in demand but the rate of increase can not be predicted with any certainty.
For the above reason, the Connectivity team felt more comfortable with a first year target of 8,000 students especially now that we have been told that special provisions will be made for students living in residence. Erring on the side of ``too much'' would be preferable to the status quo of having ``too little''. Any excess resource would soon be consumed as the increase in demand continues.
Having established a target for the number of users to support, the next task was to determine the service level we would like to provide which can be expressed as a ratio of users to access points (lines/modems/ports). Comparisons were made between services offering high ratio environments (ie. commercial service providers where busy signals are accepted if not expected, 100:1), community networks (`freenets') where an accepted, but not often attained optimum ratio is 19:1 and low ratio environments (ie. staff/faculty access at UWO where busy signals are perceived as inhibiting productivity, >5:1). The desire to provide a service which would be viewed by the students as satisfactory led the team to target an access ratio of approximately 20:1 or better. With this ratio in sight, the number of access points into the UWO network can be quickly approximated at around 400 connections. We need to size our serving equipment to handle this and communicate this estimate to the group that is responsible for modem access (See section 6.1).
The students themselves will have a direct investment in the annual cost of providing these resources given the USC commitment to direct funding into this project. As such, ITS (as the principle financier and manager of these resources) must be careful to show a willingness to accept the level of demand as it is presented to us. We can not accept generic student funding without offering access free of arbitrary limits such as threshold cutoff points seen in the current academic session. Unfortunately, in the first few years, the required resources to support all of the students will not be in place. Throughout this ramping up period, some threshold limits may still need to be enforced in order to balance demands for the service with adequate user service levels.
The expectation is to provide an increase in the number of students which can be accommodated each year and hopefully keep pace with the increase in demand expected. When limits must be applied, the only fair approach seems to be to accept applications on a first-come, first-served basis (subject to alternate suggestions by other interested parties, such as the USC). Some resources may be withheld from the student pool before the remaining resources are opened up to subscription by the general student population; these reserved resources would be used to satisfy certain academic requirements for access/accounts as stipulated by professors, courses or disciplines.
As the number of clients grows so too must the back end services and infrastructure to support those clients. This means that to prevent a massive reduction of service to our existing faculty and staff customers, Mail, News, Gopher and Web servers must be scaled to match the increased demand from these new student users of the systems. For example, we cannot allow the deterioration that affected Julian during the latter months of 1994 to be repeated. A similar scaling up will be required in many parts of ITS including the Help Desk, support services, Hardware Services and the Store.
The registration and software distribution system has been described in a companion paper from the Connectivity and Access Team entitled Design Notes for Student Account Initiation. The recommendations in that report may have to be modified in light of the pending agreement with Bell (see section 6.1).
The implementation of this system should be assigned to a separate group so that work can begin immediately. This report assumes that that work is in progress and that we will have a working prototype system in place for students to be informed about the new system via a specially mailed information package in mid-summer 1995. A fully functioning system should be running before the students start to return to campus in late August 1995. That system should implement a much more robust configuration capability than the current PPP/SLIP distribution to significantly reduce the amount of bad e-mail addresses getting into the system.
We have talked with a number of faculties and departments around the campus about how students might use their existing facilities to register for the central student computing service and obtain our software distribution. As a result of these talks, we have commitments from the Social Science Computing Lab, Engineering and the Business School to provide service for their students. These facilities would be in addition to the dedication of the two ITS labs and the Science Faculty lab in NSC for the first 3 weeks of the school term to this activity.
A team should be immediately set up to work on the implementation of a new registration and software distribution system.
Detailed costs for implementing a new registration system have not yet been estimated. That should be an early result from the implementation team. We expect that it will primarily utilize time from existing people at ITS. There may be some money required for extra help to get the screens formatted and the database programming completed. A rough estimate is for about 210 hours of programming effort or about $10,000 at our current internal programming rates.
We will require student staffing of the major campus labs that we will
be using for initial registration: 90 hours (2 days) training + 3
weeks 
70 hours 3 labs $10 per hour + 4%
benefits = $7488.
A concise, understandable and example rich campus computer Acceptable Use Policy must be written to be applied to all computer users. We must include mechanisms to deliver this information to each user regularly so that each can distinguish right from wrong.
Policies and procedures for shutting down student accounts when abuse is known or suspected need to be developed and implemented. These procedures should outline the appeal mechanisms for students.
For September 1995 we intend to provide substantially the same services that ITS is currently providing to students on julian.uwo.ca and on cheetah.uwo.ca via our $25 cash accounts. A detailed discussion of these services (and other services) was presented by NST, FST and DST to the student computing teams. Much of this information is summarized in the paper Student Computing Discussions: Back-end Services -- Basic Infrastructure and other papers distributed at that information session. A full set of notes from this information session is attached to this report.
Each student will be provided with the facilities for communicating
with peers and the rest of the Internet connected world via electronic
mail (E-mail) for private communications and the Usenet news system
for public discussions. In addition, tools will be provided for
searching and gathering information from the Internet. Programs such
as (but not limited to) gopher, Web browsers, FTP clients and telnet will provide this
capability. The environment will be limited because it will be
located on a machine that is separate from the main research machines,
but it will also be extensible because other client-programs can be
added to a user's suite and there will always be access to the Unix
shell on the central server. We will rely on adherence to a strict
code of ethics to control resource abuse.
The following is a brief description of how these services will be provided:
Four basic services will be provided via modem connections:
Users with modems less than 9600 bps use a terminal
emulator to connect. Since the client/server
applications do not run on a system using only a terminal emulator,
these users need to have an account on a server to log into. With
a cheetah-like account, users would have access to e-mail through
pine and also run the Unix gopher, telnet and FTP clients. Lynx
will provide text-based access to
World Wide Web (WWW).
These users can use the ITS Taking the Internet Home for DOS package. It includes:
These users can use the ITS Taking the Internet Home for Windows package. It includes:
These users can use the ITS Taking the Internet Home for Macintosh package. It includes:
For September 1995, we will provide general communications and information gathering tools for 8,000 students including access to a shell prompt on a separate Unix-based server. Software will be provided to allow client-based computing for many functions and we will encourage as many users as possible to to use the facility in this way.
Sizing recommendations:
After the initial implementation in September 1995, a team should be formed to continue to expand on the applications and services that are available via the student server(s). This set of services should be formulated in consultation with the initial user population as well as tracking current trends in computer-mediated communications. We feel that one of the early tasks should be to develop a student e-mail directory based on authoritative data from the Office of the Registrar. This team should also be charged with the task of scaling up the project to include all students.
An on-going student computing services team be set up to constantly monitor and improve the services provided. For the first 3 years a major focus of this team will be to expand the service to the entire student population and to consider expanding the service to other related groups like alumni.
The system should have adequate excess capacity to handle moderate growth during the first year of operation, including the provision of some additional applications. Further, the system should have a well defined growth path to handle much larger numbers of users, eventually providing an extended range of services to about 1,500 concurrent users from the entire population of approximately 30,000 students. One possibility for this growth is to ``clone'' the system three or four times rather than purchasing larger and larger monolithic systems.
The final configuration for the server system will likely be based on the results of an RFI which has yet to be issued. We can, however, provide an outline of the approximate configuration and estimated cost.
The proposed system would have the CPU capacity of a six processor Sun SPARCcenter 1000, 512 MB of memory, 2 GB of local disk and a 100MB/s ethernet adapter. The 2 GB disk will be reserved for system files, swap space, and other system overhead, while user files will reside on the new Auspex NFS file server. We are recommending that we provide 1 MB per user so the initial user space requirement is 8 GB.
A rough estimate of the server cost is $100,000 to $150,000. We recommend that the implementation team obtain formal bids and quotes for the system before it is purchased. We would expect that the maintenance on such a system would be about $15,000 per year. The system will take about 70 hours to set up.
Since the addition of 8GB of disk to the file server will require the addition of an expansion cabinet the incremental cost is about $25,000. Expansion after this will cost about $5,000 for each 4GB disk. The maintenance cost would be about $4,000 per year.
The implementation team should investigate the logistics of ``cloning'' a base-level system to quickly and painlessly add capacity.
An additional 1.0 FTE for system management including postmaster functions and applications and software support will be required to run the student server. Estimated cost: $50,000.
Access to the student computing service will be provided through many faculty and departmental on-campus labs as well as via the very limited on-campus ITS facilities. The majority of connections are expected to originate from off-campus. The technology that currently supports that access is dial-up modems. We also recommend further investigation of directly connecting on-campus student residences. The following sections elaborate on the expansion and implementation of these latter two access methods.
The preferred implementation for providing connectivity to the UWO network is to contract out the business to a commercial provider. Many providers contacted were interested in the capturing this business but none were felt to be far enough along in their development for us to bank our future on. With lead times running short and many technological questions unanswered, the team members concluded that only by expanding on the existing technology (and, unfortunately, the existing capital expense) could we be assured of being able to provide a solid, tested foundation on which to base the new student computing initiative.
In the coming year, we expect that the commercial providers will be able to better define their offerings and present themselves as real alternatives. At this future time, these companies may well provide us an alternative to additional significant capital investment as the number of students supported expands from 8,000 to 30,000. Moving to external providers would have a number of benefits beyond the capital investment issue:
Some questions remain regarding the direction that these external providers will take when designing their services. Only as these services mature will we be able to see if the ideologies chosen by the commercial providers will be resolvable with our own future direction.
Late in the process of developing this report a decision was made outside of the team that we will be outsourcing the provision of modem service to Bell. We fully expect that this service will be a superset of our current modem services. Bell has promised to maintain enough modems to keep up with the demand for service with a minimum number of busy signals. We assume that they will be providing mechanisms to fairly limit an individual's use of the resources. Details for that will have to be worked out with Bell during the implementation phase. Bell is proposing that a per-hour fee be charged but the team feels that at least 3 hours a day connect time be provided to each student at no cost to the student. Details of the contract with Bell on these and other issues will have to be referred to the implementation team.
Figure 1: Components of Bell's Proposed Modem Service
Many of the details about how the connection to an external modem pool will be controlled, monitored and even physically be connected have still to be determined. Figure 1 illustrates Bell's idea of the parts that will be involved. Bell feels that a 60 day test period will be adequate to address these problems. The team feels that this is unrealistic and that a one year trial (May to May) is much more reasonable. Due to the late start (the equipment doesn't arrive at the earliest until mid-May), the team would like to make it clear that a supreme effort and significant resources will be required to get a system into production by our early August deadline. This level of effort is going to be difficult to provide given all the rest of the work that also needs to be done not only for student computing but for other major ITS projects ongoing during the same period. Indeed we are assuming that one of those projects, the NFS file server installation, will be in place before the student system.
We estimate that an additional half an FTE will be required to liaise with Bell, monitor and report on usage, maintain user databases, help with security issues related to the modem pool and to coordinate the help desk functions between Bell and UWO. During the initial implementation phase when Bell is still learning how to do this the resources required will be much greater. We recommend that Bell be charged for any consulting that we do to help them build their system. We estimate that this will require an effort of about 0.3FTE or $20,000.
Should Bell be unable to deliver a suitable modem service then the team has investigated and can recommend a UWO purchased modem pool sufficient to meet our initial needs. The time for making this decision about Bell is very short as it will take about 3 months to set up our own system. It should be noted that we estimate the capital costs of doing it ourselves to approximate $500,000 with an on-going yearly charge of more than $100,000. Costing information for a smaller version of this option has been included in section A.1 of this document. In addition to the actual hardware and line maintenance costs, some work would have to be put into mechanisms for fairly dispensing this limited resource in addition to on-going support of the pool which might amount to as much as 1.0 FTE.
Bell should provide a BUSY-tone free modem pool with modems that provide PPP/SLIP and simple terminal access at speeds up to 28,800 bps for the period from June 1,1995 until May 31, 1996. The University will pay $100,000 for this service. There should be no additional charges to individual users of this system.
An extra 0.5 FTE should be provided by ITS for ongoing support of the modem pool system. Estimated cost: $25,000/year.
For students that are housed on-campus in residences it makes sense to provide them with high-speed network connections rather than have them burdening the modem pool for access. This provides a much better (higher speed, more reliable) service to those students and in the long run, (especially when Bell implements connect time charges) these connections will cost less than providing service via a modem pool.
While we do not currently have any estimates in writing, both Mike Ashton and Terry Muise (Bell Canada) vaguely remember a figure of $250-$300 per room for rewiring Saugeen-Maitland.
However, if we assume that it includes the wiring only, and we assume that 500 rooms need to be rewired, then the capital cost will be $150,000. If we have to add hubs, etc, we need about another $50,000 for 10 hubs. Other costs to be considered are those for any networks and servers in common areas.
We currently estimate that a charge of $250,000 to wire a building like Saugeen-Maitland hall is not unreasonable.
All new residences must be designed and built with adequate closet space and pre-installed data wiring (category 5 twisted pair) to allow the easy addition of networking to every room. The feasibility of adding appropriate hardware to provide an ethernet connection to each residence room should be investigated.
Formal quotes for adequate data wiring and ethernet hubs for each resident of Saugeen-Maitland Hall should be obtained and a cost recovery plan written. This model should then be used and applied to the other campus residences as well as for facilities in the affiliated colleges.
The team has not had time to explore in any detail the possibilities of on-campus docking stations for portable student computers. Some of the issues identified include:
The opportunities for on-campus docking stations require further study and should be looked into after the initial September 1995 implementation. We would expect that a limited test facility could be ready for September 1996 and a large-scale distributed facility could be in place by September 1997.
Issues of providing direct and adequate computer support for the students includes more than just coming to their aid when they need help. There is considerable developmental work, troubleshooting and maintenance work necessary to keep everything running smoothly for them, both from the hardware and software side as well as networking. Training and documentation are other elements of support.
As of the writing of this document, ITS has distributed 116 Mac, 118 DOS and 948 Windows copies of the PPP pilot project software to UWO students. The people involved have provided us with valuable information about the process. Of the students that have picked up the PPP package, 35 - 40% have requested some sort of help from Help Desk staff related to getting the package up and running. Many of these are short 5 to 10 minute calls. If a call goes beyond the basic consulting of 15 to 20 minutes (mostly because the computer is non-standard in its hardware or its software setup) then the call is passed on to another member of FST (Front-Line Services Team in ITS of which the Help Desk is a part). Once a student received help with the initial connection however, it quickly became apparent that they tend to come back for help with other computer related issues and therefore the Help Desk consulting time is dramatically increased yet again.
Assuming that the students that we have been dealing with this year are more computer literate ( they were the ``eager-beavers'' that found out about our service and came in to get it first), we are likely to see a higher percentage of students needing hand-holding as this project really takes off. As we open up our services to more students, there will be a huge impact on the Help Desk. Statistics show that the recent addition of approximately 1000 students with computer accounts increased the number of consulting calls to the Help Desk by 2000 calls per month. There will also be a need for extended hours into the evenings and weekends to accommodate students needs. The Help Desk manager has estimated that the addition of 8,000 students will require the addition of 8 new 35 hour/per week positions during the school year.
Preliminary results from the survey also indicate that students put a very high importance to all types of support and that 'drop-in' and 'hot-line' support lead the way. Proposals for how this much increase in consulting might be handled are being prepared by the manager of the Help Desk staff.
NOTE: During the real crunch in September when we expect to handle the bulk of the registrations and software distributions, there will be students in each of 3 labs to assist (see recommendations in Design Notes for Student Account Initiation). It is proposed that these students also handle the bulk of the PPP related consulting during those 3 weeks to take the load (and traffic) away from the limited area in the Help Desk.
Consulting for the PPP package beyond the Help Desk level currently occupies 7 to 10 hours a week of FST time as well as consultation with members of NST (Network Services Team in ITS). These are typically problems of software conflicts or unique hardware. This need will also be increased with larger numbers of computers being connected. While the numbers would indicate a need for two extra positions we are confident that through increases in efficiency we can hold that increase to a single person.
Experiences of the support staff have identified a couple of problem areas that need to be addressed as we prepare to offer this service to more students.
The first is that there are a lot of misconfigured systems out there because people don't read the documentation provided and this is causing many problems. One of the most obvious problems is in undeliverable mail that requires ITS staff to 'track down' the user responsible. Currently this is a complicated and tedious process that only a couple of people can handle. It is suggested that we will need procedures in place to make this a fast simple check that can be somewhat automated. There would also need to be policies in place for notifying the users and for handling those systems that are accidentally misconfigured as well as those that are obviously misconfigured on purpose (trying to be untraceable). Another possibility for improvement in this area would be to the actual install routine of the PPP package to force users to configure the system and maybe do some degree of error checking. We recommend that the implementation team investigate ways in which this might be accomplished.
The second major problem involved lack of understanding on the part of our users. Many of the short Help Desk calls reveal a general misunderstanding of what AccessIDs, login IDs and E-mail addresses are. Knowing that our general users do not tend to read lengthy documents, it is suggested that the registration process reinforce the concepts by displaying a WEB page that tells the user what their e-mail address, AccessID and UserID are and to instruct them to copy them down for future reference.
As mentioned above, plenty of support is needed behind the scenes other than direct consulting. There are constant updates and bug-fixes to software that require testing, packaging, documenting, notifying and distributing. From modem support to problems with misconfigured mail or news postings or software conflicts, many areas of support are showing an increase of work load due to an increase of usage on our systems. The new student server will require system support, networking support, software support and backups etc. More network traffic will require more monitoring etc. Continued improvements and additions to the services offered as we develop toward a complete information system online will require many hours of work from many areas of the university.
Currently ITS is not providing training geared to students. There are two distinct types of training at issue. The first is training on how to get started (register, get the first PPP package and get it running) and the second is general computer training which includes how to manage your own system and how to use certain applications. This team feels that a large auditorium style training would be of benefit, possibly during orientation for the getting started portion of the training. It is felt that this training would decrease the amount of confusion as well as the amount of consulting that is needed. There may be room here for a cooperative venture between ITS and Student Council, not only on the getting started issue but in general training. There may also be a need to do the training at a later date for students that were not here or did not attend in September.
There are many helpful How do I... documents related to getting connected and using the PPP package and other software that are of use to students and were developed with students as well as staff and faculty in mind. These are very popular and appreciated. They will need to be updated on a regular basis to keep them current. For the initial hand-out however, it is suggested to give only the getting started documentation and not a full set of every document they may want. The documents are easily available once you are on line and care should be taken to point the students in the right direction.
Other documentation would include the advanced mailing to students. This should be professional looking and full of helpful information so that it is kept for reference. It should describe who we are, what facilities are available to students, how to contact the right person, how to get an account (during the first 3 weeks or later in the year) and what training and consulting is available. NOTE: It should encourage students to come in during the first 3 weeks so they can take advantage of our facilities while they are available!! Other issues to be covered in the first mailing could include an obligations and acceptable use document, general awareness information and explanations of what an account is, what e-mail is and what networking is all about.
Funding for an additional 8 full time equivalent student consulting positions be made available during the school year: approximately $100,000.
0.5 FTE be allocated to on-going security problems associated with the new service. This will grow to 1.0 FTE as we scale up to the full student population: $30,000 to $60,000.
Advertising and promotion at Orientation: $600.
1.0 FTE be added to the Front-line Services Team for back-end support of student consultants: $50,000.
Developing a detailed package of instructions for students is estimated to take approximately 105 hours to develop: about $5,000 at our current rates. Charges for printing and mailing the connection information to approximately 20,000 students is estimated to cost about $60,000 ($3 per package).
The following is an estimate to add 250 modems, lines and terminal server ports to the modem pool for student use. We assume an increase of 5000 students from the present number.
The prices shown were supplied by R.E.D Electronics when we purchased the last group of 96 V.34's. These prices are slightly below those of the Store.
Because of the quantities involved in each case we may be able to command a slightly better discount, but I don't think it will be more than 1%.
Cisco and USR have combined the V.34 rack-mounts with the 2511 terminal server in one rack. The system, known as the Cisco 5100, is packaged as 48 modems and server ports in one rack.
The following is the cost of 250 modems using the 5100 system, (note we receive a 30% discount from Cisco).
The lines monthly rental cost is the same as the quote for the separated modems.