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

This is Geek of the Week. We have with us Milo Medin, who is deputy project man­ag­er of the NASA Science Internet office. He also heads up engi­neer­ing for NASA’s NREN pro­gram. Those are a lot of titles, but basi­cal­ly when we think of NASA Science Internet we think of Milo’s net. Milo’s also an active par­tic­i­pant in the Internet Engineering Task Force. He’s worked a lot on OSPF and oth­er stan­dards. Milo, wel­come to Geek of the Week.

Milo Medin: Ah, thank you Carl. Quite an inter­est­ing oppor­tu­ni­ty to par­tic­i­pate in this new exten­sion of mul­ti­me­dia capa­bil­i­ty on the Internet.

Malamud: That’s right, an adven­ture in broadcasting.

Medin: That’s right, that’s right.

Malamud: I’ve got a cou­ple ques­tions about the NASA Science Internet and its rela­tion­ship to the rest of the Internet. You’re both part and apart of the Internet—

Medin: Right.

Malamud: You’re a mission-oriented network.

Medin: Right.

Malamud: And you’re also the tran­sit net­work for much of the Pacific Rim.

Medin: Right. We have coop­er­a­tive rela­tion­ships with a num­ber of orga­ni­za­tions. In gen­er­al, we try and accom­plish our job in such a way that we can ben­e­fit the over­all infra­struc­ture of the Internet as a whole. Because we believe that if we— There’s no way we can go off and run point-to-point links to every place in the net­work. That’s sort of counter to the Internet phi­los­o­phy any­way. By going in and work­ing with the peo­ple in a nation who are work­ing on that nation’s infra­struc­ture, we can achieve high­er lev­els of per­for­mance and con­nec­tiv­i­ty at low­er costs, and make it in gen­er­al bet­ter for our sci­en­tists and sci­en­tists over­all to be able to access.

Malamud: Do you find the goals of the coun­try might con­flict with your goals as a mission-oriented network?

Medin: In some cas­es that’s there, and oth­er cas­es we… You know, our require­ments are such that some­times we have to meet them via ded­i­cat­ed facil­i­ties. There’s just no way that if we have a flight projects for exam­ple who is push­ing data at near real-time capa­bil­i­ty, the Internet today, Internet tech­nol­o­gy in gen­er­al does not allow you to sort of have ded­i­cat­ed resources or band­width allot­ment. They’re being worked on in R&D on DARPA​’s DARTNet and sev­er­al orga­ni­za­tions are work­ing on things like that. But in gen­er­al, it’s sort of a free-for-all. Now, some­times that works out quite well and it’s com­pat­i­ble with cer­tain require­ments, and some­times it’s not. But we, I think, and the fed­er­al gov­ern­ment as a whole tries to take the approach that we want to build up the infra­struc­ture over­all, and that will in the end be bet­ter off for all of our needs, mis­sion and non-mission require­ments as well.

Malamud: Do you expect some of these clients of yours, coun­tries for exam­ple, to migrate over to alter­na­tive car­ri­ers to com­mer­cial nets in the future? Are you a tran­si­tion path for them?

Medin: Well, I’m not the car­ri­er for coun­tries per se. For exam­ple in PACOM, we’re part of that con­sor­tium. And we get things out of that, oth­er peo­ple get things out of that. We act as their sort of gate­way to the Internet, to the general-purpose Internet. As a whole it’s true. But that’s not dif­fer­ent than the role that NSF or DOE play in oth­er arenas.

I think if the Internet real­ly becomes a pub­lic data net­work in the true sense of the word, some­thing that equals Telenet or some­thing like that, or sur­pass­es it in capa­bil­i­ty, but it’s being used that way then I think in gen­er­al the mis­sion agency net­works will become much more pri­vate, and not have to go off and pull capa­bil­i­ty to places. The over­all struc­ture of the pub­lic data net­work will be at the lev­el that our own net­works won’t have to be as large and we can con­cen­trate on those par­tic­u­lar require­ments which need spe­cial links. 

And I think if every­thing is suc­cess­ful, then that will great­ly decrease in the future. On the oth­er hand, there are a lot of issues which will make it dif­fi­cult for the Internet to expand into that glob­al sort of pub­lic data net­work vision, and we have a job to do. So the ques­tion is how to meet that job, how to how to meet the require­ments that we have in the most cost-effective ways pos­si­ble, and try­ing to do it in a way which is as coop­er­a­tive and as ben­e­fi­cial to the sci­ence and research com­mu­ni­ty over­all. We’re not in the busi­ness of try­ing to com­pete with Sprint or any­body else. It’s not the role of the fed­er­al gov­ern­ment. But we have a lot of exper­tise, and we have cer­tain require­ments that are basi­cal­ly very dif­fi­cult to meet right now in the general-purpose structure.

Malamud: I’ve noticed that the National Science Foundation places cer­tain restric­tions on the type of data that goes over their net­work, an appro­pri­ate use policy.

Medin: Right.

Malamud: Energy Sciences has their own AUP policy—

Medin: Right

Malamud: —as does NASA Science Internet.

Medin: Right.

Malamud: Are those poli­cies con­sis­tent with each oth­er, and if not how do we han­dle that?

Medin: In gen­er­al they’re con­sis­tent with each oth­er. There’s an agree­ment between the agen­cies to sort of pass traf­fic for each oth­er on sort of a quid pro quo basis. Most of those inter­ac­tions occur at the FIXes, the two FIX points where the fed­er­al agen­cies inter­con­nect to each oth­er. But in gen­er­al for exam­ple, NSF can use our link to the Antarctic—in fact that’s all a link that was put in place with the polar pro­grams peo­ple at and NSF—in exchange for us using their con­nec­tiv­i­ty to Cornell University, for exam­ple. And so, the fed­er­al gov­ern­ment is…this is one of the rather unique exam­ples of tight coop­er­a­tion in the fed­er­al gov­ern­ment. Most of the time you’ll end up with agen­cies dupli­cat­ing things quite a bit, and in gen­er­al I think we’ve had a remark­able amount of coop­er­a­tion. Mostly due to I think the per­son­al­i­ties and the sort of com­mon view­points of peo­ple at the head­quar­ters lev­el share.

Malamud: It’s been coop­er­a­tion among agen­cies and also coop­er­a­tion among the agen­cies towards a com­mon vision.

Medin: Right.

Malamud: Is this an exam­ple of an indus­tri­al pol­i­cy? Has been one of the few exam­ples maybe in the US gov­ern­ment of that happening?

Medin: As a civ­il ser­vice employ­ee, I cer­tain­ly could­n’t com­ment on a pol­i­cy like that.

Malamud: Well there you have it. [both laugh]

You men­tioned the FIX, the Federal Internet Exchange—

Medin: Right.

Malamud: Currently there’s a move­ment for some­thing called the Global Internet Exchange, a neu­tral place where any­body can con­nect to and basi­cal­ly peer with any oth­er network.

Medin: Right.

Malamud: Can you explain maybe the dif­fer­ence between a FIX and a GIX, and…

Medin: Well, it’s hard— It’s… You know, the FIXes— First off you know, the FIXes are con­nec­tion points between the major fed­er­al R&D net­works. Those are rel­a­tive­ly few in num­ber, okay. The archi­tec­ture of the FIX, where every­body peers with each oth­er direct­ly, is not an archi­tec­ture that can scale. That is to say you can’t have twen­ty peo­ple all peer­ing with every­body else and doing that kind of thing effec­tive­ly. It becomes a man­age­ment night­mare to con­fig­ure and make sense of all that. 

The GIXes I think are try­ing to do things in a some­what more dis­trib­uted fash­ion and allow greater amounts of car­ri­ers and orga­ni­za­tions to con­nect to each oth­er in an envi­ron­ment where they can sort of hand traf­fic off to each oth­er, pri­mar­i­ly of an inter­na­tion­al fla­vor. But you could look at them as sort of NAPs on a glob­al scale, the NSF…

Malamud: No, I still don’t under­stand why a GIX would­n’t have the same scal­ing prob­lem that a FIX would have.

Medin: I think that some peo­ple have talked about putting route servers, or peo­ple not nec­es­sar­i­ly peer­ing with each oth­er if— You typ­i­cal­ly have a sit­u­a­tion where inter­na­tion­al net­works are more inter­est­ed in get­ting data that’s in the US, and not nec­es­sar­i­ly from each oth­er. If you look at the over­all traf­fic fig­ures for exam­ple of how much say Thailand talks to Australia, com­pared to how much Thailand talks to the US and Australia talks the US, I think you’ll find that the over­whelm­ing amount of traf­fic is going to a cer­tain set of autonomous sys­tems, if you wan­na look at the NSF back­bone or some­thing like that. 

If you’re in the fed­er­al envi­ron­ment I think the sort of load mix is much more diverse. So you can opti­mize in the GIX case by reduc­ing the amount of peer­ing you have and depend­ing on sort of third-party peer­ing or route servers or some­thing like that to min­i­mize that. I think there are sig­nif­i­cant man­age­ment issues which are going to end up hav­ing to be dealt with with GIXes and it’s not clear to me that those things are going to be easy to solve. But we’ll see, you know. It’s one of those things.

Malamud: Now you men­tioned one oth­er con­cept, which is a NAP, a Network Access Point.

Medin: Right.

Malamud: How does that com­pare to GIXes and FIXes?

Medin: Well I think the con­cept of a NAP as defined by sort of what NSF’s vision of where they’re going, at least in my mind is they’re sort of an inter­con­nec­tion point for net­works that’s basi­cal­ly AUP-free, but there’s some­thing called a route serv­er there which acts as sort of the brain that the sort of NSFNET routers do today. But this route serv­er isn’t actu­al­ly a net­work. It does­n’t move data from one point to the oth­er. Everybody sends it routes, it digests them, and sends back a con­sis­tent set of rout­ing infor­ma­tion to the peo­ple who are peer­ing with it. And…

Malamud: That sounds just like a GIX, though, does­n’t it?

Medin: Well, I think the con­cept of the GIX is that peo­ple actu­al­ly peer with each oth­er. And that there’s not cen­tral sort of rout­ing pol­i­cy source on a GIX. Whereas on a NAP the idea is that there’s some­body there that every­body can talk to, and so the rela­tion­ships are not n squared. It’s every­body’s peer­ing with one, and that in turn redis­trib­utes the infor­ma­tion around. It’s the same sort of thing we do in rout­ing algo­rithms, right. If you’re on an Ethernet and you’re run­ning a link-state rout­ing pro­to­col, you could mod­el that Ethernet as a series of point-to-point con­nec­tions between all the routers there. Or you can sort of abstract it by talk­ing to a cen­tral­ized rout­ing agent which redis­trib­utes things. And those things are called des­ig­nat­ed routers in the IS-IS and the OSPF rout­ing pro­to­cols. So it’s the same sort of thing. You deal with it by try­ing to con­sol­i­date the rout­ing inter­changes so you don’t have that kind of ran­dom, or wide­spread rout­ing interaction. 

Malamud: You’re lis­ten­ing to Geek of the Week. Support for this pro­gram is pro­vid­ed by O’Reilly and Associates, rec­og­nized world­wide for defin­i­tive books on the Internet, Unix, the X Windows sys­tem, and oth­er tech­ni­cal top­ics. Additional sup­port for Geek of the Week comes from Sun Microsystems. Sun, the net­work is the computer.

Don’t touch that mouse. Internet Talk Radio will be right back.

[Ask Dr. SNMP seg­ment omitted]

Malamud: You men­tioned OSPF and IS-IS, which are two inter­nal rout­ing pro­to­cols. Of course we start­ed with the famous RIP as an inter­nal rout­ing pro­to­col. Then OSPF and IS. People are now using Border Gateway Protocol as an inter­nal pro­to­col. We have RIP2 com­ing down the pike.

Medin: Right.

Malamud: Do we have too many rout­ing pro­to­cols? Should we say no, or is this good to have so many?

Medin: You know, I don’t know. I find RIP actu­al­ly is a great router dis­cov­ery pro­to­col. You can use it, basi­cal­ly routers send out RIP default, and most hosts that are shipped from ven­dors are equipped with a rout­ed that they can run in ‑q mode (basi­cal­ly qui­et mode) and they just pick up routes from routers, and that way hosts can fig­ure out where their default gate­way is and then they can be ICMP redirected—

Malamud: So it’s good for a workstation.

Medin: So I think it’s good for cer­tain sets of thing there. It’s also the case that a lot of sit­u­a­tions if you have three or four Ethernets, you know, do you real­ly need some­thing more com­pli­cat­ed? Especially if you’ve got low-cost routers. People are build­ing Ethernet routers, PC-based plat­forms that Ethernet to Ethernet very cheap. You have a lot of com­pa­nies get­ting into the low-end Robert busi­ness these days. And so there’s a lot of topol­o­gy that I think that you don’t—static rout­ing work fine in, okay. And so RIP is just an eas­i­er way of doing it than sta­t­ic routing. 

But once— I think we’ve learned in the past that net­works tend to get very com­pli­cat­ed. They grow. They’re not a sta­t­ic thing. And as net­work get larg­er and larg­er you need to move up to some­thing that has a more capa­ble pro­to­col. OSPF I think has been proven in the mar­ket­place as a good pro­to­col. It’s being used all over the world. It’s being used in some very large net­works. And one of the things that we put into it when it was being designed was this notion of class­less rout­ing. Everything is sort of a route plus a mask. There’s not A, B, or C that’s hard-coded into that. That has proven with CIDR and some of the future activ­i­ties that peo­ple are try­ing to put in place now for sort of restruc­tur­ing the way rout­ing in the Internet works to be a very good deci­sion. And so I think you may use OSPF in places where the com­plex­i­ties isn’t dri­ving you but just the way you want to do your sub­net­ting or sort of route mask­ing and match­ing works. 

Malamud: Now I know some net­works…EBONE, the European Backbone for exam­ple, instead of using OSPF inter­nal­ly they’re going to be using BGP inter­nal­ly—IBGP.

Medin: Right.

Malamud: Why would you want to use IBGP or OSPF? Is there room for both of them as an inter­nal rout­ing protocol?

Medin: Um, I don’t— You know, if you’re basi­cal­ly in the tran­sit net busi­ness, you don’t have real­ly very many inter­nal routes, okay. If you look at NSF back­bone, for exam­ple, how many routers and how many router-to-router inter­con­nects are there? There are not that many. Most of the routes that are passed are exter­nal routes. You can pass exter­nal routes by import­ing them into an inter­nal gate­way pro­to­col like OSPF and then reex­port­ing them out at the oth­er end. Or you can pass them in essence via an exter­nal pro­to­col that’s run­ning through your inter­nal net­work. That’s the dif­fer­ence. OSPF can car­ry exter­nal infor­ma­tion, it can car­ry a cer­tain amount of infor­ma­tion in a tag field that goes with it. And that allows you to make pol­i­cy deter­mi­na­tions when you import it and export it. You can do the same thing with IBGP. 

I think the way that IBGP works, with its pri­mar­i­ly sort of point-to-point ori­en­ta­tion— And in cer­tain cir­cum­stances that works quite well. And it avoids hav­ing all that infor­ma­tion be passed in your [insides?]. If you’ve got a router, you’ve got a very sim­ple net­work topol­o­gy inter­nal­ly, and you’re car­ry­ing a lot of exter­nal infor­ma­tion, then why both­er the inter­nal pro­to­cols with car­ry­ing all kinds of infor­ma­tion where it’s just basi­cal­ly act­ing as sort of a trans­port for it It’s just pass­ing it from one place to the oth­er, it’s not real­ly act­ing on it inter­nal­ly, effectively. 

On the oth­er hand, if you’ve got a com­plex inter­nal struc­ture like NSI does, or the way a lot of region­al net­works do, there are some def­i­nite advan­tages by import­ing that and espe­cial­ly if you’ve got a very wide range of inter­faces. You may not be able to effec­tive­ly do point-to-point IBGP connectivity.

Malamud: What about IS-IS? When would I want to run that?

Medin: Well, um… You know, I think right now there’s just not enough IS-IS imple­men­ta­tions out that peo­ple real­ly want to use that. I think if you’re in an IP-only envi­ron­ment, I think you’re prob­a­bly still bet­ter off using OSPF which was real­ly designed and opti­mized to deal with things the way IP does them. IS-IS is a very capa­ble pro­to­col, but I think that most of the pro­po­nents of IS-IS argue that you should use it in sort of this inte­grat­ed rout­ing mod­el where you have both IP and OSI being car­ried in a sin­gle rout­ing pro­to­col. Or oth­er pro­to­cols as well. And we just don’t have enough ven­dors who are doing that, or enough cus­tomers who are actu­al­ly doing that right now to say whether it’s suc­cess­ful or not. I just… All the suc­cess­ful multi-protocol router ven­dors so far have imple­ment­ed mul­ti­ple pro­to­cols using mul­ti­ple stacks. They have not done it the inte­grat­ed way. 

In cer­tain sit­u­a­tions, there’s advan­tages to doing it in an inte­grat­ed way. In oth­er sit­u­a­tions it’s not. The mar­ket­place is basi­cal­ly going to decide that, you know. That’s the great thing about the Internet, right, you can actu­al­ly val­i­date your design prin­ci­ple by whether or not it’s suc­cess­ful at meet­ing real-world prob­lems that real-world peo­ple have. And it’s not just the­o­ry, it’s not just—

Malamud: Well, gross rev­enue speaks a world, does­n’t it?

Medin: Yeah, it cer­tain­ly does. It cer­tain­ly does.

Malamud: I’ve heard a view, and I’m not sure how many peo­ple share it, which is that all this work on com­plex scal­able rout­ing pro­to­cols is a waste of time, and the rea­son is because we’re mov­ing to a glob­al ATM cloud around the world. And you don’t real­ly need rout­ing pro­to­cols, every­one’ll be able to speak to every­one else directly.

Medin: Well, you know— That’s an inter­est­ing view, and it’s held by a lot of peo­ple who I have a lot of respect for. The prob­lem— You know, the prob­lem is that you’re always going to have con­ven­tion­al LANs out. There’s Ethernets that are out there… Ethernet is not going to go away. Not when you can get adapters for you know fifty, six­ty dol­lars and that’s just a part…you know, you put them in and they’re built into work­sta­tions. 10BASE‑T and all of that, oper­at­ing at 10 megabits. There’s a lot of con­ven­tion­al net­work­ing tech­nol­o­gy that’s out there.

And there are low-speed lines. You know, I’ve heard some peo­ple talk about putting ATM over T1 or even some­thing like 56Kbit but real­ly you know, you pay a lot of over­head when you’re try­ing to run on top of a small line that you’re try­ing to get the max­i­mum amount of data across—

Malamud: As we’ve learned with TCP over over dialup lines.

Medin: For exam­ple! For exam­ple. And so— 

Malamud: And head­er com­pres­sion for ATM I guess is not being con­sid­ered yet? [laughs]

Medin: Well I mean, there are dif­fer­ent ways you could com­press. You know, there are plus­es and minus­es of that. I think you know, the ques­tion is real­ly… You know ATM is not a per­fect tech­nol­o­gy. And I don’t think any of its pro­po­nents are argu­ing that. It solves a cer­tain set of prob­lems. And it’s a stan­dard that a lot of peo­ple have embraced. And it gives you cer­tain func­tion­al­i­ty that’s very good to get that way. It uses resource con­trol, and some of the oth­er capa­bil­i­ties are great; isochro­nous transport. 

But as long as you have dis­parate net­works, you need an Internet Protocol, okay. Now, if you’re going Ethernet-to-ATM, how’re you going to do that? Are you going to do that by push­ing some MAC-layer stuff and then, what appli­ca­tion stack? You know, TCP/IP… You’ve got to TCP as trans­port, but that’s designed to run on top of IP. You can’t run TCP on top of 802.2 right now. I don’t know any­body who’s propos­ing doing that kind of thing. And giv­en that, you’ve got a large soft­ware base, a lot of exist­ing host inter­faces. I think there’s a large argu­ment that can be made for run­ning TCP and IP direct­ly on top of ATM. Even if you had a ubiq­ui­tous ATM struc­ture, you could just run that and have com­pat­i­bil­i­ty with all your appli­ca­tions and all these oth­er facil­i­ties that are out there right now. And it’s not clear to me what you’re try­ing to opti­mize if you get rid of IP. There are peo­ple who will argue that TCP is not going to be the pro­to­col that takes us into the giga­bits. I think a lot of peo­ple have said that TCP/IP was not the par­ti­cle that would work well on Ethernet. There are peo­ple who said TCP/IP is not a par­ti­cle that would work well on FIDI. And now peo­ple are say­ing that TCP/IP is not a pro­to­col that will work well at very high data rates.

Malamud: Well I think the bench­marks and work done by David Borman at Cray kind of proves that it may not be the opti­mal pro­to­col for giga­bits but it will cer­tain­ly work [crosstalk] at that speed. 

Medin: Right. And the oth­er thing too is you know, we’re not talk­ing about a sta­t­ic tar­get. You have options…header exten­sion options and oth­er kin­da things which are in place for TCP, and peo­ple are also work­ing on things. So it’s not the same TCP that we had back in 1980 that’s run­ning at giga­bits. You’ve got big­ger win­dow sizes and things like that in there. And so there’s a capa­bil­i­ty there for evolv­ing the stan­dard, which we do all the time in the Internet. And so I have a… You know, again the ques­tion is what do you gain? If you look at where the cycles are spent it’s typ­i­cal­ly not in TCP and IP. You’ve got a lot of oth­er prob­lems to deal with when you’re oper­at­ing at a giga­bit speed. 

So you know, the ques­tion there is what kind of…why would you want to do that? Maybe mul­ti­me­dia con­fer­enc­ing, etc., some of these appli­ca­tions may not be well-suited for run­ning on top of IP. Maybe better-suited to run­ning on top of an ATM net­work directly.

Malamud: Oh sure. Audio for exam­ple could nev­er run over the Internet.

Medin: No, it could nev­er run on top of some­thing like IP. And so you know, there’s a lot of dif­fer­ent ways that you could solve some of these prob­lems. I think one of my con­cerns as some­one who’s look­ing toward actu­al­ly build­ing an ATM wide area sys­tem and using it, is that I think a lot of peo­ple are over­hyp­ing ATM. Especially some of the LAN ven­dors who are pur­port­ing that ATM will cure bald­ness and you know, it’s a dessert top­ping, it’s a floor wax, it does every­thing. And I guess my con­cern is you know, as with all net­work tech­nol­o­gy, that it be used where it makes sense and that it not be sold into envi­ron­ments where it’s not the right answer.

Malamud: Does it make sense as a LAN inter­con­nect for high-speed workstations.

Medin: I think it does. I think there’s a lot of cas­es where it makes sense for that. Now, there’s a lot of envi­ron­ments where Ethernet’s a per­fect­ly good solu­tion. And you don’t real­ly need very high-speed require­ments, per­for­mance require­ments, because work­sta­tions’ I/O archi­tec­ture can’t sup­port good I/O out at very high data rates any­way. And if you’re look­ing at a phys­i­cal plant that’s lim­it­ed to 10BASE‑T type of wiring, Type 5 wiring plan or some­thing, you might get 155 out of it. But you know, you’ve got FDDI and oth­er things there. I think it’s good at doing a cer­tain set of things, but we need to look at it from the point— I mean, there’s a par­a­digm shift involved when you’re talk­ing about ATM. You’re talk­ing about a switch­ing rather than a LAN tech­nol­o­gy. And the abil­i­ty of a LAN over the net­work to be use­ful, you have to have oper­a­tions and man­age­ment capa­bil­i­ties as well. And with ATM you just can’t butt a lan­a­lyz­er into the LAN and see all the traf­fic that’s going across it, right. By def­i­n­i­tion it’s being switched from—there’s not a cen­tral spot where you can just tap into it like you can with FDDI or Ethernet.

So, it’s impor­tant that…you know, there’s a— That’s a down— That’s a neg­a­tive argu­ment against using that type of tech­nol­o­gy in LANs, because how many times when you are hav­ing a prob­lem do you resort just to putting some­thing out on the net­work in promis­cu­ous mode and look­ing at all the pack­ets. If you did­n’t have the tools avail­able to you…you got your­self poten­tial­ly some problems.

Now, that has to be weighed against the advan­tages that ATM switch­ing gives you. And I think a poten­tial advan­tage is an inte­grat­ed local area/wide area envi­ron­ment. And so again you have to look at the cost/benefit trade­offs. But it’s not a sim­ple cal­cu­la­tion. And I think peo­ple, in gen­er­al, a lot of deci­sions that I think sort of mar­ket droids try and try and push are deci­sions that the cus­tomers real­ly have to take a good sol­id look at. Not just in terms of acqui­si­tion cost. Not just in terms of raw per­for­mance. But in terms of oper­a­tions, and main­te­nance, and the abil­i­ty to sup­port the thing, and adapters that work at high per­for­mance. We’re only now start­ing to see adapters for things like work­sta­tions that actu­al­ly oper­ate at rea­son­able data rates because before, they were doing the seg­men­ta­tion and reassem­bly in soft­ware. And you’re burn­ing your work­sta­tion’s CPU just try­ing to put the cells? togeth­er and pull them part. 

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 sys­tems for open minds. Additional sup­port for Geek of the Week comes from O’Reilly and Associates, pub­lish­ers of books that help peo­ple get more out of computers. 

This is Internet Talk Radio. You may copy these files and change the encod­ing for­mat, but may not alter the con­tent or resell the pro­grams. You can send us mail to mail@​radio.​com.

Internet Talk Radio, same-day ser­vice in a nanosec­ond world.

You talked about migra­tion of the TCP pro­to­cols over time to han­dle faster speeds. We’re look­ing at a migra­tion effort now at the IP lev­el, to han­dle right address space exhaus­tion, to look at rout­ing table explo­sion, to sup­port things like pol­i­cy rout­ing. Where do you see that going? What are the require­ments we should be look­ing at for rout­ing protocols?

Medin: Well you know, it’s an inter­est­ing envi­ron­ment. I think the…you know… My per­son­al opin­ion is that— Well we have a say­ing in NASA called ​“fail­ure to achieve orbit,” right. You’ve launched a rock­et, but it did­n’t quite have enough delta‑v to make orbit. And I think a lot of the pro­pos­als out there are going to end up not real­ly mak­ing orbit. They’re not gonna have a lot of imple­men­ta­tion. And I think part of the issue there is you have to look at not just archi­tec­ture but a tran­si­tion plan of how you get from where you are now to where you want to be. 

And we have to learn some­thing from the ISO expe­ri­ence. People are not gonna con­vert to some new pro­to­col unless there’s a sig­nif­i­cant func­tion­al advan­tage to doing so. Okay?

Malamud: Well that’s inter­est­ing because many of the ISO pro­to­cols had um…were feature-rich, one might say. X.400 was tout­ed that way. Many of the low­er layers.

Medin: Right. But I can run X.4—

Malamud: What hap­pened there.

Medin: But I can run X.400 and X.500 on top of IP.

Malamud: Mkay.

Medin: So, I mean just because I want the ISO appli­ca­tion, regard­less of whether or not the appli­ca­tion is good or bad, if it’s a good appli­ca­tion, my—inside NASA there’s a major effort to put in place name­servers using the X.500 pro­to­cols run­ning on top of an IP Internet. So I don’t need the ISO low­er lay­ers to get ISO applications.

Malamud: Are there advan­tages at the low­er lay­ers that I ISO had. For exam­ple, ESIS as a dis­cov­ery program.

Medin: I think there’s a lot of advan­tages in piece­work, but the ques­tion is you know, you’ve got a large installed TCP/IP base/ It is not ade­quate just to have slight advan­tages to get peo­ple to con­vert, okay. How many ven­dors… Here’s an inter­est­ing ques­tion. How many ven­dors ship ISO soft­ware as their default net­work soft­ware that their oper­at­ing sys­tems use, okay, for things like file ser­vice, remote logon, remote pro­ce­dure call mechanisms—ship it by default in their work­sta­tions. It’s not an extra cost option. I’m talk­ing about some­thing that’s bun­dled in because it’s so key to the soft­ware on the dis­trib­uted com­put­ing envi­ron­ment that it has to be there. How many ven­dors do that?

Malamud: Well it’s a good thing we can’t name ven­dors on this program.

Medin: [laughs] Right. So it’s…you know, so there’s a ques­tion there. And I think the ques­tion with an IPv7 follow-on is what advan­tages does it give you on top of the exist­ing IP? If the only advan­tage it gives you is that the sys­tem is scal­able, better-scalable, that’s an advan­tage which is a glob­al advan­tage but has very lit­tle effect on a local deci­sion, right. Some uni­ver­si­ty is not going to go off and renumber…I mean go off and reim­ple­ment all the host soft­ware, or buy brand-new host soft­ware and net­work diag­nos­tic tools and routers and all that oth­er stuff…just so that the Internet can grow, right. There’s no advan­tage to them to do that. So, from the point of view of an incen­tive, what incen­tive do you pro­vide peo­ple to change, okay?

Malamud: What would you like to see in a new rout­ing pro­to­col? What are some of the things miss­ing in IP that you’d like to see there?

Medin: Well, you mean in an Internet protocol.

Malamud: Yeah.

Medin: I think the point— Well, there’s obvi­ous­ly some issues with scal­ing. I think that would be use­ful. But I think…better— We’re not get­ting with ATM and that type of an envi­ron­ment com­mu­ni­ca­tion sub­nets which have abil­i­ty to do resource con­trol and some bet­ter performance-assuring capa­bil­i­ties. And you’d like to have the IP pro­to­col have some capa­bil­i­ty for doing flow IDs or some­thing like that would allow the routers to get some infor­ma­tion that they could use to test either sig­nal down to the sub­net in terms of ​“this flow needs such and such capa­bil­i­ty” and now the ATM net­work can pro­vide that, the TCP lay­er knows that it needs that, how you get that information. 

Malamud: So that’s coor­di­nat­ing. For exam­ple if we have isochro­nous data run­ning across mul­ti­ple ATM clouds in a com­plex Internet, a flow ID would let us iden­ti­fy that flow of data through the network. 

Medin: Yeah, it’s…it’s an over­sim­pli­fi­ca­tion but yeah. Basically what we’d like— You know, think about how much bet­ter it would be if you had an MBbone, a mul­ti­cast back­bone, where you could actu­al­ly devote band­width on demand so when some­body’s run­ning a video con­fer­ence that they can get that band­width and not be stomped on by two Crays start­ing to do a file trans­fer with each oth­er. With an ATM sub­strate you can actu­al­ly do that kind of thing. But yet it’s very dif­fi­cult when you’re actu­al­ly try­ing to use that in an envi­ron­ment where you’ve got TCP and IP and routers and the whole nine yards to make that work. So I think there would be some advan­tages there.

I think anoth­er area would be some­thing that would help you bet­ter pro­vide secu­ri­ty, and secur­ing access to hosts. So this is pri­mar­i­ly a prob­lem with the com­plex oper­at­ing sys­tems we have. There’s poten­tial at least for cer­tain things that could be done there. I think that’s— Unless some­thing is done about being able to secure com­mu­ni­ca­tions, not just…[indis­tinct phrase] most­ly encryp­tion, but make sure that peo­ple can’t do bad things to you across the net­work and that your net­work’s not sub­ject to denial of ser­vice attacks, etc. The Internet’s not going to become a glob­al vil­lage pub­lic data net­work. Businesses are not going to pick a com­mon carrier-based IP solu­tion as opposed to a frame relay or an ATM or SMDS type of solu­tion, because of the poten­tial issues. 

You’ve got­ta— Take your aver­age work­sta­tion. You look at how many lines of code there are in there for the var­i­ous ser­vices that’re avail­able over the net­work. That’s a very com­plex beast, and it really—a lot of this was not designed with secu­ri­ty in mind. And now if you’ve got cor­po­rate data that’s your liveli­hood, and you’re attach­ing it to a net­work where any­body, you know, from the Antarctic to you know, Kuwait can get on to the thing, I mean…this is quite an quite inter­est­ing thing. You need to think about that.

Malamud: Interesting’s an under­state­ment. [both laugh]

There you have it. This is Geek of the Week. We’ve been talk­ing to Milo Medin. Thanks a lot Milo.

Medin: Thank you.

Malamud: This has been Geek of the Week, brought to you by Sun Microsystems and by O’Reilly and
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.