Campus Communication Strategies
|
TechTalk | Virtual Seminars | Glossary Campus Communication Strategies TranscriptObjectivesDouglas S. GaleAssociate Vice President for Information Systems and Services George Washington University dgale@gwis2.circ.gwu.edu Planning for, deploying and supporting digital network connections has become a roller coaster: a technical roller coaster, an economic roller coaster, and most of all, a political roller coaster. In this segment, we are going to try to very briefly look at where we've been and where we want to go. If we look at the history of campus networking growth prior to 1994, we see very consistent data. The graph that you are looking at is a semi-logarithmic plot, and it shows campus network utilization doubling every twelve months. That means every 3 and one half years, the campus network is supporting ten times as much traffic as it had earlier. Now, some folks say that this growth has been largely driven by new users coming on the network. The data we have indicates differently. The growth is driven almost entirely by increased utilization by individual users. We don't have reliable data past 1994 because that was when the NSFNet was privatized and we no longer have access to the raw data. However, we do know that the last few data points that we had in 1994 didn't fit this model of traffic doubling every twelve months. In fact, the growth was much faster, and we all know why. It was the advent of the World Wide Web and the extensive use of graphics by our users. In planning for future network development, we've made a very conservative assumption. That assumption is that users will return to the FTPs and Telnets that they know and love, and that the World Wide Web and the use of multimedia is a passing fancy. In other words, that we can look forward to continued growth in the future that parallels the growth that we saw prior to 1994. We know in reality that that assumption is probably much too conservative. Telecommunications companies are currently experiencing 7% growth compounded weekly. Doubling times are now measured in months. In December of 1995, the Monterey Futures Group hosted a workshop of network engineers to try to develop a vision of where it was we were trying to go in higher education and what the technical requirements would be for our infrastructure. We have labeled the outcome of that workshop "The Technical Requirements for the Virtual University." And what was it that we were trying to achieve? What is the end objective for this infrastructure? First of all, we decided we wanted to be able to support real-time transmission of text, graphics, audio, and video to the desktop. We wanted to be able to support high-performance research applications. And finally, we needed to have the software tools and systems such as multimedia and digital libraries necessary to support a distributed learning environment. Can we meet those requirements with our current campus networks? Can our national networks meet those requirements? We can support the real-time transfer of text, the real-time transfer of graphics. Sometimes it may be a little slow, but it works. And, in fact, the software tools and multi-media tools that we need to fully take advantage of these network connections are becoming available. What can't we do? We can't support the exchange of real-time audio and real-time video, nor can we support our current high-performance research applications. Why can't we do this? Why can't we support real-time audio and video? Later on in the series, we're going to talk about the technical reasons, but very briefly, it has to do with something called "delay and jitter," the way the packets of information arrive and the timing of those packets. For example, voice does not present very stringent band width requirements on the network. It does, however, present very stringent timing requirements. Iftheinformationiskindofgarbledupandbunched inthepacketexactlyquiterightinsequence, it'sveryhardtounderstand whatisbeing said. Even though there was adequate band width in that transmission to carry the information, it wasn't intelligible. So, those are technical problems that we'll discuss later in the series. But the Monterey Futures Group decided to look at the problem in three components. The first component is the Campus Network. What are the requirements for a Campus Network to meet the objectives that I outlined? Secondly, how do we interconnect the campuses to each other? And, finally, how do we connect the campuses and the national infrastructure to our home? Let's focus on the first of those, and that's the connectivity requirements for the Campus Network. Our design objective was to be able to support real-time video to the desktop. That requires a switched ten megabit Ethernet connection or better to the individual desktop. Architectures exist for providing this kind of Campus Network. We looked at connecting these work group switches back to a central campus core and concluded that 155-megabit technology would be adequate, and that a campus backbone capable of supporting OC 12 or 600 megabit traffic would, again, meet most of our requirements for the next few years. This is going to be the primary subject of this series. However, we know that our campuses do not exist in isolation. We have to interconnect them to other campuses and to other users and to other institutions. That requires a national infrastructure. This national infrastructure has requirements that are based on the aggregation of the Campus Network. At the national level, as we aggregate this into some sort of cloud, we're estimating that the requirements are going to be in the order of OC 12 or 600 megabit connectivity. This is going to be briefly discussed by Doug van Howling as he talks about the Internet 2 Initiative. And finally, we would like to be able to provide connectivity into the home. And this last piece is probably the most difficult of all, using today's technology. We're not going to discuss this to any detail in this series; however, the consensus of the Monterey Futures Group Workshop was that we needed to be targeting something on the order of 1.5 megabit to ten megabit into the home to be able to provide the distributed learning environment that was our original objective.
| ||||
[Top of Page] |