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 protocol’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 toolk­it?

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 pro­to­col?

Perlman: I’m not that famil­iar with that kind of thing, but absolute­ly there’s no rea­son why you couldn’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 func­tion­al­i­ty.

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 shouldn’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 didn’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 shouldn’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 couldn’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 com­mit­tees.

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

Malamud: Absolutely. That’s our goal in this whole thing any­way.

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 pro­to­col?

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 couldn’t route every­thing.

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]?

[From here, Perlman occa­sion­al­ly switch­es between pro­nounc­ing routers, rout­ing, etc. as rout…” and root…”. It will not be fur­ther not­ed in the tran­script.]

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 couldn’t route every­thing. And that’s known as inte­grat­ed rout­ing; have one rout­ing pro­to­col.

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 tom­ah­toes.

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 ISIS 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 what­so­ev­er.

Malamud: Those are both link‐state pro­to­cols, ISIS 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 for­ward­ing.

There are sub­tle dif­fer­ences between ISIS and OSPF. The most sig­nif­i­cant one is if you’re in a multi‐protocol envi­ron­ment ISIS 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 ISIS. 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 ISIS 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 net­work.

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 ISIS adding new options to the pro­to­col doesn’t real­ly change the pro­to­col.

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 ISIS 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 wasn’t that adopt­ed?

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 mat­ters?

Perlman: Yes, def­i­nite­ly there was it doesn’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 didn’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 people’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 ISIS, 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 com­pli­cat­ed.

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 ISIS 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 ISIS as well.

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

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 shouldn’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 doesn’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 bet­ter.

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 exam­ple?

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 under­al­lo­cat­ed.

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 ser­vice.

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 con­cepts?

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 deter­mined.

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 num­ber?

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 can­cel­la­tion.

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 prob­lem?

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 doesn’t; there are cer­tain­ly some clear­ly use­ful policy‐based rout­ing things that it doesn’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 doesn’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 doesn’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 every­thing—

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 doesn’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 doesn’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 mech­a­nism?

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 expen­sive.

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…,” wouldn’t that work?

Perlman: You might be able to do that with just met­rics. You wouldn’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 met­rics.


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 some­how.

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 doesn’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 address­es?

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 doesn’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 wouldn’t work, espe­cial­ly since tech­nol­o­gy keeps improv­ing.

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 doesn’t mat­ter.

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 per­for­mance.

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 com­put­er.

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 vil­lage.

Further Reference

Geek of the Week: Radia Perlman at the Internet Archive


Help Support Open Transcripts

If you found this useful or interesting, please consider supporting the project monthly at Patreon or once via Square Cash, or even just sharing the link. Thanks.