Carl Malamud: Internet Talk Radio, flame of the Internet.
Malamud: This is Geek of the Week. We’re talking to Don Hoffman. He’s a senior staff engineer at Sun Microsystems. Welcome to Geek of the Week, Don.
Don Hoffman: Thanks.
Malamud: You’re in the advanced multimedia networking group at Sun, and I understand you’re in the process of building a laboratory to deploy multimedia for yourself. You’re trying to bring some technology out of the research labs and begin using it within Sun.
Hoffman: Yeah. A lot of what’s happening is certainly people have been making extensive use of tools like nv and vat on MBone. And there’s some limitations to the Internet environment there where we’d like to say do higher-quality video, or a lot more audio. But we’ve run into a thing recently thing with a lot of people doing video, it’s starting to put a lot of pressure on the capacity of the Internet. These sort of limitations you don’t run into in say a campus network environment where we have hundreds of megabits of bandwidth running from one end of campus to the other and between say, campuses here in the Bay Area. So what we’re trying to do is take a lot of the technology that’s already available in the Internet world and bring it into the corporate Internet environment.
Malamud: So what do you have in mind? What do you view your own personal computing environment looking like in a year?
Hoffman: From our point of view, there’s really I’d say two main applications. Actually, one of them tends to be sort of a one-to-many application. You know, in the Internet world you sort of see the IETF broadcasts of taking all the various IETF working groups and sending them out into the Internet. Here for instance we can do similar things. We can take seminars that are being offered say by the Sun U group. We can take say, satellite— One of the things we have is we have connected to a standard satellite broadcast receiver, and then we can now be rebroadcast this on the internal engineering network.
Malamud: Now doesn’t that take a lot of work? I mean, producing TV is not a simple thing to do—
Hoffman: Well that’s the point is— Right now we’re taking either things that’re already produced. Like for instance the Sun U people have already put together course material—
Malamud: Sun U is the internal—
Hoffman: Internal training, yeah. For internal people, and also say for people from outside of Sun who wanna come in and get some training about Sun technology. And so they’ve already produced a lecture series. Somebody who’s used to speaking in front of a large audience, they already have prepared materials. It turned out to be not very difficult to take that and just put a camera and some networking infrastructure in the room and redistribute that around the Sun network.
Malamud: Now that’s just TV on a network. I mean, you could’ve used a coaxial cable, an internal cable system to do that. Why would you run that on a computer network instead of using cheaper technology?
Hoffman: Well in our case it actually isn’t cheaper. We would’ve had to— The idea is here to get to everybody’s desktop— This seminar, for instance. We would’ve had to put in, into everybody’s office, an additional parallel network, another TV, another CRT, more stuff on the desk. Instead what we have is we can use the existing network. And the existing workstations. So our goal here is to not it would require an additional add-on card on the desktop that you’re using to view this but whether we can run it on a standard Sun workstation, software-only decompression. Much like we’re doing with nv today.
And so what you see then is I can take any workstation and down the hall here, we could walk up to and I could now show you say CNN that we’re picking up off the satellite antenna. The same sort of technology would be used for instance for the Sun U class.
Malamud: Okay, so you hook up your local training facility with some video broadcasting equipment. You have a satellite dish on the roof—
Hoffman: We have a lot of different sort of feeds we can use. The Sun U, we have— One of the groups here, it’s human interface group, is setting up a special studio so the Sun U people can go in and produce…take their standard stuff and present it in that studio.
One of the things you run into, I think a lot of experience we’ve got from say the IETF broadcast is that lighting and the training of the cameraman makes a lot of difference. Bad lighting…you know, people can’t see the slides, the camera— One sort of annoying thing that often happens in a lot of the IETF broadcasts is the cameraperson is panning back and forth between the speaker and say somebody asking a question in the audience. And the nature of the compression algorithms causes the image to break up really badly. And so by having trained camera operators and rooms where you can sort of do cuts between cameras, we can improve the quality of the presentation.
Malamud: Now this means you have to hire trained camera operators and lighting technicians. Is this the kind of employee that Sun has to hire now to do this?
Hoffman: Well generally you do need to have— We’ve always needed to have somebody trained in operating the cameras. If for no other reason than high-end cameras are rather complicated to operate. It’s not like a Sony minicam where you just go plug it in. And so really the additional training for that person is probably not that great.
The room for the presentations is fairly… Well, it’s set up ahead of time and so the lighting tends to be fairly static. We don’t need to redo the lighting for every presentation. It tends to stay the same way. So there’s a fixed lectern, fixed lighting…
Malamud: When we hear of video conferencing on computer networks, and when we hear of things like Internet talk radio, a lot of the press looks at and says “Ah, this is bringing the technology to the masses. This is personal broadcasting.”
Malamud: And what I’m hearing here is that if you’re gonna do video, and you don’t want it to look like a home movie, it’s not the kind of thing that you slap together in two seconds and you’re a TV station broadcasting to the world. It’s just as complicated in the computer world as it is in the… [crosstalk] 3D world?
Hoffman: Absolutely. In fact there’s a lot of I think parallel with other ways of communication. When an easy way to prepare graphic slides became available, there were a lot of bad slides, and a lot of—you know, desktop publishing became possible and there was a lot of really bad newsletters. And as people gained experience, they starting becoming sort of literate in the style of doing say desktop publishing and preparing newsletters that actually looked good.
And I think we’ll see the same thing on the video side. That right now, you know, the standard way is you stick a camera down in front of the guy and he says what he’s gonna say. But people will start becoming more literate in the style of producing video material.
Malamud: So you think just as people can now recognize a 150 dot-per-inch dot-matrix resume, they’ll be able to recognize a home video 8 millimeter poorly lit.
Hoffman: It wouldn’t even be surprising that say a lot of the college curricular communication would include how to produce videos. You know, right now people learn how to write in college and they learn how to do presentations. Well why shouldn’t they learn how to do videos also.
Malamud: Don Hoffman, we’ve been looking a lot at multimedia networks. Maybe you can tell us a little bit about the affect of multimedia on a computer network. Do we have to do things differently on the network, or is this just more bandwidth and faster processors?
Hoffman: Well in fact it actually turns out to be all of the above. It’s generally in the case of computing that you find and fix one bottleneck and another one pops up. And so in order to do the things we’re doing internally within Sun, we’ve had to do both. We’ve had to increase the bandwidth. Although, the current generation of our backbone is an FDDI-based backbone. So we’ve increased the bandwidth a reasonable amount, but also we need to do smarter things. So for instance our corporate internet is not all FDDI. So for instance, the final part of the network into my office is still Ethernet. So we need to start looking at a smarter mechanisms, the router between the FDDI network and the final leg do things like resource management and bandwidth limitation.
Malamud: Now, you have ten megabits coming to your desktop and you do a lot of video conferencing work. Is ten megabits enough?
Malamud: Barely. Is a hundred megabits enough?
Hoffman: A hundred megabits… For instance right now for one-to-many style video, a hundred megabits is actually plenty. So here on campus, let’s say even if we had half a dozen at any one time groups producing a one-to-many video show of some signal of some sort, an FDDI network for instance could probably handle that using say the current level of video we’re able to do on a workstation. That is say less than ten frames a second, 240 by 380 resolution.
Malamud: Are we gonna always want more bandwidth? Or is—
Hoffman: We’re always gonna want more bandwidth because what happens is I show this quality of video to people that are say, a little bit more…video-aware, such as the MPEG people. And they look at it and they just sort of pff, this is not video, this is…toys or something like that. But it’s still very useful. So for instance, for me to be able to stay in my office and see some sort of training module, that’s useful to me and so I’m not necessarily concerned about the quality of video.
Malamud: But at some point you’ll get the quality you want—
Malamud: An HDTV stream is what, twenty megabits per second?
Hoffman: I don’t—probably a little bit more than that, depending how much compression.
Malamud: Would 600 megabits to the desktop be enough forever? I mean, are we going to continually want more bandwidth or is there an end in sight.
Hoffman: Um, I don’t think there’s ever going to be an end in sight because then you start proposing things like virtual reality and that sort of thing. And I think it was… The idea’s that I think it was…Norm Schryer at Bell Labs was talking about the idea of having drones you send out. So instead of actually going somewhere on vacation you send out a drone. Imagine the sort of bandwidth you’d need to do that sort of thing.
Malamud: A virtual vacation.
Hoffman: A virtual vacation, yeah. And so, you can always sort of say that well—
Malamud: That’s an awful thought, you know.
Hoffman: Yeah I know, I know.
Malamud: Like, we’re unable to give you your vacation this week, Don, but we’ve allowed your computer to take one instead.
Hoffman: Well, But the thing is you won’t have to sit in the airplane for all that time, so.
Malamud: And the computer would send you a postcard.
Hoffman: Right, exactly.
Malamud: Don Hoffman, we’ve been looking a lot at multimedia technology again, and part of that is the underlying infrastructure of the network. You’ve talked about an FDDI backbone, and that that’s probably not enough for the future. Is ATM the technology that you’ve spotted as the one that’s going to solve all our problems forever? Or…
Hoffman: Well there’s some nice things about ATM. It isn’t all there yet. And so if we took ATM that I could buy off the shelf today or even in the next year, I don’t think it’ll solve all of our problems. But ATM offers the possibility… It offers a platform where one could solve a lot of the problems, say in the next three to four years.
Malamud: But today, is it a wide-area network? Is it something I could use for putting a virtual corporate backbone in place?
Hoffman: The main thing ATM offers today is the bigger pipe. And there’s a lot of people doing research on congestion control and resource management in the network. And I think in order for ATM to be a complete solution we’re going to need to see that sort of work make its way into the products. So today, I can go to Synaptics and buy a switch, and a very good, fat pipe that handles the LAN environment very well. Other vendors more on the telephony side are offering ATM switches that sort of deal with the wide-area networking well.
Malamud: Do you have to change your software in order to go let’s say from an Ethernet to an ATM environment? Does ATM give you everything that Ethernet gives you?
Hoffman: Well, in fact this is a big discussion in the ATM forum about ATM LAN emulation. Because there are a lot of features in sort of standard…the way we we’ve seen LANs is they tend to be intrinsically broadcast and multicast-based media. And so for instance you’ll see that in Ethernet we can do something like multicast or broadcast— It’s sort of standard, it’s easy to do. In ATM it’s a bit more difficult. And so some of the problems they have right now is we’ve— At least in the Internet world, we’ve defined a certain model of multicast that works very well on the Internet wide-area network, and then on the final LANs like Ethernets and token rings. It’s going to take a little bit more work to take that same approach and fit it into the ATM environment.
Malamud: I mean, how do you do it? Do you set up a virtual circuit with everyone you’re talking to, strictly for each multicast address, or—
Hoffman: There’s a lotta discussion on this. There’s really several ways the problem could be solved, and I don’t think any one of them is the obvious winner right now. One is to say that…well, you change the multicast model. I mean, the current ATM forum specifications have really the idea more of a source-control multicast, where the source sort of sets up the multicast group and decides who the members are.
Malamud: So a PC wakes up on the network, is looking for its operating system from a remote server. It’s got to have enough smarts to know the names of the servers ahead of time, I guess.
Hoffman: But—as I said if a PC comes up and wants to join a training class, it’d have to contact the broadcasting machine and say “Add me to the group.” So it’s source-controlled. Unlike say the IP multicast model, where the receiver just basically joins the group. It doesn’t have to ask permission from anybody. So that’s the obvious way one would do it now, when we’re doing a multicast-style of application on the ATM network.
Other people are talking about having resequencer servers where the source is sending out packets to a resequencer and it’s then redistributing it to all of the stations that want to receive the multicast.
Malamud: So a reflector of some sort.
Hoffman: Reflec— [indistinct phrase] reflector. In which case even then— So you really only have to go establish a relationship with the resequencer or reflector.
Malamud: It’s important to understand of course that multicasting is used not only as a way of joining a video conferencing group, but at very low layers for things like advertising services and—
Malamud: It’s a very basic part of the LAN environment.
Hoffman: If you look at all the tools what we have available on the internally today, they all really rely very heavily on multicast technology. And they rely very heavily on the style of multicast technology avail—the IP multicast available today. And so we’re gonna need either rethink the basics of multicast, or we’re going to need to basically make ATM emulate that. And so I think what Steve Deering said that well, ATM’s only gonna succeed if it actually supports the style of multicast that we have in the Internet today.
Malamud: Now, what— The Internet multicasting is using a wide-area IP-level multicasting technology. Which assumes in order to work effectively something at the local area network that’s efficient for moving information out. Why if you have IP multicasting in a wide area, why can’t IP take care of those problems? Why does ATM as a data link layer, as a wide-array of cloud, also have to do the same thing?
Hoffman: Well, one of the advantages given to ATM is that it lowers the barriers between the local area network and the wide-area network. And so many people are proposing that in fact we try to have end-to-end ATM. And so it’s… I think there’s a lot of discussion on this. Whether we sort of say that the ATM network really becomes the Internet… And in fact a lot of people even propose taking some of the technologies [indistinct] the Internet and trying to move them down [crosstalk] in the ATM fabric.
Malamud: Exactly. That was my question, is if you’ve got multicasting at the ATM layer, why do we need IP at all? I mean is the Internet gonna go away and be replaced by an ATM cloud?
Hoffman: That’s quite possible—not anytime soon, of course. But that would be the fantasy a lot of people I think would have. That by taking the functionality we have today it in the Internet, moving it into the ATM network fabric, we’d get the advantages of end-to-end ATM but the flexibility of the Internet. Plus since you are using an Internet architecture you have a much easier way for you to migrate between the two environments. Because the problem now is if you sorta said well, we’re only gonna use end-to-end ATM mechanisms, you’d cut out a lot of your current population because you know, even for the next years it’s gonna be relatively expensive to get an ATM connection.
Malamud: Is it realistic that we would ever get rid of [crosstalk] Ethernets and token rings and…
Hoffman: No, in fact there’s— Well… I mean, it’s not realistic in the next ten years.
Malamud: I mean, I could see putting an Ethernet connector on my home toaster, but I think ATM on my home toaster might be a little much.
Hoffman: Right. And so you’re going to continue to need the Internet approach, which assumes some level of heterogeneity in your network.
Now a lot of the problem, though, is still a lot of the architect—a lot of the work we’re doing now assumes meshes that are not as fully-connected as you might have in say and end-to-end ATM environment. So in an end-to-end ATM environment you’re going to have basically a virtual connection between every pair of communicators instead of the simple model. And so it’s a little bit different today where I do at least a little bit of traffic aggregation, when I cross say some of the… So for instance here in the Bay Area, all the Sun traffic goes through one link into Barnett. And so that really looks like one virtual…it’s really is one virtual circuit from the point of view of Sun.
Whereas if we were to have end-to-end ATM fabric, now all of a sudden we’re setting up virtual circuits willy-nilly all over the place and now the whole issues of routing become very difficult. The issues of how do you set up a multicast group that’s made up of thousands and thousands of virtual connections. It’s not necessarily clear that what we’re doing today is going to be able to transfer over to an end-to-end ATM environment without some major changes in the architecture.
Malamud: As a developer of software for your base platform, basically the network is now part of the operating system. How do you choose which of the things from the research world or from the public domain world actually get implemented in your core software?
Hoffman: Well that’s actually really hard to do. What you see a lot of times is we start a lot of efforts… We start a lot of efforts, and so get ’em the prototype stage. And when it comes time to decide whether we make it into a product, we say well no we don’t. And I can’t think of anything off the top of my head right now where we would would’ve said no, but— Well I think an example is that in some cases we’ve actually taken things all the way to product and they have actually succeeded as much as we might expect.
Early days, I actually started out at Sun developing OSI software. And in some sense we probably spent as much engineering effort implementing OSI software as we did on the Internet stack. Because we had it a little bit easier because we were using a Berkeley software base. We got a lot of the Internet networking software essentially for free, and most of our effort was optimizing it for the Sun platform, bug fixes, that sort of thing. And so we had an engineering team actually larger than the Internet team developing OSI software. And we actually took all that to taking some early research work—this would be in the early 80s—taking some research work from BBN, moving it over to the Sun platform, adding some additional stuff of our own, actually sent it out the product and yet we found that it never really sold the way we expected it to.
Malamud: Have you tried giving it away?
Hoffman: Well in fact— A good sales rep often will arrange things that way, where the cost of the software is hidden in the overall cost of the deal. And so from the point of view of the customer it appears that’s it’s being given away.
Malamud: Was OSI really hard to implement? I know that’s a softball question, but uh— [chuckles]
Hoffman: Yeah. I mean… No actually it was not very hard to implement. I think in any protocol it’s always easy to sorta get something basically running. There’s nothing particularly difficult about say…oh, session layer and below. Now I wouldn’t say the same thing about some of the application layer’s protocols. I think anybody who’s tried to implement an ASM.1 encoder and decoder knows that that’s not necessarily a simple thing to do. But say CLNP is actually very straightforward. I actually did the actual coding in probably less than a week. That was of course starting from the Berkeley IP implementation using essentially the same approach and just changing the— There’s really not that many differences and so the implementation was actually fairly quick.
Malamud: If it’s so straightforward, why aren’t we looking more seriously— I know some people are, but there’s the division in the Internet on the use of the connectionless network services, the next-generation IP. And if it’s such an easy change in the code why isn’t there a real strong movement saying gee, just give us TUBA, it gives us bigger addresses and it’s an easy upgrade.
Hoffman: Well— Historically a lot of the difficulty came from the fact that at least in CLNP, the addressing was too flexible. And so we spent a lot of effort in trying to come up with mechanisms that would sup— We’re a platform vendor, number one. So we have to provide a platform that can support all the likely addressing mechanisms that somebody would want to use in CLNP. Well, at least at the time we’re talking about, mid/early 80s, it was not quite the— We didn’t have something like IETF who could’ve said well there’s this one address format that you need to support. So in that case, it was just difficult to put together an OSI network because you really had to be an ex—you really had to design your own addressing approach.
Malamud: But even today, Sun for example is one of the leaders in the SIP effort for a new-generation IP. You’ve put all this money into doing your CLNS implementations. Why in the world are you inventing a new IP when you could’ve reused this ISO code that’s still sittin’ around that all these engineers developed?
Hoffman: Well. I mean a lot of it was that there weren’t really any advantages…at least in the technology we’re looking at there weren’t really any real advantages to cause us to go through all the tr—other than sort of more flexible addressing, we didn’t see a whole lot of advantages to CLNP. And neither did a lot of our customers. Why move over from a perfectly functional and robust networking platform to something else that didn’t really give you any advantages. So for instance, why move over to X.400 when you had something like SMTP-based mail. It worked perfectly well. What was the motivation?
And I think what we see today is that… In the case of SIP there’s actually some new concepts in there, some simplifications. And instead of making things more complicated, we made things simpler. I think that’s one of things we realized, that at least below a certain layer in the protocol abstraction simplicity is better.
Malamud: It’s a RISC approach to network—
Hoffman: A RISC approach to networking. And I think that’s been a lot of what’s driven SIP, is to try to sort of take some things that were simple. Now you can do, of course— CLNP can do everything in the world but, it’s not necessarily the case that it’s simple to do. And so I think you see SIP sort of saying what are the top 80% of things we want to accomplish? Let’s make those very very easy to do. And other things—the last 20% become more difficult. Whereas the CLNP approach, nothing is really particularly difficult; there’s a lot of things you can do. But on the other hand nothing is like, trivially easy. And so I think the idea of it is the RISC approach of sort of say, taking the functions you use the most and making those the simplest.
Malamud: So at the lower layers we’re looking at simplicity. What about the upper layers? Do we need a richer development environment on the Internet? Should there be object-oriented inheritance class support built in somehow in the presentation layer?
Hoffman: Well that in fact is what’s driving a lot of… Yes, I think so. And in fact I think you need to hide those behind toolkits. We’re seeing that today in the multimedia world, where today it’s quite easy to— I mean not quite easy. It’s quite possible to write a multimedia application that runs in the existing— You could sit down— You know, Ron Fredericks and Van Jacobson have both done excellent tools in very wide use.
But it’s not trivial to do, and it takes somebody of a very high caliber to put together an application of that sort. And so I think there’s a need— But how does the… One of the problems we have in the software world is finding people to write all the applications that we need. And you can’t do that if you have to be intimately aware of how the multicast packets behave and on your own deal with the issues of quality of service, and synchronization. And so, at least in Sun’s point of view as a platform vendor, we need to put together higher-level toolkits that make it easier for more conventional application programmers to develop distributed multimedia application. And so a lot of Sun’s effort these days has been into trying to come up with appropriate toolkits that allow you to do that sort of thing without being an expert in multimedia or networking.
Malamud: Give me an example of what a toolkit might do for me as an application programmer.
Hoffman: Well today for instance… An example would be, today to write a tool, say something like a video tool of some sort, similar to nv, what you need to do is first you need to be fairly aware of the way that the frame grabber operates. And so nv grabs frames directly off of the…in the case of the Sun platform the VideoPix device driver. So you have to be intimately aware of the way the device driver works, some of the timing aspects of the device driver, and the data format. You know, YUB and all the sort of color spaces and things like that. You now have to come up with some sort of your own packetization and compression algorithm, and write the code to do that. You then have to actually on your own now encapsulate that and maintain some sort of a network transport stream.
Malamud: Sounds like a nice senior class project.
Hoffman: Well in fact I think it’s probably a fairly common graduate student project these days. But the same thing again, we’d like to make it much easier. So for instance our goal would be to say that you have an abstract object that’s a frame grabber or compression device, and you basically say “Grab me a video stream off of here, and push it out the network.” And so really, writing the application really consists of instantiating two objects, a frame grabber object and say some sort of a network endpoint object, and just connecting the two together and saying you know, off you go.
Now, that’s a much easier conceptual model… But I would— So you do that and say well that’s hard to implement, yeah, and it’s still I think something—what remains to be seen is whether we’ll be able to actually get say the performance level we need.
Malamud: Does that lead to programmers writing things that are not network-aware because it’s just too easy to grab a toolkit?
Hoffman: Well in fact they are… What we’re trying to do is say the toolkit— Well, I think an example that is…maybe not a good example but we’ll start with the idea of the X environment, X Windows environment, where there’s really no real— You can write applications that’re at least somewhat distributed without any real awareness of the network. And so you know, if you’re writing to [xlive?] well, that tends to be—it’s kind of a low level— But if you look at a toolkit like Tk or XView, something like that, much higher level of abstraction. And so you’re really not aware of the network.
The same thing here is we like to say that well, you’re aware of the network but it’s in more of an abstract sense. The idea that I’m going to attach a video display object on my system to a video capture object on your system…that’s still intrinsically networked, but at least at a conceptual level I’m not having to worry about the details of what exactly is the representation across the wire, how do I schedule the packets on the workstation or across the network.
Malamud: Well thank you very much. We’ve been talking to Don Hoffman and this has been Geek of the Week.
Malamud: You’ve been listening to Geek of the Week, a production of the Internet Multicasting Service. To purchase an audio cassette of this program, send mail to email@example.com. You may copy this file and change the encoding format, but may not resell the contents or make a derivative work.
Support for Geek of the Week comes from Sun Microsystems, makers of open systems solutions. Sun: when you think geek, think Sun. Support for Geek of the Week also comes from O’Reilly & Associates. O’Reilly & Associates, publishers of the Global Network Navigator Send mail to firstname.lastname@example.org for more information. Network connectivity for the Internet Multicasting Service is provided by UUNET Technologies, and by MFS DataNet.
This is Carl Malamud for the Internet Multicasting Service, town crier to the global village.