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

Malamud: This is Geek of the Week. We’re talk­ing to Ron Frederick, he’s a research sci­en­tist at Xerox’s Palo Alto Research Center, and wel­come to Geek of the Week, Ron.

Frederick: Thank you very much.

Malamud: You are the author of nv. Why don’t you tell us what nv is and…why would I want to use it.

Frederick: Okay. NV is short for ​“net­work video.” And it’s one of the tools on the Internet right now which allows you to do mul­ti­me­dia over the MBone, the mul­ti­cast back­bone that’s been set up. And the design is arranged such that if you have a work­sta­tion, you can pret­ty much receive the video just using your reg­u­lar work­sta­tion screen, no spe­cial hard­ware required.

Malamud: So this is video as in…TV, right, not just pic­tures and satel­lite images and things like that.

Frederick: That’s right. It’s video at a slight­ly slow­er rate and slight­ly small­er size than your tele­vi­sion set would give you in your house. The frame rates and such are lim­it­ed by pro­cess­ing pow­er and by what the net­work can deliver.

Malamud: Well how good a video is it? You say it’s reduced res­o­lu­tion and reduced frame rate. How reduced com­pared to a tele­vi­sion image would video on the Internet be?

Frederick: The stan­dard video that we’re trans­mit­ting around right now is about five frames a sec­ond. And it’s sort of—the size is what you might call a quar­ter size of tele­vi­sion res­o­lu­tion. It’s close to what you’d get off of a VHS VCR in terms of pic­ture quality. 

Malamud: And what kind of band­width are we talk­ing about here to do this?

Frederick: And that par­tic­u­lar stream typ­i­cal­ly takes about 128 kilo­bits worth of band­width. So it’s about dou­ble what an uncom­pressed audio stream would take up on the network.

Malamud: And what’s it gonna take to turn it into…or is it ever going to be full-motion video in full col­or and HDTV and all these things? Is this the first step?

Frederick: This is a pro­gres­sion. As the machines con­tin­ue to get faster, the same tech­nol­o­gy that’s allow­ing this video to be out on the net­work will allow bet­ter qual­i­ty. Today if you have a DEC Alpha work­sta­tion and a video card you can actu­al­ly push it up to about twen­ty frames a sec­ond at that size. And as you get anoth­er step, maybe anoth­er fac­tor of two in per­for­mance you’ll be up at the full rate. And even­tu­al­ly up at the larg­er sizes as well. Of course you’ll need more band­width on the net­work to do that. But we’re installing more and more band­width every day on our back­bones and on our region­al net­work. So even­tu­al­ly I do think that this tech­nol­o­gy will push all the way to tele­vi­sion quality.

Malamud: Now you said to receive the video you don’t need any spe­cial hardware. 

Frederick: That’s right.

Malamud: So how does this work? I thought you usu­al­ly do video with spe­cial codecs and devices like that. You’re doing this all in soft­ware, then.

Frederick: Yes. The encod­ing and the decod­ing of the video’s com­plete­ly in soft­ware. And the only thing you need at the encode side there­fore is some­thing that will take raw tele­vi­sion images out of a cam­era or a VCR or some­thing like that and turn them into dig­i­tal bits. So you need a frame grab­ber or some oth­er very sim­ple video card. And the soft­ware will take care of the rest.

Malamud: And what kind of includ­ing do you use for the data?

Frederick: The pri­ma­ry nv is some­thing I designed myself. It’s a com­bi­na­tion of doing dif­fer­enc­ing from one frame to the next, so that it does­n’t always have to trans­mit the whole pic­ture every time, and then a com­pres­sion scheme which is sort of a sim­pli­fied form of some of the stuff JPEG does. It’s a wavelet-based scheme.

Malamud: And does the com­pres­sion scheme… Is this loss­less com­pres­sion or do we lose qual­i­ty? Are there arti­facts based on the way you do your encoding?

Frederick: There are some arti­facts. The most notice­able arti­facts are caused by the frame dif­fer­enc­ing. The fact that even though a block has changed a lit­tle bit it might not send it right away. But the encod­ing is designed such that if you end up ever going back into a still image, it will even­tu­al­ly pro­duce a per­fect­ly clean full high-resolution pic­ture. And so it’s only a mat­ter of whether or not it’s mov­ing too quick­ly to ever get to that state. But the back­ground and some of the oth­er things that aren’t chang­ing the image will get to full res­o­lu­tion eventually. 

Malamud: Now, you men­tioned the stan­dards such as MPEG. How does that relate to the encod­ing scheme? Why aren’t you using MPEG, for example?

Frederick: Well in fact for the lat­est gen­er­a­tion of nv I looked very seri­ous­ly at JPEG, or some­thing like it. JPEG is the still ver­sion of the MPEG stan­dard. And the answer there was that cur­rent­ly JPEG is too expen­sive to real­ly do in soft­ware on the machines that we have today.

Malamud: Why are you—

Frederick: You can do it, but MPEG decod­ing for exam­ple is much cheap­er than MPEG encod­ing. And so you can’t do a real-time encode, even though you can take a file that some­one cre­at­ed for you and play it back at a fair­ly nice rate.

Malamud: Now you said you looked at JPEG, not at MPEG as a stan­dard. Why would you be look­ing at a still pho­to stan­dard for doing full-motion video?

Frederick: Um, what I was intend­ing to do with JPEG was actu­al­ly take some of my frame dif­fer­enc­ing, but then just use the JPEG stan­dard for send­ing the data which had changed. And the rea­son for that as opposed to just using MPEG was that MPEG was so expen­sive to encode. So I sort of start­ed with the most expen­sive stan­dard I knew of that was real­ly design for this, but designed to require hard­ware, and tried to step back one step at a time to see what was pos­si­ble in soft­ware. And JPEG was eas­i­er than MPEG but not easy enough. When I replaced cer­tain pieces of JPEG, it final­ly got easy enough that I could actu­al­ly do a rea­son­able encod­ing in real time in software.

Malamud: Now, there’s anoth­er stan­dard, CellB. How does that relate to what you do? 

Frederick: That’s right. And in fact the lat­est ver­sion of the nv tool will actu­al­ly encode and decode CellB as well as my own format.

Malamud: What’s the dif­fer­ence between CellB and what you invented?

Frederick: CellB is some­thing that can’t—that was devel­oped over at Sun, and it was actu­al­ly designed with many of the same goals in mind as to what nv does. It has a very sim­i­lar idea about only trans­mit­ting frame dif­fer­ences. And it has a slight­ly dif­fer­ent tech­nique for how it actu­al­ly encodes the por­tions of the image that have changed. The main dif­fer­ence between the two of them is that the CellB stan­dard does­n’t have a high-resolution mode. So it’s much bet­ter than nv in terms of com­pres­sion ratio and frame rate, at the same band­width. But, if you just sort of end up with a still image at some point, the CellB image does­n’t crisp up to the full res­o­lu­tion of what the cam­er­a’s grab­bing in the way the nv encod­ing does.

Malamud: There’s anoth­er set of video tools on the net, known as CU-SeeMe that are made for Macintoshes. They don’t use native mul­ti­cas­t­ing. The way CU-SeeMe works is you know, they send a video stream to a reflec­tor which then sends it back out to the oth­er par­tic­i­pants in the con­fer­ence. Now, you’re using mul­ti­cas­t­ing. Can you describe those two approach­es and whether in fact they’re going to merge?

Frederick: Uh, okay. Sure. I’ll say a cou­ple things about CU-SeeMe first, and that’s that there was actu­al­ly an inter­est at one point in allow­ing the CU-SeeMe reflec­tor to talk mul­ti­cast as well. And so nv sup­ports CU-SeeMe decod­ing and more recent­ly encod­ing as well. But the rea­son it need­ed the reflec­tor was pri­mar­i­ly that the Macintosh does­n’t sup­port native-mode mul­ti­cast yet at all. 

Malamud: Is the idea of hav­ing mul­ti­cas­t­ing on a Mac at all feasible?

Frederick: Oh, very much so. And Apple has promised that it in some fair­ly soon future release of Mac TCP it will be there, and oth­er third-party ven­dors for IP on the Mac have said the same thing. 

The reflec­tor has a lot of nice prop­er­ties. I mean, it gives you a lit­tle bit more con­trol than just sort of raw mul­ti­cast would give you. On the oth­er hand, it’s much more expen­sive on the net­work. What ends up hap­pen­ing is all of these streams end up hit­ting the same Ethernet and go into this reflec­tor, and then if you have five par­tic­i­pants in the con­fer­ence you have five times as much band­width leav­ing the reflec­tor to go back to those par­tic­i­pants. And so you run out of net­work band­width much soon­er than you would if you actu­al­ly had native-mode multicast.

Malamud: Now, you said that nv has CU-SeeMe decod­ing int it. Does that mean the that a per­son on a Sun or oth­er envi­ron­ment that has X Windows sup­port on it can par­tic­i­pate in a CU-SeeMe ses­sion? Is that what that means?

Frederick: In the cur­rent imple­men­ta­tion that’s out there now, nv did CU-SeeMe decode only. And so some­one who was on a Sun could watch a stream that had been trans­mit­ted from a Macintosh by hav­ing the reflec­tor send out a copy to a mul­ti­cast group at the same time it was send­ing it out to the oth­er par­tic­i­pants. In the more recent release I added an encode step as well. And there’s a lit­tle bit of work that needs to be done in the reflec­tor to con­vert from mul­ti­cast back into uni­cast for the Macintosh par­tic­i­pants. But yes, in the very short term we’re hop­ing that a user on a Mac and and a user on a Sun could actu­al­ly talk back and forth to each other.

Malamud: Your tool nv and CU-SeeMe both are video-only solu­tions. Why aren’t you doing audio as an inte­gral part of this tool?

Frederick: The intent of writ­ing nv was to add to the exist­ing research efforts on the MBone. And there was already some­one, in this par­tic­u­lar case Van Jacobson and Steve McCann at LBL, doing a very nice audio tool. So rather than try­ing to dupli­cate their effort, I want­ed to write some­thing that would be a com­pan­ion pro­gram. And in typ­i­cal use, you actu­al­ly run a vat and an nv side by side. And you don’t get the syn­chro­niza­tion between the audio and the video. At least you don’t get explic­it syn­chro­niza­tion. But, it’s sort of good enough for now, and the pro­to­cols we’re design­ing have the right infor­ma­tion in it so that even­tu­al­ly you could do lip sync and all of the oth­er things that you want it to do. 

As far as a pro­fes­sion­al, pol­ished appli­ca­tion long-term, I def­i­nite­ly see a case where you have a sin­gle user inter­face that pro­vides both video and audio. It’s just more expe­di­ent for the research to keep them separate.

Malamud: Now, you said that the pro­to­cols you’re design­ing will even­tu­al­ly let these things sync togeth­er. Is there an under­ly­ing pro­to­col that both nv and vat use?

Frederick: Yeah. There’s a par­ti­cle called RTP, which stands for Real-time Transport Protocol. And that’s some­thing that’s being stan­dard­ized in the IETF com­mu­ni­ty right now. It sup­ports both video and audio, and could be used for oth­er things as well. For exam­ple, a shared white­board appli­ca­tion might imag­ine using RTP. And—

Malamud: Now, is RTP a replace­ment for IP? Is it a replace­ment for TCP? What lev­el of the net­work stack does this live?

Frederick: It can run on top of sev­er­al dif­fer­ent trans­port pro­to­cols. The appli­ca­tions that we’re using right now, almost all of them run RTP on top of UDP, on top of IP. But it’s designed so that if you have a fair­ly rea­son­able end-to-end trans­port pro­to­col you can lay­er RTP on top. In that sense, call­ing it a trans­port pro­to­col is some­what strange. It’s almost more of a pre­sen­ta­tion lay­er pro­to­col, if you believe in the OSI stack.

Malamud: And what does it do? I mean, obviously…we’re famil­iar with some­thing like TCP does. What does RTP add to the UDP datagrams? 

Frederick: What it’s intend­ed to do is pro­vide syn­chro­niza­tion infor­ma­tion, time­stamps, sequence num­bers, um…some com­mon way of express­ing the for­mat that the pack­et might be in, what kind of video or what kind of audio it is. And enough infor­ma­tion about the par­tic­i­pants that you can form a light­weight con­fer­ence of some sort where every­one knows about every­one else and knows how to decode the streams as they receive them.

Malamud: Ron Frederick, we’ve been talk­ing about video and audio on the Internet. The cur­rent struc­ture for the MBone allows any­one to bring in nv, and if you have the right video card any­one to become a TV station. 

Frederick: That’s true.

Malamud: And there’ve been times when two or three video streams at the net at the same time, and the MBone starts to col­lapse a lit­tle bit. Is this just a tem­po­rary grow­ing pain or are we gonna have to solve the prob­lem? Are you gonna have to have a license in order to be able to trans­mit nv?

Frederick: [laughs] That’s a very inter­est­ing ques­tion, and you’re right, we have had prob­lems already about some kind of con­gest­ed over­loads when we have sev­er­al dif­fer­ent things run­ning at once. 

I don’t think you could pos­si­bly do some­thing on the order of an FCC license in a world like the Internet. It’s just real­ly not fea­si­ble to do that sort of thing. But there are def­i­nite­ly efforts going on in the com­mu­ni­ty to try to deal with resource reser­va­tion issues. And there are also efforts going on on a slight­ly dif­fer­ent tack of, if you notice from the reports you’re get­ting back from your receivers that you’re get­ting a large amount of loss, you can adapt the amount of band­width you use, so that everyone—if they all play nicely—can actu­al­ly pro­duce some­thing that will get rea­son­able results.

Malamud: Is this auto­mat­ic, or is built in…is this some­thing that the per­son has to do who’s doing the transmitting?

Frederick: In that sec­ond case that’s some­thing auto­mat­ic in the tool that they’re using to trans­mit. So, if there are five peo­ple in a con­fer­ence and a sixth one joins, all six of them might start using slight­ly less band­width than the five were before. So the total amount of band­width remains rel­a­tive­ly con­stant. And could even vary over time based on oth­er loads that’re on the network. 

So, both of those solu­tions are being looked at. And the resource reser­va­tion solu­tion is much nicer in terms giv­ing you guar­an­tees about what kind of qual­i­ty you can get, but has a lot of addi­tion­al prob­lems about well, what stops me from just ask­ing for a reser­va­tion for 100 megabits, or a giga­bit, right? There need to be oth­er fac­tors that cause me not to reserve more than I actu­al­ly need, or could afford, or some­thing like that. So those are much hard­er problems.

Malamud: And how are we going to tack­le those? Do we have some indi­ca­tions of…I know peo­ple like David Clark have been exam­in­ing these issues. What are some strate­gies that you think look promising?

Frederick: It’s a real­ly tough issue. And I think long term the only right solu­tion is going to be an eco­nom­ic one. That you’re going to have to start look­ing at this as you pay for what you use. If not, you pay for what you ask for. And I don’t real­ly see that the Internet could grow uncon­trol­lably with­out even­tu­al­ly involv­ing some­thing like that. But I do think there are good tech­ni­cal solu­tions that will get us by in the short term that don’t require all of that mech­a­nism. And it’s impor­tant that we con­tin­ue to research this as well.

Malamud: Some peo­ple say that doing TV on the Internet is sil­ly because we only do bad TV. And we should just stop doing that and do elec­tron­ic mail or some­thing else. Are you… Do you see a day when tele­vi­sion streams run over a general-purpose Internet infrastructure?

Frederick: I guess—

Malamud: Is CNN gonna use this mech­a­nism that you’re work­ing on now?

Frederick: I guess I don’t see why the tele­vi­sion broad­cast indus­try is any dif­fer­ent than any of the oth­er things that we’re talk­ing about doing even­tu­al­ly. Putting tele­phone on the Internet is some­thing else that has come up in the past. And putting oth­er types of reg­u­lar data ser­vices but at much high­er band­widths on the Internet has come up. And it real­ly seems to me that hav­ing dif­fer­ent infra­struc­tures for each of these things does­n’t make any sense. That if even­tu­al­ly all of our cam­eras are digital…then it’s all bits. And why should those bits be car­ried in a dif­fer­ent way just because these are tele­vi­sion bits instead of high-quality x‑ray image bits, or god knows what else. So, I do see, long-term, an inte­grat­ed net­work of some sort of mak­ing a lot of sense.

Malamud: I read an arti­cle in one of our new trade press pub­li­ca­tions about the Internet. And the head­line was ​“MBone Offers Low-cost Tool for Business Communication.” [Frederick chuck­les] The impli­ca­tion being you would place your phone calls over the Internet. Now, you and I know that it’s much more expen­sive right now to use the Internet to place a phone call. Certainly as a sys­tem cost if not the cost to the user.

Frederick: Yes.

Malamud: Is it going to be cheap­er to run a voice call over the Internet than it would be in the under­ly­ing infra­struc­ture? Just pick up the phone and dial?

Frederick: I think that if you had an inte­grat­ed net­work, there would be very nice economies of scale. That the fact that you had all these very very high-bandwidth links between all the dif­fer­ent sites, and you had a com­mon high-bandwidth link that could be shared for lots of dif­fer­ent amounts of data, would allow some­thing as low-band­width as a phone call to go through incred­i­bly cheap­ly. You could almost fit it into the holes that exist in high-bandwidth streams. You know oh, file trans­fer I start­ed will take ten extra sec­onds because I decid­ed to talk on the phone at the same time. But we used the same link and actu­al­ly there weren’t any addi­tion­al resources beyond that ten extra sec­ond delay.

Malamud: Right now we live in a world in which our demands for band­width are tru­ly infi­nite. We will take any­thing they’ll give us, right now. You got a T1? I want a T3. Is that gonna peak? Is there some break-even lev­el there where peo­ple stop ask­ing for more band­width and we’re able to steady-state this thing?

Frederick: Well, for any giv­en appli­ca­tion, there are human per­cep­tion lim­its at which more band­width does­n’t help. So, it’s cer­tain­ly true that a video stream is going to get to a point where you’ve got so much band­width that there’s no point in using more for that one video stream. But, I real­ly don’t see a lim­it from the long-term per­spec­tive of what we want our net­works to do. 

Malamud: Well an HDTV stream is 22 mil­lion bits per sec­ond, I believe? Somewhere in that range?

Frederick: In the com­pressed case that’s about right, yeah.

Malamud: Okay. And so…an indi­vid­ual home, what’s gonna be the…a hun­dred mil­lion bits per sec­ond, is that enough into the home, a bil­lion bits per second?

Frederick: Well, if you real­ly want that file which is across the coun­try to become some­thing that’s on your local machine and you want it in one sec­ond, and you can use an arbi­trar­i­ly large amount of band­width to get it there, right, the ques­tion is how long are you will­ing to wait for the ser­vices that you’re ask­ing for. 

Malamud: And how much you—

Frederick: As well as how many ser­vices you want to be able to run at the same time. And so, if you could give me two giga­bits to my house I’d be pret­ty hap­py. I won’t say that I would be hap­py for­ev­er. There may be some appli­ca­tion some day which will want more than that.

Malamud: Ron Frederick, we’ve been talk­ing about audio and video and the poten­tial for doing video con­fer­ences on the net and audio con­fer­ences. Right now, that’s a fair­ly lim­it­ed audi­ence. It’s a very tech­ni­cal group that uses the MBone as a gen­er­al rule. There’s occa­sion­al times when things like the Global Schoolhouse Project would show up there.

Frederick: right.

Malamud: Um… Is there a time when this is going to be a tool for shared work? You’ve talked about some projects at Xerox PARC like Jupiter. Maybe you can describe some of the visions of where these tools might be going.
19.48
Frederick: One of the prob­lems with the tools as they exist today is that the tools them­selves were writ­ten by very tech­ni­cal peo­ple with oth­er very tech­ni­cal peo­ple in mind to use them. They’re not all that com­fort­able if you just sort of want to walk up to the machine and say ​“I wan­na talk to him over there.” You have to know all these strange things about the way the MBone works, and make sure you pick up the tools via FTP and install them at your local site and so on and so forth. And if you try to present that to a slight­ly less technically-inclined audi­ence it’s easy to turn them off. 

So, one of the research projects at Xerox is to try to take that tech­nol­o­gy and hide some of its rough edges a lit­tle bit more. Provide a sim­pler user inter­face, a sim­pler mod­el for how all this works. So that it feels a lot more like how you inter­act with peo­ple nor­mal­ly in your every­day work envi­ron­ment. And Jupiter is a project to take some of the things that we’ve learned about the virtual…“social vir­tu­al real­i­ty” is sort of the gener­ic key­word that we often hear in that case. Some of the things that we’ve learned about the text-based con­fer­enc­ing sys­tems that pro­vide you with a vir­tu­al world that you can wan­der around in and meet peo­ple and talk to them in, and add the advan­tages of mul­ti­me­dia to that. 

Malamud: Is it the MOOs, and the MUDs

Frederick: The MUDs and the MOOs and all of that sort of thing, yes, exact­ly. So, what we have on Jupiter is a MOO as the very base environment—

Malamud: MOO who stands for what?

Frederick: MOO is ​“MUD, Object-Oriented.” And MUD is ​“Multi-User Dimension,” or ​“Multi-User Dungeon” if you believe its gam­ing origins.

Malamud: So in the text case, you say things…you get a descrip­tion in front of you say­ing ​“You are stand­ing in a hall­way,” and you type in ​“Open the door,” and it says ​“You’re in a room with a guy named Joe,” and you say ​“Hello, Joe.” That’s the MUD, right?

Frederick: Yes, that’s a pret­ty good descrip­tion of it. If you’ve ever played the old Zork adven­ture games or things like that, it’s a lot like that except that instead of only hav­ing you in the world with some computer-generated char­ac­ters you have more than one real per­son. And so, yes, as you wan­der around, you go north and it’ll give you anoth­er descrip­tion. It’ll say ​“Somebody is here” and you can then speak to that per­son. And what­ev­er you say, your text will appear on their screen and vice versa. 

Malamud: So Jupiter is a MOO on steroids?

Frederick: To a cer­tain extent, yeah. What we’ve done with it is we’ve tak­en that envi­ron­ment as the base, and we’ve added to it audio, and video, and a graph­i­cal user inter­face where instead of just being able to run an X appli­ca­tion on my local machine which only I can oper­ate, a win­dow will appear on my local machine whether I’m run­ning X or a Macintosh envi­ron­ment or a PC Windows envi­ron­ment, what­ev­er, that this cen­tral­ized sys­tem that con­trols all the dif­fer­ent users in the world is con­trol­ling. so, I might open a white­board which is an object in my vir­tu­al office in the sys­tem. But some­one else is also on the sys­tem and also in my vir­tu­al office, they can open that white­board, too. And if I make a mark on it they see that mark. 

Or there might be an away board which says who’s on vaca­tion and gets updat­ed dynam­i­cal­ly in this world. And if I tell the sys­tem to open the away board a lit­tle win­dow pops up that shows me every­one who’s away.

Malamud: So it’s a shared work­space moved on to your com­put­er screen.

Frederick: That’s right. The hope is that even­tu­al­ly this will become sim­ple enough and com­fort­able enough that I could actu­al­ly sit at home and it would­n’t be any dif­fer­ent than me sit­ting in my office, for the peo­ple at least that are at the oth­er end of the build­ing that would have a hard time vis­it­ing me in per­son any­way. In fact we’ve had con­ver­sa­tions where two peo­ple are at home, the third per­son might be in the office, and the fourth per­son is some­where else off on the Internet. And we’re all talk­ing to each oth­er just by wan­der­ing around in this vir­tu­al world. We get shared audio chan­nels just because we’re in the same room. And there isn’t any spe­cial but­tons we have to push or spe­cial pro­grams we have to run to get it.

Malamud: So your screen has a map of the office, and you click on a room and you go in there, and you see peo­ple? I mean, do you actu­al­ly see their images?

Frederick: In the case where we’re run­ning video, yes. You see some low frame rate ver­sion of wher­ev­er they cur­rent­ly are if they’re trans­mit­ting video. At the very least you see their name, and if they start speak­ing you see some high­light around that name that indi­cates their speaking.

Malamud: And this is some­thing real. I mean, you actu­al­ly uses at that PARC.

Frederick: That’s right. It’s imple­ment­ed and run­ning today.

Malamud: And can you use it from your home? Is this too much band­width to be able to do this from home?

Frederick: We are able to do it from home over ISDN. What we’ve got set up to sev­er­al peo­ple at PARC is rough­ly a hun­dred kilo­bits’ worth of band­width between work and home. And that’s enough for one low-bandwidth audio stream, one low-bandwidth video stream, and all the rest of the stuff that needs to hap­pen to make the win­dows and the text work.

Malamud: Now, you’re talk­ing about this world at Xerox PARC. In the Internet Engineering Task Force peo­ple go to meet­ings three times a year, and there is some effort to use the MBone to actu­al­ly you know, send some of the sig­nals out. But the peo­ple on the remote ends are real­ly view­ers, they’re not participants.

Frederick: That’s true.

Malamud: Is the tech­nol­o­gy you’re talk­ing about in the Jupiter project some­thing that we can scale onto a glob­al Internet? Or is only going to be with­in let’s say a small cor­po­ra­tion or you know, kind of an iso­lat­ed island?

Frederick: We hope that the band­widths required, espe­cial­ly since we’re work­ing over such low-bandwidth things as ISDN, are things that the glob­al Internet could han­dle. But it does have the same scal­ing prob­lems that the cur­rent MBone tools do in that if you have a hun­dred of these streams or a thou­sand of these streams all run­ning at the same time, you need a lot of back­bone band­width to make it all work. 

And there are a lot of oth­er tech­ni­cal prob­lems we have yet to solve in terms of echo can­cel­la­tion, and…audio is hard, as you prob­a­bly know from run­ning the show. And so it’s dif­fi­cult to make it real­ly as com­fort­able to work from home or you know, instead of attend­ing the meet­ing in per­son to sit in your office and try to attend, today. It’s dif­fi­cult to get the same ben­e­fits as you would being there in person.

Malamud: But it’s still usable. It’s like the ear­ly modems, the 300 baud modems that were…you know, if that’s all you had you kin­da get used to ​’em I guess.

Frederick: That’s right. And the intent of the research is to make it more and more com­fort­able, to make it clos­er to actu­al­ly being there.

Malamud: Now one of the things I noticed with 300 baud modems is they were fine as long as I did­n’t have any­thing else. And the minute I got up to 9600 bits per sec­ond, 300 was too painful to even both­er using. I mean, I would occa­sion­al­ly if I real­ly real­ly had to. You work at Xerox PARC and you’ve got all these won­der­ful tools. What do you do when you go on the road? Can you no longer get any work done, or are you able to fall back and—

Frederick: That’s an inter­est­ing ques­tion. And I have to say that so far, the MBone has not become quite as much of my every­day life as some­thing like email has. I mean, when I go on the road if I’m away from email for two weeks I go nuts. That real­ly has become some­thing that I absolute­ly need to get my work done. And right now, Jupiter and the oth­er MBone tools or things that are very very con­ve­nient. I mean I can have very pro­duc­tive con­ver­sa­tions with peo­ple on the oth­er coast or down in Los Angeles or what­ev­er that prob­a­bly in the long term have saved me a few plane trips. But, we can still do the work via email if we have to, it’s just some­times not as convenient. 

Longer term, that may change. I mean, it may get to the point where you sort of assume that IETF has…since its only meet­ing a few times a year and that’s not often enough, you have to have some­thing like the MBone to real­ly con­tin­ue to do work as effectively. 

Malamud: I’ve heard argu­ments that the Internet is very nice but we’re spawn­ing a group of elite peo­ple. That most peo­ple don’t even have email, how can we pos­si­bly be talk­ing about these oth­er things. Are you find­ing you can still relate with an engi­neer who does­n’t use email, for exam­ple? Can you work with a com­put­er sci­en­tist that does­n’t have elec­tron­ic mail?

Frederick: I can, though I have to admit it’s some­what painful. I’ve dealt with some of the sup­port peo­ple at var­i­ous com­put­er ven­dors, that the only way to reach them is by call­ing this 800 num­ber and wait­ing on hold for twen­ty min­utes, and only find­ing out after all that time that they’re actu­al­ly not in their office after all, and you have to leave them a voice­mail mes­sage and they’ll call you back two days lat­er. And com­par­ing that to just spend­ing a minute send­ing them some email which gives them the same information…there’s no con­test. I mean, clear­ly email is the win.

Malamud: Now what about the email-to-MBone prob­lem? Are we cre­at­ing a core of elite on the Internet that have MBone access and for­get­ting about wide-spread computing?

Frederick: I would hope not. I think the efforts toward things like the National Information Infrastructure, and the deploy­ment of net­work­ing tech­nolo­gies like ISDN and so forth are rais­ing the low­est com­mon denom­i­na­tor. You know, it’s true today that if you’re at all involved in com­put­er net­work­ing or remote access with com­put­ers, you don’t buy a 300 baud modem. You buy a 14.4 kilo­bit modem. And the economies of scale have got­ten to the point where buy­ing any­thing less than that just does­n’t make sense from a cost per­spec­tive. And hope­ful­ly it won’t be too long before buy­ing ISDN or some­thing bet­ter than ISDN is so cheap that you would­n’t even think about buy­ing a modem. And that real­ly does seem like a tech­nol­o­gy we can deploy to every home. We already have at least 20 mil­lion users in the world who have email. And that’s prob­a­bly a low estimate.

Malamud: 20 mil­lion peo­ple can’t be wrong, right?

Frederick: [laugh­ing] No. Hopefully the same will be true with these oth­er technologies.

Malamud: Well there you have it. We’ve been talk­ing to Ron Frederick, and this is 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­tent or make a deriv­a­tive work. 

Support for Geek of the Week comes from Sun Microsystems. Sun, mak­ers of open sys­tems solu­tions for open minds. 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. Additional sup­port is pro­vid­ed by HarperCollins and Pearsall. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by UUNET Technologies, and MFS DataNet.

Geek of the Week is pro­duced by Martin Lucas, and fea­tures [?], our house band. This is Carl Malamud for the Internet Multicasting Service, flame of the Internet.