Carl Malamud: Internet Talk Radio, flame of the Internet. This is Geek of the Week and we’re talk­ing today with Bob Hinton, who’s man­ag­er of Internet engi­neer­ing at Sun Microsystems. That’s the group that comes up with the TCP/IP code that’s in your SPARCstation. He’s also the Area Director of rout­ing for the Internet Engineering Steering Group. and he co-chairs the SIP effort, the Simple Internet Protocol. SIP is one of the key con­tenders as the can­di­date for the IP next gen­er­a­tion, IPng as it’s being called. Welcome to Geek of the Week, Bob.

Bob Hinden: Hi Carl. Thank you. 

Malamud: Maybe we could start by you can tell us a lit­tle bit about what SIP is and maybe how that dif­fers from the cur­rent Internet protocol.

Hinden: Well SIP is real­ly designed to be a step evo­lu­tion from the cur­rent IP pro­to­col. The notion behind it is to take a look at what needs improve­ment, and the thing that start­ed all of this was hav­ing a pro­to­col which could sup­port a larg­er Internet, had larg­er address­es, had bet­ter rout­ing facil­i­ties, and take a look at what IP had, what worked, what did­n’t work, and do some­thing which improves it a lit­tle bit but does­n’t take any rad­i­cal steps. It sort of tries to take a low-risk back­wards com­pat­i­bil­i­ty step.

Malamud: So, you just take…we need big­ger address­es, you just dou­ble the address size and we’re done. What’s…what’s the big deal?

Hinden: I guess it— Maybe that’s what we thought too. There’s a lot of sub­tle issues that have to be dealt with. We’ve sort of tak­en some things out of the head­er, restruc­tured things a bit, moved some of the things that aren’t used very much to option­al head­ers to try to increase the per­for­mance. We’ve end­ed up with some­thing which while it cur­rent­ly has address­es which are twice as large, the over­all head­er’s only four bytes longer than IP, so it’s still rel­a­tive­ly small and rel­a­tive­ly simple.

Malamud: Well let’s go through a cou­ple of those issues. You say the address­es are twice as large but the Internet is dou­bling every year. Did you just buy us an extra year by dou­bling the headers?

Hinden: Ah, that’s a good ques­tion. When you dou­ble the size of the address­es you don’t dou­ble the num­ber of address­es, you mul­ti­ply them togeth­er. Someone made a sim­ple obser­va­tion that the cur­rent— You know, we have a cur­rent sys­tem which will prob­a­bly scale to…I guess we have total of a cou­ple mil­lion net­work num­bers. And you could prob­a­bly have many more than that hosts. If you could allo­cate the address­es com­plete­ly flat­ly, SIP would allow you to have four bil­lion of the cur­rent Internets. So anoth­er way to say this is that every per­son on Earth today could have their own Internet as big as the cur­rent Internet tech­nol­o­gy will grow. 

Malamud: Or alter­na­tive­ly there’s enough room in the SIP address space for every pro­ton in the uni­verse, I believe, or some num­ber of the uni­verse of that size.

Hinden: Well, the uni­verse is a pret­ty big place. But certainly—

Malamud: Why do we need such a big address space?

Hinden: We need a big address space for two rea­sons. One is that there’s going to be a lot of things we need to address. The sort of a com­mon notion that every­where there’s a tele­phone today there’ll be a net­work. And the only thing that— That esti­mate might be too small. But in some sense any­where there might be a com­put­er you might want to be able to address it. 

You also need big­ger address­es because you can’t uti­lize them opti­mal­ly so you need to allow room for cre­at­ing hier­ar­chies and admin­is­tra­tive structure. 

Malamud: And so we don’t need an address space big enough to have one address for every per­son, we need more room than that in order to pro­vide that structure?

Hinden: We prob­a­bly need an address space which is big enough that every per­son can have a num­ber of com­put­ers. And exact­ly what that num­ber is no one knows, but we need some­thing that will pro­vide enough growth in the fore­see­able future. Sort of the ques­tion that comes up is do we need enough address space to…that we could nev­er run out in any cir­cum­stances. And that’s… I believe in build­ing things which run over in the domain which we can sort of under­stand and fore­see but it’s real hard to pre­dict what things will be like a long way in the future if the indus­try and the tech­nol­o­gy changes very quick­ly. If we look back ten or twen­ty years, you would­n’t’ve imag­ined we’d be where we are today. So I sus­pect we can’t real­ly imag­ine what it’s going to be like twen­ty years from now. So I think if we design a solu­tion which looks like it can be can scale as far as we can rea­son­ably imag­ine today I think that’s adequate. 

It’s also an issue of solu­tions which tend to work well in today’s envi­ron­ment that scale are much bet­ter than solu­tions which build in a lot of inef­fi­cien­cy because they might be need­ed lat­er. Those tend not to solve peo­ple’s prob­lems very well.

Malamud: So you have a sim­ple Internet pro­to­col list, as you call it. But we’re ask­ing more of our net­work play­ers these days. For exam­ple, Steve Deering, your co-chair on the SIP Working Group is the father of multi-casting. By remov­ing some of that func­tion­al­i­ty and sim­pli­fy­ing things are you going to make it hard to sup­port mul­ti­cas­t­ing, for example?

Hinden: No, in fact just the oppo­site. We’re tak­ing the things we think are impor­tant, like mul­ti­cast in par­tic­u­lar, oth­er things like mobil­i­ty and auto­con­fig­u­ra­tion, and we’re build­ing those in from the start. There’s a lot of work going on to essen­tial­ly add those things to the exist­ing pro­to­cols, the exist­ing IP ver­sion 4 we have now today, but when there’s a large installed base, you have to design what— You can’t change the pro­to­col in ways that’re incom­pat­i­ble. When you get a chance to do some­thing which there isn’t a big installed base, and if you can pro­vide those things at the begin­ning, then you can require that all imple­men­ta­tions do them from the start. So by deploy­ing in par­tic­u­lar SIP, we believe that we’ll be build­ing a base that all imple­men­ta­tions will do mul­ti­cast, all imple­men­ta­tions will be easy to con­fig­ure, they’ll have a pro­vi­sion for sup­port­ing real-time traf­fic with flows. You know, there is some oppor­tu­ni­ty here to do the things that need to get done.

Malamud: Well how for exam­ple do you sup­port auto­con­fig­u­ra­tion. What is it in SIP that makes it easy to do that kind of thing?

Hinden: Well, I think the biggest thing is again we get to, because it’s an area that IP ver­sion 4 does­n’t do, we get to define some new con­trol pro­to­col mes­sages which allow host and routers to exchange the right infor­ma­tion to do that.

Malamud: What about sup­port for real-time data, now that we’re see­ing video and oth­er isochro­nous data on the net­work. How does SIP pro­vide that support?

Hinden: Well SIP essen­tial­ly, with­out any­thing new, makes it work as well as what IP ver­sion 4 does today. SIP has a place­hold­er for real-time traf­fic called up a flow label­er, flow iden­ti­fi­er, which is intend­ed to allow—with some set­up or nego­ti­a­tion allows state infor­ma­tion to be put into a router to either iden­ti­fy the traf­fic or to asso­ciate it with a par­tic­u­lar flow so we can pro­vide some guar­an­tees of ser­vice and fair queu­ing. This is an area which is more in the research com­mu­ni­ty but we’re con­fi­dent enough in the idea that we think it’s impor­tant to allo­cate some space in the SIP head­er to allow that infor­ma­tion to be used lat­er as the work gets done. So we think it’s prob­a­bly the answer—you know, there will be a solu­tion based around flows that we’re pro­vid­ing the facil­i­ty to add that with­out hav­ing to change the protocol. 

Malamud: That’s one research area that you’ve looked at and said that looks fruit­ful and we’re gonna make room for that. Are there research areas you’ve looked at and said well, we don’t think that’s going far enough and we’re going to explic­it­ly ignore this?

Hinden: Well, we’ve had the philosophy—and I give Steve Deering quite a lot of cred­it, which is he’s resist­ed putting things in that there aren’t very clear uses for or we have a good under­stand­ing of how they work. Um—

Malamud: What’s an exam­ple of that kind of thing that you’ve resisted?

Hinden: One exam­ple is there’s a field in IP called Time To Live, which is essen­tial­ly the num­ber of hops or routers that a par­tic­u­lar pack­age can go through. It’s used for loop detec­tion. So if there’s a loop, the pack­et won’t go around the loop for­ev­er. When Steve was first design­ing SIP, peo­ple said, ​“Does that field need to be big­ger?” And cur­rent­ly it’s eight bits and you can have 256 hops, which in the cur­rent Internet is by a fac­tor of…probably in most cas­es sev­er­al orders of mag­ni­tude but even in the most extreme cas­es prob­a­bly fac­tor of four.

Malamud: Yeah, twen­ty or thir­ty hops is real­ly the out­side poten­tial diam­e­ter and that’s even…that’s real­ly strange.

Hinden: Yes. But there were some com­ments that well gee, let’s make the field big­ger, let’s make it so it could be six­teen bits or sixty-four thou­sand hops, and Steve and some of the oth­er SIP devel­op­ers resist­ed doing that because we just don’t think that’s… While yes, it would make the pro­to­col more gen­er­al, we don’t you can build Internet works where the traf­fic has to go for tens of thou­sands of hops. That’s just not gonna work. So we think hav­ing some con­straints on the pro­to­col that will con­strain the topol­o­gy of the net­work is in fact a good thing. 

In some sense keep­ing the address size to sixty-four bits is also a sim­i­lar thing. If you don’t under­stand the— If you don’t have absolute answers to all of the ques­tions, one approach is to make things so gen­er­al. You could have either extreme­ly large address­es or variable-size address­es. And that’s sort of nice because it keeps it open-ended but you pay a price in per­for­mance and in table size. And if you can come up with a more lim­it­ed more lim­it­ed size address that still address­es every­thing you can rea­son­ably imag­ine, I think it’s a bet­ter engi­neer­ing solu­tions. So a lot of areas we’ve resist­ed mak­ing things gen­er­al because just to make them gen­er­al there had to be a real rea­son. You know, if some­one could come and point out rea­son­able sce­nar­ios why what is there won’t work, or isn’t scal­able enough, does­n’t have enough life­time, we’re real open to change but there has to be pret­ty con­crete reasons.

Malamud: The Internet has moved beyond being a research net­work. It’s very much an oper­a­tional envi­ron­ment. Many of us real­ly depend on that. I know your busi­ness depends on it and cer­tain­ly mine is absolute­ly depen­dent on the Internet work­ing. How are we gonna do a tran­si­tion to SIP in a way that keeps the cur­rent world working?

Hinden: Well, one of my major inter­ests in work­ing in the IPng are­na, and I’ve been involved with some oth­er pro­pos­als which have sort of evolved into the cur­rent SIP group, is to do things that have back­wards com­pat­i­bil­i­ty, make tran­si­tion easy.

Malamud: How do you make IP ver­sion 4 and SIP worlds talk to each oth­er? Or do you do that? I mean, do you just say, ​“We’re going to tran­si­tion this net­work on a cer­tain day,” or…

Hinden: No. We’ve built as many things in that are…where there was no rea­son to change them. Like the way do frag­ment pack­ets. We’ve used the same seman­tics, so it’s easy to map from one to the oth­er. The areas that are obvi­ous­ly dif­fer­ent are address­es, and we have a tran­si­tion scheme where for the peri­od of time until IP ver­sion 4 address­es are no longer unique glob­al­ly in the eco—the word we tend to use—that we will embed one of those in a SIP address—low order thirty-two bits, and this allows IP ver­sion 4 host to essen­tial­ly address SIP hosts it’s a rel­a­tive­ly easy map­ping to map between them, so we’ve actu­al­ly designed and imple­ment­ed code that can trans­late from one pro­to­col to the other.

Malamud: So the address of a SIP host is, if you take off the high thirty-two bits and there’s some pre­fix, what’s left is actu­al­ly a valid IP address.

Hinden: Yes. And it’s our intent that until the world decides that IP address­es are no longer unique every­where, essen­tial­ly when they would have to get reused, that all SIP hosts that want­ed to com­mu­ni­cate with IP ver­sion 4 hosts would essen­tial­ly be assigned an IP address.

Hinden: I guess the way I think about it is that I don’t want to require things to have soft­ware upgrades if they don’t need the func­tion­al­i­ty. So that…I mean com­put­ers, they don’t wear out but there comes a point where you throw them away. Or you know, you replace them for oth­er reasons—the main­te­nance cost gets too high. When you put in a new com­put­er with new soft­ware, it should come with a new pro­to­col. But we don’t think there’s a need to force every host who does­n’t need to talk over the glob­al Internet to do a soft­ware upgrade.

Malamud: So the eas­i­est part of the tran­si­tion is while the IP space is still glob­al­ly unique.

Hinden: Yes. This gets a lot hard­er if we haven’t deployed the new pro­to­col before we run out of addresses.

Malamud: How far along are you now?

Hinden: Well, I think we’re pret­ty far along. The thing… Maybe what this comes down to in all the dif­fer­ent choic­es is the amount of risk asso­ci­at­ed with each pro­pos­al. I think SIP has the advan­tage that it’s real sim­i­lar to IP. If you can under­stand the cur­rent IP you can under­stand SIP real clear­ly. It’s real sim­ple. It has some new stuff in it but the basic oper­a­tion is real­ly the same ideas. A lot of the ele­ments in the head­ers are exact­ly the same. And we have…I guess about sev­en or eight dif­fer­ent imple­men­ta­tions now. Most peo­ple have found that it’s real­ly very easy to take their exist­ing code and to add SIP to it. And it—

Malamud: And is this the case for for machines that maybe aren’t as network-aware as a SPARCstation? Can you do this on DOS for example?

Hinden: Yes. We have imple­men­ta­tions on DOS and Windows. There’s VMS. There’s a Mac imple­men­ta­tion. There’s sev­er­al fla­vors of Unix.

Malamud: And have you test­ed these against each oth­er? Do they actu­al­ly work?

Hinden: Yes. We had what we called a SIP inter­op­er­abil­i­ty event before the pre­vi­ous IETF meet­ing. We did a demo then. We did a demo at this IETF meet­ing. So we’ve actu­al­ly run the imple­men­ta­tions against each other.

One of the real nice things about SIP is that because it uses IP ver­sion 4, it actu­al­ly encap­su­lates your tun­nels as part of its nor­mal mech­a­nism. You don’t need to deploy any new infra­struc­ture in order to test it. So it means we get to test it over the Internet as nor­mal oper­a­tion. It’s sort of— We don’t have to put in spe­cial things to test it, it’s nor­mal mode is to run this way. So it’s been real easy to plug machines in and do the test­ing. You don’t have to fool around with deploy­ing lots of new things in order to set up the com­mu­ni­ca­tion paths.

Malamud: You and sev­er­al oth­ers at Sun are invest­ing a con­sid­er­able amount of time work­ing on this. Why does it make sense for Sun to do this instead of wait­ing for the stan­dards to come out and then just imple­ment­ing them?

Hinden: Well, I— My view on this is that in this industry—I call it the the inter­net­work indus­try, com­mu­ni­ca­tion industry—you know, it’s not a place where you win by having—or are suc­cess­ful by hav­ing pro­pri­etary solu­tions. You win— You become— You want to become a leader in the tech­nol­o­gy and you do it by doing things and hav­ing lots of oth­er peo­ple use them. I think the areas where—I’ve been at Sun for I guess…it’ll be eigh­teen months in a lit­tle while. So I had been had been a Sun cus­tomer before I worked there. And I think the areas where Sun has had great suc­cess is where Sun has devel­oped tech­nol­o­gy and then worked with oth­er com­pa­nies and seen it deployed on a very large scale, and not made any claims of…not licensed it, just make code and specs freely avail­able. And I think in the Internet world it’s the same thing. You are suc­cess­ful by get­ting oth­er peo­ple to use the same pro­to­cols, or the same tech­nol­o­gy. And if you then also deliv­er good prod­ucts around them, you will be suc­cess­ful. So it’s not an area where you want to do things and don’t tell any­one what you’ve done, you want to be as coop­er­a­tive with oth­er peo­ple. So Sun’s inter­est in this is advanc­ing the tech­nol­o­gy and pro­vid­ing a solu­tion which we think is best for our cus­tomer base, of course. I mean, there’s cer­tain­ly self inter­est in this. But we would like to see the IPng process end up with a solu­tion which we think pro­vides good solu­tions to our customers.

Malamud: You say the key is an open solu­tion, every­one can imple­ment it. It would seem to me the log­i­cal thing to do would be go and get the inter­na­tion­al stan­dard, CLNP—the Connectionless Network Protocol which is already wide­ly deployed around the world, and just use that. Why aren’t you using the ISO standard? 

Hinden: Well that’s a good ques­tion. That’s the ques­tion the Internet com­mu­ni­ty asked. And I gave this quite a lot of thought, and the prob­lem with that is that I think some of the com­mon assump­tions that it’s wide­ly deployed and it’s all done aren’t quite right. There’s a lot­ta details that aren’t done and all of this stuff is in the details. It’s not just the main pro­to­col, it’s all the con­trol pro­to­cols and the rout­ing and the imple­men­ta­tions and the testing.

Malamud: Well what kind of details are miss­ing in the…in either the CLNP com­ing out of ISO or the mod­i­fied ver­sion known as TUBA that the Internet com­mu­ni­ty is con­sid­er­ing as a pos­si­ble candidate?

Hinden: Well, where I see the problems—this isn’t a direct answer your question—but where I see the prob­lem is that CLNP is real­ly IP five to ten years ago. It’s…you know, it’s been sort of slow in com­ing but there’s noth— It has larg­er address­es but every­thing else is approx­i­mate­ly the same. It’s big­ger but it pro­vides about the same functionality.

And my con­cern, besides— Well I guess two con­cerns. One is that there is there is no, at least in my opin­ion, rea­son­able tran­si­tion strat­e­gy that makes it easy to deploy and makes it easy to oper­ate with the exist­ing IP ver­sion 4 hosts. But the oth­er prob­lem is that I think if the Internet com­mu­ni­ty adopts this the Internet is going to spend the next five years redo­ing all of the things that have been done for IP ver­sion 4, as opposed to spend­ing five years mov­ing the tech­nol­o­gy forward. 

Malamud: So it’s it’s miss­ing mul­ti­cast and flow con­trols, for exam­ple, or auto­con­fig­u­ra­tion, or—

Hinden: It’s miss­ing mul­ti­cast, it has two rout­ing pro­to­cols. IP ver­sion 4 has some­times more than we can count. There isn’t much expe­ri­ence with it. There’s— Maybe this is the final thing, there real­ly aren’t very many users who use CLNP in an oper­a­tional mode.

Malamud: Well ISO has expressed its will­ing­ness to liaise with the Internet Engineering Task Force and come up with a com­bined thing. Now would­n’t be a great polit­i­cal win if we could com­bine ISO and the IETF togeth­er into one super open sys­tem solu­tion? Isn’t it worth giv­ing up some of these flow con­trol fea­tures in order to have this nice rapproachement?

Hinden: Well, I think that would be…for some val­ue of ​“nice,” but I don’t want to sac­ri­fice the exist­ing base to do that. I think TCP/IP has essen­tial­ly won in the mar­ket­place. CLNP OSI has been…the mar­ket has had plen­ty of time to adopt it and to deploy it, and it has­n’t hap­pened. I think there’s— I don’t think I’m the only one with this opin­ion, but I think that if the Internet does not choose the IPng solu­tion, which is based on CLNP, my pre­dic­tion is that CLNP does­n’t have much of a life left to it. I think this is the last big oppor­tu­ni­ty for the com­mu­ni­ty which is push­ing on CLNP.

And again, my view is that I would hate to see the Internet spend five years redo­ing all of the things that have made TCP/IP work over a large scale. You know, there’s solu­tions for large net­works, there’s solu­tions for small net­works, a lot of var­ied imple­men­ta­tions, a lot of expe­ri­ence, a lot of sort of train­ing and books and…a lot of peo­ple invest­ment, I guess, not just soft­ware. Vendors are real good at writ­ing soft­ware. But a lot of peo­ple under­stand it. And I would hate to see us spend a long time redo­ing all that and then at the end of the time be technically—the func­tion­al­i­ty be at the same place we are now, except we could have a big­ger sys­tem. I think the world is not going to wait that peri­od of five years. There are oth­er things hap­pen­ing in the world that peo­ple will come up with oth­er solu­tions and it would essen­tial­ly obso­lete this technology. 

The area that I think is most inter­est­ing is the things that Apple and General Magic and peo­ple are talk­ing about doing around cable TV sys­tems who’re essen­tial­ly putting net­works and com­put­ers in every­one’s hous­es. And I sus­pect those are going to be the areas where the growth comes from. The cur­rent sort of com­mer­cial mar­ket of work­sta­tions and PCs and stuff is cer­tain­ly gonna grow for a long time but there’s like­ly to be anoth­er big step func­tion as peo­ple build very low-cost, very pow­er­ful com­put­ers that every­one gets—go into peo­ple’s hous­es, and those are all going to be net­worked. If we can pro­vide an Internet solu­tion that works in that are­na, then I think every­thing will be will have sort of a uni­fied, glob­al inter­net­work that spans super­com­put­ers down to hand-held devices. If we can’t pro­vide a solu­tion that the peo­ple build­ing those prod­ucts need, then they’ll do their own. And we’ll end up with anoth­er set of incom­pat­i­ble things. So I think our oppor­tu­ni­ty is to pro­vide some­thing which will scale not only in size but also into the kind of appli­ca­tions and the envi­ron­ments that we see the world going to.

Malamud: You have two func­tions in the IETF. On the one hand you’re an advo­cate; you’re the co-chair of the SIP group. You’re also a mem­ber of the Internet Engineering Steering Group, which will be mak­ing the deci­sion about IPng. Does it make sense to have some­one who’s actu­al­ly going to make the deci­sion also be involved in the work, or should you be some­how more neu­tral and kind of wait for the results to be pre­sent­ed to you?

Hinden: Well, it’s an inter­est­ing ques­tion. If you take it to extreme, then any­one who has any opin­ion or any knowl­edge should­n’t be involved in the deci­sion. And that clear­ly does­n’t work because you want to…this is not you know, pick­ing A or B. All of the solu­tions are essen­tial­ly opti­mized for dif­fer­ent things, and the outcome—how well it works, will be…you know, they will do dif­fer­ent things, they will have dif­fer­ent effects. And you clear­ly want to have a very informed decision.

On the oth­er hand you cer­tain­ly don’t want— It’s impor­tant that when the deci­sion is made, it’s impor­tant that it not be viewed from the out­side as an inside job, as you know a back­door solu­tion and it favored insid­ers. So it’s very impor­tant that it be open and fair, and the process that made it be vis­i­ble so it’s essen­tial­ly beyond reproach. And even then that there be an appeals process. And in that sense it’s prob­a­bly rea­son­able for the peo­ple who are obvi­ous advo­cates of par­tic­u­lar solu­tions to step aside from the deci­sion­mak­ing process.

Malamud: Are you ready to decide it? Could you in good con­science say, ​“Okay, SIP is it, we’re ready to go.”

Hinden: Yeah, I’ve decid­ed. I mean, I’m putting my ener­gy work­ing with oth­er peo­ple chair­ing the group. I’m not doing this for fun. It’s a lot of work. I have oth­er things to do. It’s not exact­ly my real job. But I think it’s impor­tant. I think it’s impor­tant for…you know, essen­tial­ly for the Internet, for the coun­try, for the world. I think it’s also impor­tant for the com­pa­ny I work for. I think Sun Microsystems has a stake in the out­come. We have a cus­tomer base, and we I think want solu­tions that work best in that environment. 

I see sort of a cou­ple of pos­si­ble out­comes here. One is that the work gets done and the IESG picks one of the four. I mean in some sense it could be done at any time. There’s always going to be… At any point there’ll be a cer­tain amount of infor­ma­tion and if you wait­ed there would be more. But if you take that phi­los­o­phy then you could wait forever.

Another approach is that there’ll nev­er be a deci­sion. That the four con­tenders will go off and they will be deployed and the world will see four more pro­to­cols. And—

Malamud: Is that all bad?

Hinden: Um, I think it’s…

Malamud: I mean we have X.400 and 822 mail and they work, sort of.

Hinden: Well, and we have AppleTalk and we have IP and we have IPX, and…there’s a long list. I think that there’s a lot of ben­e­fit in hav­ing one major Internet lay­er pro­to­col [crosstalk] that works on a glob­al scale.

Malamud: Is the glob­al con­nec­tiv­i­ty, is that the key goal of doing that? Is glob­al con­nec­tiv­i­ty the rea­son we want one [crosstalk]pro­to­col?

Hinden: Yes. We want one pro­to­col because it makes it so that every­one can talk with each oth­er eas­i­ly, as opposed to all pro­to­cols hav­ing to be implemented. 

Malamud: Well there you have it. This has been Geek of the Week and we’ve been speak­ing with Bob Hinden. Thanks a lot Bob.

This is Internet Talk Radio, flame of the Internet. You’ve been lis­ten­ing to Geek of the Week. You may copy this pro­gram to any medi­um, and change the encod­ing, but may not alter the data or sell the con­tents. To pur­chase an audio cas­sette of this pro­gram, send mail to radio@​ora.​com.

Support for Geek of the Week comes from Sun Microsystems. Sun, the net­work is the com­put­er. Support for Geek of the Week also comes from O’Reilly & Associates, pub­lish­ers of the Global Network Navigator, your online hyper­text mag­a­zine. For more infor­ma­tion, send mail to info@​gnn.​com. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by MFS DataNet and by UUNET Technologies.

Executive pro­duc­er for Geek of the Week is Martin Lucas. Production Manager is James Roland. Rick Dunbar and Curtis Generous are the sysad­mins. This is Carl Malamud for the Internet Multicasting Service, town crier to the glob­al village.