Carl Malamud: Internet Talk Radio, flame of the Internet. 

Malamud: This is Geek of the Week. We’re talk­ing to Don Hoffman. He’s a senior staff engi­neer at Sun Microsystems. Welcome to Geek of the Week, Don.

Don Hoffman: Thanks.

Malamud: You’re in the advanced mul­ti­me­dia net­work­ing group at Sun, and I under­stand you’re in the process of build­ing a lab­o­ra­to­ry to deploy mul­ti­me­dia for your­self. You’re try­ing to bring some tech­nol­o­gy out of the research labs and begin using it with­in Sun.

Hoffman: Yeah. A lot of what’s hap­pen­ing is cer­tain­ly peo­ple have been mak­ing exten­sive use of tools like nv and vat on MBone. And there’s some lim­i­ta­tions to the Internet envi­ron­ment there where we’d like to say do higher-quality video, or a lot more audio. But we’ve run into a thing recent­ly thing with a lot of peo­ple doing video, it’s start­ing to put a lot of pres­sure on the capac­i­ty of the Internet. These sort of lim­i­ta­tions you don’t run into in say a cam­pus net­work envi­ron­ment where we have hun­dreds of megabits of band­width run­ning from one end of cam­pus to the oth­er and between say, cam­pus­es here in the Bay Area. So what we’re try­ing to do is take a lot of the tech­nol­o­gy that’s already avail­able in the Internet world and bring it into the cor­po­rate Internet environment.

Malamud: So what do you have in mind? What do you view your own per­son­al com­put­ing envi­ron­ment look­ing like in a year?

Hoffman: From our point of view, there’s real­ly I’d say two main appli­ca­tions. Actually, one of them tends to be sort of a one-to-many appli­ca­tion. You know, in the Internet world you sort of see the IETF broad­casts of tak­ing all the var­i­ous IETF work­ing groups and send­ing them out into the Internet. Here for instance we can do sim­i­lar things. We can take sem­i­nars that are being offered say by the Sun U group. We can take say, satel­lite— One of the things we have is we have con­nect­ed to a stan­dard satel­lite broad­cast receiv­er, and then we can now be rebroad­cast this on the inter­nal engi­neer­ing network.

Malamud: Now does­n’t that take a lot of work? I mean, pro­duc­ing TV is not a sim­ple thing to do—

Hoffman: Well that’s the point is— Right now we’re tak­ing either things that’re already pro­duced. Like for instance the Sun U peo­ple have already put togeth­er course material—

Malamud: Sun U is the internal—

Hoffman: Internal train­ing, yeah. For inter­nal peo­ple, and also say for peo­ple from out­side of Sun who wan­na come in and get some train­ing about Sun tech­nol­o­gy. And so they’ve already pro­duced a lec­ture series. Somebody who’s used to speak­ing in front of a large audi­ence, they already have pre­pared mate­ri­als. It turned out to be not very dif­fi­cult to take that and just put a cam­era and some net­work­ing infra­struc­ture in the room and redis­trib­ute that around the Sun network.

Malamud: Now that’s just TV on a net­work. I mean, you could’ve used a coax­i­al cable, an inter­nal cable sys­tem to do that. Why would you run that on a com­put­er net­work instead of using cheap­er technology?

Hoffman: Well in our case it actu­al­ly isn’t cheap­er. We would’ve had to— The idea is here to get to every­body’s desk­top— This sem­i­nar, for instance. We would’ve had to put in, into every­body’s office, an addi­tion­al par­al­lel net­work, anoth­er TV, anoth­er CRT, more stuff on the desk. Instead what we have is we can use the exist­ing net­work. And the exist­ing work­sta­tions. So our goal here is to not it would require an addi­tion­al add-on card on the desk­top that you’re using to view this but whether we can run it on a stan­dard Sun work­sta­tion, software-only decom­pres­sion. Much like we’re doing with nv today. 

And so what you see then is I can take any work­sta­tion and down the hall here, we could walk up to and I could now show you say CNN that we’re pick­ing up off the satel­lite anten­na. The same sort of tech­nol­o­gy would be used for instance for the Sun U class.

Malamud: Okay, so you hook up your local train­ing facil­i­ty with some video broad­cast­ing equip­ment. You have a satel­lite dish on the roof—

Hoffman: We have a lot of dif­fer­ent sort of feeds we can use. The Sun U, we have— One of the groups here, it’s human inter­face group, is set­ting up a spe­cial stu­dio so the Sun U peo­ple can go in and produce…take their stan­dard stuff and present it in that studio. 

One of the things you run into, I think a lot of expe­ri­ence we’ve got from say the IETF broad­cast is that light­ing and the train­ing of the cam­era­man makes a lot of dif­fer­ence. Bad lighting…you know, peo­ple can’t see the slides, the cam­era— One sort of annoy­ing thing that often hap­pens in a lot of the IETF broad­casts is the cam­er­ap­er­son is pan­ning back and forth between the speak­er and say some­body ask­ing a ques­tion in the audi­ence. And the nature of the com­pres­sion algo­rithms caus­es the image to break up real­ly bad­ly. And so by hav­ing trained cam­era oper­a­tors and rooms where you can sort of do cuts between cam­eras, we can improve the qual­i­ty of the presentation.

Malamud: Now this means you have to hire trained cam­era oper­a­tors and light­ing tech­ni­cians. Is this the kind of employ­ee that Sun has to hire now to do this?

Hoffman: Well gen­er­al­ly you do need to have— We’ve always need­ed to have some­body trained in oper­at­ing the cam­eras. If for no oth­er rea­son than high-end cam­eras are rather com­pli­cat­ed to oper­ate. It’s not like a Sony mini­cam where you just go plug it in. And so real­ly the addi­tion­al train­ing for that per­son is prob­a­bly not that great. 

The room for the pre­sen­ta­tions is fair­ly… Well, it’s set up ahead of time and so the light­ing tends to be fair­ly sta­t­ic. We don’t need to redo the light­ing for every pre­sen­ta­tion. It tends to stay the same way. So there’s a fixed lectern, fixed lighting…

Malamud: When we hear of video con­fer­enc­ing on com­put­er net­works, and when we hear of things like Internet talk radio, a lot of the press looks at and says ​“Ah, this is bring­ing the tech­nol­o­gy to the mass­es. This is per­son­al broadcasting.” 

Hoffman: Right.

Malamud: And what I’m hear­ing 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 togeth­er in two sec­onds and you’re a TV sta­tion broad­cast­ing to the world. It’s just as com­pli­cat­ed in the com­put­er world as it is in the… [crosstalk] 3D world?

Hoffman: Absolutely. In fact there’s a lot of I think par­al­lel with oth­er ways of com­mu­ni­ca­tion. When an easy way to pre­pare graph­ic slides became avail­able, there were a lot of bad slides, and a lot of—you know, desk­top pub­lish­ing became pos­si­ble and there was a lot of real­ly bad newslet­ters. And as peo­ple gained expe­ri­ence, they start­ing becom­ing sort of lit­er­ate in the style of doing say desk­top pub­lish­ing and prepar­ing newslet­ters that actu­al­ly looked good. 

And I think we’ll see the same thing on the video side. That right now, you know, the stan­dard way is you stick a cam­era down in front of the guy and he says what he’s gonna say. But peo­ple will start becom­ing more lit­er­ate in the style of pro­duc­ing video material.

Malamud: So you think just as peo­ple can now rec­og­nize a 150 dot-per-inch dot-matrix resume, they’ll be able to rec­og­nize a home video 8 mil­lime­ter poor­ly lit.

Hoffman: It would­n’t even be sur­pris­ing that say a lot of the col­lege cur­ric­u­lar com­mu­ni­ca­tion would include how to pro­duce videos. You know, right now peo­ple learn how to write in col­lege and they learn how to do pre­sen­ta­tions. Well why should­n’t they learn how to do videos also.

Malamud: Don Hoffman, we’ve been look­ing a lot at mul­ti­me­dia net­works. Maybe you can tell us a lit­tle bit about the affect of mul­ti­me­dia on a com­put­er net­work. Do we have to do things dif­fer­ent­ly on the net­work, or is this just more band­width and faster processors?

Hoffman: Well in fact it actu­al­ly turns out to be all of the above. It’s gen­er­al­ly in the case of com­put­ing that you find and fix one bot­tle­neck and anoth­er one pops up. And so in order to do the things we’re doing inter­nal­ly with­in Sun, we’ve had to do both. We’ve had to increase the band­width. Although, the cur­rent gen­er­a­tion of our back­bone is an FDDI-based back­bone. So we’ve increased the band­width a rea­son­able amount, but also we need to do smarter things. So for instance our cor­po­rate inter­net is not all FDDI. So for instance, the final part of the net­work into my office is still Ethernet. So we need to start look­ing at a smarter mech­a­nisms, the router between the FDDI net­work and the final leg do things like resource man­age­ment and band­width limitation. 

Malamud: Now, you have ten megabits com­ing to your desk­top and you do a lot of video con­fer­enc­ing work. Is ten megabits enough?

Hoffman: Barely.

Malamud: Barely. Is a hun­dred megabits enough?

Hoffman: A hun­dred megabits… For instance right now for one-to-many style video, a hun­dred megabits is actu­al­ly plen­ty. So here on cam­pus, let’s say even if we had half a dozen at any one time groups pro­duc­ing a one-to-many video show of some sig­nal of some sort, an FDDI net­work for instance could prob­a­bly han­dle that using say the cur­rent lev­el of video we’re able to do on a work­sta­tion. That is say less than ten frames a sec­ond, 240 by 380 resolution. 

Malamud: Are we gonna always want more band­width? Or is—

Hoffman: We’re always gonna want more band­width because what hap­pens is I show this qual­i­ty of video to peo­ple that are say, a lit­tle bit more…video-aware, such as the MPEG peo­ple. And they look at it and they just sort of pff, this is not video, this is…toys or some­thing like that. But it’s still very use­ful. So for instance, for me to be able to stay in my office and see some sort of train­ing mod­ule, that’s use­ful to me and so I’m not nec­es­sar­i­ly con­cerned about the qual­i­ty of video.

Malamud: But at some point you’ll get the qual­i­ty you want—

Hoffman: Yeah.

Malamud: An HDTV stream is what, twen­ty megabits per second?

Hoffman: I don’t—probably a lit­tle bit more than that, depend­ing how much compression.

Malamud: Would 600 megabits to the desk­top be enough for­ev­er? I mean, are we going to con­tin­u­al­ly want more band­width 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 propos­ing things like vir­tu­al real­i­ty and that sort of thing. And I think it was… The idea’s that I think it was…Norm Schryer at Bell Labs was talk­ing about the idea of hav­ing drones you send out. So instead of actu­al­ly going some­where on vaca­tion you send out a drone. Imagine the sort of band­width you’d need to do that sort of thing.

Malamud: A vir­tu­al vacation.

Hoffman: A vir­tu­al vaca­tion, 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 vaca­tion this week, Don, but we’ve allowed your com­put­er to take one instead.

Hoffman: Well, But the thing is you won’t have to sit in the air­plane for all that time, so. 

Malamud: And the com­put­er would send you a postcard.

Hoffman: Right, exactly.

Malamud: Don Hoffman, we’ve been look­ing a lot at mul­ti­me­dia tech­nol­o­gy again, and part of that is the under­ly­ing infra­struc­ture of the net­work. You’ve talked about an FDDI back­bone, and that that’s prob­a­bly not enough for the future. Is ATM the tech­nol­o­gy that you’ve spot­ted as the one that’s going to solve all our prob­lems for­ev­er? 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 prob­lems. But ATM offers the pos­si­bil­i­ty… It offers a plat­form where one could solve a lot of the prob­lems, say in the next three to four years. 

Malamud: But today, is it a wide-area net­work? Is it some­thing I could use for putting a vir­tu­al cor­po­rate back­bone in place?

Hoffman: The main thing ATM offers today is the big­ger pipe. And there’s a lot of peo­ple doing research on con­ges­tion con­trol and resource man­age­ment in the net­work. And I think in order for ATM to be a com­plete solu­tion we’re going to need to see that sort of work make its way into the prod­ucts. So today, I can go to Synaptics and buy a switch, and a very good, fat pipe that han­dles the LAN envi­ron­ment very well. Other ven­dors more on the tele­pho­ny side are offer­ing ATM switch­es that sort of deal with the wide-area net­work­ing well.

Malamud: Do you have to change your soft­ware in order to go let’s say from an Ethernet to an ATM envi­ron­ment? Does ATM give you every­thing that Ethernet gives you?

Hoffman: Well, in fact this is a big dis­cus­sion in the ATM forum about ATM LAN emu­la­tion. Because there are a lot of fea­tures in sort of standard…the way we we’ve seen LANs is they tend to be intrin­si­cal­ly broad­cast and multicast-based media. And so for instance you’ll see that in Ethernet we can do some­thing like mul­ti­cast or broad­cast— It’s sort of stan­dard, it’s easy to do. In ATM it’s a bit more dif­fi­cult. And so some of the prob­lems they have right now is we’ve— At least in the Internet world, we’ve defined a cer­tain mod­el of mul­ti­cast that works very well on the Internet wide-area net­work, and then on the final LANs like Ethernets and token rings. It’s going to take a lit­tle 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 vir­tu­al cir­cuit with every­one you’re talk­ing to, strict­ly for each mul­ti­cast address, or—

Hoffman: There’s a lot­ta dis­cus­sion on this. There’s real­ly sev­er­al ways the prob­lem could be solved, and I don’t think any one of them is the obvi­ous win­ner right now. One is to say that…well, you change the mul­ti­cast mod­el. I mean, the cur­rent ATM forum spec­i­fi­ca­tions have real­ly the idea more of a source-control mul­ti­cast, where the source sort of sets up the mul­ti­cast group and decides who the mem­bers are.

Malamud: So a PC wakes up on the net­work, is look­ing for its oper­at­ing sys­tem from a remote serv­er. 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 train­ing class, it’d have to con­tact the broad­cast­ing machine and say ​“Add me to the group.” So it’s source-controlled. Unlike say the IP mul­ti­cast mod­el, where the receiv­er just basi­cal­ly joins the group. It does­n’t have to ask per­mis­sion from any­body. So that’s the obvi­ous way one would do it now, when we’re doing a multicast-style of appli­ca­tion on the ATM network.

Other peo­ple are talk­ing about hav­ing rese­quencer servers where the source is send­ing out pack­ets to a rese­quencer and it’s then redis­trib­ut­ing it to all of the sta­tions that want to receive the multicast.

Malamud: So a reflec­tor of some sort.

Hoffman: Reflec— [indis­tinct phrase] reflec­tor. In which case even then— So you real­ly only have to go estab­lish a rela­tion­ship with the rese­quencer or reflector.

Malamud: It’s impor­tant to under­stand of course that mul­ti­cas­t­ing is used not only as a way of join­ing a video con­fer­enc­ing group, but at very low lay­ers for things like adver­tis­ing ser­vices and—

Hoffman: Yeah.

Malamud: It’s a very basic part of the LAN environment.

Hoffman: If you look at all the tools what we have avail­able on the inter­nal­ly today, they all real­ly rely very heav­i­ly on mul­ti­cast tech­nol­o­gy. And they rely very heav­i­ly on the style of mul­ti­cast tech­nol­o­gy avail—the IP mul­ti­cast avail­able today. And so we’re gonna need either rethink the basics of mul­ti­cast, or we’re going to need to basi­cal­ly make ATM emu­late that. And so I think what Steve Deering said that well, ATM’s only gonna suc­ceed if it actu­al­ly sup­ports the style of mul­ti­cast that we have in the Internet today. 

Malamud: Now, what— The Internet mul­ti­cas­t­ing is using a wide-area IP-level mul­ti­cas­t­ing tech­nol­o­gy. Which assumes in order to work effec­tive­ly some­thing at the local area net­work that’s effi­cient for mov­ing infor­ma­tion out. Why if you have IP mul­ti­cas­t­ing in a wide area, why can’t IP take care of those prob­lems? Why does ATM as a data link lay­er, as a wide-array of cloud, also have to do the same thing?

Hoffman: Well, one of the advan­tages giv­en to ATM is that it low­ers the bar­ri­ers between the local area net­work and the wide-area net­work. And so many peo­ple are propos­ing that in fact we try to have end-to-end ATM. And so it’s… I think there’s a lot of dis­cus­sion on this. Whether we sort of say that the ATM net­work real­ly becomes the Internet… And in fact a lot of peo­ple even pro­pose tak­ing some of the tech­nolo­gies [indis­tinct] the Internet and try­ing to move them down [crosstalk] in the ATM fabric.

Malamud: Exactly. That was my ques­tion, is if you’ve got mul­ti­cas­t­ing at the ATM lay­er, 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 any­time soon, of course. But that would be the fan­ta­sy a lot of peo­ple I think would have. That by tak­ing the func­tion­al­i­ty we have today it in the Internet, mov­ing it into the ATM net­work fab­ric, we’d get the advan­tages of end-to-end ATM but the flex­i­bil­i­ty of the Internet. Plus since you are using an Internet archi­tec­ture you have a much eas­i­er way for you to migrate between the two envi­ron­ments. Because the prob­lem now is if you sor­ta said well, we’re only gonna use end-to-end ATM mech­a­nisms, you’d cut out a lot of your cur­rent pop­u­la­tion because you know, even for the next years it’s gonna be rel­a­tive­ly expen­sive to get an ATM connection.

Malamud: Is it real­is­tic 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 real­is­tic in the next ten years. 

Malamud: I mean, I could see putting an Ethernet con­nec­tor on my home toast­er, but I think ATM on my home toast­er might be a lit­tle much.

Hoffman: Right. And so you’re going to con­tin­ue to need the Internet approach, which assumes some lev­el of het­ero­gene­ity in your network. 

Now a lot of the prob­lem, though, is still a lot of the architect—a lot of the work we’re doing now assumes mesh­es that are not as fully-connected as you might have in say and end-to-end ATM envi­ron­ment. So in an end-to-end ATM envi­ron­ment you’re going to have basi­cal­ly a vir­tu­al con­nec­tion between every pair of com­mu­ni­ca­tors instead of the sim­ple mod­el. And so it’s a lit­tle bit dif­fer­ent today where I do at least a lit­tle bit of traf­fic aggre­ga­tion, when I cross say some of the… So for instance here in the Bay Area, all the Sun traf­fic goes through one link into Barnett. And so that real­ly looks like one virtual…it’s real­ly is one vir­tu­al cir­cuit from the point of view of Sun.

Whereas if we were to have end-to-end ATM fab­ric, now all of a sud­den we’re set­ting up vir­tu­al cir­cuits willy-nilly all over the place and now the whole issues of rout­ing become very dif­fi­cult. The issues of how do you set up a mul­ti­cast group that’s made up of thou­sands and thou­sands of vir­tu­al con­nec­tions. It’s not nec­es­sar­i­ly clear that what we’re doing today is going to be able to trans­fer over to an end-to-end ATM envi­ron­ment with­out some major changes in the architecture.

Malamud: As a devel­op­er of soft­ware for your base plat­form, basi­cal­ly the net­work is now part of the oper­at­ing sys­tem. How do you choose which of the things from the research world or from the pub­lic domain world actu­al­ly get imple­ment­ed in your core software?

Hoffman: Well that’s actu­al­ly real­ly 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 pro­to­type stage. And when it comes time to decide whether we make it into a prod­uct, we say well no we don’t. And I can’t think of any­thing off the top of my head right now where we would would’ve said no, but— Well I think an exam­ple is that in some cas­es we’ve actu­al­ly tak­en things all the way to prod­uct and they have actu­al­ly suc­ceed­ed as much as we might expect. 

Early days, I actu­al­ly start­ed out at Sun devel­op­ing OSI soft­ware. And in some sense we prob­a­bly spent as much engi­neer­ing effort imple­ment­ing OSI soft­ware as we did on the Internet stack. Because we had it a lit­tle bit eas­i­er because we were using a Berkeley soft­ware base. We got a lot of the Internet net­work­ing soft­ware essen­tial­ly for free, and most of our effort was opti­miz­ing it for the Sun plat­form, bug fix­es, that sort of thing. And so we had an engi­neer­ing team actu­al­ly larg­er than the Internet team devel­op­ing OSI soft­ware. And we actu­al­ly took all that to tak­ing some ear­ly research work—this would be in the ear­ly 80s—taking some research work from BBN, mov­ing it over to the Sun plat­form, adding some addi­tion­al stuff of our own, actu­al­ly sent it out the prod­uct and yet we found that it nev­er real­ly sold the way we expect­ed it to. 

Malamud: Have you tried giv­ing it away?

Hoffman: Well in fact— A good sales rep often will arrange things that way, where the cost of the soft­ware is hid­den in the over­all cost of the deal. And so from the point of view of the cus­tomer it appears that’s it’s being giv­en away.

Malamud: Was OSI real­ly hard to imple­ment? I know that’s a soft­ball ques­tion, but uh— [chuck­les]

Hoffman: Yeah. I mean… No actu­al­ly it was not very hard to imple­ment. I think in any pro­to­col it’s always easy to sor­ta get some­thing basi­cal­ly run­ning. There’s noth­ing par­tic­u­lar­ly dif­fi­cult about say…oh, ses­sion lay­er and below. Now I would­n’t say the same thing about some of the appli­ca­tion lay­er’s pro­to­cols. I think any­body who’s tried to imple­ment an ASM.1 encoder and decoder knows that that’s not nec­es­sar­i­ly a sim­ple thing to do. But say CLNP is actu­al­ly very straight­for­ward. I actu­al­ly did the actu­al cod­ing in prob­a­bly less than a week. That was of course start­ing from the Berkeley IP imple­men­ta­tion using essen­tial­ly the same approach and just chang­ing the— There’s real­ly not that many dif­fer­ences and so the imple­men­ta­tion was actu­al­ly fair­ly quick.

Malamud: If it’s so straight­for­ward, why aren’t we look­ing more seri­ous­ly— I know some peo­ple are, but there’s the divi­sion in the Internet on the use of the con­nec­tion­less net­work ser­vices, the next-generation IP. And if it’s such an easy change in the code why isn’t there a real strong move­ment say­ing gee, just give us TUBA, it gives us big­ger address­es and it’s an easy upgrade.

Hoffman: Well— Historically a lot of the dif­fi­cul­ty came from the fact that at least in CLNP, the address­ing was too flex­i­ble. And so we spent a lot of effort in try­ing to come up with mech­a­nisms that would sup— We’re a plat­form ven­dor, num­ber one. So we have to pro­vide a plat­form that can sup­port all the like­ly address­ing mech­a­nisms that some­body would want to use in CLNP. Well, at least at the time we’re talk­ing about, mid/early 80s, it was not quite the— We did­n’t have some­thing like IETF who could’ve said well there’s this one address for­mat that you need to sup­port. So in that case, it was just dif­fi­cult to put togeth­er an OSI net­work because you real­ly had to be an ex—you real­ly had to design your own address­ing approach.

Malamud: But even today, Sun for exam­ple is one of the lead­ers in the SIP effort for a new-generation IP. You’ve put all this mon­ey into doing your CLNS imple­men­ta­tions. Why in the world are you invent­ing a new IP when you could’ve reused this ISO code that’s still sit­tin’ around that all these engi­neers developed?

Hoffman: Well. I mean a lot of it was that there weren’t real­ly any advantages…at least in the tech­nol­o­gy we’re look­ing at there weren’t real­ly any real advan­tages to cause us to go through all the tr—other than sort of more flex­i­ble address­ing, we did­n’t see a whole lot of advan­tages to CLNP. And nei­ther did a lot of our cus­tomers. Why move over from a per­fect­ly func­tion­al and robust net­work­ing plat­form to some­thing else that did­n’t real­ly give you any advan­tages. So for instance, why move over to X.400 when you had some­thing like SMTP-based mail. It worked per­fect­ly well. What was the motivation? 

And I think what we see today is that… In the case of SIP there’s actu­al­ly some new con­cepts in there, some sim­pli­fi­ca­tions. And instead of mak­ing things more com­pli­cat­ed, we made things sim­pler. I think that’s one of things we real­ized, that at least below a cer­tain lay­er in the pro­to­col abstrac­tion sim­plic­i­ty is better. 

Malamud: It’s a RISC approach to network—

Hoffman: A RISC approach to net­work­ing. And I think that’s been a lot of what’s dri­ven SIP, is to try to sort of take some things that were sim­ple. Now you can do, of course— CLNP can do every­thing in the world but, it’s not nec­es­sar­i­ly the case that it’s sim­ple to do. And so I think you see SIP sort of say­ing what are the top 80% of things we want to accom­plish? Let’s make those very very easy to do. And oth­er things—the last 20% become more dif­fi­cult. Whereas the CLNP approach, noth­ing is real­ly par­tic­u­lar­ly dif­fi­cult; there’s a lot of things you can do. But on the oth­er hand noth­ing is like, triv­ial­ly easy. And so I think the idea of it is the RISC approach of sort of say, tak­ing the func­tions you use the most and mak­ing those the simplest.

Malamud: So at the low­er lay­ers we’re look­ing at sim­plic­i­ty. What about the upper lay­ers? Do we need a rich­er devel­op­ment envi­ron­ment on the Internet? Should there be object-oriented inher­i­tance class sup­port built in some­how in the pre­sen­ta­tion layer?

Hoffman: Well that in fact is what’s dri­ving a lot of… Yes, I think so. And in fact I think you need to hide those behind toolk­its. We’re see­ing that today in the mul­ti­me­dia world, where today it’s quite easy to— I mean not quite easy. It’s quite pos­si­ble to write a mul­ti­me­dia appli­ca­tion that runs in the exist­ing— You could sit down— You know, Ron Fredericks and Van Jacobson have both done excel­lent tools in very wide use. 

But it’s not triv­ial to do, and it takes some­body of a very high cal­iber to put togeth­er an appli­ca­tion of that sort. And so I think there’s a need— But how does the… One of the prob­lems we have in the soft­ware world is find­ing peo­ple to write all the appli­ca­tions that we need. And you can’t do that if you have to be inti­mate­ly aware of how the mul­ti­cast pack­ets behave and on your own deal with the issues of qual­i­ty of ser­vice, and syn­chro­niza­tion. And so, at least in Sun’s point of view as a plat­form ven­dor, we need to put togeth­er higher-level toolk­its that make it eas­i­er for more con­ven­tion­al appli­ca­tion pro­gram­mers to devel­op dis­trib­uted mul­ti­me­dia appli­ca­tion. And so a lot of Sun’s effort these days has been into try­ing to come up with appro­pri­ate toolk­its that allow you to do that sort of thing with­out being an expert in mul­ti­me­dia or networking.

Malamud: Give me an exam­ple of what a toolk­it might do for me as an appli­ca­tion programmer.

Hoffman: Well today for instance… An exam­ple would be, today to write a tool, say some­thing like a video tool of some sort, sim­i­lar to nv, what you need to do is first you need to be fair­ly aware of the way that the frame grab­ber oper­ates. And so nv grabs frames direct­ly off of the…in the case of the Sun plat­form the VideoPix device dri­ver. So you have to be inti­mate­ly aware of the way the device dri­ver works, some of the tim­ing aspects of the device dri­ver, and the data for­mat. You know, YUB and all the sort of col­or spaces and things like that. You now have to come up with some sort of your own pack­e­ti­za­tion and com­pres­sion algo­rithm, and write the code to do that. You then have to actu­al­ly on your own now encap­su­late that and main­tain some sort of a net­work trans­port stream. 

Malamud: Sounds like a nice senior class project.

Hoffman: Well in fact I think it’s prob­a­bly a fair­ly com­mon grad­u­ate stu­dent project these days. But the same thing again, we’d like to make it much eas­i­er. So for instance our goal would be to say that you have an abstract object that’s a frame grab­ber or com­pres­sion device, and you basi­cal­ly say ​“Grab me a video stream off of here, and push it out the net­work.” And so real­ly, writ­ing the appli­ca­tion real­ly con­sists of instan­ti­at­ing two objects, a frame grab­ber object and say some sort of a net­work end­point object, and just con­nect­ing the two togeth­er and say­ing you know, off you go.

Now, that’s a much eas­i­er con­cep­tu­al mod­el… But I would— So you do that and say well that’s hard to imple­ment, yeah, and it’s still I think something—what remains to be seen is whether we’ll be able to actu­al­ly get say the per­for­mance lev­el we need.

Malamud: Does that lead to pro­gram­mers writ­ing 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 try­ing to do is say the toolk­it— Well, I think an exam­ple that is…maybe not a good exam­ple but we’ll start with the idea of the X envi­ron­ment, X Windows envi­ron­ment, where there’s real­ly no real— You can write appli­ca­tions that’re at least some­what dis­trib­uted with­out any real aware­ness of the net­work. And so you know, if you’re writ­ing to [xlive?] well, that tends to be—it’s kind of a low lev­el— But if you look at a toolk­it like Tk or XView, some­thing like that, much high­er lev­el of abstrac­tion. And so you’re real­ly not aware of the network. 

The same thing here is we like to say that well, you’re aware of the net­work but it’s in more of an abstract sense. The idea that I’m going to attach a video dis­play object on my sys­tem to a video cap­ture object on your system…that’s still intrin­si­cal­ly net­worked, but at least at a con­cep­tu­al lev­el I’m not hav­ing to wor­ry about the details of what exact­ly is the rep­re­sen­ta­tion across the wire, how do I sched­ule the pack­ets on the work­sta­tion or across the network.

Malamud: Well thank you very much. We’ve been talk­ing to Don Hoffman and this has been Geek of the Week.

Malamud: You’ve been lis­ten­ing to Geek of the Week, a pro­duc­tion of the Internet Multicasting Service. To pur­chase an audio cas­sette of this pro­gram, send mail to audio@​ora.​com. You may copy this file and change the encod­ing for­mat, but may not resell the con­tents or make a deriv­a­tive work.

Support for Geek of the Week comes from Sun Microsystems, mak­ers of open sys­tems solu­tions. Sun: when you think geek, think Sun. Support for Geek of the Week also comes from O’Reilly & Associates. O’Reilly & Associates, pub­lish­ers of the Global Network Navigator Send mail to info@​gnn.​com for more infor­ma­tion. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by UUNET Technologies, and by MFS DataNet.

This is Carl Malamud for the Internet Multicasting Service, town crier to the glob­al village.