TechTalks Transcript
Managing the Convergence of Data, Voice and Video Streaming
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 James Jokl [JJ] |
December 14, 2000
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN Tech Talk series for Fall of 2000 and to this session on Managing the Convergence of Data, Voice and Video Streaming. You are here because it's time to discuss the core technologies for your future campus. This is Judith Boettcher, your CREN host for today, and I'd like to thank our CREN member institutions and Apple Computer for their joint sponsorship of today's Tech Talk. Apple's QuickTime is the leading cross-platform multimedia format for the Internet. Let me also welcome Howard Strauss of Princeton as the technology anchor for Tech Talk. Howard is a well-know web technology and portal expert and always surprises us with his interesting introductions. Howard?
HS: I have to live up to that, don't I?
JB: All the time!
HS: Right! Okay, thank you, Judith. I'm Howard Strauss, I'm the technology anchor for the Tech Talk series of technology webcasts. In this webcast, I invite you to join Judith and me in a lively technical dialogue with our guest expert, Jim Jokl, that will answer the questions you'd like answered and to ask those very important follow-up questions. You can join in this dialogue by sending your questions via e-mail to expert@cren.net at any time during this webcast. If we don't get to your questions during the webcast, we'll fill out an answer in the webcast archive.
Convergence is actually nothing new. When computers were first built, some were built just for scientific computing and others were built just for commercial computing. It soon became clear that building a single computer that could do both commercial and scientific computing was not only more cost-effective, but on occasion, an investment bank actually needed to calculate a sine or cosine and that scientists actually needed a computer to calculate and print their paychecks.
But convergence usually does not work. For example, despite repeated attempts to converge cars and airplanes, cars and boats and even cars and submarines, all have resulted in vehicles that are the worst of both worlds. Despite the attractiveness of being able to avoid the high tolls at bridges by just driving one's amphibious car across the river, no such practical thing exists today. Rube Goldberg was a master of doing convergence wrong. He could take common objects and actions and join them together to do totally unexpected things in ways more complex and unlikely than anyone but he could have imagined. It seems that for convergence to work, it must greatly reduce the complexity and the cost of doing whatever it is one's trying to do and it must do it without much disruption and it must have some magic about it that makes it appealing for reasons that perhaps might be difficult to quantify.
Taking voice, data and video-which today are all commonly in digital format-and treating them the same seems like a convergence begging to happen. Our IT staff, who are charged with moving data around on networks on IP packets do it with such skill and alacrity that they should hardly notice it when we also give them voice and video packets to move around. But video can generate an overwhelming number of packets and voice and video are not all that much like data, even when they are packetized. If a web page or database takes a few extra seconds to load, it is no big deal. But a few seconds of delay in a telephone call or a movie can make them unusable. A server that goes down and keeps you from your e-mail for 15 minutes can be very annoying, but a phone that won't let you make a 911 call for 15 minutes can be fatal.
Before we terminate our cable TV service, toss our phone system in the trash heap and trust all our campus communications to IP packets, we need to realize that convergence-like most new IT endeavors-needs lots of planning and understanding of the issues to be successful. As alluring as it is to go up and build a combination car-boat-plane-submarine-TV-phone-computer-food processor, James Jokl will tell us how we can disappoint Rube Goldberg by doing convergence that will actually help us work more effectively on today's webcast of Tech Talk. Judith?
JB: Well, thank you, Howard, and I'd just like to comment, you know, I think as we start converging things, you know, we often find that things will dis-converge or separate again, but the pieces will look a little bit different.
HS: So we're going to do a session on dis-convergence?
JB: Dis-convergence, that comes next year! But now, we will focus on convergence and see which things perhaps we might want to combine and which things we might want to keep separate. Okay, I am very pleased to introduce a new Tech Talk expert to our webcasters today. He's Jim Jokl from the University of Virginia. Jim is the Director of Communications and Systems within the Information Technology and Communications Department at the University of Virginia. In this role, he oversees the university's central computing and communications, including responsibility for the range of video, voice and data that we're going to be talking about converging today. And Jim is also active on state and national working groups on these same topics, plus also PKI, which we'll only spell today. Welcome, Jim, to your first experience here as one of our Tech Talk experts.
JJ: Thanks, Judith, glad to be here!
JB: Good, good. I'm glad that you didn't get disturbed by the storm, right?
JJ: No, I was lucky in that regard. We were far enough down south that we had a little bit of ice in the morning, but it's already melted now.
JB: Great!
HS: Yeah, we might mention that we had some considerable difficulty in getting people up in Ann Arbor through the really bad weather they're having there. But we really appreciate them getting out in their four wheel drive vehicles and going through snowdrifts and things to make this thing happen.
JB: Thanks for mentioning that, Howard, that's good.
HS: Jim, when we talk about convergence, we're talking about converging - I think you said - data, voice and streaming video. What do you really mean by converging them and what are those things - this data, voice and streaming video - being used for today?
JJ: Well, the simplest way is to think about it, the way I like to think about it is to, you know, sort of take the 10,000 foot view, and right now, we all run pretty much separate infrastructures on our campus for voice, data and video. We all have a telephone system which, you know, by and large handles the majority of our voice traffic and big extensive data networks. And most of us will have one or two video networks, one probably some cable TV stuff in the dorms and most likely another cable television type system that serves our academic buildings where we pipe various video sources and programming and things like that across it. The idea behind convergence is to move all that or, as you were saying in the intro, on top of the data network and make all those services work under one infrastructure.
HS: And so what we're really talking about doing is taking our telephone network, our cable TV, and just turning them into part of the IP traffic that travels around campus?
JJ: Yes.
HS: Why do we want to do that?
JJ: Well, if you sort of again start with the high level, right now, we're running - even in the same wiring closets - we're most likely sending one group of people out when we want to install a telephone, another group of people out when we want to go ahead and install a new data network connection or doing repairs. The same type of thing with video. So there are some high level opportunities, if the technology shapes out the way we hope it will, to reduce some costs. But that's only one piece of it.
There are a lot of things that we'll need to do for the data networks anyway, even if we don't move other services on top of them, such as making them more reliable and having higher capacity to deal with these types of things. And in general, you usually end up with something better than the sum of the whole when you put things together, you know, if you manage to ignore the Rube Goldberg part that you were doing in your introduction. So there should be applications, and there probably are applications that work better as a single unit running on a single infrastructure than something that's completely separate, so you don't have the phone in your ear while you're looking on your web browser to try to talk to someone and get something done.
HS: But, I mean, we obviously should be concerned that we don't do a Rube Goldberg-like thing. With respect to the phone network, I mean, the phone network has been around for about a hundred years or something like that and it seems like it works real well. I'm on one right now. In fact, that's the technology the three of us are using to communicate here. I mean, it seems like the technology is really pretty good. Is converging it going to make it better, or is it going to make us give up some things?
JJ: If it makes you give up something, it's probably not the right approach. Making telephones better, I don't think, is what convergence is all about. It's taking what's now three infrastructures and turning them into one and reaping the benefits of that, along with better facilities. So you know, I have to admit, telephones work very well. We run a big telephone system here and it's incredibly reliable. And we have a long way to go on some of our campuses, ours included, to get that level of reliability out of our data networks.
JB: Don't we, in fact, isn't that where the phrase - the telephone system - isn't that where the phrase the five-nine reliability came from, Jim?
JJ: Yes, you know, and five-nine's uptime is 99.999% of the time. And I ran a calculation once and off the top of my head, I think it comes out to something like five minutes of downtime a year.
JB: Um-hum.
HS: Yeah, that's probably even more than I see on my telephone. My telephone just, year after year, I pick it up and I get dial tone, which means it's working.
JJ: It's a hard thing to do. The big advantage-�
HS: But if we compare that to the uptime of, say, an e-mail system or anything that's running on IP, right, those things don't approach that.
JJ: No, there is a lot of work to do to get the infrastructure to the right place to do that. I mean, in a telephone system, you're doing reliability based on a single box so you're building a highly redundant computer, which is what a telephone switch really is. Then you're running some copper from that computer all the way over to an end station, another instrument. The only places of failure are, in that highly redundant box which is pretty rare, or some kind of a software glitch in it. The most common type of telephone failure that we have on campus is what we like to joke about as the backhoe failure, you know, when a construction project tears up the cable between here and there. But because you've got that kind of reliability on the phone system doesn't mean you can't get it on your data network, and I'll argue that you need to be working on that anyway.
I often hear from, you know, faculty and staff who say, "Well, I could live without my telephone, but if my e-mail is down, I go home 'cause I can't get my job done." You also have to differentiate the different types of services that are on your data network. You know, there's raw transport and then there's e-mail and they really are kind of different. You know, there are lots of times when I can move packets back and forth across the network when my PC might be broken or the e-mail server might be having problems, but that the basic data transport facility is still working well. So you have to differentiate between the various services too. But you're right, reliability is critical.
HS: But I think another problem is quality. I talk to a number of people using IP telephony and really, the quality has been by and large awful. It sounds like there's delays and the speech is irregular and things get missed and things. Am I just using a real cheap system?
JJ: I'm not sure it's a cheap system. You can take the most expensive IP telephony system that exists and put it on top of a network that's not designed for handling voice and run into a lot of problems. But the classical network that most of us have in place right now for data is Best Effort Delivery, so if you have someone on the network who's swamping the network with lots of traffic, you know, streaming video someplace, just to use another part of what we're talking about, or doing large file transfers, there's nothing in the data network to prioritize the voice traffic to make it work well.
HS: So what you're saying is that we really have to do something a little bit different on the networks if we're going to put voice and video on them?
JJ: Right, as you move towards your next generation of campus network, it really needs to be designed differently if you're planning to converge than some of what we've done in the past. In the past, as you were saying, it really doesn't matter if a web page loads a little bit slower or if it takes an extra second or two to download an e-mail message, but for audio and video, real time characteristics-�
HS: Oh, you sure notice it!
JJ: Right. What you have to have is a network that's designed from the ground up to deal with that.
HS: Could you talk a little bit more about that network? I mean, how is that different from the kind of best effort thing that chances are we have in most of our universities?
JJ: Fundamentally, what you need in the network is the ability to do what we call Quality of Service so that once you have the technical infrastructure in place to do that, you then have the ability - sort of the standard joke about Quality of Service is you rob Peter to pay Paul. In this particular case, Peter is your web traffic and some other bulk file transfer and Paul is your voice traffic.
And the idea is that, if you have certain classes of service that a real time sensitive - audio and video, for example - and those packets, when they come in to some network device that's experiencing any level of congestion have to be transmitted out first so that the data is received at the other end in sequence and on time. And there are various mechanisms for doing it both at layer two and layer three and on the layer two side, if you're working towards deciding what you're going to be doing for your next campus upgrade, you really need to be looking at being able to support 802.1 P and Q so that you have a way at the layer two side and the switches in your wiring closets to be able to prioritize traffic. Then as you move further into your network core, you need to decide what you're going to do for Quality of Service characteristics at the IP layer. Some folks like to think about RSVP, but there's another technology-�
HS: What's RSVP?
JJ: RSVP is a reservation type system, so if you want to set up a network flow from point A to point B, basically point A will go ahead and request a certain amount of capacity out of the network and each piece of network equipment in the path between A and B has to understand that request for reservation, say that it has the capacity available and then allocate it to it.
Another, simpler way to approach the problem is to use class of service, so inside an IP packet, there are three bits available inside the type of service field in the IP header. And you can use that to differentiate between different types of traffic, so for example, your voice traffic, typically you'd want to classify that as five, whereas your normal traffic is running at a zero. And then what you do, instead of trying to manage setting up flows per hop and having all the equipment in the network understand that, you simply go ahead and make decisions on a per hop basis so every hop on the network that the packet flows through from A to B, it simply says, "Okay, this is a higher priority packet, I will send it out first to make sure that it gets the data flows that it needs, and then the regular bulk traffic will go afterwards."
HS: Right. And that can mean that if you have a lot of higher priority stuff, the lower priority stuff never goes.
JJ: That's correct, and you do need to differentiate between them. You know, in the case of voice traffic, the amount of bandwidth that you need is very, very small. You know, a standard telephone like what we're talking on right now, a regular old telephone network's using about 64 kilobits for the audio but studies have shown that if you drop that down to eight to ten kilobits just with the standard compression that's available, you really can't tell much difference in the quality of the audio. So for voice traffic, for just doing the phone stuff, what you really need is the ability to make sure that none of the packets are dropped, that they all get there on time, as opposed to worrying about adding a tremendous amount of capacity to your network.
JB: So does all that mean, then, that if in fact everything else was available, one could add voice to the network and it wouldn't take up a very high percentage of the network?
JJ: Right. Voice itself won't add a lot of capacity, won't add the requirement to add a lot of capacity to your network just because you're adding voice to it. Other applications will probably force you to do capacity increases, but the critical thing for voice traffic - and for video, too - is the ability to differentiate the different kinds of services riding on the network and being able to give priority, for example, to voice.
HS: One more Quality of Service question just before we drop this. I just want to get a little bit better idea of what is required to go from where we are to implementing this Quality of Service thing. I mean, do we have to just add different software? Do we have to add different hardware, do we have to take our routers and throw them out and get different ones? What really needs to be done?
JJ: I mean, typically, your biggest expense is going to be in the wiring closet. So you know, if right now you're in the place where most of your wiring closets have hubs and you haven't upgraded them to switches, the critical thing to do will be to make sure that as you buy the switches to go in for that next round of upgrades, that you buy devices that can do 802.1 P and Q and that you've got some kind of a global plan to do the management of that policy.
HS: But then are we going to need some kind of different network management software?
JJ: Right. Exactly. You'll want to make sure that you can do, you know, network wide policy management so in order to make voice work, if that's one of your goals for your converged network, you need to be managing the network from the edge device-in other words, where the user's telephone or PC plugs in, all the way through the core to the remote user. So you need to have not only hardware that can support 802.1 P and Q at the layer two end and at least something like IP Precedence at layer three, what you need is an integrated network management strategy and I'll also point out, centralized network management, which a lot of campuses don't have.
HS: Okay, we have a question that just came through from Michael Geddes at Georgetown University and Michael says, "What role do you see Quality of Service playing in these converged networks?" But he gets specific, he says, "Is Quality of Service real?" And he says, "Will DEN�" I'm not sure what DEN is, but maybe you know. "Will DEN play a major role in service management and deployment?"
JJ: Well, DEN is Directory Enabled Networks and the idea there is that you can specify the Quality of Service parameters for users and different applications in real time, so the network itself is smart enough to understand that, based on a per-user basis or per application, what Quality of Service is needed for this to make it work. Directory enabled networks will definitely play a role as things shape out in the long run. In the short run, you can do a lot of what you need just by having the IP precedence type things and the 802.1 P and Q stuff in the wiring closet switches. But in the long run, if you sort of want to take a longer view of how things are going to all shape out, having directory enabled networks to be able to understand so that per applications and per users you can actually allocate who gets what and how well it works, that is probably the future of where things are going.
HS: When we talked to you before, Jim, you said that even if you put telephones on your IP network, you wouldn't get rid of every telephone on the public telephone network on your PBX. Want to talk about why you wouldn't do that?
JJ: Well, I think a lot of that is a question of when. I think at that point in time, we were having a discussion about what might be some first steps that you would do. And if you, for example, wanted to try to put a new building in place and instead of adding to your existing PBX, you wanted to install a voice over IP system, for example, to try to leverage that, that might be a very reasonable approach so that at least on each floor, you'd have a traditional telephone that was available for emergencies should something happen. It's more a matter of how comfortable you are with your data network and with the reliability of new technology vs., as you were saying before, where your telephone never goes down.
HS: Yeah, wasn't there some problem with - I mean, the telephone network is powered by batteries, the public telephone network.
JJ: Yeah, I mean-�
HS: And the batteries are at a remote location, typically.
JJ: Exactly. I mean, there are a lot of things that you need to do to your data network beyond just having Quality of Service capabilities if you want to do voice. The biggest one is power and you need to be able to power your IP telephones somehow out of the wiring closet. You can't have a little wall transformer in each office, you know, if you expect people to be able to make 911 calls when the power is down. But typically if you were doing a voice over IP installation, trying to replace the majority of your phones in a building, you would want to have UPS's in the wiring closets which can deal with that.
HS: But why in the wiring closets? Why not at just some central location where your network's all connected?
JJ: Well, that typically is the wiring closet. In each building, you'll have the wires that are coming from the person's office to the closest wiring closet and the same cable that runs the Ethernet connection back and forth will also be handling the power for the phone. So that's just the logical place to put it. You don't want to have to do separate power wiring just so that you can power little wall transformers in each office. The other thing you need to take into account in the wiring closets is how much cooling capacity you have there. In a lot of cases, you know, you may not have dedicated cooling there but it may be okay with the amount of power you're burning up in the closet now. As you add, as you move from hubs to switches and then you start powering lots of remote devices from there, the amount of heat that you generate in that closet is likely to grow up. You know, I won't say "explode," but will grow up significantly.
HS: That would be [inaudible] if it exploded.
JJ: Exploding would be bad, but it's likely to increase significantly. And you need to make sure that you've got the cooling there if you're going to do those types of things.
JB: Well, maybe that would be a good place for a Jacuzzi or something, with all that heat, you know?
HS: Now, while you're talking about replacing my phone with an IP telephone, the same time you're doing that, I see lots of people - in fact, you can't go anywhere without seeing people using their cell phones and mobile phones and things like that. Would it be better just to skip this whole replacement of desktop phones with IP phones and just give me a wireless IP phone?
JJ: Well, you know, when I get asked that question, usually my standard answer is probably the biggest challenge for voice over IP in a traditional telephone market is wireless. If you look at wired IP phones and all the things that it takes to deal with those, you know, as far as the upgrades that you need for your wiring closets for power and all that, that's relatively expensive. Although not necessarily bad. If the world really is going to move to wireless technology, which is more and more happening, there's that general rule of thumb that says things that used to be wired are now going wireless and things that used to be wireless are now going wired. So where you used to have your telephones on wire, more and more of that's going wireless and TV and things like that are now-which used to be exclusively radio based-are now mostly cable based or certainly largely cable based. So the biggest challenge I think to traditional wire based voice over IP infrastructure is going to be wireless. But there's a whole other class of applications, too, with IP soft phones so you may very well want to have the-
HS: IP what? Soft phones?
JJ: Soft phones, sure. So instead of having-�
JB: Soft phones?
JJ: Software phones is the idea behind it, but instead of having a hardware device on your desk that looks like a telephone and acts like a telephone but is actually plugged into the Ethernet instead of all the way back to the PBX, you might very well want to be able to place telephone calls from your PC. There's nothing fundamentally different about doing that than with the logic that's inside a hard phone. You have the same power issues as far as what happens if your PC loses power during an important call. But you might want to have the same infrastructure there anyway. I guess it's sort of turning around and getting back directly to the question about wireless.
It is the future and for voice and running voice over IP, even over wireless is coming also. But it doesn't mean-it's not really an if/then. If you look at either you're going to do wireless or you're going to do converged networking, most of the things that you need to do to be able to support a converged network in your network core, you're going to do regardless of whether you're going to do voice over IP for telephones or not. I mean, you still need to get the reliability of your data network up. You still need to be able to provide different levels of service for different types of applications in order to be able to make video and things like that work well. You still need to increase the reliability.
HS: Can we talk a little bit about video now?
JJ: Sure!
HS: There's a couple different kinds of video. You mentioned a couple, but just looking at, say, broadcast video vs. video on demand, how do these things fit in? Are we going to converge them both? Do they present different problems and have I missed some kind of video here?
JJ: Well, I mean, the basic answer is "yes and no to all of the above." And just to try to get into the individual details, I mean, there is a fundamental difference if you're going over a data network between broadcast video and video on demand. Well, broadcast video, what you really need in your network core is multicast support so that you have the ability to send a single stream of the video and have the network hardware do all the pruning and replication that's needed to deliver that video stream to each person who's watching the broadcast. If you have a thousand users on campus watching a video stream, if the only thing that your network supports is unicast, you'll have a thousand copies of that flowing over the network and you're sure to swamp certain links on the network. If you have a fully multicast enabled network and the applications that are streaming the video are multicast enabled, there's only one copy of that data flowing over the network and the replication and pruning happens in the network core.
JB: Are you doing any of this at Virginia right now, Jim?
JJ: We are not yet, but that is - we're just starting to roll out our support for multicast across our network core and then we're going to be moving towards doing that. Right now, we only do broadcast via unicast. In other words, we have stream replication that we do video on demand. And video on demand is a much harder problem if it's going to grow on a large scale because there the video streams aren't synchronized, so even if you have a hundred people watching the same program, they're probably not all watching it at the exact same point in time so you really do have 100 copies of the stream flowing over your network and you need to have the ability to keep those things flowing with enough capacity so that it doesn't swamp everything else.
HS: How much bandwidth is that going to take, given that somebody uses whatever the best compression technique is?
JJ: With video, there's a lot of different features that you can trade off, you know, the size of the video, the quality, how well you handle the motion. Typically, if you think about low end applications, sort of to start with, something like what you might think of as adequate for talking heads video, that's going to be 128 or less, something in that kind of range, kilobits per second can do a pretty good job with talking heads. If you want-if you're using something like MPEG-2 for encoding, if you want to get for example VHS quality over your network, you'll need two to three megabits for that. Broadcast quality with MPEG-2 is three to four megabits. If you look at some of the commercial products that are around, you know, QuickTime or RealNetworks or even the Windows Media stuff, you'll find that you can get that same kind of basically VHS quality some place around 250 to 500 kilobits per second using some of the newer technology.
Microsoft just did some press releases about their latest version of Windows Media that says they're getting near DVD quality at half a megabit per second. So 500 kilobits. Yeah, they're saying that that was like a 30 or 40 percent - I forget exactly what the article said - improvement from their previous generation, so we're at a point in time when the amount of improvement, I think, that you're going to get in compression is starting to slow down as new technology comes into play. But still, being able to do something on the order of VHS type quality video, 250 to 500 kilobit stream, is very good. It gets to the point where you'll be able to start doing things at home over DSL type connections.
HS: Are people doing that?
JJ: I think you're going to start seeing that. I'm not trying to say that I've seen the new Microsoft stuff or tried to watch over DSL connection a 200 or 500 kilobit stream, so I can't tell you personally how well it works. A lot of the issue with that's going to be what kind of arrangements the campus has with the local DSL providers. You know, if you're trying to get the video from your DSL connection at home through the Internet in general and then back into your campus, you're probably not going to get anywhere near the throughput you need. But one of the things that we've been pretty successful with locally in Charlottesville is getting the various DSL providers to agree to a direct interconnect to the campus network. So instead of going through the Internet, any traffic that's to and from the university goes through the private interconnect.
HS: Oh, that sounds like a great idea!
JJ: We pretty much get full throughput to it so if you have that kind of arrangement or at least arrangement with some of them and your users buy from the people that you've got direct termination agreements with, you probably will be able to do that kind of thing without any real problems. So if your students are living close to campus in apartments but not actually in the dorms where you can guarantee the network performance, it'll probably still be doable.
HS: Yeah, of course, you're going to have some licensing and copyright problems. Bad enough on campus! When that stuff leaves the campus, that's going to be kind of interesting.
JJ: Yeah, I mean, if the materials are licensed for use by your students, you're probably okay. You know, a lot of it's going to depend on exactly how the licensing is written. But you're right, there are things that are licensed for use on campus as opposed to by active students, so you need to be careful with your licensing agreements.
HS: Okay, we have a question from the Colonial Williamsburg Foundation, from Bill White who's there. Normally, we just get universities here. It's nice to hear from somebody down in Williamsburg. That's probably pretty near you, isn't that?
JJ: Yeah, it's about 100 miles. It's right on our back doorstep.
HS: Well, one of your neighbors called! Okay, Bill White says, "I'm interested in the instructional possibilities of converging video, voice and data. How far away are applications that will allow us to broadcast a live video signal while allowing the viewer to communicate with the signal originator by voice and data at the same time, provide a screen with data and graphics that enrich the broadcast content?" Jim?
JJ: Sure.
JB: Anytime soon, right?
JJ: Well, I think a lot of it depends, not so much on the campus infrastructure - although that's important, too - but on what kind of long haul connections you've got, if that's really the focus. We've been doing some work - it's actually in our Education school. We've been providing support for it of classes between Charlottesville and some other Internet2 schools where the courses are actually seminar style, but team taught, so that there will be two professors at the different locations team teaching the class and a group of students at each end, using Internet2 and the campus networks with standard videoconferencing technology. We use the VCON and POLYCOM systems that are available, those basically running in the 768 kilobit type range. And it works very nicely. The students can see each other, hear each other. They use NetMeeting to do shared whiteboards and shared applications and they found it a very good experience. It's worked quite well.
JB: Now, that's point-to-point, Jim, isn't it?
JJ: Correct.
JB: Yeah, okay.
JJ: But you know, you can, if you install a multipoint control unit, do more locations. A lot of that, the question becomes, I can easily see two or three locations working well but I think the technology will live longer than your ability to use it in that kind of environment. If you had five or six or seven locations, it's not that amenable to a seminar style class. If you're trying to do a traditional distance learning model where you're doing more broadcast and then occasional questions come back to the instructor, you'd probably use a slightly different technology, basic normal video streaming type technologies instead of two-way videoconferencing. Both would work.
HS: Does this mean that this thing is going to really make videoconferencing a lot easier? I mean, right now, we have a special facility to do videoconferencing. We have to wander off into some special place. Are you saying that I'll soon be able to sit in my office, have my little camera that lives on top of my PC and start a videoconference from here?
JJ: You know, I actually have one of those. It works nicely. And the basic answer to that, I think, is yes. I mean, I don't think any of our - I shouldn't say "any," but I can speak for ours. Our campus network isn't ready for everybody doing that right now.
HS: Because it will-�
JJ: It would swamp the network.
HS: Fall over.
JJ: Right. But we do have, you know, our plans for our next campus upgrade include all the things that I was talking about before when we were talking about the basic infrastructure, as far as the right kind of switches and the right kind of backbone to actually be able to add the capacity and the Quality of Service we need to do it. But the bottom line is, yes, we were talking earlier about what do we think the new applications are going to be that'll be supported, and I'm not sure that it's going to be brand new applications, but it's going to be more that some of the applications that we think about as special things - you know, you go to a videoconferencing building or something like that - instead are just going to become pervasive. So instead of just picking up your phone, you'll probably do a videoconference. Or in classes, when you're trying to bring in a guest lecturer, instead of flying them in from someplace, you'll probably just bring them in over the network. It should be a whole lot easier to get someone to agree to lecture to your class if it takes them two hours instead of two days.
HS: But doesn't that sort of give us the videophones that people have been talking about for decades? I mean, if I have a camera sitting on top of my PC, if I have IP telephony through my PC, then when I call somebody up, I just turn my camera on, they turn their camera on and we have kind of a videophone.
JJ: That's exactly what you get. You know, for that kind of application where you really just want to see the person a little bit, one application that's really nice for that, which is very cheap to deploy, is Microsoft NetMeeting. And it adds some extra features that I really find powerful, much more powerful than the video part is the application sharing.
HS: The little whiteboard thing?
JJ: The whiteboard-�
HS: Oh, sure, and the application sharing. Yeah.
JJ: Actually, the application sharing, so if I'm working on a talk or a paper with someone, I can talk to them on the phone but we can pull up the Word document or the PowerPoint. We can actually sit there and edit it and-�
HS: Yeah, they can sort of reach their hands across the network.
JJ: Right, you can both edit. You can share the thing, you can both see it, make changes. It's very effective for that. You know, the video is okay. NetMeeting's not really designed for high quality video. But the application sharing and the ability to talk is really useful. I think you'll see that used a lot in the future.
HS: Yeah, I mean, I think that the thing you described is much more useful than just seeing somebody's face, but I suspect that since campuses tend to have lots of students on them that students are going to call each other and turn the video cameras on. It's going to become, as more and more machines are equipped with cameras, that's going to become the way that you call people. Why not turn the video on? And it seems like that is going to put a huge number of packets onto our networks.
JJ: Well-�
HS: Just turn on all the cameras all the time.
JJ: Sure, but you have to be careful before you start panicking too much. I mean, if you're moving to a switched network where you're going to have at least ten megabit switch ports - which I think is at least everyone's goal. Most people are installing 10-100 networks. And you've got the backbone to support it, an application like NetMeeting, you know, when you're talking even with the video camera turned on, it's typically just burning up a couple hundred kilobits per second. It's not doing a lot of capacity. I mean, it's lot if you're on shared ten megabit hubs. It's only practical to have a few of them running. But as soon as you've got a switched network and you've done an upgraded core, you know, something based on gig Ethernet or trunk, you'll probably have plenty of capacity on campus to deal with that.
HS: Okay, so that suggests, though, that people who right now have shared networks to their dorm ought to be thinking about switched rather than shared.
JJ: Yeah, and I don't think that's a surprise to anyone. I mean, most of your network managers are probably already planning or probably already implementing plans to be upgrading anyplace that they still have hubs to switches.
JB: Let me just interrupt here for just a minute and remind our listeners that any questions they'd like to send in to you can be sent to expert@cren.net. And that way I can ask a question, too, Jim, and that is just, you know, where are you at Virginia in terms of upgrading your core network and what speed do you see yourself upgrading to in your next upgrade?
JJ: Well, we're hoping to do, as far as the core goes, we're hoping to have that procurement done sometime next semester and start on the upgrades. Our current network is an OC 12, basically a 622 megabit ATM core and our target is to move, instead of ATM, to move to layer three switching and start off with gigabit links on the backbone. Hopefully as soon as the standards are finished, we're going to try to buy equipment which will take ten gigabit links so that the upgrades are relatively minor.
HS: Are you making much use of Internet2?
JJ: A fair amount. You know, it depends on your definitely of that. You know, if you talk about the number of researchers who know they're using it it's probably pretty hard to quantify. But if you focus more on just general use, you know, we get a fair amount of traffic over it. A lot of applications such as videoconferencing and some of our research groups have stared, you know, where they've got collaborations going on with equivalent groups at other institutions, have started doing videoconferencing with them and that's made a big difference. It's avoided a lot of travel and made things more productive.
HS: Is convergence going to push that? As we put more and more video on our networks. I mean, one of the things that universities do is they tend to share stuff so as we get video on our networks, it seems like we're going to be sharing it. Is it really going to take Internet2 to share it?
JJ: Again, it depends on what you're trying to share. If you're talking about videoconferencing, I don't think that that's practical right now without Internet2, although if you have multiple institutions on the same Internet backbone provider, you may get enough throughput to make that work. If you're talking about shared video, do you mean like video clips and materials?
HS: Yeah.
JJ: Sharing that. I think the harder part, you know, assuming that you're on Internet2, the harder part is what you were talking about earlier, the ability to have the right licenses in place to make that happen. But certainly if the institutions own the materials and want to make them available, if you have Internet2 right now, it'll work fine as long as you've got the right kind of servers and things in place.
HS: How is this convergence going to play on PDA's, even on laptops, which are less powerful and net appliances and things like that? Are those things going to be powerful enough to take advantage of this?
JJ: Well, you have to start to think about-and I think this goes a little bit back to your question on wireless and, you know, what about all the digital cell phones and things like that. If you talk about PDA's, where the convergence is probably happening there is more probably in the wireless space than in the wired space. Having the ability to be able to get to your data and things like that while you're wandering around as opposed to having the hot [inaudible] and be able to access the data. But the newer Codex that are capable of doing high levels of compression, you're starting to see people announcing wireless based video streaming services, or at least claiming the capability to make that happen through PDA's and lower powered devices like that. So I don't know that the kind of convergence that we've really been focusing on as far as what you need to do for your campus core to be able to support these things is directly applicable to PDA's, but more on what you're going to do and what your wireless strategy is on campus is going to make a big difference there.
HS: Does this thing fit in with this wireless application protocol?
JJ: Right.
HS: I mean, this is supposed to put the web on your mobile phone and that kind of thing.
JJ: Yeah, I mean, that's really what we're talking about. The ability to use your wireless phone to also be able to get at your data applications and be able to do web clipping, you know. Web clipping is the idea of being able to get information out of a web page as opposed to try to actually display the whole web page on your cell phone. But that's what the wireless application protocol was all about, being able to get those materials to you.
HS: On some-�
JJ: On some kind of a portable device.
HS: Right, on some little tiny screen.
JB: What about the idea, Jim, as we talk about convergence, I think one of the interesting things about where you are is that how do you manage all these three infrastructures? We started talking about, you know, the voice and then the data networks and then the videos as three separate infrastructures. How might a university look at managing what's happening in this space? Do they converge organizations to do this or what suggestion might you have?
JJ: Well, that's probably the harder question than the technology even in that, I think, most campuses or at least many of them still do have completely separate organizations, sometimes not getting together until you get to the very highest levels of the university. And in order to make this happen, they really need to be working together. So if you're going to try to merge your voice traffic on top of your data network and move your video on top of the data network, having three organizations is going to make that very hard to do. There's a lot of interesting financial pieces that fit in place with that as far as, you know, people are used to paying for telephones but on a lot of our campuses, they're not used to paying for data, so how do you handle that and how do you still pay for things?
But I think it goes even further than a lot of campuses, even further than just the three organizations in that there are many campuses where the network within the building is actually run by the department so while a central organization might be handling the backbone and a department in a building might pay to get a connection to the network backbone and get DHCP and mail services and things like that, the network itself is run by the department. But in order to make these multimedia services work well, you really have to have end-to-end management so you have to have the ability-if you're trying to do Quality of Service, it needs to happen such that the traffic is classified where it's injected into the network on the telephone and then that kind of policy management and mapping happens all the way through the core into the network and actually to the jack at the other end. And people/campuses need to start thinking about their network probably more in terms of power and water as opposed to things that are run by not necessarily even three but four or five different organizations or three organizations plus the department.
HS: So you're saying that the IT organization actually has to go over to the Computer Science department and tell them that they want some say in what their network looks like? That's a scary prospect!
JB: I didn't say that, did I?
JJ: You know, I don't know if "say" is the right word, but if you really want this to work, you need some way where everyone agrees on what the policies are. I'm not talking about policy in terms of a written document, but how the network policies are enforced and having the right kind of hardware and having consistent hardware. You know, if you have one brand of switch in this wiring closet and a different brand in this one and those vary all over the campus, chances of being able to do centralized policy control and centralized Quality of Service management to make all this stuff actually work is going to be very challenging.
HS: Do you even run into folks trying to agree on what things should have priority? I mean, when you try to do Quality of Service, you're giving priority to some things. Is that easy to get agreement on?
JJ: Well, I think that the definition of what needs the priority is pretty common. I think everyone understands that real time traffic like your telephone especially and if you're doing videoconferencing for classes or for research projects, that that needs priority over bulk file transfers. Where you'll probably run into trouble is for some forms of specialized research applications where they need probably as much capacity as you have or at least they need to be able to burst that high and not having that capacity may or may not cause problems for them. So I think, you know, if you take again the very high level view, get up on top of a mountain and look down from 10,000 feet, I think everybody probably will agree on what the applications are but the devil is in the details when you get to one or two specific exemptions that make life hard.
JB: In terms of where your network is right now, you mentioned that you're going to be upgrading over the next year, 18 months, Jim. If a campus has a network now which is at one of the - say the 100 megabit level, for example, are there some of these applications that they could experiment with and do some pilots to kind of get some experience with this, say the video over the network?
JJ: Yeah, I mean, all these applications will work. It's just a question of how well. If you have enough capacity available on your network, then you don't need Quality of Service. It's the standard argument, but if you want to guarantee that they're going to work the way they're advertised, you need something like that.
HS: Yeah, but the opposite is true, too, where standing up on my mountain over here I see six videoconferences occurring simultaneously and trying to decide which one is more important. I mean, if you have tons and tons of capacity, not a problem.
JJ: Right.
HS: But if you don't, all of a sudden it's impossible to make that decision. They're all important.
JJ: Yeah, and you know, you often hear arguments that implementing Quality of Service without implementing charging for it is something that doesn't do a whole lot of good for the exact reason you mentioned. If your network is horribly capacity-starved, then you really are making decisions between who is allowed to use the network and who isn't. If you're thinking about Quality of Service in terms of giving priority to applications like voice as opposed to other things which are very low capacity-needing but have very high constraints on delay and jitter and things like that, it becomes a little bit easier. I mean, fundamentally, if you don't have enough capacity to support these applications, then you really shouldn't be trying to make them work.
HS: How do you know? Are there measures that tell you when you're under capacity or things that tell you when you have enough capacity in terms of planning? How much capacity do you need?
JJ: Well, you have to put on your wizard's cap and make a guess and I'm just sort of joking, but your network management tools will tell you-�
HS: People are going to be asking us where we can get one of those things.
JJ: Right, exactly. I mean, your network management tools will tell you where things are right now, but as far as knowing how much you need a year from now, it really depends on your best guess as to how quickly you think the newer technology will start to get used heavily on your campus. You know, if you've got an initiative to do more distance education or if you've got an initiative to start doing a lot of case materials over on demand video, as part of the planning for those projects, you should make sure that you've got the network capacity to and from where you need it to be to make those things work. Quality of Service can help solve momentary shortages and things like that and it can help make sure that applications that are critical happen, but it doesn't solve the problem fundamentally of not having enough capacity to meet the needs of the users. You still have to do that.
JB: Going back to Michael asked earlier in one of his questions that I'm not certain we answered, is Quality of Service real? I mean, is it happening today? Is there sufficient tools, software, etc., to really implement a Quality of Service network today on campus?
JJ: Yes, if you're installing new equipment now and you buy wiring closet equipment that does P and Q and you buy core equipment that has the ability to put different types of services in the type of service field in the IP header, different queues, you can do a relatively good job of Quality of Service. That's not a technology that guarantees a certain amount of throughput from point A to point B. It's not RSVP which would actually do that. But as far as having a network that practically-again, you know, if your network is hopelessly out of capacity, that won't do you a lot of good. But if you've got a network that has about the right amount of capacity and you implement those features, you really do get something for it.
HS: Could you just tell us some of the key vendors who are in this whole convergence area that are doing some of this video streaming and things like that?
JJ: Yeah, I mean, on the video side, it really is a little bit different between the video side and the audio side. On the video side, for on demand and for broadcast type stuff, I would just tend to look at the big three. So if you look at Apple's QuickTime and RealNetworks and Windows Media, those are good, relatively cost effective ways to get into both stored and broadcast video. In all those cases, you need a server and some software, but there's nothing horribly expensive. It runs on PC class machines and works pretty well. They do have different business models so depending on whether you're expecting to go to a large number of people, you probably want one of the technologies that doesn't have per-stream licenses. So there are tradeoffs and you need to do some homework. But I'd probably focus on those. Those are easy ways to get started.
HS: Okay, and for IP telephony?
JJ: Well, IP telephony, Cisco and ThreeCom along with all of your big PBX manufacturers are probably the ones to look at. So Cisco, ThreeCom, Lucent, Nortel, they all have lots of offerings in that area. And for videoconferencing, I'd look at VCom and PolyCom, those are the two we use, although there are plenty of other ones available also.
HS: How fast is all this going to happen? If we were to do this thing again next year, would we be talking about convergence as something that happened in the past?
JJ: No, I think it's something that you'll see happening over time. There are very few places, and I'm not even sure I could rattle off any institutions of higher ed that have done monster implementations of voice over IP, although I think a couple campuses are starting to do some of that now. The best way I'd probably think about it is as you're doing your next network upgrades, you should be planning to make sure that the network upgrade that you're doing has the basic characteristics to support multimedia services. And then, as your users start to take advantage of it is when it will grow.
Over time, I think it's pretty clear in my mind that you'll start to see lots more network video and video type services running over the data network. The jury is probably still out on how much hardwired IP phones you'll see vs. wireless vs. soft phones which are running basically on your PC. But it's something that you'll be seeing over the next two to five years, but the thing that I'd reemphasize is everyone has a cycle that they run through as far as how they're planning to do the next generations of their network. And the critical thing for multi-services convergence like this is, as you're doing the planning for your next generation network, you want to make sure that you're putting in the kind of infrastructure that you need-in other words, multicast support, Quality of Service support and sufficient capacity to start supporting these applications. Then it's a matter of getting your users up to speed and finding the early adopters who will do it.
HS: So you're telling folks the first thing to do is get your network in shape before you try any of these applications and then IP telephony might be the first one you're going to try?
JJ: Well, I'm not sure I would phrase it exactly that way. If you have sufficient capacity on your network, which most people probably do to some extent, there's no reason not to do most of these applications now. I don't think I would do-as long as you have in the back of your mind and you know what you'll need to do to support it when it grows to a large scale, you're probably in good shape. I wouldn't do a large scale IP telephone deployment until I had taken care of a lot of details like making sure that I had very reliable network management, that I had power--you know, the right kind of power and cooling in the wiring closets. You know, if you're going to take out all of your telephones, that really is a life safety thing and you need to have the redundancy and the operational procedures in place to deal with it.
For example, on our telephone side, our people respond to a single dead phone within two hours. We don't right now have that level of support in our data network and probably won't for quite a while. So there are a whole lot of different pieces that you need to put together, but there's also a lot of low hanging fruit. You know, there's a lot of things that people could be doing right now without having everything in place and get some big wins.
HS: Tell us about the low hanging fruit! Which things can we get our hands on easily? JJ; The ones I like to think about are videoconferencing and the ability to do video, some level of video broadcasting and store video. Those things are all doable now. Most of our networks probably don't have the capacity they need if everyone's going to do them, but the reality is it always takes time for people to get up to speed on those things. For voice over IP, if you're doing it for something like toll bypass, you know, so if you've got a network that runs across your state that works relatively well-which a lot of state networks do-running voice over IP traffic over that is perfectly acceptable. If there's a problem with the voice over IP for some reason, people in the remote locations can still place a long distance call and it'll work well.
Telecommuting, and if you've got voice over IP phones, the key difference between a voice over IP phone or at least one of them and a regular phone is the phone number is tied to the instrument instead of to the jack in the wall. So if I've got a reasonable network connection at home, if I just take my voice over IP phone with me and I want to telecommute, it's my phone, my phone number, I'm not just trying to keep up with messages. It really looks and feels like I'm in my office. There are a lot of applications like that if you think about call centers and transcriptions and things like that that you can do before you have a network that's fully able to do that everywhere.
HS: Okay, I think we're more than out of time here, but whoops! I think, shall we get this last question in, Judith?
JB: Which one?
HS: From Bill Miller.
HS: I think he was asking about why we weren't doing video earlier?
HS: No, he actually has a question here.
JB: Okay, let's go!
HS: Okay, this will be the last question here. He says, "Do you have any experience using H.323?" Know anything about that?
JJ: Sure.
HS: He says a few more words about it, but that's basically what he wants us to chat about.
JJ: H.323 is the standard thing that you're going to use for videoconferencing and until recently, it was pretty much how all IP telephones worked, although there are some newer protocols called SIP that are starting to take more and more in the IP telephony world. But when I was talking about videoconferencing of some of the things we had been doing, for example, using VCom hardware or using PolyCom systems or NetMeeting, those are all running H.323. So H.323 is basically a videoconferencing standard and it's also how most IP telephony still works right now.
JB: And that's the standard you used when you were talking about that point-to-point videoconferencing with the seminar teaching?
JJ: Right, the seminar teaching was all using H.323. The voice over IP stuff that we do right now on campus and some of our remote locations is all H.323. And Microsoft NetMeeting is H.323-based.
JB: Yeah. Bill's comment actually goes on to say that they use that for videoconference of experts and then stream it for a class or public to see, which is kind of an interesting idea. That way it says it enables a class to view experts from various locations as they discuss a topic, and then they do combine a chat session for interaction. That's an interesting way of mixing media.
JJ: Yeah, that really is. I bet that works well.
HS: But isn't that - I mean, it's true that as soon as you have something on IP, you can archive anything because we're just collecting the bytes and so once it's in that format, it's easy to archive.
JJ: Right.
HS: Of course, people will be tempted to do that. We will fill up all the available disk space in the world.
JB: Right!
HS: But it's kind of nice that you can do that.
JB: Yeah. Well, Howard, I think we probably should kind of wrap up. You know, we've got the folks in Michigan that barely-�
HS: They'll never get home tonight!
JB: They'll never get home tonight, right. Do you have a final comment or question that you would like to make?
HS: Yeah! Jim, in just the ten seconds we have left - isn't that the way they do that on TV? You only have ten seconds left.
HS: In the ten seconds that we have left, what's next for convergence?
JJ: Well, what's next? Probably more of the same and I guess what's next depends on what each campus has already done. In our case, it's focusing on the network core to make sure that when we get more and more users of the applications, that we'll be ready to deal with them. So instead of, you know, I'm not going to try to guess at what the next new big application is. I think we've talked about a lot of things that have the potential for that, but what's next is probably making sure that you're ready to meet the demand when it hits.
JB: Okay, so getting your network ready and maybe getting your organization ready?
JJ: Right.
JB: Okay, great. Howard?
JB: Okay, all right. Well, I would like to - let me thank everyone for being with us here today and for the good questions that came in. It is time for our closing notes and I'd like to note that - good news/bad news - we're going to be taking a holiday break here. I think everyone's going to be spending a lot of time with family so we'll be starting our Spring 2001 session on January 11th. So please watch for the announcements in the web pages for the upcoming experts. Some of the topics we'll be looking at are XML, firewalls, electronic books, video applications and more, so-�
HS: Lots of stuff I have to brush up on!
JB: Those are the things, right, over Christmas, Howard! Many thanks to all the institutions who support the Tech Talks and also to Apple for their special support of this Tech Talk, and be sure to check out some of the URL's for Apple's QuickTime and the latest that they are showing on the event page today. Thanks to all the Tech Talk folks who helped make this event possible today, and for Terry and his four wheel drive for getting our digitizing expert right there just in time! A special thanks to our Tech Talk expert, Jim Jokl; to technology anchor, Howard Strauss; to Terry Calhoun, Tech Talk web guru; to Jason Russell, to Gayle Terkeurst and the support team at Merit Network; to Susie Berneis, the audio file transcriber-which will be up, most likely, in a week-and finally, a thanks to all of you for being here. You were here because it's time. Bye, all. Jim, Howard. Have a great holiday. Bye everyone.
HS: Bye, Judith. Bye-bye.
JJ: Thank you.
JB: Bye-bye.
END OF WEBCAST
