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

Malamud: This is Geek of the Week, and we’re talk­ing to Stuart Vance, who’s vice pres­i­dent of engi­neer­ing at TGV. Welcome to Geek of the Week, Stuart.

L. Stuart Vance: Thank you Carl.

Malamud: Your com­pa­ny makes TCP/IP and NFS soft­ware for VMS oper­at­ing system-based machines. I’ve always been curi­ous, what hap­pens if DEC starts doing the same thing, bun­dles it into their oper­at­ing sys­tem. Does that just wipe you out of that mar­ket? Are you gone?

Vance: Well, DEC fact does have a TCP/IP prod­uct for VMS that they sell. ​“DEC TCP/IP ser­vices for OpenVMS,” kind of a mouth­ful. And we have been a bit wor­ried about whether they might actu­al­ly bun­dle it in with their oper­at­ing sys­tem. They have not as of yet. And while we’re con­cerned about it I would­n’t say that we’re over­ly so. We have a very good prod­uct. It’s been around for a long time. And the his­to­ry of MultiNet goes back to ​’82. In fact MultiNet was one of the first NCP/TCP stacks on the Internet, peri­od. Back then I guess it was actu­al­ly just the ARPANET.

DEC’s prod­uct is much new­er. It’s a lot… It has­n’t real­ly stood the test of time. And I think that DEC is dis­cov­er­ing with their prod­uct that it might be easy to play in a small envi­ron­ment, but play­ing in the Internet itself and pro­vid­ing all of the req­ui­site ser­vices that people…well, require for the Internet is a lot hard­er than it looks per­haps on paper. 

Malamud: The rea­son I ask is because as you know there there’s many giants in this indus­try. There’s Microsoft, and there’s many small com­pa­nies com­pet­ing with Microsoft. Do you think small com­pa­nies like yours are able to com­pete with the giants, by being quick­er, faster, better?

Vance: It cer­tain­ly helps to be nim­ble. One of the rea­sons why we’ve been able to be suc­cess­ful is when we’ve seen an oppor­tu­ni­ty we’ve been able to jump on it quick­ly. Whereas with com­pa­nies that’re…the billion-companies out there… They have big feet, and it takes a lot longer for them to get them mov­ing. Of course, the one dan­ger of that for a small com­pa­ny is that com­pa­nies with big feet tend to leave a lot of a flat­tened toes. So…

Malamud: No doubt about it.

Vance: But I think it is clear that if you look at in par­tic­u­lar the PC com­pa­nies, cer­tain­ly Microsoft could’ve come in a long time ago and done their own TCP/IP or bought one of the small­er com­pa­nies and start­ed sell­ing their prod­uct. But I think that in par­tic­u­lar in the case of Microsoft, they’ve rec­og­nized the advan­tage of hav­ing these small inno­v­a­tive com­pa­nies out there pro­vid­ing real­ly good soft­ware. So, I actu­al­ly rather applaud that in cer­tain companies. 

Malamud: You spend a lot of your time when you’re not actu­al­ly doing your job going over to Interop and help­ing set up the show net­work there. In fact you’re part of the core team of this fanat­i­cal band of vol­un­teers that puts this huge net­work togeth­er. Why do you do that?

Vance: That’s a real­ly good ques­tion, and I’m not sure that I can give you a par­tic­u­lar­ly coher­ent answer on it. I’ve been doing it myself since ​’89. Which I guess was the sec­ond or third Interop. And we’ve had a cou­ple oth­er peo­ple at TGV who’re work­ing on the cur­rent show, in fact, and who’ve been work­ing on Interop since then. 

I guess what keeps bring­ing me back is the col­lec­tion of peo­ple. It’s not so much that we’re doing it out of the good­ness of our heart, but it is fun work­ing with tech­nol­o­gy that…for exam­ple I per­son­al­ly don’t get the chance to work with much here at TGV. 

Malamud: Is this a par­tic­u­lar­ly sophis­ti­cat­ed net­work that you’re putting togeth­er, or par­tic­u­lar­ly large-scale, is that why you do it?

Vance: I guess that’s part­ly it. I used to work at a large land grant insti­tu­tion, as we used to call it, a big uni­ver­si­ty in Texas. Which had a very large net­work. Seventy build­ings on a broad­band net­work. But the thing that’s most impres­sive about Interop is the fact that the net­work is staged over the course of two to three weeks, and then when we actu­al­ly move into the facil­i­ty and put it up, it takes about twelve hours. And we end up mobi­liz­ing any­where from a hun­dred to a hun­dred and fifty peo­ple, with a core group of about twelve to fif­teen peo­ple. And basi­cal­ly there’s this incred­i­bly mon­u­men­tal effort to put togeth­er a net­work that’s used basi­cal­ly for three days. I guess there’s some sort of…a sort of mor­bid fas­ci­na­tion at this. It’s always some­what dis­heart­en­ing when you actu­al­ly sit down and real­ize that you just put a sig­nif­i­cant por­tion of your life…well, per­haps in terms of ener­gy out­put, to put togeth­er some­thing that three days lat­er you’re going to rip out of the ceil­ing and…perhaps not throw away, but spool up and store away for lat­er. There’s some­thing kin­da strange about it. 

But I guess what keeps bring­ing me back, and the peo­ple at TGV, is the col­lec­tion of peo­ple that Internet has put togeth­er for their NOC team, which is what they call this core group. They’re peo­ple from a vari­ety of dif­fer­ent com­pa­nies, from large sys­tem man­u­fac­tur­ers, from con­sul­tants, from soft­ware com­pa­nies like our­selves. And the col­lec­tion of peo­ple is…is tru­ly amaz­ing. There are soft­ware engi­neers, there are hard­ware engi­neers. There are cable pullers. And it’s a real­ly great group of peo­ple to work with.

Malamud: It sounds like fun, as I’ve learned just doing this a cou­ple times just on the weekends.

I want to turn back to soft­ware, and pro­to­cols, and things on the Internet. You work in a com­pa­ny that uses VMS a lot, and as you know most of the Internet is some­what Unix-centric. Do you see that Unix-centric approach hurt­ing the Internet? Is there some­thing that can be done to change that? Are the protocols…too Unix‑y?

Vance: Well Unix is clear­ly the most pre­dom­i­nant oper­at­ing sys­tem in use on the Internet, so it’s hard to say one way or the oth­er whether it’s 

hurt­ing

the Internet. It cer­tain­ly caus­es us grief every now and then, because there’s a lot of pub­lic domain soft­ware writ­ten that can grok Unix quite well but when it comes to any­thing else it just…the trans­la­tion does­n’t work so well. We cer­tain­ly find our­selves in the minor­i­ty in terms of sup­port­ing VMS. At times we find our­selves… I don’t want to save the sub­ject of abuse, but that’s what it bor­ders on. VMS is looked at at times with scorn by many Unix advo­cates out there. But, our whole goal is to be able to inte­grate VMS in with, in par­tic­u­lar Unix, to pro­vide all the nor­mal ser­vices and func­tion­al­i­ty that will allow the two to com­mu­ni­cate bidi­rec­tion­al­ly, such that a per­son on a Unix sys­tem would nev­er even be able to tell that he’s talk­ing with a VMS system.

Malamud: And you’re able to do that.

Vance: We get pret­ty close. 

Malamud: Pretty close. And do you think some­one with Windows NT, or OS/2 or some of these oth­er oper­at­ing systems—the Macintosh—is gonna be the same thing?

Vance: I don’t think so. There are a num­ber of com­mon con­cepts between VMS and Unix that you don’t real­ly get with things like NT and the Macintosh. Yeah, they all pret­ty much have hier­ar­chi­cal filesys­tems, but in terms of a mul­ti­task­ing oper­at­ing sys­tem, in terms of the con­cept of what a user is, what a file is, in the Macintosh and Windows NT world, it’s very dif­fer­ent. It’s… In fact I think peo­ple are going to dis­cov­er as NT becomes more and more pop­u­lar, and peo­ple in par­tic­u­lar start look­ing at NT as a serv­er plat­form, they’re going to real­ize that it’s going to take a new style of think­ing to adapt servers to the NT envi­ron­ment. Because it does­n’t have the same con­cept of a user that you get with VMS and Unix.

Malamud: Your soft­ware is often used for an appli­ca­tion which has puz­zled me a bit. And that is cre­at­ing DECnet tun­nels. You encap­su­late DECnet pack­ets inside of TCP/IP pack­ets, move ​’em over a TCP/IP net­work to some oth­er place, decap­su­late ​’em, turn ​’em back into a DECnet pack­et. Um, why would any­body do this? Why don’t you just run mul­ti­pro­to­col router, for exam­ple, or do away with one of the networks?

Vance: Well, it is kind of inter­est­ing. We first did DECnet over IP large­ly on…I don’t know if I’d nec­es­sar­i­ly say it was a dare, but some­one told Ken Adelman, one of our founders, that it could­n’t be done. That you could not do DECnet over IP tun­nel­ing. Ken of course…real­ly real­ly hates being told that he can’t do some­thing. So he set out to prove the guy wrong. He devel­oped the soft­ware— As it turns out it’s been very use­ful in the Internet, in par­tic­u­lar by NASA. NASA runs a very large DECnet net­work, for­mer­ly called SPAN, the Space Physics Analysis Network, cur­rent­ly I believe called NSI/DECnet.

And basi­cal­ly these guys need to be able to pro­vide DECnet to some of the far reach­es of the Internet. Well, it’s not really…practical in many cas­es to estab­lish a ded­i­cat­ed DECnet line from one of the NASA hub sites to a small col­lege some­where, or to a research facil­i­ty. And when you look at how these folks are con­nect­ed any­way, they’ve already got an Internet link. But the Internet itself of course does­n’t run DECnet. So being able to tun­nel DECnet over the Internet back­bone to be able to reach into some of these small­er sites saves you a tremen­dous amount of mon­ey, and extra line costs in terms of poten­tial­ly hav­ing to swap out one router ven­dor for anoth­er if the exist­ing router ven­dor does­n’t sup­port DECnet. There are quite a num­ber of economies of scale that you can achieve by using this exist­ing infra­struc­ture. And NASA has def­i­nite­ly been one of our largest sup­port­ers in that area.

Now as it turns out, one of the oth­er big uses that we’ve seen for run­ning DECnet over IP are in cer­tain cam­pus envi­ron­ments, where they do not allow any­thing else on their cam­pus back­bone aside from IP.

Malamud: You’re lis­ten­ing to Geek of the Week. Support for this pro­gram is pro­vid­ed by Sun Microsystems. Sun Microsystems, Open Systems for Open Minds. Additional sup­port for Geek of the Week comes from O’Reilly & Associates, pub­lish­ers of books that help peo­ple get more out of computers.

Malamud: Now, let me ask you this. What if I had mul­ti­pro­to­col routers on the entire path between these two end­points. Would it still make sense to do a tun­nel, or should I just acti­vate the mul­ti­pro­to­col rout­ing capability?

Vance: It does­n’t real­ly make much sense at that point. You do end up tak­ing a hit in per­for­mance because of course you have to have these two end sys­tems run­ning MultiNet to be able to do the encap­su­la­tion and decap­su­la­tion. And if you’ve got a ded­i­cat­ed sys­tem that you can pro­vide for that, per­for­mance isn’t real­ly so much of an issue. But it’s going to reduce the band­width you’re going to have, it’s going to increase the laten­cy. So in that par­tic­u­lar case, you’re real­ly bet­ter off just enabling DECnet on the mul­ti­pro­to­col routers. But the issue is then that now you have to wor­ry about man­ag­ing two pro­to­cols on a par­tic­u­lar plat­form instead of just one. Because you know you’re gonna have to— Since you know you’re gonna have to man­age DECnet on the VMS sys­tem anyway…yeah, adding an extra cir­cuit in usu­al­ly isn’t a big deal.

Malamud: So run­ning the TCP/IP-only back­bone might actu­al­ly make sense in some envi­ron­ments as far as the net­work man­age­ment load and things of that sort.

Vance: In some envi­ron­ments, yes. As I men­tioned there are cou­ple of uni­ver­si­ties I’ve run into that do not allow any­thing on their cam­pus back­bone aside from IP because they feel like they can man­age IP. They under­stand it. And they actu­al­ly tie togeth­er all of their DECnet hosts by hav­ing one DECnet host in each depart­ment run­ning MultiNet, With a DECnet over IP link going into a cen­tral sys­tem at the main com­put­er facil­i­ty. And it—at least the last time that I talked to them it was run­ning some­thing on the order of six­teen dif­fer­ent DECnet over IP tun­nels to these departments. 

Malamud: Tunneling and encap­su­la­tion is used when ser­vices are not deployed through that entire net. It’s a way of jump­ing over an infra­struc­ture. That’s cur­rent­ly being used to sup­port new tech­nolo­gies such as mul­ti­cas­t­ing. Is this is a gener­ic tech­nique we should be using in design­ing our protocols?

Vance: I ful­ly think so. The nice thing about encap­su­la­tion like this, tun­nel­ing, is that you can employ a new pro­to­col, or deploy a new pro­to­col, in an area where you don’t have the native net­work sup­port for it. For exam­ple if you look at some of the work that’s going on with the IP ver­sion 7, there’s one par­tic­u­lar pro­pos­al called SIP, the Simple Internet Protocol. There is test­ing going on on the Internet today between end sys­tem imple­men­ta­tions of SIP, even though there is no end-to-end SIP path between the two test­ing sites. They’re using a scheme known as IPAE, IP Address Encapsulation, that allows you to estab­lish a SIP con­nec­tion, ​“con­nec­tion,” between two SIP hosts, over an IP backbone.

So the nice thing about this is it allows you to do rapid pro­to­typ­ing because you don’t have to wor­ry about replac­ing your entire net­work infra­struc­ture. And it can end up sav­ing you a lot of time and mon­ey in terms of development.

Malamud: You think this is how the Internet is gonna do its tran­si­tion to the to the next IP, is by tran­si­tion­ing parts of the net and then using tun­nels on the parts that haven’t made it? Or is there a more sophis­ti­cat­ed scheme we can use?

Vance: Well it’s prob­a­bly going to depend some­what on what pro­pos­al is cho­sen. If you look at the two cur­rent pop­u­lar pro­pos­als, one is SIP, which is pret­ty much like straight IP only with a 64-bit address—a fair num­ber of oth­er changes, but it’s not a rad­i­cal departure. 

The oth­er, how­ev­er, is TUBA, which is TCP and UDP over the OSI Connectionless Networking Protocol stack. That’s a more rad­i­cal depar­ture. And while there is quite a bit of OSI work, OSI traf­fic flow­ing around on the Internet over a num­ber of mul­ti­pro­to­col back­bones, when it comes to tran­si­tion­ing, you real­ly are look­ing at a tran­si­tion. It’s not a… There’s not real­ly as much coex­is­tence poten­tial­ly pos­si­ble as you have with say SIP and IPAE. 

But I think in both cas­es you are look­ing at a sit­u­a­tion you’re gonna do a lot of encap­su­la­tion, a lot of tun­nel­ing, because you are going to cer­tain areas where you’ve got two hosts that want to com­mu­ni­cate using CLNP, and there’s only an IP back­bone between them. And of course cer­tain­ly as is the case with SIP, it’s planned all along that you’ll have SIP tun­neled over IP, and IP tun­neled over SIP, and they’re even look­ing at even more gen­er­al things like tun­nel­ing IP over IP.

Malamud: Why would you do that?

Vance: It has a num­ber of inter­est­ing ben­e­fits, one of which is in terms of sup­port­ing mobile hosts. You can have your host assigned a unique IP address, which you keep with you no mat­ter where you go. And if you ever have to stop and plug in some­where, you get a local net­work near a local IP address, but you then estab­lished an IP over IP link into your home facil­i­ty, your cen­tral facil­i­ty, giv­ing you effec­tive­ly a con­stant address no mat­ter where you go. 

The oth­er nice thing it pro­vide you is a sit­u­a­tion where you might have two dif­fer­ent sub­nets of an IP net­work num­ber sep­a­rat­ed by a dif­fer­ent net­work num­ber. IP in gen­er­al does­n’t deal well with par­ti­tioned sub­nets, but if you can estab­lish an IP over IP link to tie the two sub­net togeth­er, you’ve basi­cal­ly healed your sub­net gap. And it gives you an inter­est­ing and very flex­i­ble way of doing…in par­tic­u­lar handling—doing mul­ti­ple path rout­ing where…let’s say you’ve got two paths between two sites. But one of the paths is a dif­fer­ent net­work num­ber. Well, if the pri­ma­ry path goes down, you can failover using the back­up path as long as you have this IP over IP tun­nel to be able to main­tain con­nec­tiv­i­ty between the two sides.

Malamud: Is this an approach that’s gonna scale? What’s gonna hap­pen when every car is a mobile host and the car starts talk­ing to traf­fic con­trol and there’s a mil­lion of those?

Vance: I don’t think any­body real­ly has a good con­cept of what’s going to hap­pen when every car, and every toast­er, and every tele­vi­sion has its own IP address, or its own net­work address. It’s sort of one of those things that’s not just an order of mag­ni­tude prob­lem, it’s a sev­er­al orders of mag­ni­tude prob­lem over what peo­ple are used to deal­ing with now. It’s cer­tain­ly the case that the exist­ing Internet infra­struc­ture could not even begin to han­dle that big of a jump. Either in terms of address allo­ca­tion or in terms of han­dling the rout­ing. The Internet right now is get­ting pre­car­i­ous­ly close to an edge from which it’s going to have a hard time back­ing off. Because there are too many net­work num­bers in use, and the exist­ing rout­ing infra­struc­ture is hav­ing a hard time deal­ing with it. I real­ly do think it’s going to take a cou­ple of leaps in tech­nol­o­gy before we can look at what a num­ber of peo­ple have dubbed ​“ToasterNet,” which is you know, pret­ty much every electro­mechan­i­cal device hav­ing its own address­able network…basically being an address­able net­work entity.

Malamud: Will that be the Internet that we know today, evolved of course, or will it be a dif­fer­ent thing? Will the Internet just go away and become history.

Vance: That’s anoth­er real­ly tough one. I have to tell you I can­not hon­est­ly tell you. There are times when I think the Internet will get its act togeth­er and will have a long and fruit­ful his­to­ry, and there are oth­er times when I think that the Internet is tee­ter­ing pre­car­i­ous­ly on the brink of dis­as­ter. I think that if any of the com­mon car­ri­ers ever real­ly get their act togeth­er and can come up with a low-cost inter­net­work ser­vice, the Internet as we know today may indeed dis­ap­pear. I’m not con­vinced that the com­mon car­ri­ers quite com­pre­hend how to deal with that, how to do some­thing like that. Sprint cer­tain­ly has got­ten into busi­ness now. MCI has got­ten into it to a cer­tain extent. But none of them have real­ly tak­en a big plunge…in com­par­i­son to pro­vid­ing even say X.25 ser­vice, which a num­ber of the car­ri­ers do. 

So I— I real­ly don’t know. It’s going to be inter­est­ing to see what hap­pens in the near future because I think that with­in the next two to three years we’ll get a good han­dle over where the Internet is going to be going for the next ten to fif­teen years.

[Here the record­ing inserts a clipped copy of the ear­li­er Ken Adelman anec­dote, which has been omit­ted as an error. But it’s unclear if there may have been oth­er audio that should have appeared instead.]

Malamud: This is Geek of the Week, fea­tur­ing inter­views with promi­nent mem­bers of the tech­ni­cal com­mu­ni­ty. Geek of the Week is brought to you by O’Reilly & Associates, and by Sun Microsystems. 

Malamud: You’ve been work­ing on an inter­est­ing lit­tle research project with some oth­er folks known as IP over E‑mail. Can you tell me about this effort?

Vance: Well, unfor­tu­nate­ly it’s nev­er quite got­ten as far as we’ve want­ed. We’ve actu­al­ly got the pro­to­col designed. But it sort of came out of get­ting some email from some­body in the Soviet Union want­i­ng infor­ma­tion about our prod­uct. And I start­ed talk­ing with some friends of mine down at a com­pa­ny called Innosoft International. They make a pop­u­lar VMS email gate­way pack­age called PMDF. And were think­ing gee, it’s cer­tain­ly nice that these guys have email but gosh, I won­der how they could actu­al­ly ever end up get­ting direct­ly on the Internet. Well we fig­ured you know, if they’ve got email access, well what we could do is come up with a fram­ing scheme where­by you could lay­er IP pack­ets into an SMTP mail mes­sage. I mean if you think about it, elec­tron­ic mail real­ly is just a data­gram pro­to­col. The data­grams tend to be a lit­tle bit larg­er, and they can be of vari­able size, but you can do pret­ty much any­thing with them that you want. And if you con­sid­er how email func­tions in its store-and-forward tra­ver­sal of the Internet, it real­ly is a lot like an IP data­gram flow­ing through the Internet. Although the nice thing is that in gen­er­al you’ve got a lit­tle bit more like­li­hood that your SMTP mail mes­sage is going to get all the way through than you do say, of an IP data­gram get­ting through. 

Te real chal­lenge, though, is that if you’re going to sup­port some­thing like IP over email, you’ve got­ta make sure that say, your round-trip esti­ma­tion, the RTT esti­ma­tion, can han­dle delays of say…a day. Two days, or three days. I—

Malamud: So tel­net as an appli­ca­tion may not be as snap­py as you’re used to it.

Vance: No, tel­net def­i­nite­ly is going to be a bit slow­er. I mean if you can think about how tel­net nor­mal­ly works, you type a few char­ac­ters and in gen­er­al you end up get­ting one char­ac­ter per pack­et. Well if you think about that in terms of one char­ac­ter per email message…all of a sud­den you start real­iz­ing that the head­ers of your email mes­sage start dwarf­ing the actu­al data inside by oh, I’d say fac­tors of maybe five or six hun­dred in the worst cas­es. Sort of depends on how many email gate­ways you end up hav­ing to pop through. But yeah, the round-trip esti­ma­tion, I don’t if many Berkeley-derived Unix sys­tems could actu­al­ly han­dle round-trip time char­ac­ter­i­za­tions of two or three days. 

The oth­er thing you have to wor­ry about is that most Berkeley-based Unix sys­tems have a TCP con­nec­tion time­out of thirty-seven and a half sec­onds. All of those would cer­tain­ly have to be fixed. I mean if you if you imag­ine hav­ing to send a TCP SYN in an email mes­sage, wait for the SYN-ACK com­ing back, and then send­ing the ACK to final­ly open the con­nec­tion, you poten­tial­ly may have any­where from a few min­utes to sev­er­al hours that will take just to open a TCP con­nec­tion. I don’t know of many TCPs that real­ly are gonna deal with that par­tic­u­lar well either, but. We actu­al­ly looked at the ker­nel hacks that would be nec­es­sary to do that in MultiNet, and we’ve talked to Innosoft and looked at han­dling it in MultiNet. And it’s one of those things where I— As soon as we get in a par­tic­u­lar sil­ly mood…we’ll def­i­nite­ly go ahead and add in. It’s actu­al­ly some­thing that would­n’t real­ly be all that dif­fi­cult. It’s just that I guess we’ve… Well, I guess we’ve sort of blown our­selves out on fun and friv­o­lous activ­i­ties for a while. As you know, we’ve done a num­ber of oth­er enter­tain­ing things, and—

Malamud: You should describe some of those.

Vance: Well back about three years ago, I met a gen­tle­man by the name of Simon Hackett, who at the time was work­ing at the University of Adelaide down in Adelaide, South Australia. Simon and I met at the Australian Network Shop, which was a meet­ing of aca­d­e­m­ic and research types from all over Australia, to try and put togeth­er a nation­al net­work down there. You know, these guys got start­ed on this process in ​’89, which allowed them to do some­thing that unfor­tu­nate­ly we in the US did not have the lux­u­ry of doing. It allowed them to learn from the mis­takes made by…

Malamud: They were able to do it right.

Vance: Exactly, to be able to plan on how to do it right from the start. And AARNET, the Australian Academic Research Network, has been to my mind a shin­ing exam­ple of how to do a nation­al backbone. 

But Simon and I end­ed up meet­ing. He was doing VMS and net­work­ing sup­port down at the University of Adelaide. And he and I met at this con­fer­ence and end­ed up chat­ting quite a bit. And I dis­cov­ered that Simon has quite a knack for elec­tron­ic tin­ker­ing, and inter­fac­ing strange things to com­put­ers. For exam­ple he worked with some friends of his down there on doing a computer-controlled…in fact an Apple II-controlled mul­ti­me­dia sys­tem. You con­trol the CD play­er, a slide pro­jec­tor. I believe also a film pro­jec­tor, so that he was actu­al­ly run­ning this mul­ti­me­dia pre­sen­ta­tion all from an Apple II which he had pro­grammed himself. 

And he and I got to dis­cussing how you could make things like that net­work-con­trolled. And what sort of fol­lowed from that was the first SNMP-con­trolled stereo sys­tem. We used stan­dard Pioneer stereo equip­ment, which had this nice lit­tle remote con­trol jack in the back. The ini­tial pass at the con­troller was a cus­tom 68000 lit­tle con­troller box. Which we still have some upstairs some­where around here. It had 64K of mem­o­ry in it, so we had the fun of relearn­ing how to pro­gram with­out the ben­e­fit of vir­tu­al mem­o­ry. Wrote a sim­ple TCP/IP/UDP stack, which actu­al­ly fit in about 6K. Added an SNMP agent, added a sim­ple com­mand pars­er in it. And end­ed up build­ing some­thing that was an SNMP con­troller for a stereo sys­tem. You could con­trol the vol­ume, you could select what radio sta­tion you want­ed to lis­ten to, you could change the input to the CD play­er. You could play a CD. You could cause the US CD disc pack to be eject­ed. You could pop a new one in. It was real­ly a pret­ty sophis­ti­cat­ed lit­tle box. 

Malamud: And it was­n’t a general-purpose oper­at­ing sys­tem. All it ran was the net­work stack and some upper layer—

Vance: It was strict­ly the net­work stack and a few appli­ca­tions. It was…not multi-tasking, it was single-threaded. But…

Malamud: But it was small and cheap.

Vance: It was small and cheap, and if you look at how much time we put into it, most of the work for this was done in about a month to two months before Interop in ​’90. It was a pret­ty amaz­ing lit­tle project. It man­aged to gar­ner both TGV and Simon quite a bit of both notice and I sup­pose noto­ri­ety at that par­tic­u­lar Interop.

Now as it turns out the fol­low­ing year, we did a slight­ly dif­fer­ent spin on the on the net­work audio stuff. Instead of an SNMP-controlled stereo sys­tem, we actu­al­ly start­ed work­ing on doing audio over the net­work. Simon devel­oped a pro­to­col called MMDS, the MultiMedia Data Stream. MultiMedia Data Switch, excuse me. And in fact that year we actu­al­ly had one receiv­er with a PC con­troller. We decid­ed that the cus­tom— Simon in par­tic­u­lar decid­ed that the cus­tom con­troller con­cept was a lit­tle expen­sive and rather unwieldy to deal with. So we decid­ed that per­haps a PC with a general-purpose oper­at­ing sys­tem run­ning some cus­tom soft­ware might be a lit­tle bit eas­i­er to deal with. And cer­tain­ly an eas­i­er devel­op­ment plat­form to work with. But using a PC as a fron­tend, using some 8‑bit audio cards, and just a stan­dard Ethernet card with pack­et dri­ver sup­port, he was actu­al­ly able to devel­op the hard­ware and soft­ware nec­es­sary to take an audio source and just pump it out over the Ethernet using UDP datagrams. 

We in turn devel­oped a switch that would allow you to be able to act as effec­tive­ly a phone switch for peo­ple being able to call each oth­er up using these PCs. Or be able to dis­trib­ute— Neither of us real­ly were wor­ried about sup­port­ing mul­ti­cast at the time, so if you want­ed to have mul­ti­ple peo­ple lis­ten­ing to a giv­en audio source—a radio sta­tion, for exam­ple, you had to have the audio streams redi­rect­ed through the switch to mul­ti­ple lis­ten­ers. And I guess the crown­ing achieve­ment of that was being able to actu­al­ly play radio sta­tions from Australia on the Interop show floor.

And I guess the most amaz­ing thing about the whole the whole process was when we actu­al­ly tuned in an Australian radio sta­tion and we dis­cov­ered that they lis­ten to the same songs that we do, they have many of the same for­mat radio sta­tions that we do. And the most amaz­ing thing is that their DJs are just as obnox­ious. They just talk with Australian accents. I mean you could eas­i­ly imag­ine an Australian DJ doing the old nox­ious— Well I’m from the South so we used to have mon­ster truck shows down there. And I could just eas­i­ly imag­ine one of the Australian DJs say­ing, [adopts a thick Australian accent] ​“Friday! Saturday! Sunday! Come down to the big mon­ster trucks stomp!” 

They had quite a few com­mer­cials that were in exact­ly that vein. 

Malamud: Would it make sense to take radio sta­tions from around the world and put them all on the Internet so we could tune in? Would the Internet be able to han­dle that? Do we have the infra­struc­ture for some­thing like that?

Vance: I think we will soon. Certainly on the over the NSFNET back­bone, if you look at the band­width they have nowa­days. They’re look­ing at T3 now—or they have T3 now, excuse me. They’re look­ing at giga­bit speeds in the near future. It’s cer­tain­ly pos­si­ble. I think the real issue is… Well, one is sort of the accept­able use issue. Is this real­ly an accept­able or even a good use of pro­vid­ing the Internet? Certainly it would be an inter­est­ing cul­tur­al exper­i­ment to pro­vide access to radio sta­tions. But…I mean gee, where do you draw the lim­it? The inter­est­ing thing about the Internet is that since there’s no cen­tral­ized man­age­ment per se, there’s nobody say­ing when to stop doing some­thing. And we cer­tain­ly know that doing too much of a good thing… If you have eighty or nine­ty radio sources scat­tered around the Internet, even­tu­al­ly you’re going to end up suck­ing down the entire back­bone, poten­tial­ly, doing strict­ly audio stuff. And most peo­ple when they’re pay­ing for their Internet access are pay­ing to actu­al­ly be able to do sci­en­tif­ic and research work.

I think how­ev­er in a con­trolled fash­ion it could cer­tain­ly be an inter­est­ing cul­tur­al exper­i­ment. And I think—at least in my mind that’s also one of the one of the pur­pos­es of the Internet. There are a num­ber of tech­no­log­i­cal issues that need to be dealt with. You real­ly do want to have wide­spread mul­ti­cast sup­port. Because you don’t real­ly want to have to house six­teen or sev­en­teen or twen­ty or thir­ty dif­fer­ent streams run­ning in par­al­lel to dif­fer­ent des­ti­na­tions for every input stream. Yeah, I think as mul­ti­cast IP becomes a lit­tle bit more wide­spread that won’t be so much of a problem. 

But yeah, I would actu­al­ly found it pret­ty fas­ci­nat­ing. I would love to be able to tune into the BBC, or to be able to dial around and pick an Australian radio sta­tion to lis­ten to at times. Or even, on per­haps a more exot­ic note, lis­ten to some sta­tions in Japan. Or Italy. I think there are a num­ber of inter­est­ing possibilities.

Malamud: Well, we’ve been talk­ing to Stuart Vance. This is Carl Malamud and you’ve been lis­ten­ing to Geek of the Week.

Malamud: This has been Geek of the Week, brought to you by Sun Microsystems, and by O’Reilly & Associates. To pur­chase an audio cas­sette or audio CD of this pro­gram, send elec­tron­ic mail to radio@​ora.​com.

Internet Talk Radio, the medi­um is the message.