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

Geek of the Week. We’re talk­ing to Dr. Radia Perlman. She’s the author of Interconnections: Bridges and Routers. It’s the defin­i­tive book on bridges and routers, as you may guess, and she’s at Novell, Inc. Welcome to Geek of the Week. 

Perlman: Hello. 

Malamud: Well why don’t you start by telling us the dif­fer­ence between a bridge and a router. Aren’t these device—haven’t they merged? Doesn’t Cisco do every­thing for you now? 

Perlman: Ah, yes. What’s the dif­fer­ence between a bridge and a router? Well, if you look at the ISO mod­el… ISO has them defined very well, which is that a bridge is a data link lay­er relay, and a router is a net­work lay­er relay. And that’s fine, until you start won­der­ing what’s a data link lay­er and what’s a net­work lay­er. And if it were up to me, what a data link lay­er would be is some­thing that gets mes­sages one hop to a directly-connected neigh­bor. And what a net­work lay­er is is some­thing that pieces togeth­er a whole path.

So under that def­i­n­i­tion, there should be no such thing as a bridge. But it turns out that the real def­i­n­i­tion between a net­work lay­er ver­sus a data link lay­er is that a data link lay­er pro­to­col is any­thing that’s designed by a com­mit­tee char­tered to do a data link lay­er pro­to­col. And that’s how bridges get to be called bridges—

Malamud: Let me guess. And a rout­ing pro­to­col’s any­thing chart­ed by a com­mit­tee char­tered to do that, right.

Perlman: Absolutely, yes.

Malamud: Okay. Well, um…okay, stan­dards designed by com­mit­tee. As I under­stand bridges and routers, many of the func­tions have merged into a sin­gle box these days; many devices can can do both. And for a while there was a real reli­gion. There were some net­works that were bridge-only net­works. A lot of big deck instal­la­tions were like that. And oth­ers were router-only instal­la­tions and you know, a lot of the kind of clas­sic TCP/IP land was that way. Do both play a role in any net­work? I mean, should we be look­ing at both as part of our toolkit? 

Perlman: Yes, because some­times you need bridges because you have non-routable pro­to­cols. Like LAT. But um… 

Malamud: Should there be non-routable pro­to­cols? Is that a design error?

Perlman: No, there should not be non-routable pro­to­cols, and as a mat­ter of fact I was not too hap­py about LAT orig­i­nal­ly. Because you could do some­thing like tel­net, which does the same pur­pose but it’s built on top of a net­work lay­er. But the design­ers basi­cal­ly said, ​“Why would any­body want the ter­mi­nal serv­er on a dif­fer­ent LAN than the host?” And so they were absolute­ly con­vinced that you would nev­er want to do that and so there­fore it was per­fect­ly safe to not both­er with a net­work lay­er because it would always be con­fined to a LAN. But of course that’s one of the most pop­u­lar rea­sons for bridges, is in order to get things mul­ti­ple hops. 

Malamud: Now, LAT has some nice prop­er­ties, of course. It lets you mul­ti­plex data from sev­er­al users on the same device going to the same host. Should we have changed tel­net to accom­mo­date these needs, or is this kind of an overde­sign of the LAT protocol? 

Perlman: I’m not that famil­iar with that kind of thing, but absolute­ly there’s no rea­son why you could­n’t have designed all the func­tion­al­i­ty of LAT on top of a net­work lay­er. And any sort of func­tion­al­i­ty that’s in LAT and not in tel­net you— I mean, any pro­to­col can become any oth­er pro­to­col by sort of mod­i­fy­ing it, by tak­ing away all the old pack­et for­mats and adding new ones. You cer­tain­ly could have a routable thing that has all that functionality. 

Malamud: So it sounds like a bridge is sim­ply a stop­gap mea­sure when you have non-routable pro­to­cols, and you would pre­fer to see a router in your net­work instead of a bridge if you could.

Perlman: Yeah. A bridge is a kludge. It’s a world-class kludge. It’s a won­der­ful kludge. But it’s def­i­nite­ly a kludge to get around the fact that peo­ple built things with­out a net­work lay­er. Now, that’s par­tial­ly the prob— The prob­lem came about because the peo­ple that invent­ed Ethernet did a real good thing. Ethernet is good tech­nol­o­gy. But they did a real­ly bad thing because they called it a net. And they should­n’t have called it Ethernet, they should’ve called it ​“Etherlink.”

Malamud: Or ​“Etherwire,” or…yeah.

Perlman: Right. And so all these peo­ple got fooled. They said, ​“Wow, this is our entire net­work. It’s this one wire.” And then they did­n’t need a net­work lay­er, because all the rout­ing was done by this one wire, because every­thing in the uni­verse was attached to this one wire. But that was of course very sil­ly, in ret­ro­spect, and peo­ple should­n’t have built devices that only could talk—and pro­to­cols that could only talk on a sin­gle wire. 

When the world got entrenched that way and then decid­ed they want­ed a way for pack­ets to leap from one Ethernet to anoth­er, I sort of felt like well, you know, they deserve what they got. Because they should’ve had a net­work lay­er there in the first place. But, there cer­tain­ly was a mar­ket for a mag­ic device that would some­how splice these things togeth­er. And that’s where bridges came from. Now, that’s where trans­par­ent bridges came from. The notion was that you could­n’t change the installed base, and that you had to be able to talk from one wire to anoth­er wire mag­i­cal­ly, with­out chang­ing the installed base. 

Then along came source rout­ing bridges, which are real­ly a mys­tery as to how they can pos­si­bly be called a bridge, because it was a whole net­work layer—a very com­plex net­work lay­er. Not only did the end nodes have to be aware that there were store-and-forward devices there, but the end nodes had to fig­ure out the routes. So you had to change the head­er, and you had to change what the end nodes did. But that did get to be called the bridge rather than a router just because it was done by the 802 com­mit­tee. And as a mat­ter of fact it’s called a MAC lay­er bridge, which if you con­sid­er the data link lay­er it’s sort of sub-divided by IEEE 802 into the phys­i­cal lay­er, which…well, I guess that’s the same as the phys­i­cal lay­er. But there’s the MAC sub-layer and the LLC sub-layer. There’s real­ly no rea­son for this lay­er­ing, oth­er than the fact that some peo­ple thought that pro­to­cols ought to be connection-oriented even on LANS. So that’s why you need­ed this upper lay­er. But because the com­mit­tee that spon­sored the source-routing bridges hap­pen to be Token Ring Committee, which is a spe­cif­ic MAC lay­er device which is sort of low­er than the data link lay­er, bridges got to be called MAC lay­er devices, which again the only rea­son that’s mean­ing­ful at all is because that was the com­mit­tee that stan­dard­ized it. 

Malamud: And by split­ting up the data link lay­er into two sub-layers you have room for two committees. 

Perlman: Right. Oh, yes. And more com­mit­tees means more trav­el, more fine lunch­es and dinners…

Malamud: Absolutely. That’s our goal in this whole thing anyway. 

Perlman: right.

Malamud: Let’s turn our atten­tion to routers. Most routers these days are multi-protocol routers. And most of them will for­ward sev­er­al dif­fer­ent pro­to­cols, IPX and IP, and typ­i­cal­ly will speak sev­er­al dif­fer­ent rout­ing update pro­to­col lan­guages. Is this a good thing or are routers get­ting too com­pli­cat­ed? Should we be try­ing to pare it down to a sin­gle net­work lay­er and a sin­gle rout­ing update protocol?

Perlman: A sin­gle net­work lay­er would be nice. That’s not gonna hap­pen in any near time­frame. There’s absolute­ly no excuse for mul­ti­ple rout­ing pro­to­cols, though. It just hap­pens that every­one who designed a net­work lay­er hap­pened to also design a rout­ing pro­to­col because every­one assumes that their pro­to­col suite is the only one in the uni­verse. And every pro­to­col suite needs a rout­ing pro­to­col, and so they have done this. But there’s absolute­ly no rea­son why one rout­ing pro­to­col could­n’t route everything. 

Malamud: But aren’t some eas­i­er to wor— For exam­ple, RIP is kind of— Out of the box it’s brain­dead, but it’s real easy to put togeth­er. BGP4 on the oth­er hand is a more sophis­ti­cat­ed type of oper­a­tion. Wouldn’t it be appro­pri­ate to have dif­fer­ent rout­ing pro­to­cols for dif­fer­ent envi­ron­ments, just like we have dif­fer­ent data link lay­ers for dif­fer­ent envi­ron­ments? Or can one do every­thing [inaudi­ble]?

Perlman: I think one can do every­thing. There’s some ques­tion about whether you need an inter-domain ver­sus an intra-domain, but there’s noth­ing so exot­ic about these var­i­ous net­work lay­ers like IPX, IP, CLNP DECnet, AppleTalk. There’s noth­ing so exot­ic about any of them that one rout­ing pro­to­col could­n’t route every­thing. And that’s known as inte­grat­ed rout­ing; have one rout­ing protocol. 

And it’s much eas­i­er to deal with because you only have to read one spec. You only have to imple­ment one thing. You only have to con­fig­ure one thing. And in terms of imple­men­ta­tion it’s actu­al­ly hard­er, more than twice as hard to imple­ment two rout­ing pro­to­cols as one because you have to wor­ry about the inter­re­la­tion­ships between them. But then also it just is so hor­ri­bly waste­ful. If you con­sid­er link state pro­to­cols, one of the things they do is they have routers— Oh, I use ​“root­ers” and routers inter­change­ably that way. I don’t— 

Malamud: Oh, that’s okay. I use toma­toes and tomahtoes. 

Perlman: Interchangeably? 

Malamud: Well in sal­ads as well. 

Perlman: Right, okay. 

Perlman: You have to find out who your neigh­bor routers are, and so all of these pro­to­cols have some kind of thing where you peri­od­i­cal­ly send ​“hel­lo.” You say, ​“Hello, I’m Radia,” to your neigh­bors, and they send some­thing to you. 

Why on Earth you have to send two dif­fer­ent mes­sages to do the same thing because for instance you have to send an OSPF hel­lo, and you have to send let’s say an IS-IS hel­lo, they’re exact­ly the same kind of thing, just a slight­ly dif­fer­ent pack­et. And so that’s twice as much traf­fic for no good rea­son whatsoever. 

Malamud: Those are both link-state pro­to­cols, IS-IS and OSPF. Are there dif­fer­ences between them? Are there things that one pro­to­col does and the oth­er doesn’t?

Perlman: Not…terribly…much. I mean, in terms of func­tion­al­i­ty they real­ly are doing the same thing. Nobody real­ly wants to see the net­work lay­er. What they want to do is they want to deposit their pack­ets and have them crop up some­place else where they tell it to. All the rout­ing pro­to­cols do that. RIP does that, too. It basi­cal­ly builds a for­ward­ing table, and how­ev­er a rout­ing pro­to­col does that is fine; once you have the for­ward­ing table you just for­ward pack­ets. And that’s real­ly where the per­for­mance of a router mat­ters most, is forwarding. 

There are sub­tle dif­fer­ences between IS-IS and OSPF. The most sig­nif­i­cant one is if you’re in a multi-protocol envi­ron­ment IS-IS will route every­thing, and so you only have to do one pro­to­col, where­as if you insist that if you have IP you have to have OSPF then it means that if you have CLNP you have to also have IS-IS. If you have IPX you also have to have NLSP and so forth. And then you wind up with all these rout­ing pro­to­cols basi­cal­ly doing the same thing.

Malamud: What would it take to mod­i­fy OSPF to han­dle mul­ti­ple pro­to­cols? I would think in a multi-protocol inter­net that that would be a desir­able goal. 

Perlman: Well, the thing about IS-IS which makes it some­what unpalat­able to some peo­ple is that every­thing… There’s a base pro­to­col which has the fields in there. And then every­thing else is options. So there’s a way of adding options to pack­ets. So if you need a new field you just invent a new option code. And espe­cial­ly if it’s some­thing like here are IPX address­es I can reach, you can just add that as an option and even if there’s routers in your net that nev­er heard of IPX, they just pass the rout­ing infor­ma­tion through and the fact that there’s this extra field in there they don’t under­stand, that’s okay. The rule is if you don’t under­stand an option you don’t both­er look­ing at it but you cer­tain­ly keep it in mem­o­ry and you for­ward it to the rest of the network. 

So the abil­i­ty to put options in there makes it very easy to extend it and have mul­ti­ple pro­to­cols. OSPF has very much fixed-length fields. So it would be a dif­fer­ent pro­to­col if you were to do it, where­as with IS-IS adding new options to the pro­to­col does­n’t real­ly change the protocol. 

Malamud: Now, you were quite active in the IETF and and oth­er com­mit­tees dur­ing the devel­op­ment of a lot of the IS-IS work and OSPF. Surely you made this argu­ment to the IETF about why OSPF should route mul­ti­ple pro­to­cols, and the use of options instead of fixed-length… Why was­n’t that adopted?

Perlman: Because…

Malamud: Were oth­er pro­to­cols not tak­en seri­ous­ly? Was it a feel­ing that IP’s the only thing that matters?

Perlman: Yes, def­i­nite­ly there was ​“it does­n’t mat­ter” about oth­er pro­to­cols. And so there­fore the multi-protocol abil­i­ty was irrel­e­vant to some peo­ple. But most most­ly, to tell you the truth, the argu­ments were not tech­ni­cal. If they had been tech­ni­cal it would have been a lot more clear-cut. But a lot of the peo­ple with real­ly strong opin­ions did­n’t under­stand the details of either pro­to­col. And I would say vir­tu­al­ly nobody under­stood both pro­to­cols. And I would think that any­body that real­ly want­ed to have a strong opin­ion would owe it to the world, before hav­ing that strong opin­ion. to make sure that they deeply under­stood the tech­ni­cal aspects of both.

Malamud: Well, most peo­ple’s strong opin­ions have been busy gar­ner­ing the opin­ions and— 

Perlman: Right. 

Malamud: Reading the doc­u­men­ta­tion is always one of those big steps to actu­al­ly take.

Perlman: Right. Now, there are some things to be said against IS-IS, which is that it was writ­ten in ISO-ese, which is a dialect of gib­ber­ish. I mean, it was real­ly very hard to read. It turns out to be a very sim­ple pro­to­col, but some­how it is pos­si­ble to write any­thing sim­ple up in a way that makes it seem very complicated.

Malamud: Well that’s the inter­na­tion­al process. 

Malamud: OSPF has been extend­ed to sup­port mul­ti­cas­t­ing, as a part of the rout­ing update process. Does IS-IS also sup­port con­cepts of mul­ti­cas­t­ing in there?

Perlman: Certainly any­thing that you could do there in OSPF you could eas­i­ly do with IS-IS as well.

Malamud: Would you explain [?] what mul­ti­cast exten­sions mean in the con­text of a rout­ing protocol?

Malamud: Well in terms of OSPF, what was done is that… Yeah, right. This I’m not that famil­iar with, so I’m like tread­ing a lit­tle bit on thin ice. But, what hap­pens is that any­one who’s lis­ten­ing to a par­tic­u­lar mul­ti­cast address announces that fact to the router. And the router puts into the link-state pack­et who’s lis­ten­ing to what mul­ti­cast address­es. And then when there’s a pack­et trans­mit­ted with a par­tic­u­lar des­ti­na­tion mul­ti­cast address, there is a opti­mal tree built from that source to every pos­si­ble lis­ten­er of that. 

My feel­ing is that that’s not the right way to do mul­ti­cast. That instead you should be… Yeah, you should­n’t have some­thing where every­body in the uni­verse has to know who’s lis­ten­ing to every mul­ti­cast address. That just does­n’t scale. What instead you do is that all the routers on the path of a par­tic­u­lar mul­ti­cast have to keep state that there’s a mul­ti­cast going on. And that is more done in the style of what’s going on today in terms of mul­ti­cast research, which is the… What does the acronym stand for, Protocol Independent Multicast. I think it was rough­ly based on the core-based tree stuff, and has been evolv­ing, is still evolv­ing some­what, but I like that approach much better. 

Malamud: You talk about build­ing state into the routers, and there’s been a vari­ety of efforts by Dave Clark and and oth­ers to build some form of state into the net­work lay­er so we can begin doing things like resource reser­va­tion, for exam­ple. Do you have any idea how that research is going to turn out? Are we begin­ning to see a glimpse of how we’re going to do dif­fer­ent class­es of ser­vice, for example?

Perlman: Yeah, I find… I don’t firm­ly believe that resource reser­va­tion is a good idea. The idea of a data­gram ser­vice is where if it gets over­crowd­ed, then pack­ets get lost at ran­dom and your ser­vice goes down but nobody’s com­plete­ly locked out. With resource reser­va­tion, the lucky few that get in get great ser­vice. But when you reserve resources… Yeah. If you actu­al­ly believe, like I do, that almost all appli­ca­tions are bursty, then resource reser­va­tion, either you have to over­book, in which case you’re back to the old world of data­grams because you will have to throw things away, or else you’re hor­ri­bly underallocated. 

Now, if you’re will­ing to live with an incred­i­bly under­al­lo­cat­ed net­work then you don’t need to do any­thing fan­cy at all. If you’re only using 30% of your capac­i­ty, then any scheme what­so­ev­er will work fine; all users will get good service. 

Malamud: Can you com­bine those togeth­er and say that for this class of asyn­chro­nous data we real­ly are going to kind of over­book just a lit­tle bit and make sure we’re okay, and for this oth­er class of gen­er­al pur­pose if a few data­grams fall on the ground it’s okay?

Perlman: You cer­tain­ly could do that. It’s rea­son­able to reserve some band­width for the appli­ca­tions that real­ly are not bursty and real­ly do require that kind of ser­vice, and then for others…not both­er. Yeah.

Malamud: How is that going to fall out, though? I mean, is ATM going to solve all these prob­lems for us or are we going to have to do some­thing at the net­work lay­er to sup­port some of these concepts?

Perlman: I’m not sure about that. ATM is sort of a fun­ny case. It declared vic­to­ry, and I then decid­ed that I real­ly need­ed to learn what it was. And so I would ask things like, ​“Well, what do the address­es look like?” And they said, ​“Well we…haven’t [crosstalk] done that yet.” 

Malamud: For fur­ther study. To be determined.

Perlman: Right, yeah. And ​“Well, how do you set up calls?” 

“Well, we haven’t decid­ed that.” 

You know, ​“How do you route things?” 

“Well, we haven’t decid­ed that.” 

And turns out the only thing they’d actu­al­ly decid­ed at the time that I first got into look­ing at it was that the cell size would be 48 bytes. And based on this one deci­sion that made nobody hap­py, ATM was going to take over the world. 

Malamud: 48 bytes is a strange num­ber. You know the ori­gin of that number?

Perlman: Yeah, the phone com­pa­nies want­ed it to be no big­ger than 32 bites because oth­er­wise they’d have to do echo sup­pres­sion. And the data com­mu­ni­ca­tions peo­ple want­ed it to be at least 64 bytes. And so they picked 48. 

Malamud: So the voice cir­cuits will in fact have to do echo cancellation.

Perlman: I believe so, yes.

Malamud: And can we live with 64-byte cells? I mean, does this make any sense at all in a data­gram world, espe­cial­ly run­ning at let’s say giga­bit speeds, to be break­ing that up into lit­tle pieces?

Perlman: Well, I thought for a while that that seemed incred­i­bly stu­pid, to have such tiny pack­ets. But they’re not real­ly pack­ets if you think of them as big bits rather than tiny pack­ets. And you don’t real­ly see the fact that your pack­et gets chopped up into indi­vid­ual bits as it gets sent to cross an Ethernet. Here you want real­ly see the fact that your pack­et gets chopped up into 48-byte chunks. 

Malamud: In the rout­ing world one of the things that many peo­ple have long want­ed to have is pol­i­cy rout­ing. Saying, ​“Gee, let’s see, this pack­et ought to go this direc­tion because it’s com­mer­cial, and this pack­et ought to go that direc­tion because it’s a Tuesday.” How are we going to build pol­i­cy rout­ing, or will we ever do that? Is this an appli­ca­tion ques­tion or can we expect our net­work to be a traf­fic cop? 

Perlman: Yeah, that’s tough also. If you look at all the pos­si­ble things that any­body might ever want to solve, there’s real­ly no way to do a net­work lay­er that accom­plish­es all that, except by per­haps giv­ing you all the infor­ma­tion required and let­ting you cal­cu­late your own path and set it up. 

Malamud: So source rout­ing, is that how we solve this problem?

Perlman: If that’s the absolute most gen­er­al prob­lem needs to be solved, then that’s real­ly the only way I can imag­ine doing it. But if you’re will­ing to solve some cas­es, then that’ll be fine. BGP does that. It solves some­thing. It’s not clear exact­ly what things it solves, what things it does­n’t; there are cer­tain­ly some clear­ly use­ful policy-based rout­ing things that it does­n’t solve, like the abil­i­ty to pick a dif­fer­ent route depend­ing on where the pack­et came from. So you might have two ways to get to the des­ti­na­tion, one which only mil­i­tary users are allowed to use, and the oth­er one which only com­mer­cial are allowed to use. If you receive pack­ets from both mil­i­tary types and com­mer­cial types, BGP only has you select one path to the des­ti­na­tion. So if you pick the one that mil­i­tary types are allowed to use the com­mer­cial ones aren’t hap­py, and vice ver­sa. So that is some­thing BGP does­n’t do, and for a while I guess I was argu­ing about that. But the design­er of BGP had a killer argu­ment when­ev­er I said any­thing that well, ​“BGP does­n’t do this.” it It was, ​“Well, it’s bet­ter than EGP. Which nobody can argue with.

Malamud: Can’t argue with that.

Perlman: And we need­ed to do some­thing, so. It does a lot of pol­i­cy kinds of things, not everything—

Malamud: Like what? What are some exam­ples of what it can do? 

Perlman: Well, it allows you to not pass cer­tain routes around. It allows you not to tell some peo­ple that you can real­ly reach some oth­er place. Now, that does­n’t pre­vent them from actu­al­ly using you to get the pack­ets through. If they’re smart enough to know that if they send you the pack­et you’ll get it there, it does­n’t stop you. But it won’t have mind­less rout­ing, won’t just auto­mat­i­cal­ly find you as a path.

Malamud: So this is a secret trap door; if you know to look behind the brick you can go through through this door, and oth­er­wise you don’t.

Perlman: Right. 

Malamud: So this is kind of a pol­i­cy rout­ing through obscu­ri­ty type of mechanism?

Perlman: Yeah, I guess so. And then the oth­er kind of thing that it does is it allows you to select which route you’re going to use to the des­ti­na­tion on some­thing oth­er than a met­ric. A met­ric just…you’re told well, it costs this this way and it costs that that way. Here you’re actu­al­ly told, ​“Here’s the path. And now exam­ine it and and decide which one you want to use.” 

Now, the prob­lem is that’s awful­ly com­pli­cat­ed for peo­ple to con­fig­ure. It involves things like well, I don’t want to go through this par­tic­u­lar domain in order to get there. That’s a fair­ly sim­ple one. Or, if I am going through this domain I don’t also want to go through that domain. You can do arbi­trar­i­ly com­plex things. But— 

Malamud: Because that domain is expen­sive and you don’t— Or that domain is… Why would you want to do that?

Perlman: You could say I don’t want to go through that domain unless there’s no oth­er way to get there, in the case of one domain being expensive.

Malamud: Wouldn’t met­rics han­dle that?

Perlman: Yes, unless you want­ed to say, ​“I don’t want to go through that domain at all.” 

Malamud: Mm hm.

Perlman: Well, I guess met­rics we do that, too.

Malamud: Well, maybe you could have mul­ti­ple met­rics? One’s a boolean that says ​“don’t go there” and anoth­er is ​“here’s the cost” and anoth­er one is you know, ​“here’s the through­put met­ric…,” would­n’t that work?

Perlman: You might be able to do that with just met­rics. You would­n’t be able to do some­thing like say­ing it’s okay to go through Domain A or through Domain C, but I nev­er want to go through both of them on a par­tic­u­lar path. I don’t know why any­one would need this par­tic­u­lar kind of pol­i­cy, but I’m sure there are things that you can’t just do with metrics. 

Perlman: …if you can pig­gy­back off of exist­ing num­bers that already exist out in the world, that’s very con­ve­nient. And one kind of thing is tele­phone num­bers, which are 8 bytes long. So if you could just take your tele­phone num­ber (every­one owns at least one tele­phone num­ber) and turn that into an address somehow. 

Malamud: Now, the tele­phone num­ber is a struc­tured space. It’s a coun­try code, an area code, a local exchange… And so you’re you’re say­ing we should be con­fig­ur­ing our address­es based on geo­graph­ic or oth­er topol­o­gy con­sid­er­a­tions? My address should be…let’s see, in my case Alternet’s my ser­vice provider, I ought to be a us​.alter​net​.thisside​ofth​er​outer​.radio. And then 48 bits for the machine. 

Perlman: Right, that’s one way of doing it. And there maybe should be lots of ways of doing it. Telephone num­bers is one way of doing it. Or you could go to some cen­tral author­i­ty and get it. Or you could get get it based on the provider. So there’s noth­ing waste­ful about hav­ing lots of ways of doing it because as far as a router is con­cerned it’s just a pile of bits, and you route to the longest match­ing address pre­fix; the longest match­ing ini­tial part of that address is where you route to. So it does­n’t hurt if there’s lots of ways of get­ting these things. You want to make it as con­ve­nient as pos­si­ble for peo­ple to find—

Malamud: And could we build an effi­cient router with 20-byte address­es? Could we build effi­cient pro­to­cols with 20-byte addresses?

Perlman: Yes. It’s not real­ly any hard­er. It might be…5% more dif­fi­cult. But 5% is mean­ing­less. If if it were three orders of mag­ni­tude more dif­fi­cult, then you might say one scheme works and anoth­er scheme does­n’t. But giv­en that you’re only talk­ing about a cou­ple of per­cent, then you can’t pos­si­bly have a solu­tion where it works but if you were to make it 1% slow­er it would­n’t work, espe­cial­ly since tech­nol­o­gy keeps improving. 

Malamud: So in a world where we’re I send 30 megabyte audio files out you’re say­ing a few more bytes on an address just isn’t going to hurt our routers, it’s not going to hurt our machines, it does­n’t matter.

Perlman: Right. Right. And if it turns out that routers can’t keep up with the band­width, that peo­ple can’t build routers fast enough to route as fast as the links are, the fact that the address­es are a lit­tle bit small­er won’t help you at all. What you real­ly need to do is some­thing like ATM, where you first set up a path and then send the pack­ets. And that’s a per­fect­ly rea­son­able thing to do. And in which case the ini­tial address, The size of the address that you use in the ini­tial pack­et for set­ting up routes, is irrel­e­vant for performance. 

Malamud: Well, this has been Geek of the Week, and thank you very much Radia.

Malamud: This is Internet Talk Radio, flame of the inter­net. You’ve been lis­ten­ing to Geek of the Week. You make 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 computer. 

Support for Geek of the Week also comes from a 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 Producer 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.