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

Malamud: This is Geek of the Week. We’re talk­ing to Geoff Baehr, who is the Chief Technical Officer for Networking. He also has the amaz­ing title of Director of Networking and Commerce, I believe, at Sun Microsystems. Welcome to Geek of the Week, Geoff.

Geoff Baehr: Thanks, Carl. It’s a plea­sure to be here.

Malamud: You are well-known for advo­cat­ing the use of ATM as a local area net­work. Why would I want to use this very com­plex tele­phone company-developed tech­nol­o­gy instead of let’s say, Ethernet?

Baehr: Well actu­al­ly pre­cise­ly because it is a tele­phone tech­nol­o­gy. And unlike Ethernet in its ear­ly days, one can take advan­tage of the fact that dozens if not hun­dreds of tele­pho­ny research labs and tel­cos around the world have been devel­op­ing this tech­nol­o­gy since the mid ​’80s. And one can dive in and rec­og­nize that the abil­i­ty to take this tech­nol­o­gy and apply it to the local area net and to lever­age off of all of the work that was done could have some sub­stan­tial changes in what’s going on in networking.

Malamud: Well, using that strat­e­gy I would think that you’d use that same log­ic for let’s say ISDN. Why aren’t are we using ISDN as a LAN?

Baehr: Well actu­al­ly when we looked— A cou­ple years ago sev­er­al peo­ple were look­ing around at what the next tech­nol­o­gy might be. And the cri­te­ria were to have some­thing that was scal­able, and also some­thing where the fun­da­men­tal tech­nol­o­gy in the local area net and the wide area net was not dif­fer­ent. And ISDN did­n’t meet the criteria. 

Malamud: Why is not dif­fer­ent a goal? Why does it mat­ter? I mean, do we want a sin­gle uni­form data link for all things?

Baehr: Well that’s right. What we refer to here is we’ve drop the W or the L of wide area or local area net—WAN and LAN—we just call it AN, A Network. And the goal here is to use the same tech­nol­o­gy across the wide area as well as in the local area, and have the wide area net end at your desk­top. Because we can then pre­serve the char­ac­ter­is­tics of trans­mis­sion speed and laten­cy and such across any link. Right now, I don’t know about you but I’m painful­ly aware when I cross that T1 router off into my Ethernet or FDDI net­work. I’m painful­ly aware of the fact that I’m doing that cross. And I don’t want that anymore.

Malamud: That’s just a mat­ter it seems not of the inter­face but of sim­ple raw bandwidth. 

Baehr: Well it’s also con­cerned much more, and it will be con­cerned more in the future, with laten­cy con­trol and sig­nal­ing trans­ac­tions to deter­mine the amount of band­width one can reserve and to deter­mi­nate the end-to-end delay and some of the oth­er char­ac­ter­is­tics that future apps will want to have.

Malamud: Tell me a lit­tle more about that. Why would I want to con­trol for exam­ple the laten­cy of my link, and how would I do that?

Baehr: Well actu­al­ly this is one of the areas that is being researched, is how does one deter­mine the end-to-end laten­cy. Moreover, how do you ensure that laten­cy does­n’t fluc­tu­ate? That there’s very lit­tle jit­ter in the deliv­ery. This would be impor­tant for deliv­er­ing things such as video. But I mean like, video is kind of the no-brainer, if you well. I much pre­fer to con­cen­trate on real-world apps such as mul­ti­cas­t­ing, and appli­ca­tions that use multi-casting, I should say. 

And we’ve thought about sev­er­al. What if one were able to mul­ti­cast data­base updates to data­base servers? And do this with­in a time-bounded latency-guaranteed mech­a­nism. This would change the way that peo­ple run par­al­lel data­bas­es. And you could do things such as think of it in the stock mar­ket set­ting, where one could go out and those who are able to mul­ti­cast data­base updates regard­ing stock prices in 100 mil­lisec­onds would be sub­stan­tial­ly ahead of those folks who were wait­ing for a stan­dard trans­mis­sion to occur in a best-effort approach. Arbitrage against time.

Malamud: I’ve seen peo­ple already mul­ti­cas­t­ing Usenet news. People have been mul­ti­cas­t­ing images from NASA as JPEG data. And so basi­cal­ly you tell your grab tool on the MBone that ​“Hey, I want the next pho­to that comes by.” Do we have to fun­da­men­tal­ly change that cur­rent par­a­digm in order to be able to do—you’re talk­ing rela­tion­al data­bas­es and trans­ac­tion, time-bounded operations. 

Baehr: Well actu­al­ly what we have to change is the way that peo­ple enter and leave mul­ti­cast groups. Because right now mul­ti­cast groups are sta­t­ic, and the copy­ing and retrans­mis­sion of mul­ti­cast data is also done pret­ty much in a sta­t­ic sense, in that the inbound to out­bound map­ping is set up at the par­tic­u­lar con­fig­u­ra­tion time that the machine is set up. And we would very much like to be able to change that and say any per­son can join or leave any mul­ti­cast group, depend­ing upon their par­tic­u­lar inter­est or their needs. 

Malamud: And their secu­ri­ty, of course.

Baehr: Yeah, of course. And there’s always the left­over of security. 

Malamud: That will be deter­mined at a future document.

Baehr: [laughs] That’s right. Actually it will be deter­mined in a doc­u­ment which will be clas­si­fied and kept secret.

Malamud: Well, the nice thing about secu­ri­ty is obscu­ri­ty. When you’re talk­ing about mul­ti­cas­t­ing, the cur­rent mul­ti­cast back­bone shares band­width with the rest of the Internet. And if some­one starts to do a large file trans­fer, for exam­ple, it can take away bits that the mul­ti­cast envi­ron­ment had. How are we going to guar­an­tee band­width? Or are we?

Baehr: Well let me— And this is one of the prob­lems that is kind of fun­da­men­tal that remains to be solved with ATM. People seem to believe that these prob­lems have already been ful­ly thought out on the solu­tions are at hand, and they’re not. And the prob­lem is more pre­cise­ly, how do I guar­an­tee if I open up the fifth appli­ca­tion on my work­sta­tion that requires mul­ti­cas­t­ing, not that I’ve dam­aged myself, but that some­one on the oth­er side of the world does­n’t have their appli­ca­tion drop off the face of their work­sta­tion because I’m con­gest­ing their switch? Or that their switch is being called on to do the copy­ing of yet anoth­er mul­ti­cast stream, and it exceeds the capa­bil­i­ty of that switch. 

And there are var­i­ous schemes that peo­ple are research­ing right now for actu­al­ly reserv­ing band­width, and that’s what it real­ly comes down to. How do you make a request for band­width, and then enforce it? And then if you don’t sub­scribe, or you don’t fol­low the request that you made, what is the penal­ty? And the penal­ty usu­al­ly is your pack­ets get dropped, or your cells get dropped. How do we enforce that on a network-wide basis, and make that apply to the new apps?

Malamud: You’re talk­ing about the wide area and the local area net­work are the same, pre­sum­ably ATM. Why are we doing mul­ti­cas­t­ing at the Internet lay­er instead of build­ing that into our ATM switches? 

Baehr: Well the ques­tion real­ly is where is the inter­face, and where is the trans­la­tion going to occur? I should­n’t say the trans­la­tion as much as, how is one going to treat ATM? Just as a fat­ter pipe? Which is prob­a­bly what’s going to hap­pen, with per­ma­nent vir­tu­al cir­cuits in the begin­ning, as opposed to SVCs. If you treat it as a fat­ter pipe, then you’re run­ning the cur­rent suite of Internet pro­to­cols on top of it. Therefore you can’t guar­an­tee that each one of the switch­es in the inter­ven­ing dis­tance in an inter­ven­ing net­work is going to sup­port all the capa­bil­i­ties that you want. For this rea­son, the fat­ter pipes evolve, peo­ple bridge their cur­rent traf­fic or route their cur­rent traf­fic over this fat­ter pipe, and we’re stuck with the cur­rent model.

Malamud: Well again, if we’re look­ing at where do we build a func­tion in, we could be doing mul­ti­cas­t­ing at the IP lay­er. If that’s the case, why are we using ATM at all? Why don’t we just build IP on top of let’s say the Synchronous Optical Network, SONET, and just use raw bandwidth?

Baehr: Alright, this is one of the fun­da­men­tal prob­lems. People don’t seem to real­ize that the inher­ent mul­ti­plex­ing capa­bil­i­ty should be at the ATM lay­er, where one is able to push the prob­lem off of copy­ing and such into the switch­es and let the hard­ware do the copy­ing for you before you have to deal with it at the net­work lay­er. And this is I believe the right way to go. However, peo­ple always take the path of least resis­tance, and they’ll go and do IP mul­ti­cas­t­ing at the net­work lay­er because that’s what’s here right now. No one knows how to do ATM copy­ing, cell copy­ing, and mul­ti­cast group admis­sion and make that work in a very large net­work. So peo­ple will go with what they’ve got.

Malamud: Geoff Baehr, you do work­ing for Sun Microsystems and it seems to me that you have some fun­da­men­tal con­flicts. For exam­ple your prod­ucts have to be secure, yet they have to be easy to use. How does an appli­ca­tion like let’s say Mosaic in the World Wide Web inter­act with secu­ri­ty when you’re think­ing about what your net­work prod­ucts look like?

Baehr: Well maybe I could give you the view­point from how we run our net­work here at Sun, which is total para­noia with our con­nec­tion to the out­side world. And the secu­ri­ty now is large­ly dealt with—entire­ly dealt with by application-level gate­ways and these essen­tial­ly store-and-forward relays that take appli­ca­tion data from one side and hand it to the oth­er with­out any IP for­ward­ing built into the ker­nel with IP for­ward­ing turned off. That’s how peo­ple like to have their secu­ri­ty right now, because there isn’t any oth­er solution.

Malamud: So my mail mes­sage hits your out­er gate­way and your out­er gate­way hands it to your inner gate­way and sends it on in.

Baehr: That’s correct.

Malamud: How is that secure? How is that…solving any­thing that—

Baehr: This is the usu­al moat defense, which by putting in as many bar­ri­ers as pos­si­ble with­out for­ward­ing pack­ets, with hav­ing only spe­cif­ic ser­vices lis­ten­ing on the router machines and on the gate­way machines, we hope to have a lit­tle secu­ri­ty. In real­i­ty, what should be required and what should be installed is what I kind of call the ulti­mate fire­wall, which is real­ly a packet-tracing util­i­ty that has some heuris­tics built in. And if that packet-tracing util­i­ty sees—and I will leave it to the lis­ten­er as an exer­cise to deter­mine what ​“bad pack­ets” are—but if this trac­ing util­i­ty sees ​“bad pack­ets,” it should do some­thing. And the some­thing is either erad­i­cate the incom­ing pack­et or nev­er let an ACK to a SYN out onto the net­work so no one sees that there is any pos­si­bil­i­ty of hav­ing a con­nec­tion, that there’s a serv­er sit­ting there.

And that’s the ulti­mate approach. However unfor­tu­nate­ly, no one’s built one of those yet.

Malamud: It would seem that in addi­tion there’s one oth­er very use­ful thing. If we had strong authen­ti­ca­tion on the net­work and we knew that it was Geoff Baehr com­ing from some oth­er place, we would let Geoff in, and his pack­ets and let him do what­ev­er he wants. And if it’s some ran­dom stu­dent, maybe that stu­dent would go off to some pub­lic archive instead. Is strong authen­ti­ca­tion some­thing that will help solve some of these fire­wall problems?

Baehr: Yes, how­ev­er it should be rec­og­nized that the strong authen­ti­ca­tion… You’re real­ly refer­ring to two dif­fer­ent mod­els. One is authen­ti­cat­ing the host com­ing in. But since IP address­es aren’t tied to any notion of a par­tic­u­lar host loca­tion or who’s using that host, there also has to be authen­ti­ca­tion of the indi­vid­ual users. And this get direct­ly into the issue of what type of iden­ti­fi­ca­tion do you car­ry as a user to iden­ti­fy you to a machine, and more impor­tant­ly how do you iden­ti­fy a machine end-to-end to a fire­wall or to a gateway? 

And the ques­tion that we’ve been look­ing at is, how do you reduce the nec­es­sary infor­ma­tion down into some­thing that peo­ple will accept? Is it some­thing that you want embed­ded in the machine? Probably not. Is it some­thing that the peo­ple car­ry with them, like a smart card? Maybe. Is it a very long pass­word or some type of RSA key that they car­ry around? That’s also possible. 

But the ques­tion comes down to is it going to be peo­ple or machines, and the answer is it’s going to be both that are authen­ti­cat­ed. And the machines them­selves will have to have some type of mech­a­nism to bind their IP address with a par­tic­u­lar cer­tifi­cate that says ​“Yes, I indeed am the cor­rect machine at this address. I’m not spoof­ing you.” But sec­on­dar­i­ly, the peo­ple who use the machine to what you real­ly want to authenticate. 

Malamud: So for the machines it seems pret­ty sim­ple, you just buy your­self a Clipper chip and put it on your machine, right?

Baehr: Well, uh…the Clipper chip uh, to put it mild­ly I don’t think is the right answer. And we and a num­ber of oth­er peo­ple have been very strong in our oppo­si­tion to this. And—

Malamud: What’s wrong with the clip­per chip?

Baehr: If you’d like to have the gov­ern­ment spy on you from now until the end of time, go ahead and use Clipper chips. Because the prob­lem with Clipper I don’t believe is relat­ed to the fact that they can read your infor­ma­tion as much as the fact that they want to ana­lyze your traf­fic. Because traf­fic analy­sis is much more impor­tant than the actu­al infor­ma­tion con­tained, in many instances. 

Also, I don’t trust the gov­ern­ment to hold— Nah, I don’t real­ly care about the keys as much as the infor­ma­tion that’s derived from using the keys. I don’t believe that with­in the way the gov­ern­ment works that there’s any secu­ri­ty in the data that the gov­ern­ment is going to col­lect. And unless that data is kept classified—and by the way, I have no desire to increase the amount of clas­si­fied data around the world—I have absolute­ly no faith that this infor­ma­tion will be kept secret. And I pose the ques­tion, if Clipper had authen­ti­cat­ed the con­ver­sa­tions between Tonya Harding and Gillooly, how long do we think that those con­ver­sa­tions would remain private?

Malamud: So it sounds like you have two wor­ries. One is that the key escrow mech­a­nism is not a reli­able one. That we can’t keep that key secret.

Baehr: That’s correct.

Malamud: But also it sounds like you were hint­ing that even if we could­n’t get the key we might be able to break that encrypt­ed information?

Baehr: Well. I actu­al­ly— And no, I think that even if the keys were kept secret and were being used by a law enforce­ment agency, I have no faith that the infor­ma­tion that was derived will in itself be kept secret, and will be kept pri­vate. In oth­er words, the con­ver­sa­tions that you and I have over the tele­phone dur­ing the day, I have no faith that that’ll be kept secret until the end of time. And more impor­tant­ly I don’t like the fact that the gov­ern­ment holds the mech­a­nism to read my pri­vate data and my pri­vate voice traf­fic. And if that data has been record­ed, the gov­ern­ment has the abil­i­ty to replay that or attack that infor­ma­tion from now until whenever.

Malamud: Is there a bet­ter solu­tion for authen­ti­cat­ing hosts? Is it just a mat­ter of they should­n’t have the back­door key, or is it a mat­ter of there should­n’t be a uni­ver­sal stan­dard and… I’m try­ing to under­stand what it’s gonna take to authen­ti­cate hosts and at the same time pre­serve the indi­vid­ual pri­va­cy and freedom.

Baehr: Well I think the first prob­lem is that an algo­rithm should be used which is under­stood, and has a rea­son­able chance of not hav­ing a trap­door or back­door built into it. Secondarily, I think that the algo­rithm should employ keys that are main­tained by the user. And this should be a stronger form of authen­ti­ca­tion than what the gov­ern­ment is employ­ing. Of course we’re trad­ing off the abil­i­ty to authen­ti­cate and also to encrypt those con­ver­sa­tions that are pri­vate with those that might dam­age the secu­ri­ty of the coun­try. Where do you call the indi­vid­ual— Where do you draw the line as to what should be bro­ken and what shouldn’t? 

To get back to the ques­tion, what do you want for an algo­rithm? You want some­thing that’s pub­lic, you want some­thing that’s ver­i­fi­able, and you want some­thing where the keys can be freely exchanged and can be updat­ed. And also bad keys can be declared to be bad so that peo­ple don’t use keys which have been invalidated.

Malamud: Is this an area where the gov­ern­ment should be issu­ing the keys to peo­ple? Is this some­thing where each indi­vid­ual can go ahead and use what­ev­er they want? Do we need a stan­dard type of certificate?

Baehr: We need a stan­dard so that peo­ple can write pro­grams which use authen­ti­ca­tion and expect a par­tic­u­lar key size or a par­tic­u­lar key mech­a­nism to be used. Regarding how the keys are gen­er­at­ed, there also has to be a stan­dard to ensure that the keys are suf­fi­cient­ly ran­dom and that there are cer­tain char­ac­ter­is­tics of the key gen­er­a­tion algo­rithms which in them­selves are not weak­ened pure­ly by pro­gram­ming error and by lack of knowl­edge. But the actu­al key them­selves should be kept pri­vate. People should be able to retain their own key and do with it as they wish. 

Malamud: How do we pre­serve all those things like mak­ing sure they’re are ran­dom and safe and good, and still let any user go ahead and gen­er­ate their own? Are there laws that say ​“Thee shall not gen­er­ate a bad certificate?”

Baehr: Well actu­al­ly they’re not— Yes, they’re called math­e­mat­i­cal laws, and the algo­rithms if they are employed, one can deter­mined using var­i­ous tests whether algo­rithms used to cre­ate the keys are good. 

The ques­tion here is not so much that the keys them­selves are impreg­nable, but the fact that one should be able to change the key upon demand. You as a user should be able to do what you wish in terms of encryp­tion. And I’d add at this point that it’s ludi­crous for the US gov­ern­ment to believe that by man­dat­ing a scheme that’s applic­a­ble in the US, that the rest of the world won’t go and do exact­ly what they want, which is imple­ment a scheme which they find to be flex­i­ble and strong. And to this end, there are sev­er­al dozen schemes which are float­ing around the net, out­side the US, for both authen­ti­ca­tion and encryp­tion. And peo­ple are using these right now. And do we have any belief that man­dat­ing a stan­dard in the US, or man­dat­ing a gov­ern­ment approach in the US will cause this to change? I don’t think so.

Malamud: So it sounds like we’re real­ly not going to be able to leg­is­late indi­vid­ual behav­ior, and when we’re talk­ing about how you secure your vir­tu­al per­son, it’s like hav­ing the gov­ern­ment say you should­n’t spit on the side­walk. You can pass laws like that, but there’s a lim­it as to how much peo­ple will actu­al­ly listen.

Baehr: I’d also say that the gov­ern­ment will cer­tain­ly find out in a short order that the peo­ple who are bad will not be using their approved encryp­tion mech­a­nism. And even if they do, they’ll prob­a­bly encrypt the data before they even apply it to a Clipper chip.

Malamud: So you do your first encryp­tion, and then you hand it off to Clipper and say, [crosstalk] ​“Here, do what­ev­er you want.”

Baehr: ​“Here, I have— Thank you very much, have an excel­lent time.” And there are mech­a­nisms that are known to search for encrypt­ed data inside data streams, but you actu­al­ly have to break the data stream first to find out that it’s encrypted. 

Malamud: Well the­o­ry behind Clipper of cours­es is that because the fed­er­al gov­ern­ment is gonna to buy lots of these and every­one in indus­try will fol­low, this seems to remind me of anoth­er government-led stan­dard called GOSIP.

Baehr: I was just going to men­tion OSI. And I see that they’re wav­ing the white flag now. The only prob­lem here is the war isn’t some­thing which is…intrinsically inter­est­ing only to com­put­er sci­ence and net­work­ing peo­ple. This is some­thing which is much more per­va­sive and affects the entire soci­ety. And I hate to have the gov­ern­ment go through all this just to find out that the entire sys­tem has been negat­ed by either some­one reveal­ing the algo­rithm and a trap­door, some­one break­ing it, some­one using their own algo­rithm, what have you. There’s so many avenues to negate this that the gov­ern­ment should actu­al­ly con­cen­trate on things which are much more important.

Malamud: So Clipper might end up being the GOSIP of the 1990s if we’re not careful.

Baehr: And actu­al­ly that’s prob­a­bly a good way of stat­ing it.

Malamud: Geoff Baehr, you’ve been active rep­re­sent­ing Sun in a vari­ety of groups. And as a com­put­er ven­dor you’re the ones that actu­al­ly have to make the stuff. And I guess I’m won­der­ing which groups mat­ter today? Do you lis­ten to the IETF? Do you lis­ten— There are so many groups out there. ATM forums, and SNDS forums, and you know, Interop shows, just to name a few. What part of that feed­back actu­al­ly is use­ful to you in design­ing a product?

Baehr: Well I’d say first of all, stan­dards are good. That’s the gen­er­al atti­tude of the indus­try these days. And one there­fore must have a suf­fi­cient num­ber of peo­ple on every stan­dards body to indi­cate that you too sup­port standards. 

Actually what we found out over time is that the groups that are most effec­tive are ones that come togeth­er as ad hoc coali­tions. And par­tic­u­lar­ly those such as the IETF and the IAB, and groups that are led by peo­ple who actu­al­ly have a prod­uct to ship or who have a stan­dard which affects peo­ple mak­ing mon­ey, either indi­rect­ly or direct­ly. Those groups seem to have a goal, as opposed to some of the open-ended groups which are work­ing on a stan­dard for its own good. And this leads to thrash­ing. And we’ve seen that before. We men­tioned one of the pre­vi­ous pro­to­col suites that has had end­less revisions. 

The efforts which Sun is mak­ing right now in stan­dards are we’re attempt­ing to do the uni­fi­ca­tion of sev­er­al dif­fer­ent fla­vors of Unix and such, because it affects the way we make mon­ey. And also with net­work­ing and data com­mu­ni­ca­tions, we imple­ment those stan­dards and we par­tic­i­pate in those stan­dards bod­ies which are dri­ving ahead and are mak­ing progress. We par­tic­i­pate in many dif­fer­ent bod­ies, but kind of the cri­te­ria that we apply are when is the out­put going to be vis­i­ble? And what does it affect? And does it affect real-world appli­ca­tions that peo­ple want? And if the answer is yes, we should go ahead and push real hard.

Malamud: Well what about the oth­er groups doing vir­tu­al stan­dards that are based on imag­i­nary prod­ucts? Do those groups mat­ter? Do you have to send peo­ple there in self-defense or do you just ignore them?

Baehr: Well this is real­ly the ques­tion of if you don’t go peo­ple can accuse you of not going. So, do you send peo­ple who don’t mat­ter to you from your com­pa­ny, who are prob­a­bly not the top rank? And the ques­tion is no, because then what hap­pens is you’re not able to leave the group. So it’s a dou­bly bad posi­tion. But we try to send peo­ple to most of the groups that have country-wide effect, and this includes some of the groups in Europe and some of the groups around the world which are man­dat­ing stan­dards for their entire coun­try or for an entire indus­try. You don’t want to be left out. That’s the prob­lem. And, at the same time peo­ple use stan­dards as a weapon right now. And it’s just like any­thing else. In the begin­ning it start­ed for the good of all peo­ple. Now it’s turned around to a weapon which peo­ple can use to either sell or not sell machines. Even if the stan­dard is only a check box or tick box item.

Malamud: Many of these groups seem to have two pur­pos­es. One is ​“we fight among our­selves to agree on what the stan­dard is going to be,” the oth­er is to some­how pro­mote the indus­try. And net­work­ing seems to be get­ting big enough and strong enough that there’s a need to do things like that. I’ve noticed some groups in Washington that are attempt­ing to influ­ence our nation­al infor­ma­tion infra­struc­ture. There’s a cross-industry work­ing group, there’s been giga­bit jam­borees. Are we going to be able to influ­ence the shape of this so-called infor­ma­tion super­high­way, or is this going to hap­pen led by the tele­phone com­pa­nies and the net­work TV and the cable TV— Are we gonna play a part in the NII or are we just gonna fur­nish MIPS?

Baehr: Well… It’s… I belong to one of these groups. And I believe that what will hap­pen is that while the gov­ern­ment is inher­ent­ly slow, and the gov­ern­men­t’s reg­u­la­to­ry process­es are designed for the Communications Acts of the 30s, there­fore the gov­ern­ment will indi­cate a pro­pos­al of what they would like to do when they can apply mon­ey. And the mon­ey caus­es peo­ple to jump up and to pay atten­tion. But, like any­thing else in net­work­ing, the spec­i­fi­ca­tions are suf­fi­cient no mat­ter how tight­ly you think you’ve writ­ten. They’re still suf­fi­cient­ly vague that the pro­pos­als and the results can swing all over the map. 

What this means is that the peo­ple who have mon­ey and who are going to try to make mon­ey off of these things are the ones who are going to guide or to push their results around. And be it the ven­ture cap­i­tal com­mu­ni­ty, or be it the access providers, or be it the car­ri­ers, these are the peo­ple who are going to make mon­ey off of these things. So that their desires that we’ll see reflect­ed in terms of the implementations. 

And there’s noth­ing to say that an imple­men­ta­tion nec­es­sar­i­ly has to meet the goal of the gov­ern­ment. So the argu­ment that I would make is that the com­mer­cial imple­men­ta­tions indeed will be this infor­ma­tion super­high­way or what have you. And that the com­mer­cial imple­men­ta­tions will lead. Because pub­lic pol­i­cy is nec­es­sar­i­ly slow. Because the delib­er­a­tive process requires such a sub­stan­tial amount of time.

Malamud: But what is this infor­ma­tion super­high­way? Is it just the Internet grown big­ger? Is it you know, Super Mosaic? Or is it some­thing total­ly dif­fer­ent? Are we talk­ing cable TV with maybe the abil­i­ty to order a movie?

Baehr: Well my belief is that it’s done, and it’s called the Internet. And soon­er or lat­er some­one should stand up and say this infor­ma­tion super­high­way’s here, and it’s the ques­tion of degree. Whether you’re gonna run DS3 lines around or whether you’re gonna run T1s into every school, fine, that’s up to you for you folks to pay. But in real­i­ty, it’s here. The mech­a­nisms that the cable TV folks are putting togeth­er, those are mech­a­nisms for them to make mon­ey, to be able to keep their busi­ness­es going to a closed user base. Talk to the cable tele­vi­sion peo­ple and you’ll find out they have no goal to inter­con­nect cable sys­tems togeth­er. There’s no inter­net­work­ing that’s been the goal by any of these people.

Malamud: So they’re build­ing LANs. LANs under the liv­ery of video data.

Baehr: They’re build­ing MANs, for the deliv­ery of video data and shop­ping ser­vices, what have you, for their sub­scriber base. Yet when you look at the inter­con­nect­ed­ness and the range of ser­vices, and also the sub­scriber base out there on the Internet, gee, the peo­ple who fig­ure out how to con­duct com­merce over the Internet are the folks who will real­ize the fact that this high­way is here—I hate call­ing it ​“high­way,” by the way. They’ll fig­ure out that this thing is here. 

Malamud: So is the home user gonna have sev­er­al dif­fer­ent ways to get out to the world? They’ll use their TV and their set-top box to get a movie, they’ll use their modem to go out to the Internet—

Baehr: Yes.

Malamud: —or is there gonna be the sin­gle mag­ic set-top box?

Baehr: No, I don’t believe there’ll be a sin­gle mag­ic set-top box, for a sin­gle rea­son, and that is if you’ve ever tried to get between a three-year-old and a tele­vi­sion set to go surf the Internet, I can tell you who’s going to win that bat­tle. And it’s not going to be surf­ing the Internet, it’s going to be the three-year-old. 

And the ques­tion I have is, if you bring all these ser­vices to peo­ple, how much is going to actu­al­ly be used ver­sus the cost of mak­ing all this infra­struc­ture go? I mean we’re talk­ing about two anti­thet­i­cal ideas here. One is I sell ser­vices to a closed user base. Yet on the oth­er hand I’m going to hook in the Internet, to rich­ly inter­con­nect all these peo­ple togeth­er? It does­n’t quite make sense to me.

Malamud: Do you think peo­ple are going to want both, or they just want to get their movies? Do peo­ple care about uni­ver­sal Internet access?

Baehr: Uh. Well it’s inter­est­ing. I think that the peo­ple who do care will go and buy the appro­pri­ate gad­get to hook them in. Be that a PC or some spe­cial­ized gad­get. The folks who want to see movies, it’s a very com­pelling argu­ment that you pay only $2 to go down to Blockbuster to rent a movie. The folks—

Malamud: Or $2 for pay-per-view.

Baehr: The pay-per-view, what have you. People are used to doing that. Changing things fun­da­men­tal­ly, and this is— I dis­like say­ing ​“par­a­digm shift,” but chang­ing the usage mod­el for the pub­lic takes a long time, and peo­ple have got­ta be pre­pared to stick out for the long course any of these changes. Take for exam­ple VCRs. How long was it before VCRs became pop­u­lar, before peo­ple were not scared and were able to go and put a tape into a VCR and use it. It was a ten-year program.

Malamud: Let alone pro­gram it.

Baehr: That’s cor­rect. And with pro­gram­ming, if any­one out there knows of the appro­pri­ate uni­ver­sal remote con­trol let me know because we’ve tried them all here. And can’t find any of them that seem to be par­tic­u­lar­ly good.

Malamud: This has been Geek of the Week. We’ve been talk­ing to Geoff Baehr from Sun Microsystems. Thanks a lot, Geoff.

Baehr: Thanks, Carl. 

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­tem 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 Tungsten Macaque, our house band. This is Carl Malamud for the Internet Multicasting Service, flame of the Internet.