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: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.


Help Support Open Transcripts

If you found this useful or interesting, please consider supporting the project monthly at Patreon or once via Cash App, or even just sharing the link. Thanks.