Carl Malamud: Internet Talk Radio, town crier to the glob­al village. 

We’re talk­ing with Steve Deering, who’s a mem­ber of the research staff at Xerox’s Palo Alto Research Center. Xerox PARC of course is the foun­tain­head where it all began, and there’s work still going on. Steve, wel­come to Geek of the Week.

Steve Deering: Thank you.

Malamud: You’re the author of mul­ti­cas­ting­ing IP. Now I know we can do mul­ti­cas­t­ing on Ethernets, and we send a pack­et out and sev­er­al dif­fer­ent nodes can receive that at once. Why do we want mul­ti­cas­t­ing at the IP level?

Deering: Well, there are two that mul­ti­cas­t­ing at the IP lev­el does for us. One is the obvi­ous one, that if what you have to do is send the same data to more than one machine, one des­ti­na­tion, it’s more effi­cient for the net­work, and for the sender, to send only one copy and have the net­work repli­cate it where nec­es­sary. You also achieve par­al­lel, con­cur­rent deliv­ery that way so it reduces the over­all delay of delivery. 

The sec­ond rea­son why mul­ti­cast is use­ful is it’s a way to send mes­sages to des­ti­na­tions whose indi­vid­ual address you don’t know. So for things like adver­tis­ing ser­vices, or seek­ing out ser­vices, var­i­ous auto­con­fig­u­ra­tion or resource dis­cov­ery prob­lems, it’s one way to deal with that.

Malamud: Is mul­ti­cas­t­ing actu­al­ly being deployed in the Internet?

Deering: [laughs]

Malamud: I know you’re work­ing on it a long time. Are we start­ing to see this become a real service?

Deering: It’s maybe a lit­tle pre­ma­ture to call it a real ser­vice. It’s out there in exper­i­men­tal mode at the moment. There is the MBone, which is a vir­tu­al IP mul­ti­cast net­work laid on top of the Internet which is reach­ing about…I don’t know, a cou­ple hun­dred IP net­works. I don’t know how many sites that rep­re­sents because some sites have more than one net­work. But it’s still pret­ty much an exper­i­men­tal facil­i­ty. Various ser­vice providers are par­tic­i­pat­ing in the MBone, learn­ing more about it and find­ing out what that dan­gers of offer­ing such a ser­vice is.

Malamud: You call it a vir­tu­al IP net­work. Is this not an inte­gral part of the Internet itself? This is not just an enhanced ver­sion of the Internet Protocol?

Deering: It is. It is an offi­cial Internet stan­dard exten­sion to IP. The prob­lem is we don’t have the IP mul­ti­cast rout­ing sup­port installed in the exist­ing routers and we have to tran­si­tion or phase it in some­how. And so what we’re doing is we have islands of IP mul­ti­cast capa­bil­i­ty, rout­ing capa­bil­i­ty, and then we join them up by tun­nels. A tun­nel encap­su­lat­ing a mul­ti­cast pack­et inside of a uni­cast to sneak it by routers that don’t under­stand mul­ti­cast, and then deen­cap­su­lat­ing it when you get to the next island and then rout­ing it onwards. And it’s this inter­con­nec­tion of islands that I’m call­ing a vir­tu­al Internet. The goal is that in fact the vir­tu­al becomes one-to-one with the phys­i­cal work, and that capa­bil­i­ty get down into the routers. Because the tun­nel­ing mech­a­nism is very inef­fi­cient. We end up send­ing mul­ti­ple copies of the same pack­et over the same link, which is what mul­ti­cast is try­ing to avoid.

Malamud: Why are you send­ing mul­ti­ple copies over the same link?

Deering: Well, if for exam­ple my machine here at Xerox PARC has— And my mul­ti­cast routers here has two peers, one in Barnet and one maybe at NASA, because the routers between here and those two des­ti­na­tions do not sup­port mul­ti­cast, I have to encap­su­late and send an indi­vid­ual uni­cast copy to each of those des­ti­na­tions. And there only one wire that goes out of here, the T1 link from here to Barnet. So there are two copies with iden­ti­cal con­tents but dif­fer­ent des­ti­na­tion addresses.

Malamud: Now the MBone is a glob­al mul­ti­cast group. Do you think mul­ti­cas­t­ing will in fact be used for glob­al com­mu­ni­ca­tions, or is mul­ti­cas­t­ing going to usu­al­ly be used with­in a local envi­ron­ment? Do you have any feel for that yet?

Deering: Both.

Malamud: Both.

Deering: Both. And the sort of most obvi­ous appli­ca­tions are con­fer­enc­ing, which the use of it for more con­fer­enc­ing, its val­ue is increas­ing the fur­ther away the par­tic­i­pants are. If we have to have a con­fer­ence between some­one in Australia, some­one in Sweden, and some­one in California, then the val­ue of that is greater than if it’s a meet­ing between three oth­er peo­ple in the Bay Area or three peo­ple here at Xerox.

Malamud: You’ve been test­ing a lot of this out on the MBone with some­thing called IETF TV, broad­cast­ing, mul­ti­cas­t­ing, the IETF ses­sions. Can you tell us a lit­tle bit about that? Is this a good way to test the ser­vice out? Is it an oper­a­tional thing? Should we expect all IETFs to be the mul­ti­cast in the future?

Deering: Well. Um…

Malamud: Do you have [crosstalk] oth­er work to do?

Deering: That’s my hope. The idea to do this came out of the chal­lenge that I don’t remem­ber who it was that said. But some­body said that we ought to be able to start using our Internet to facil­i­tate par­tic­i­pa­tion in IETF meet­ings. And so we thought there’s at least the poten­tial there to start exper­i­ment­ing with the ideas of hav­ing remote par­tic­i­pa­tion in IETF meet­ings. We had some tools mul­ti­cast infra­struc­ture, or the soft­ware to build a mul­ti­cast infra­struc­ture. And new audio tools, the vat pro­gram from Van Jacobson. At the sec­ond IETF we did this. We had a a video pro­gram from BBN. And the third time we had a cou­ple video pro­grams from—one from PARC and one from Inria in France. And…

Malamud: Well, you… I hear video con­fer­enc­ing as an appli­ca­tion that goes on the MBone. Are there oth­er appli­ca­tions that you see mul­ti­cas­t­ing being used for now, or com­ing soon down the pike besides the video conferencing?

Deering: I keep hop­ing. There’s actu­al­ly an inter­est­ing— Someone post­ed a mes­sage to the MBone list say­ing that next month they’re going to be doing some oceanog­ra­phy exper­i­ments in…I think it was the Gulf of Mexico, where they have under­wa­ter robots. And they want to trans­mit the data that these robots are col­lect­ing in real time as mul­ti­cast so that mul­ti­ple receiv­ing sites can be track­ing the data, and in the fact this may include video of the under­sea cam­era. So for sort of dis­sem­i­na­tion of sci­en­tif­ic data that’s being col­lect­ed real time, that’s an obvi­ous application. 

I men­tioned resource loca­tion mech­a­nisms, although that may turn out to be one of the appli­ca­tions that tends to be more local­ized than glob­al. I don’t think you’re going to do mul­ti­cast search­es glob­al­ly to find resources.

Malamud: The MBone, you described it as a vir­tu­al IP net­work, and in this case it’s being used to do mul­ti­cas­t­ing. That that’s a form of an enhanced IP. Can the Mbone be used for oth­er types of exper­i­ments besides just multicasting?

Deering: Oh sure. This whole idea of build­ing a vir­tu­al net­work on top of the Internet is a… Well, there are analogs in the way for exam­ple peo­ple run IPX Novell net­works across the Internet, where they tun­nel through IP. That’s build­ing a vir­tu­al IPX net­work. The mech­a­nism by which we’re going to be able to deploy a new ver­sion of IP I expect is going to look very much like the MBone, where again we’re gonna have islands of new capa­bil­i­ty, and you have to get to the exist­ing infra­struc­ture and you’re going to do this kind of tun­nel­ing mech­a­nism. So for exam­ple we’re plan­ning with the SIP work to exploit the MBone or some­thing very much like the MBone as a way to get large-scale expe­ri­ence test­ing with SIP and as a way of demon­strat­ing that you can in fact tran­si­tion to it.

Malamud: You talked about SIP, the Simple IP? is what SIP stands for? 

Deering: It’s one of the things it stands for.

Malamud: One of the things it stands for. It’s an acronym with many reverse engi­neer­ings. SIP is an attempt to solve the prob­lems that were orig­i­nal­ly posed by the rout­ing and address­ing task force of rout­ing table explo­sion and address space exhaus­tion. Are you try­ing to solve oth­er prob­lems at the same time when you’re design­ing this new IP?

Deering: Uh, well. Yes, in that— In that it’s the address­ing and rout­ing prob­lems that moti­vate think­ing about installing a new IP. But if you’re actu­al­ly going to go to the effort of installing a new IP, the temp­ta­tion is irre­sistible to try to do oth­er things as well. And cer­tain­ly there are many aspects of the cur­rent IP pro­to­col suite that could use some improvement.

Malamud: What are some of the more impor­tant ones that you think need to be in the next version?

Deering: Autoconfiguration of some sort is very impor­tant as the Internet ser­vice becomes more ubiq­ui­tous and more lay per­sons become involved in run­ning IP sys­tems. Making it a lot eas­i­er to install IP sys­tems and use them is very portant. 

We’re try­ing— I don’t know how suc­cess­ful we’re going to be, but we’re try­ing to define the secu­ri­ty pro­to­cols along with SIP such that we might actu­al­ly have secu­ri­ty in there right from the begin­ning. That’s obvi­ous­ly a big hole in IP and why I think one of the inhibitors to the growth of IP is the lack of strong security.

Malamud: So what does that mean? Does that mean encrypt­ing the data inside the IP pack­et? Does it mean putting some kind of authen­ti­ca­tion mech­a­nism in…

Deering: It means at a min­i­mum authen­ti­cat­ing. So, I guess what they refer to as um… Well it’s authen­ti­ca­tion and…

Malamud: Authorization?

Deering: No. Where you can detect if it’s been tam­pered with. Tampered either acci­den­tal­ly or maliciously.

Malamud: So mes­sage integrity.

Deering: Integrity, that’s the word. Thank you. 

It’s not— I mean, clear­ly encryp­tion gets you into all sorts of polit­i­cal mine­fields hav­ing to do with export con­trols and so on. And there’s a lot of traf­fic on the Internet. There’s no par­tic­u­lar­ly strong rea­son to encrypt it. And the basis of our sort of pro­pos­al for what to do with SIP is based on the SP3—Security Protocol Level 3—work done by NIST and I think it’s since been tak­en into the ISO world as NLSP, the Network Layer Security Protocol, which is a way of encap­su­lat­ing the pay­load part of an IP or an Internet data­gram and apply­ing either integri­ty checks to it or integri­ty plus encryption.

Malamud: So SIP is ISO-compliant.

Deering: [laughs] Um…at an abstract lev­el, sure. I hope they’ll adopt it.

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

[Incidental Tourist seg­ment omitted]

Internet talk radio, asyn­chro­nous times demand asyn­chro­nous radio. 

You’re look­ing a lot of enhance­ments in SIP. Some fair­ly rad­i­cal changes in what the IP pack­ets look like. How do you think we’re going to be mak­ing that tran­si­tion? Is there a strat­e­gy that you’ve come up with that will make a tran­si­tion from IP to SIP?

Deering: Certainly. It usu­al­ly under the rubric of IPAE, this is IP Address Encapsulation, which is kind of a clum­sy name and not quite an accu­rate name. But this is work pri­mar­i­ly attrib­ut­able to Bob Hinden and Dave Crocker, who designed it—who basi­cal­ly spec­i­fied a scheme, before SIP was invent­ed, to tunnel…to intro­duce larg­er address­es and then to be able to send pack­ets that car­ry those larg­er address­es through the exist­ing infra­struc­ture by encap­su­la­tion and tunneling. 

And as I was talk­ing about before with the MBone, this allows the piece­meal and grad­ual intro­duc­tion of of machines that under­stand the big­ger address­es into the exist­ing Internet. The scheme they had come up with in fact did not ever get away from doing that encap­su­la­tion. They sort of thought that they would build this and you would now have…packets would always car­ry this IP head­er around some head­er that car­ries big­ger address­es. But Bob Gilligan of that group—of the IPAE group—recognized that the head­er they had that was car­ry­ing the big address­es looked very much like to the SIP head­er. And geez, if only only they’d used SIP, then you could think of tran­si­tion­ing to a clean final state where in fact you weren’t doing encap­su­la­tion any­more and you were back to a straight, sim­ple head­er with big­ger address­es in it rid­ing direct­ly on top at a link lev­el. So that’s a very impor­tant part of the SIP work, is try­ing to make it so that it’s a fair­ly easy tran­si­tion path.

Malamud: Is there ever a flag day? Is there ever a day when every­body has to be doing some­thing else?

Deering: No. No. Absolutely not. And that’s… The updat­ing kin­da— The intro­duc­tion of the new capa­bil­i­ties can hap­pen in any order you can update. Just bound­ary routers first and imme­di­ate­ly get some ben­e­fit with the wide-area scal­ing of rout­ing. You can update hosts with­out any routers being updat­ed. They just tun­nel through the exist­ing part. You can update inte­ri­or routers with­in a domain but not the hosts, or you can do a whole domain. Pretty much in any order, and dif­fer­ent parts of the Internet can do things in dif­fer­ent orders. The only real flag day in any of us, and that applies to any of the the new IP can­di­dates, is the day the IP net­work num­ber space runs out.

Malamud: In oth­er words once they become non-unique, [crosstalk] or you can’t assign another.

Deering: Right. Right. And by the time you get to that stage, you have to have all of the machines that you wish to con­tin­ue to com­mu­ni­cate glob­al­ly, have to be upgrad­ed to the new machine.

Malamud: But a local thing, for exam­ple a print­er that would nev­er be acces­si­ble from the out­side world could countin­ue to use a plain old IP address forever?

Deering: Yes. Yes. And SIP— As part of tran­si­tion mech­a­nisms there’s a com­bi­na­tion of mech­a­nisms some­times involv­ing encap­su­la­tion and some­times trans­la­tion. The trans­la­tion allows a SIP-only host, a pure SIP host, to talk to an IP-only host. So that it’s not nec­es­sary to car­ry around the bag­gage of IP for­ev­er to be able to talk to this old print­er. And you could imag­ine peo­ple bring out SIP light switch­es, where the over­head of doing both SIP and IP in the light switch would be too high but SIP would be okay.

Malamud: And you nev­er know with light switch advances.

Deering: Yeah, yeah. I don’t know if we’ll have light switch­es with giga­bytes of memory.

Malamud: You’ve been look­ing at the very con­tentious issue of address­es. Obviously an IP pack­et is much more than just the address. But the thing that prompt­ed a lot of this is the address space run­ning out. How long do you think we have until that 32-bit IP spaces is gone? Do you have any idea?

Deering: Haven’t a clue.

Malamud: Do you think it’s a year, ten years…

Deering: Uh, more than a year, less than ten years. But uh…I don’t think anyone…knows.

Malamud: Is it urgent enough that we need to come up with a solu­tion right away, or can we sit back and wait and see what the best solu­tion is?

Deering: There is some urgency, but I don’t think it’s…you know, that we have to have some— You know. We’re not gonna run out at the end of this year. And there are— The way that address­es are being hand­ed out now, some of the pro­ce­dure has improved. The CIDR approach, where blocks of con­tigu­ous Class C address­es are being hand­ed out in a chunk. That’s all good work. If in fact that does­n’t buy us enough time, there are oth­er things we could do such as…causing cer­tain parts of the Internet to renum­ber. And you know, if peo­ple think that caus­ing renum­ber­ing is some­thing that’s impos­si­ble to do I don’t know how we’re ever gonna get them to install a new IP.

Malamud: How hard is it to renum­ber? I know in my home net­work of six nodes if I had to renum­ber I’d do it. Is that real­ly such a big deal to just say every­body’s got­ta change?

Deering: Oh yeah it’s a pret­ty big deal either at a place like this or on a uni­ver­si­ty cam­pus. I think of all the place where IP address­es are embed­ded in hosts and hosts are embed­ded in clos­ets and places you don’t know and… It’s pret­ty painful.And that’s sort of one aspect that we’d like to do bet­ter the next time around.

Malamud: And so renum­ber­ing is real­ly some­thing that you’d like to avoid.

Deering: But I say it still strikes me as… Well, maybe there is a way in which renum­ber­ing is worse than upgrad­ing your soft­ware, because renum­ber­ing does pret­ty much— Well, depend­ing on how you do it, could indicate—could require a flag day, where­as upgrad­ing the soft­ware as I said could be done piecemeal.

Malamud: As to how we build address­es, you’ve advo­cat­ed a scheme based on metro areas. Basically on cities, if you will. Could you explain that way of assign­ing addresses?

Deering: Okay. The moti­va­tion for it has there were exist­ing pro­pos­als… And I first came to this prob­lem in the con­text of [“n‑taps”?], sort of for how to assign [“n‑taps”?] which indi­cat­ed that a site or a sub­scriber to the CLNP Internet would obtain an address pre­fix from a local ser­vice provider. And then all of the clients of that ser­vice provider would have the same pre­fix. You could aggre­gate all those sites into one route adver­tise­ment that went between providers.

Malamud: So that’s provider-based address assignment.

Deering: Right. So, all the cus­tomers of Barnet would be iden­ti­fied by a unique pre­fix which iden­ti­fied them as Barnet, and the rest the world would­n’t have to keep a sin­gle indi­vid­ual route to Xerox, they would keep a route to Barnet. And that’s a swell scheme, the only draw­back is that if Xerox decides it wants to switch its ser­vice from Barnet to some oth­er provider…we have to change all our address­es. And I just talked about how painful it can be to renumber.

Malamud: What if you want ser­vice from both?

Deering: Well, the provider-based scheme requires you to have an address for both, and so your your inter­nal hosts become mul­ti­homed, or at least they have mul­ti­ple IP addresses.

Malamud: And every­one of your inter­nal hosts has to be multihomed.

Deering: Every one that you wish to be acces­si­ble by all of the providers you’re attached to. Now the way they’re… Okay, so the moti­va­tion for doing this was— The whole issue, all these pro­pos­als for intro­duc­ing big­ger address­es into IP is cur­rent­ly we have an address space where we give every indi­vid­ual site and sub­scriber their own net­work num­ber and that’s just a big flat space of net­work num­bers. And that’s where the scal­ing prob­lem is, because we can no longer afford to adver­tise all those glob­al­ly. And the way we know how to deal with them is to aggre­gate them into larg­er clus­ters. And aggre­gat­ing them into all of the clients of a sin­gle provider is one way of clustering. 

And so I thought well is anoth­er way of clus­ter­ing that would not require this…would not lock you in your cur­rent provider, would not make you pay the penal­ty of hav­ing to change all your address­es if you switched to anoth­er provider. And I start­ed think­ing about it main­ly in the con­text of the tele­phone sys­tem. Because the tele­phone sys­tem, sort of at one lev­el looked like it’s doing geo­graph­i­cal address­ing. The 415 area code is the San Francisco penin­su­la. But you can’t real­ly tell if that’s a provider-based address or a geo­graph­i­cal address because there’s only one ser­vice provider in the 415 area code, that’s Pacific Bell. And what would hap­pen if a sec­ond prov— You know, if we’re actu­al­ly to sup­port com­pe­ti­tion for local phone ser­vice, not just long-distance phone ser­vice but local phone ser­vice, what would have to hap­pen? Certainly if I had to change my phone num­ber when I switched to the com­peti­tor of Pacific Bell that would be a real dis­in­cen­tive for me to switch. With the cur­rent sor­ta lev­el of tech­nol­o­gy, you know, disks and mem­o­ry and so on being cheap, it would­n’t be that hard to have a sin­gle data­base of all 10 mil­lion phone num­bers in the 415 area code which was a map­ping from the phone num­ber to who the provider is. And per­haps to that provider’s local indis­tinct so I could keep my phone num­ber when I changed. It would mean updat­ing a data­base. It’s a data­base that all of the providers, the com­pet­ing providers, would update and have to share access to.

And that had a clear ana­log in the Internet prob­lem, which is if instead of iden­ti­fy­ing Xerox as a cus­tomer of Barnet, we iden­ti­fy Xerox as one of the Internet sites in the San Francisco Bay Area, then that will also give an aggre­ga­tion of all the cus­tomers in the San Francisco Bay Area; Xerox no longer has to be adver­tised as a sin­gle indi­vid­ual glob­al­ly, just San Francisco Bay Area has to. And so I would have an address which was of the form prob­a­bly what coun­try I was in. Then what met­ro­pol­i­tan area, which is sort of what major cen­ter of com­merce, radi­at­ing out till it reach­es the next cen­ter of com­merce. Then a site ID of some sort with­in that met­ro­pol­i­tan area. And then low-order bits by which I’d do address­ing and num­ber­ing of my sub­net’s hosts internally.

Malamud: So is that assign­ing address­es based on the topog­ra­phy of the Internet?

Deering: Topography? Um…

Malamud: Topology?

Deering: Yeah. What— This is a good ques­tion because…subjects of lots of debate of whether… The require­ment— The bal­ance— Okay, so the good side of metro-based address­ing is that you don’t change your address when you change providers in the same city. There still are cert— If you move to a dif­fer­ent city you have to change you address­es. But sort of…the pre­dic­tion, what I’m pre­dict­ing is that we hope we’ll get an Internet in which there are lots of com­pet­i­tive local providers. And it’ll be quite com­mon for users, for sites, house­holds, or cor­po­ra­tions, or cam­pus­es or what­ev­er to witch their providers occa­sion­al­ly just like the peo­ple cur­rent­ly switch between dif­fer­ent long-distance car­ri­ers in this country.

Now, so that’s the good side. The bad side is that it requires that all of the providers serv­ing the same met­ro­pol­i­tan area inter­con­nect with each oth­er. I men­tioned in the phone anal­o­gy that there was a shared data­base that all the phone com­pa­nies had to main­tain. The require­ment for the inter­con­nec­tion is a basic rule of hier­ar­chi­cal address­ing that if a pack­et gets deliv­ered into the San Francisco Bay Area over some provider’s facil­i­ties, once it arrives in the San Francisco Bay Area it has to be able to get to the provider that’s serv­ing the des­ti­na­tion with­out going back out­side of the San Francisco met­ro­pol­i­tan area. Because if it goes back it’ll just come right back in where it came before. And so, every hier­ar­chi­cal clus­ter in a hier­ar­chi­cal address­ing scheme has to be inter­nal­ly con­nect­ed. And I imag­ine that hap­pen­ing in sort of a more straight­for­ward way is for… Currently there are…FIX East and FIX West are the Federal Internet Exchanges where a num­ber providers come togeth­er on a com­mon sub­net, exchange routs and extchange data. You know, traf­fic flows over those inter­con­nec­tion points. And I imag­ine the estab­lish­ment of one or more of those in every met­ro­pol­i­tan area—

Malamud: A met­ro­pol­i­tan Internet exchange, a MIX.

Deering: A MIX, right.

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

[Book Byte seg­ment omitted]

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.

Malamud: So who runs the MIX? 

Deering: Um, that’s a good ques­tion. Whether the MIX is a crit­i­cal build­ing or not that every­body has to come to, or is just a mesh of wires between the dif­fer­ent providers, or a high-speed switch sit­ting in some­body’s basement…there are a num­ber of ways of doing it. There’s certainly…dangers of cre­at­ing a monop­oly if you know, the orga­ni­za­tion that runs the MIX then charges a fee to con­nect to the MIX and so on.

Malamud: Should the fed­er­al gov­ern­ment or a state gov­ern­ment be the MIX provider?

Deering: Oh, I hope not. What I… Naïve in this area of human endeav­or as I am, I would imag­ine the providers serv­ing a metro form­ing a…you know, the San Francisco Metropolitan Area IP Providers Association, and every­body chip in and cre­ate the facil­i­ties to form the MIX. 

Clearly there still has to be a num­ber­ing author­i­ty, some­one who hands a met­ro­pol­i­tan area a block of address­es and, ​“Here’s your pre­fix, and you get to use this.” And I envis­age some­thing like a nation­al chap­ter of the Internet Society or some­thing being respon­si­ble for that in each country. 

Malamud: Um, it sounds like in order to go from one ser­vice provider to anoth­er, the ser­vice providers need to coor­di­nate with each oth­er. Is that true?

Deering: Um. For some def­i­n­i­tion of ​“coor­di­nate.” The sim­plest is imag­ine all the providers came togeth­er at a com­mon LAN. Something high-speed.

Malamud: A piece of fiber run­ning through­out the city, for example.

Deering: Or one—I’m think­ing more of you know—

Malamud: One building.

Deering: An FDDI ring or some­thing, where every provider attach­es a router to it. What each provider has to do is know its own cus­tomer sites, so when pack­ets arrive from out­side the metro area Internet provider, it knows ​“Do I deliv­er it to one of my own sites, and if so I have my inter­nal rout­ing that does that. And if it’s not one of my cus­tomers I have to send it towards the MIX.” And in the sort of least coor­di­nat­ed way, you could imag­ine the router attached to the MIX doing some­thing equiv­a­lent to an ARP, say­ing ​“Okay, whose cus­tomer is this,” get­ting an answer back, caching that, and for­ward­ing the traf­fic to the new provider. And you know, if that sub­scriber that you’re send­ing to now changes to anoth­er provider, that for­ward­ing stops work­ing, you’d get back a ​“Sorry, you’ve got the wrong address,” you try a dif­fer­ent— So you could imag­ine the inter­con­nec­tion sim­ply being a pas­sive medi­um like LAN and no need for any coor­di­na­tion oth­er than a pro­to­col for ask­ing ​“Whose cus­tomers is this?”

Malamud: Let’s say I’m on a strict­ly local net­work, a strict­ly local ser­vice provider, and I want to send data to anoth­er met­ro­pol­i­tan area. How do I pick which of the oth­er ser­vice providers that are con­nect­ed to my MIX I use as my tran­sit net­work? We’re get­ting into the pol­i­cy rout­ing ques­tions, obviously.

Deering: Right, right. One thing I should make clear is despite my talk­ing about this some­what in a tele­phone anal­o­gy, there’s no neces­si­ty for a strict sep­a­ra­tion between local providers and long-haul providers. So your Sprints or your long-haul providers, your MCIs, what­ev­er, can—in my model—provide ser­vice direct­ly to the customer.

Malamud: Exactly. And the rea­son I picked a strict­ly local provider is because that way we now have the ques­tion of which of the oth­er ser­vice providers can get me to anoth­er met­ro­pol­i­tan area.

Deering: Right. And so, you pos­tu­late a mod­el that’s much more like the cur­rent phone sys­tem, where you have a local provider, and then a num­ber of options for leaving—

Malamud: Right. But it’s under­stood those long-distance providers are also local providers in this case.

Deering: Right. And there’s some­thing very sim­i­lar to what you do with the phone sys­tem, which is you reg­is­ter who is your default provider or your pre­ferred provider, maybe under some cir­cum­stances like you know, dur­ing this time of day I like my traf­fic to go over Long-haul Carrier X and this time of day Long-haul Carrier Y. Or for this type of ser­vice traf­fic that I’ve labeled appro­pri­ate­ly. So that way, you would reg­is­ter sort of default pref­er­ences the same way I reg­is­ter my pre­ferred long-distance phone com­pa­ny with Pacific Bell. And then some­thing like SIP pro­vides loose source rout­ing, which would allow you to do the equiv­a­lent of dial­ing some pre­fix to select a dif­fer­ent provider. It would be done by say­ing ​“Okay, send to this des­ti­na­tion but make sure you go you go through this clus­ter of topol­o­gy instead of my pre­ferred route.” 

Malamud: Are we gonna end up do you think with a sys­tem based on set­tle­ments between all these providers so that if I pump three giga­bytes of data in on a day and you pump five giga­bytes in, you owe me mon­ey? Or do you think we’re gonna be able to con­tin­ue the cur­rent mod­el in which every­one just con­nects up and we call it a wash?

Deering: Huh, the whole issue of how to charge for Internet ser­vices is a fas­ci­nat­ing and thorny one. The mod­el that makes sense to me, but again I say I’m not—this is an area where I’m naïve prob­a­bly a bit. Currently, peo­ple pay for their Internet ser­vice most­ly by pay­ing a fixed month­ly rate based on the band­width of their access line. And that sounds like a per­fect­ly fine mod­el to me for unre­li­able data­gram traf­fic. The net­works make no promise they’ll deliv­er your pack­ets. Most of the time it gets through, and if it does­n’t get through often enough you’ll stop pay­ing for it. But for a net­work that does­n’t offer to guar­an­tee your traf­fic I don’t think you have to pay on a per-packet basis or a per-connection basis. 

On the oth­er hand, we are see­ing. We work towards estab­lish­ing sup­port for real-time ser­vices, pre­ferred ser­vices through the Internet, which will require some kind of set­up pro­to­col and look quite connection-oriented and that you’ll ask for spe­cial treat­ment for your pack­ets like a low delay or a cer­tain jit­ter bound. And you’ll engage in a set­up, a sort of a nego­ti­a­tion with the net­work say­ing ​“Will you pro­vide this ser­vice,” the net­work comes back and says yes no. It says yes. And I can imag­ine you being charged on a sort of per-reservation or a promise basis because your pack­ets are get­ting pref­er­en­tial treat­ment. So a sys­tem where the cur­rent, unreg­u­lat­ed, best-efforts data­grams con­tin­ues to be charged at a flat rate, plus you pay per-connection charges for spe­cial treat­ment sound like a very sen­si­ble mod­el to me.

Malamud: Sounds like sim­ple mod­el, too.

Deering: Right. Now how the dif­fer­ent providers nego­ti­ate among them­selves to charge back and so on is some­thing I haven’t even thought of. As I said I had a mod­el that there isn’t a strict divi­sion between local providers an long-distance providers. So you would­n’t expect to get a sep­a­rate bill from your long-distance provider and your local provider. You would get your bill from your local provider. That provider would nego­ti­ate— It would estab­lis pair­wise agree­ments with oth­er providers to car­ry traf­fic to var­i­ous oth­er des­ti­na­tions. But that would all be blend­ed back in the bill you got from your local provider.

Malamud: That’s very sim­i­lar to how we do inter­na­tion­al tele­phone ser­vice these days.

Deering: Mm hm.

Malamud: Speaking of inter­na­tion­al, one of the dreams I’ve always had is to be sit­ting there with my lap­top fly­ing on an air­plane and stay­ing on the Internet while I’m doing it. True mobile com­put­ing. Have you giv­en any thought to the ques­tions of mobil­i­ty issues in IP, or mobil­i­ty issues in oth­er places in the stack?

Deering: [qui­et­ly laugh­ing] That’s a dumb ques­tion, of course I hvae.

Malamud: I would­n’t’ve asked it if I thought you had­n’t.

Deering: Yeah I’m the chair­man of a work­ing group of the IETF which is sup­posed to be spec­i­fy­ing pro­to­col exten­sions to IP to sup­port mobil­i­ty. And in fact we have about four sol­id pro­pos­als for the group and are going to the pain of try­ing to sort out which we pre­fer, because they all seem to solve the problem. 

Malamud: Are there some com­mon ele­ments in the proposals?

Deering: Oh yes. And part of the dis­tinc­tion between them becomes dif­fer­ent engi­neer­ing deci­sions. In all of them there is some need for a mobile machine to detect when it’s in a new envi­ron­ment. So there are some kind of peri­od­ic bea­con mes­sages or adver­tise­ments or some­thing from those routers or base sta­tions that can sup­port mobile machines so that the mobiles can hear oh, I’m in a new cell or a new sub­n­er or what­ev­er. And they all have mech­a­nisms for some­thing that looks kind of like a direc­to­ry, so that when some­thing is roam­ing away from its home area it reg­is­ters back home to say where it is and pack­ets, when a sta­t­ic host try­ing to send to a mobile host does­n’t ini­tial­ly know where it is, the pack­ets go towards the home des­ti­na­tion where some­how they’ll hit this direct­ly and get redi­rect­ed to where the mobile is. But there are all sorts of degrees of free­dom in how you define that direc­to­ry. Is it a sin­gle node, is it the set of routers on a home net­work, and so on. And some of the pro­pos­als dif­fer in sort of of how they’ve made the engi­neer­ing trade­offs and how they’ve par­ti­tiond the func­tion­al­i­ty of this direc­to­ry service.

Malamud: How far away do you think we are from begin­ning to at least deploy some solu­tions to these types of problems?

Deering: The pro­pos­als all have been imple­ment­ed. And one of the inter­est­ing prop­er­ties is that all of these schemes work with­out mod­i­fy­ing the vast major­i­ty of routers or hosts. Again, there’s this… We always have this con­cern with the installed base. We can’t update every­thing at once. And so the schemes tend to involve smarter soft­ware or IP soft­ware on the mobile, and smarter soft­ware some­where at your home base, but no one else has to know you’re doing this. So in fact you can have— All of these schemes can be going con­cur­rent­ly and nobody knows. So they’ve all been deployed in exper­i­men­tal basis. Now clear­ly for inter­op­er­abil­i­ty and to be able to go and buy a lap­top and know it’s going to do the right thing we would like to come up with an agree­ment on a stan­dard for that. And…

Malamud: Well we have four stan­dards to pick from, then.

Deering: Yes. 

Malamud: The nice thing about stan­dards is there’s so many of ​’em. Well thank you Steve Deering. This is Carl Malamud. You’ve been lis­ten­ing to Geek of the Week.

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, flame of the Internet.