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


Malamud: This is Geek of the week. We’re talk­ing to Scott Bradner. He’s a con­sul­tant on the staff of Harvard University, he’s Area Director in the Internet Engineering Task Force for Operational Requirements, and has also been named in the spe­cial inter­im area look­ing at the ques­tion of the next-generation Internet Protocol. Welcome to Geek of the Week.

Scott O. Bradner: Well, I think I’m glad to be here.

Malamud: Well good. Everyone thinks they’re glad to be here at first. We hope they retain that hap­py impres­sion of this mem­o­rable experience. 

You are best known for your router eval­u­a­tion work that you do at Harvard? Can you describe what you do in this laboratory?

Bradner: Basically what I do is to cre­ate an arti­fi­cial net­work envi­ron­ment in which I abuse ven­dors’ prod­ucts and see whether they can suf­fer the abuse glad­ly, and come up with some kind of a con­sis­tent mea­sure­ment of per­for­mance in the areas of through­put and pack­et loss rate and laten­cy so that some­body might be able to com­pare dif­fer­ent prod­ucts using some­thing oth­er than the mar­keters’ own num­bers, which are…generally tend­ed to be a lit­tle bit on the sus­pect side.

Malamud: And so do you do this…do you break it down by pro­to­col? Do you exer­cise— Are you doing con­for­mance test­ing? Are you see­ing whether the BGP4 X oper­a­tion is being done?

Bradner: Conformance is a won­der­ful thing. Conformance is my read­ing of the specs ver­sus your read­ing of the specs. And see­ing as you’re the one with the lawyers and the mon­ey, I’m always going to lose. So in oth­er words I don’t do any­thing in the way of con­for­mance. Only do per­for­mance. And the per­for­mance is I do a wide vari­ety of tests, it’s about 190 tests now, on any par­tic­u­lar prod­uct. They range from a sin­gle stream of TCP/IP or AppleTalk or IPX or VINES IP or what­ev­er, to mix protocols…to mul­ti­ple streams up to twenty-four or thirty-six streams of par­al­lel data. FDDI. Gonna do some ATM test­ing next week. So it’s a wide vari­ety of things. Comes up with a tremen­dous amount of data, which I sus­pect some­body might be able to fig­ure out how to ana­lyze. I haven’t yet.

Malamud: So you don’t come up with a met­ric? This router is a 9, that router’s a 7.” 

Bradner: That is some­thing that many peo­ple have asked for, because it’s a lot eas­i­er on the mar­ket droids to be able to use just a num­ber say­ing Our router is bet­ter than theirs because it got a 3 and theirs got a 2.” And there was a great deal of dis­cus­sion in a group that I worked with, the Benchmarking Methodology Working Group of the IETF, on doing exact­ly that. We even came up with a name for the metric—we were gonna call em mill­stones.” [sp?] But we nev­er got a way to actu­al­ly do any­thing with it and to define it in a real­is­tic way. 

The prob­lem is that what you want is some­thing that’ll say how this router will work in your net­work. Well your net­work is dif­fer­ent than the guy next door’s net­work. You may have SNA and they don’t. You may have AppleTalk and they don’t. You may have a dif­fer­ent per­cent­age of this pro­to­col ver­sus that pro­to­col than they do. So there’s no con­sis­tent way. There were sug­ges­tions we could take a snap­shot of some aver­age net­work and try that out. But the aver­ages don’t work. There’s just too much vari­ety. So we have to come up with these dis­crete pieces of data, and you have to fig­ure out from pro­fil­ing your own net­work whether these pieces of data are useful.

Malamud: So you’re look­ing at through­put of dif­fer­ent pro­to­cols and dif­fer­ent pro­to­col mix­es. Are you look­ing at things like the dif­fer­ent rout­ing update pro­to­cols and how they perform?

Bradner: Well let me go back to your first point. I actu­al­ly take three dif­fer­ent mea­sure­ments. The first I call pack­et loss rate, and that’s the input offered load against the for­ward­ed traf­fic. So that if you send in 100 thou­sand pack­ets a sec­ond, how many pack­ets a sec­ond come out. And this is use­ful because you want to find out if indeed you over­load a device, is it going to dete­ri­o­rate. And there were some devices a few years ago…matter of fact there was one even last year—mostly on the token ring side for some rea­son or oth­er, where if you over­load them they dete­ri­o­rate cat­a­stroph­i­cal­ly. One par­tic­u­lar [indis­tinct] sent it half a mil­lion pack­ets at a rate of 14,000 pack­ets a sec­ond and it for­ward­ed thir­ty pack­ets. This isn’t a thir­ty pack­ets a sec­ond, it’s thir­ty packets. 

And it turns out what was hap­pen­ing is that it would for­ward pack­ets until it ran out of buffer space, that was about thir­ty pack­ets, then it would lose a pack­et, and it would rec­og­nize it lost a pack­et so it’d go off to account for that fact. And by the time it got back from account­ing for that fact, it lost anoth­er thou­sand pack­ets. And it would go off and account for that. And when it [record­ing gar­bled] from that, it’d lost anoth­er 10,000 packets.

Malamud: Seems like a sub-optimal strategy.

Bradner: It did not yield the cor­rect behav­ior I would expect, but it actu­al­ly might have been some­thing which would be ben­e­fi­cial in a net­work if you have an over­load con­di­tion where you’re get­ting a cat­a­stroph­ic over­load. This would have pro­tect­ed the rest of your net­work because it would’ve just died in its tracks. So maybe you could—maybe a mar­keter or two could turn this into a ben­e­fit. I would­n’t call it that.

That’s the first mea­sure­ment, this pack­et loss mea­sure­ment. And this is done for a vari­ety of pack­et sizes. It’s done for a vari­ety of pro­to­cols, and pro­to­col mixes. 

The sec­ond mea­sure­ment is some­thing called through­put. This is defined in an RFCall of these are defined in RFC 1242. The through­put is the max­i­mum rate at which all of the traf­fic offered to the device is for­ward. And this gives you an idea of the zero-loss or per­fec­tion rate of a router. This can be sig­nif­i­cant­ly dif­fer­ent than the rate which the ven­dor might tell you they can for­ward traf­fic. If you push pack­ets at a router or bridge as fast you can, and most of them don’t do the cat­a­stroph­ic dete­ri­o­ra­tion, so they will for­ward out pack­ets at some rate. But they’ll be los­ing let’s say 30% of the traf­fic you give them. 

If you put that into your net­work and that rate of which they’re start­ing to lose traf­fic is below the rate that you’re going to be offer­ing traf­fic, then you’re back­off algo­rithms and your pro­to­cols start tak­ing over and actu­al traf­fic flow dete­ri­o­rates significantly. 

Malamud: Are there exam­ples of machines in which the zero-loss rate is in fact the max­i­mum rate? Is there great vari­ance in the dif­fer­ence between those two?

Bradner: There are some where th zero-loss rate is very close to the max­i­mum for­ward­ing rate. I don’t know of any where it is actu­al­ly but it’s with­in a per­cent in some devices. Many devices fold over and then go at a pret­ty much flat…um, no mat­ter how much more you offer this is the rate that they for­ward out, which is with­in a few per­cent of the through­put rate. some of the through­put rate is sig­nif­i­cant­ly below the for­ward­ing rate. And that is because there are a num­ber of routers where inter­nal soft­ware gets into over­load con­di­tions or gets into soft­ware updates of some kind—whether it’s sink­ing the disk in a machine, a Unix-type router or some­thing like that, or updat­ing the clock on your man­age­ment con­sole. It los­es a few pack­ets. And some peo­ple might say that’s not very impor­tant. You lose 100 pack­ets out of 100,000. If it hap­pens to be your data stream that los­es those hun­dred pack­ets it can make a sig­nif­i­cant impact. 

The exam­ple of that is dur­ing the start­up phase of the T3 NSFNET, there were times when the net­work was los­ing about half a per­cent of its traf­fic. Which might seem to be quite small, but this was caus­ing user-level per­ceiv­able prob­lems such that cus­tomers in NEARnet, the head of the tech­ni­cal com­mit­tee for NEARnet, users in NEARnet were com­plain­ing that their user-level pro­grams were much slow­er. And this was only with a half-percent loss.

Malamud: Why is that? Is that because all the pack­et loss­es were with­in your net­work and the oth­er net­works were doing fine? 

Bradner: No, this was across the back­bone, and any traf­fic going across the back­bone. We’re cer­tain­ly not going to claim cred­it for los­ing pack­ets in NEARnet; that’s not our job. Packets going across the back­bone, traf­fic going across the back­bone was being lost, and there­fore when­ev­er you lose a pack­et it had to go back through trans­mis­sion and restart. And if you lost two pack­ets in the right sequence, it pushed the trans­fer rate even low­er because of the restart algorithms.

Malamud: So half a per­cent is no—even though we have TCP and retrans­mis­sion, a half a per­cent is enough that the user sees a difference.

Bradner: We were sur­prised. But we looked into it because of user com­plaints. So empir­i­cal evi­dence indi­cates that there’s a problem.

Malamud: So you invent­ed the zero-loss rate test.

Bradner: Well actu— I did­n’t invent­ed it, that’s actu­al­ly came from the work of the Benchmarking Methodology Working Group. A num­ber of peo­ple worked on that. I’m not sure who specif­i­cal­ly came up with that par­tic­u­lar mea­sure­ment but this was some­thing that was felt to be very important.

The third mea­sure­ment I take is laten­cy. I mea­sure laten­cy not because I think it’s a par­tic­u­lar­ly valid mea­sure­ment. Because I don’t. I mea­sure it because every­body in the world seems to want to know it. And—

Malamud: Latency being the amount of time a pack­et spends in a router.

Bradner: The length of time it takes for a router to process it. Yeah, the time it spends lying around in the buffers. In the gen­er­al envi­ron­ment of today’s inter­net­work­ing, routers do pro­cess­ing in the range of a cou­ple hun­dreds microsec­onds for a pack­et. So it’s not very much time. And in fact, it is much small­er than the time it takes to store and for­ward a pack­et if you did no pro­cess­ing what­so­ev­er, because it takes a while for the pack­et to trav­el over the wire. And in that con­text the actu­al laten­cy induced by the pro­cess­ing of a router tends to be a small per­cent­age of the laten­cy going across a network. 

Malamud: So the fact that we’re going through six­teen hops to go from one coast to the oth­er isn’t real­ly intro­duc­ing a significant…amount of latency.

Bradner: It is pro­duc­ing a sig­nif­i­cant amount of laten­cy but it’s not because of rout­ing pro­cess­ing time, it’s because at each one of those hops,you have to receive the whole pack­et before you can start send­ing it. So every time you have to do a full pack­et store-and-forward.

Malamud: So how long does the pack­et stay in a router? Gust give me an order of mag­ni­tude here.

Bradner: It’s in the range of below sixty-four microsec­onds to about 400 microsec­onds in the…that’s the more—modern routers are in that range. Now, that’s quite small. 

And anoth­er fac­tor on laten­cy is that for most pro­to­cols, par­tic­u­lar pro­to­cols with win­dow­ing like TCP/IP, it has very lit­tle effect on user-perceivable behav­ior. Because it’s a win­dowed pro­to­col that has more than one pack­et out­stand­ing on the net­work at any one time, it does­n’t care if the net­work is a lit­tle pseudo-longer because there’s longer laten­cy some­place in the middle. 

On pro­to­cols like old IPX where you had to receive an acknowl­edge­ment for every piece of data sent, then the laten­cy could be very impor­tant. And get­ting devices with very low laten­cies, or even cut-through devices where the pack­et is start­ed to be for­ward­ed before it is ful­ly received, could make a sig­nif­i­cant impact on the per­for­mance. Lotus 123 loads a lot faster with a cut-through device.


Malamud: Scott Bradner, we’ve been look­ing at routers and the per­for­mance test­ing work that you do at Harvard University. Many routers have a few routes in their rout­ing tables. They know about a few inter­nal net­works and they send every­thing out to their ser­vice provider. But there’s maybe thir­ty, fifty, a hun­dred routers in the world that need to know about…the whole world. And those routers, for them the size of the rout­ing table begins to make a dif­fer­ence. Does the size of the rout­ing table affect the per­for­mance of a router?

Bradner: That I’m not sure. Mostly because it’s very dif­fi­cult to sim­u­late the envi­ron­ment which those rotors reside in. It’s a lot­ta typ­ing to put in on all of those routes into a sim­u­la­tion set­up. I did run a test on a ven­dor’s router just recent­ly, but it was for the abil­i­ty to sup­port a large rout­ing table rather than per­for­mance when that rout­ing table was in place. It is some­thing that I’ve thought about doing and in the past have not done because the dif­fi­cul­ty in main­tain­ing the rout­ing table—you have to send in updates on a peri­od­ic basis—and just pro­cess­ing those updates can have a poten­tial­ly sig­nif­i­cant impact on the per­for­mance even if you’re not mak­ing any changes in the rout­ing table just repeat­ing it every X peri­od of time. Though with some of the mod­ern pro­to­cols like BGP you don’t have to con­tin­u­al­ly update it. But it’s some­thing I do hope to do in the future.

I am look­ing at ways to find out the effect of pro­duc­ing rout­ing updates on per­for­mance. If indeed you’re for­ward­ing traf­fic at some rate and then sud­den­ly get a RIP update or an OSPF update and that caus­es some per­mu­ta­tion in the rout­ing table, what effect does that have on the for­ward­ing rate.

Malamud: That’s actu­al­ly a sig­nif­i­cant effect we’ve noticed on the mul­ti­cast back­bone on occa­sion, in which your audio and video was going along just fine, and every nine­ty sec­onds an update occurs and you find a lit­tle bit of your data goes away. How does one test for these types of envi­ron­ments, and how do you fix them? Is it a tun­ing prob­lem? Is it a prob­lem in the ini­tial con­fig­u­ra­tion of the router, the design of the router?

Bradner: It’s not gen­er­al­ly the design of the router because the router is just tran­sis­tors, or now inte­grat­ed cir­cuits and plugs. It’s…the rout­ing pro­to­cols have an effect there. There’s always been a…certainly an inter­est­ing ques­tion about what the effect of a minor” rout­ing update change to a large OSPF net­work which caus­es the entire fab­ric of the net­work to realign, the time it takes to run the algo­rithms on that—the Dijkstra algorithms—on the rout­ing table and what that impact would be on for­ward­ing. This is some­thing that a lot of peo­ple would like to look at, and so far it’s been some­thing that I’ve most most­ly wished to do rather than do. Because it is dif­fi­cult to set up the envi­ron­ment. Something I do plan to do in the future, though.


Malamud: One of the big issues in router design is the size of the rout­ing tables. And we’re cur­rent­ly look­ing at routers in the leafs that are maybe 16 megabytes of mem­o­ry, and in the core of the net­work that’s even 64 megabytes of mem­o­ry. Are we going to be able to stop the growth of the rout­ing table, or does that even mat­ter? Are we just gonna get more and more mem­o­ry like we do on our computers?

Bradner: Well cer­tain­ly some peo­ple think that mem­o­ry is cheap and you can just keep grow­ing that way but it has been point­ed out that the size of mem­o­ry dou­bles every three years and the rout­ing table has been dou­bling every two years, so as a long-term strat­e­gy that prob­a­bly does­n’t work. 

The answer is as CIDR is deployed in the back­bone, which is the route aggre­ga­tion process, this growth should change sig­nif­i­cant­ly. There’s been very recent work in the CIDR deploy­ment that looks extreme­ly promis­ing. The last major pieces have fall­en into place and route aggre­ga­tion is going to start. And there is no rea­son to expect that we’re going to be faced with the kind of cri­sis which is going to require major ren­o­va­tion of the back­bone routers, as long as we can start mak­ing real progress in get­ting the exist­ing route table aggre­gat­ed. That reduces both the absolute size of the exist­ing table and sig­nif­i­cant­ly reduces the growth of the rout­ing table space.

Malamud: How does CIDR do that? Maybe you can give us a brief expla­na­tion of CIDR and why it’s going to change our rout­ing tables.

Bradner: The sim­plest way to put it is that in pre-CIDR days, if you had let’s say 512 Class C net­works and you want­ed peo­ple to know where you were, you had to adver­tise 512 Class C net­works, which would cost 512 entries in the rout­ing table. With CIDR this is adver­tised in a way which allows a sin­gle entry to be put in the rout­ing table rather than the 512, there­by reduc­ing the size of the adver­tise­ment con­sid­er­ably. And in addi­tion to that, since you would have received, obtained, your address­ing from your net­work provider, and they would have pro­vid­ed it out of a block of address­es that they had obtained from the IANA, then all or at least all of the routes from this provider that were CIDR-capable could be the­o­ret­i­cal­ly col­lapsed into a sin­gle rout­ing table entry. 

Malamud: So instead of hand­ing out address­es ran­dom­ly, we’re dol­ing em out by the struc­ture of the net­work, essentially. 

Bradner: Well we’re dol­ing them out two ways. One is by the struc­ture of the net­work, so that providers get large clumps of address­es to hand out. And sec­ond of all those are being hand­ed out in a log­i­cal fash­ion which allows the seg­re­ga­tion. Basically they’re being hand­ed out and pow­ers of two. Powers of two Class C net­works. Because that way you can aggre­gate them and just make them look like one entry. CIDR stands for class­less inter-domain rout­ing, and the whole point is that you’re no longer treat­ed as Class A, Class B, Class C, you’re just treat­ed as effec­tive­ly a bit mask over the address space.

Malamud: So there’s two issues. One is how we hand out address­es. The sec­ond is tak­ing advan­tage of that in the rout­ing announcements.

Bradner: That’s correct.

Malamud: And where’s that imple­ment­ed? Is CIDR a pro­to­col, or do we see that come in some­place else?

Bradner: The first of those two is how we hand out address­es. And the process of hand­ing out address­es by the Internet providers has been using CIDR log­ic for the last year or two. So we have a lot of already-assigned address­es, a lot of the growth—recent growth—in the Internet has been along the lines that are CIDR-capable. 

CIDR itself is imple­ment­ed in the Exterior Gateway Protocol, a pro­to­col that’s used to exchange rout­ing infor­ma­tion between region­al net­works and the back­bone, or between autonomous sys­tems, in par­tic­u­lar it’s BGP4—Border Gateway Protocol num­ber 4 or revi­sion 4. This is used in the back­bone from the NSFNET to talk to oth­er region­al net­works. Or…NSFNET’s not a region­al net­work… Well actu­al­ly, maybe it is in the glob­al sense. But in any case, it’s the inter­change of the sum­ma­tion rout­ing infor­ma­tion between providers, whether they be NSFNET or AlterNet, or NEARnet, or the European net­works, they exchange infor­ma­tion with BGP4 and that allows them to make use of the CIDR aggre­ga­tion possibilities. 


Malamud: Scott Bradner, we’ve been talk­ing a lot about the engi­neer­ing of a glob­al Internet, and rout­ing pro­to­cols, and how do we make IP traf­fic flow effi­cient­ly from one place to anoth­er. Yet most of the nodes in the world don’t run IP, they run IPX from Novell, or they run DECnet, or they run a vari­ety of pro­to­cols. How are we going to sup­port all these node out there? Will the Novell peo­ple have to shift over to IP? Will we shift over to IPS? Or will they both some­how coexist?

Bradner: Well it depends what you mean by sup­port. If you mean by sup­port that I can sit at my desk run­ning a Macintosh run­ning Unix run­ning send­mail, and send email to the per­son two cubi­cles down that hap­pens to be on a PC run­ning on Novell…we sup­port that now. We do that through gate­ways. We can do that through application-specific gate­way. Email is cer­tain­ly the most com­mon one, there’s poten­tial for oth­er types of application-specific gate­ways. This is how you get to BITNET, IBM mainframe-specific kind of net­works, or AppleTalk-based net­works, or Novell.

So if you mean sup­port by the abil­i­ty to com­mu­ni­cate, par­tic­u­lar­ly in a non-real-time fash­ion, we do that through func­tion­al gate­ways. And we’ll con­tin­ue to do that through func­tion­al gate­ways. Not only because the under­ly­ing archi­tec­ture is dif­fer­ent, the pro­to­cols are dif­fer­ent, but because some peo­ple believe this is a good way to intro­duce secu­ri­ty, or addi­tion­al secu­ri­ty…some secu­ri­ty, into the Internet struc­ture. Because by putting in an appli­ca­tion gate­way of this sort, you only pass the kind of func­tion that you wish to allow, and keep­ing out the kind of func­tion you don’t, ie. the peo­ple that are try­ing to peer around and find your fam­i­ly jew­els. So, we’re gonna sup­port that kind of thing that way.

There is an addi­tion­al ques­tion, though, of if you want to sup­port the kind of thing which does­n’t go through an appli­ca­tion gate­way ter­ri­bly well, or whose func­tion is not sup­port­ed on the under­ly­ing protocol—running Mosaic over IPX, for example—you could do it by build­ing a ver­sion of Mosaic that ran over IPX that went through a gate­way. You could do by fig­ur­ing out a way to encap­su­late TCP/IP over IPX and put that through a gate­way and strip off the TCP. And that’s what’s done in the AppleTalk gate­ways to Ethernet, for exam­ple. When you run TCP/IP on a Mac, it encap­su­lates at least one form of that, encap­su­lates the IP in AppleTalk pack­ets, and then they get stripped out and turned into reg­u­lar IP in the gate­way. We could do it that way. Or we could migrate the nodes to a com­mon infra­struc­ture, to a com­mon pro­to­col infra­struc­ture. And the IPng effort in the IETF is try­ing to—

Malamud: IPng is IP Next Generation.

Bradner: Yes. IP Next Generation. This was done at a time when cer­tain new sci­ence fic­tion shows were show­ing up on the TV, and it con­scious­ly cho­sen in this way; the title was. 

We’re try­ing to con­scious­ly take into account the var­i­ous ways that you could grow and what the require­ments are on a more glob­al data net­work­ing inter­con­nect phase require­ment. Instead of look­ing at the Internet sim­ply as this col­lec­tion of TCP/IP LANs, look­ing at the Internet as the future data net­work­ing needs of the globe, not lim­it­ed to any one pro­to­col. But that does­n’t mean that the IPng area or its Area Directors are ego­tis­ti­cal enough to believe that we’re going to fig­ure out a way to con­vert every IBM main­frame and every PC in the world to a sin­gle pro­to­col, because that’s not going to hap­pen real soon now. But we want to take into account those require­ments so that in case, and in places where it is fea­si­ble to migrate the end sys­tems to a com­mon under­lay­ment in order to pro­vide a com­mon set of ser­vices, that can be done. The address­ing will be suf­fi­cient to do it, the rout­ing sta­bil­i­ty will be suf­fi­cient, the scal­a­bil­i­ty was suf­fi­cient. And the secu­ri­ty will be sufficient. 

Those are all things that we’re try­ing to take into con­sid­er­a­tion. We put out a call for whitepa­pers using RFC 1550, and we received a num­ber of them from a wide range of orga­ni­za­tions and indi­vid­u­als around the world telling us what they believe the require­ments are in this area in order to be able to sup­port this sort of thing.

Malamud: Now, you’re assum­ing a sin­gle glob­al Internet. And for a while there the trade press got on a lit­tle kick which said that Novell is gonna invent its own Internet, and our Internet will go away or will have to some­how com­pete with their Internet. Is Internet a net­work, or is it some­thing more fundamental?

Bradner: Well that’s why I very care­ful­ly phrased it as that we’re look­ing at the Internet as the data net­work­ing needs of the globe, rather than tying it specif­i­cal­ly to any par­tic­u­lar pro­to­col. There is…whether this par­tic­u­lar IPng Area Director believes that a large IPX Internet will grow up and be a viable com­mer­cial enter­prise or not…and there’s cer­tain­ly some pres­sure for some things like that…and run that in par­al­lel with an IP Internet or an IPng Internet, that does not change the pic­ture that you still would need to coop­er­ate between them. 

Malamud: You still have to interconnect.

Bradner: You still have to inter­con­nect. You’re not going to get either side—if sides be the right term in this kind of con­ver­sa­tion. You’re just not going to get either side to admit that the oth­er has won to the extent that they’re going to con­vert all their box­es, not nec­es­sar­i­ly because they don’t think that the oth­er side has won, but some of those box­es will nev­er be con­vert­ed sim­ply because no one knows how to run them any­more. And they’ve just been run­ning because some grad­u­ate stu­dent set it up three years ago and went off into the out­er dark and who­ev­er has it does­n’t know them any­more. So there’s some envi­ron­ments that sim­ply will nev­er change.

Malamud: So we’re nev­er gonna have a sin­gle inter­net­work protocol.

Bradner: We do not have a sin­gle Internet pro­to­col now,—

Malamud: And we’re nev­er gonna con­verge on one.

Bradner: And we can’t con­ver­gent one by def­i­n­i­tion, actu­al­ly. The IPng effort is defin­ing yet anoth­er Internet pro­to­col. It cer­tain­ly is hoped that we define one that every­thing could use. But, there will be IP ver­sion 4, the exist­ing gen­er­a­tion of IP, for many many years now, in real ways and for the forsee­able future. We have a great deal of iner­tia in the knowl­edge base of the mar­ket as to what they can oper­ate what they can do. We have anoth­er prob­lem, though, is let’s say you were a ven­dor and you were going to come up with some soft­ware that ran on a serv­er. And you’ll get the option of imple­ment­ing this serv­er in IPng where there are…a hun­dred thou­sand hosts. Let’s say this is a cou­ple years down the road. Or you could imple­ment it with IPv4, where there are…20 mil­lion hosts. 

Malamud: Gee. Bigger mar­ket, small­er mar­ket. Which should we pick? [both chuck­le]

Bradner: So, there’s not only an iner­tia in terms of the install base that’s there but that’s in devel­op­ment. There’s an iner­tia in devel­op­ment that will tend to go along the same lines. Now, some of the IPng pro­pos­als have ways to mit­i­gate this by using method­olo­gies by which you could build a serv­er that could deal with both types of clients—IPv4 clients and IPng clients. That won’t nec­es­sar­i­ly make the IPv4 clients go away. But it would mit­i­gate the prob­lem of providers pro­vid­ing only IPv4 services.

Malamud: So we should be pre­pared for a messy world.

Bradner: We’re in a messy world now.

Malamud: Well there you have it. This has been Geek of the Week. We’ve been talk­ing to Scott Bradner. Thanks a lot.


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

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

Executive 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.


Help Support Open Transcripts

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