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

Malamud: This is Geek of the Week. We’re talk­ing to Peter Ford, who’s a mem­ber of the tech­ni­cal staff at Los Alamos National Laboratory. Welcome to Geek of the Week, Peter.

Peter Ford: Thanks, Carl. It’s great to be here. 

Malamud: You’ve been one of the insti­ga­tors of one of the con­tenders for the next gen­er­a­tion of IP, known as TUBA. Maybe you could tell us briefly what TUBA is.

Ford: Sure. TUBA is an acronym for ​“TCP and UDP with Bigger Addresses.” And orig­i­nal­ly the pro­pos­al was quite gener­ic in the sense of just look­ing at how to run the cur­rent Internet lay­er trans­ports TCP and UDP, and of course every­thing above it like tel­net and FTP, on top of some net­work lay­er pro­to­col that had big­ger address­es than the cur­rent 32-bit address­es that we have in IP ver­sion 4. As things progress, we sort of shopped around, because of the expe­ri­ence of a lot of peo­ple in the work­ing group that was involved with TUBA, we went with look­ing at a spe­cif­ic instan­ti­a­tion on top of CLNP, which is the con­nec­tion­less net­work lay­er pro­to­col that was basi­cal­ly stan­dard­ized by the ISO community.

Malamud: And so did you basi­cal­ly take the ISO pro­to­col and slap TCP on top of it and off we go, or did you make some changes, or…

Ford: Well basi­cal­ly we did­n’t real­ly change any­thing dra­mat­i­cal­ly. In fact we did­n’t change any­thing in CLNP the way it is today. What we did do is we spec­i­fied how to encode the car­riage of TCP and UDP on top of CLNP. The biggest trick there is that TCP and UDP spec­i­fy what is known as a pseu­do head­er which actu­al­ly goes in and reach­es into the net­work lay­er to get some oth­er infor­ma­tion when it gen­er­ates a check­sum for pro­tect­ing that infor­ma­tion. And so that was one of the major design points. We actu­al­ly have a spec for it and it’s sit­ting out I guess as an exper­i­men­tal RFC right now.

Malamud: Is that the only real­ly mod­i­fi­ca­tion that you need­ed to make?

Ford: Well that’s real­ly not a mod­i­fi­ca­tion. I should— I want to clar­i­fy that. It was real­ly just a spec­i­fi­ca­tion of how to car­ry TCP and UDP on top of CLNP. 

Malamud: So TCP and UDP remain the same, and CLNP remains the same.

Ford: Architectural— Implementation-wise, CLNP remains the same. TCP and UDP of course change because it only cov­ers the case where the two end sys­tems are both run­ning TCP on top of CLNP. One thing that the cur­rent spec­i­fi­ca­tion of TUBA does not cov­er is the issue of let­ting a sys­tem orig­i­nate TCP on an IP host and ter­mi­nate on a TCP-speaking host that’s run­ning on top of CLNP. That’s not to say it’s impos­si­ble to do that, it’s just that to date there isn’t a suc­cinct spec that says how to do that.

Malamud: What were the moti­va­tions behind pick­ing CLNP? What made you decide that that was an appro­pri­ate Internet protocol?

Ford: CLNP actu­al­ly start­ed when the American com­mu­ni­ty took the Internet pro­to­col to the ISO com­mu­ni­ty, and not only to tried to get it stan­dard­ized but also in a sense bring the con­cept of con­nec­tion­less data­gram net­work­ing to the ISO com­mu­ni­ty. As you prob­a­bly know and maybe many of your lis­ten­ers know, the ISO com­mu­ni­ty used to be very focused on strict­ly connection-oriented net­work­ing. Some brave, hearty Americans and some fel­low com­pa­tri­ots in oth­er coun­tries basi­cal­ly brought CLNP to the ISO community. 

The one thing that they did change sig­nif­i­cant­ly from the orig­i­nal IP spec was the whole area of address­ing. Basically the con­cern was that if you’re going to build up a net­work, in this case a con­nec­tion­less net­work, at a glob­al scale, it was clear to the peo­ple in the com­mit­tee at that peri­od of time that the 32-bit address space that was in IP ver­sion 4 was not suf­fi­cient. And so this is the one area that shifts dra­mat­i­cal­ly from IP ver­sion 4 to CLNP. There are many oth­er things to car­ry for­ward, such a source and destination-based address­ing, TTL, the way options are processed, things of that sort are very sim­i­lar. They’re not iden­ti­cal, but they’re very sim­i­lar to each oth­er. Someone who knows IP ver­sion 4 will rec­og­nize most of their favorite fea­tures in CLNP.

Malamud: Now the address­es I’ve heard are 20-byte address­es and some ways say gee, that’s an address for every pro­ton in the uni­verse. Could you explain some of the ratio­nale behind [crosstalk] the address space?

Ford: Sure. That’s actu­al­ly a very good ques­tion and I real­ly appre­ci­ate it. It’s sort of like a soft­ball being tossed up.

It turns out that NSAPs are actu­al­ly variable-length address­es. And so the way an NSAP is spec­i­fied in its rep­re­sen­ta­tion in a CLNP head­er is it has a length byte, it has a type in a sense called the Authority and Format Identifier—the AFI, and then the rest of the address. And at the end of the rest of the address there’s a sin­gle byte called the end sel, which is equiv­a­lent to the pro­to field in IP ver­sion four.

You can actu­al­ly have any­where from let’s say, one to up to 255 in the worst case, ‑length address­es in CLNP. The rea­son the num­ber twen­ty keeps pop­ping up is because the US GOSIP spec essen­tial­ly talks about pro­fil­ing the NSAP address space for 20-byte address­es, and it lays out essen­tial­ly what the for­mat is going to be and how each of the indi­vid­ual fields with­in that for­mat are. What’s notable about that is that you then have a length indi­ca­tor of 20, you have an AFI that basi­cal­ly spec­i­fies that this is going to be com­ing out of a par­tic­u­lar range of the address space—

Malamud: AFI is an Authority and Format, um—

Ford: Identifier, right. This is, you know, ISO-ese. A lot of ter­mi­nol­o­gy here. 

The impor­tant thing is it basi­cal­ly spec­i­fies who’s in charge of the sub­se­quent por­tion of the address. And then the remain­ing bytes are essen­tial­ly very well-formatted. And they encode things like areas with­in a site and then sort of the rela­tion­ship between a site and its provider in terms of how the address space is delegated.

So in fact, you could actu­al­ly have either much short­er address­es using NSAPs, and CLNP could car­ry those, or you know, worst case you could have even larg­er address­es if you want­ed. So the 20-byte is cur­rent­ly what’s spec­i­fied. It’s not man­dat­ed that you use that. You don’t have to. It just hap­pens to be a pro­file that was done by the US GOSIP community.

Malamud: Does the group that is look­ing at a next-generation IP have any thoughts as to what that length should be, or are you gonna stick with the US GOSIP specs?

Ford: Well I think what we what we have is a gener­ic address­ing and rout­ing archi­tec­ture. And that essen­tial­ly indi­cates what the hier­ar­chy should be. It’s felt that the 20 bytes is not a bad choice. And in fact, most of the sys­tems that are out there today work with a 20-byte length. I don’t think we have any predilec­tion to come up with a new address­ing plan. In fact we have an address­ing plan that was devel­oped inside the IETF, RFC 1237. We’re mak­ing some small changes to that. What’s notable excuse me about RRC 1237 is it was actu­al­ly the base doc­u­ment that was used to gen­er­ate the most recent work on class­less inter-domain address­ing, CIDR. And so actu­al­ly if you look at the CIDR spec, and you look at RFC 1237, you’ll notice an amaz­ing amount of sim­i­lar­i­ty in the two documents.

Malamud: Now, you have a 20-byte source address and a 20-byte des­ti­na­tion address­es. Is that too big. Is that some­thing that all of a sud­den each pack­et we send is gonna be incred­i­bly huge?

Ford: Well, actu­al­ly yes, you’re right. It does change the length of the pack­et. So for today, for exam­ple, worst case that peo­ple usu­al­ly bring out is tel­net pack­ets, where a sin­gle byte is car­ried per pack­et. In fact with IP that means that you’ve got you know, less than 5% uti­liza­tion of the pack­et. And with CLNP that does get a lit­tle bit worse. You know, I’m not going to mince facts there. That’s true.

However, there are ways to com­press that. In fact, at this year’s IETF in Houston, we just went through a pro­pos­al on how to do head­er com­pres­sion, using CLNP, that would allow us to actu­al­ly sig­nif­i­cant­ly reduce the size of the packet. 

Malamud: Do you actu­al­ly com­press the address, is that you do?

Ford: You com­press the infor­ma­tion that’s in there that does­n’t change. So for exam­ple if I have a sys­tem A talk­ing to your sys­tem B, if A and B can agree on sort of a com­pres­sion scheme on the infor­ma­tion that does­n’t change as I’m talk­ing to you over time, then I can sig­nif­i­cant­ly reduce the amount of infor­ma­tion that has to go across the link. This is not dis­sim­i­lar to what hap­pens with com­pressed SLIP today, for exam­ple. And it’s just anoth­er scheme to get bet­ter uti­liza­tion of line speed. Of course there are oth­er mech­a­nisms for doing that. And we’re inves­ti­gat­ing sev­er­al of them. 

CLNP has actu­al­ly been spec­i­fied by sev­er­al com­mu­ni­ties who’re very con­cerned about effi­cient uti­liza­tion of links, for exam­ple radio fre­quen­cy links, where you typ­i­cal­ly go 9.6 kilo­bits per sec­ond. And specif­i­cal­ly in the air­line reg­u­la­to­ry are­na. And so there’s sev­er­al oth­er pro­pos­als for doing this kind of com­pres­sion. Our work­ing group, the TUBA Working Group, is look­ing at sev­er­al of these pro­pos­als and try­ing to deter­mine if we have one that we think is let’s say best, and use it for the basis of a stan­dard that we might push into the Internet com­mu­ni­ty process. 

Another group, CDPD, a very large con­sor­tium of cel­lu­lar data net­work providers involv­ing a lot of the region­al Bell oper­at­ing com­pa­nies in the United States, also has a stan­dard. And we’re going to study that as well.

Malamud: When we look at the net­work lay­er, we look at more than just the IP pro­to­col or CLNP. We look at a vari­ety of asso­ci­at­ed pro­to­cols. In the cur­rent IP world we have ICMP, for exam­ple. In the ISO pure spec there’s things like End System to Intermediate System—ESIS. Do you pro­pose to bring some of those ISO pro­to­cols into the Internet as well as bring­ing CLNP in?

Ford: Sure. there’s been a tremen­dous amount of work done by the ISO com­mu­ni­ty. And in fact, the same peo­ple who work in the ISO com­mu­ni­ty on rout­ing pro­to­cols and CLNP actu­al­ly par­tic­i­pate and have par­tic­i­pat­ed in the IETF for many many years. So, again there’s a lot of sim­i­lar­i­ty that you’ll see between the pro­to­cols that you see in the ISO of com­mu­ni­ty and the pro­to­cols that you see in the Internet com­mu­ni­ty. In fact, there was a debate a while ago about IS-IS and OSPF. And the fact is that those two pro­to­cols are prob­a­bly far more sim­i­lar than they are dissim­i­lar. So, with CLNP we pro­pose to bring in ESIS, which is in a sense a replace­ment for ARP and router dis­cov­ery, which basi­cal­ly allows an end sys­tem to be con­nect­ed into the net­work. IS-IS, which is essen­tial­ly an introdomain rout­ing pro­to­col. And IDRP, which is the Inter-domain Routing Protocol, which just recent­ly became an ISO standard.

What’s sig­nif­i­cant about IDRP is that it actu­al­ly derives direct­ly from work that was done with­in the IETF and Internet com­mu­ni­ty on what’s called the Border Gateway Protocol. And one can think, and in fact with­in the IETF com­mu­ni­ty most of the peo­ple in the BGP Working Group—the Border Gateway Protocol Working Group—think of IDRP as the log­i­cal suc­ces­sor to BGP for doing inter-domain rout­ing, which is the rout­ing done between providers of Internet con­nec­tiv­i­ty as the follow-on to BGP 4. And we’re very excit­ed about it mak­ing inter­na­tion­al standard.

So there’s a whole fam­i­ly of pro­to­cols, as you said, that will be com­ing in with this. They’re inter­na­tion­al specs, they’re well-documented, you can get a hold of them in most cases—IDRP being the notable excep­tion. They’ve been out there in the field, they’ve been test­ed, and they’re deployed and peo­ple actu­al­ly use them every day.

Malamud: Do you see a polit­i­cal ben­e­fit in adopt­ing an internationally-approved standard?

Ford: II don’t see it as a major polit­i­cal ben­e­fit. I think the fact is that the peo­ple who do the stan­dards in both the Internet com­mu­ni­ty and the ISO com­mu­ni­ties are real­ly hard-working engi­neers. They sit down, they devel­op con­sen­sus stan­dards, they do the best job they pos­si­bly can. In cas­es where they find flaws they try to get them fixed. These things are liv­ing doc­u­ments, as you’re prob­a­bly well aware, in terms of the way the stan­dards process­es work. 

I think the great­est ben­e­fit that we have today in the sense of you know, the over­all polit­i­cal scene, is basi­cal­ly to iden­ti­fy for the sake of the infor­ma­tion technology…business, if you will—the telecom­mu­ni­ca­tion providers, the com­put­er industry—that the ben­e­fits of hav­ing a sin­gle net­work lay­er pro­to­col for the devel­op­ment of infra­struc­ture, on a glob­al scale, is impor­tant. And I think in the Internet com­mu­ni­ty what we’ve done is we’ve demon­strat­ed that it can be done. I think you know, the ARPANET going into the NSFNET, now going into what we call the Big‑I Internet, has proven that we can do it. It is pos­si­ble. You can build pan-world net­work that has many autonomous admin­is­tra­tions and it works quite well. And I think the thing is just to basi­cal­ly take this tech­nol­o­gy base, come up with a work­able stan­dard that every­one can agree on, a true con­sen­sus stan­dard, and move it ahead.

Malamud: Do you believe that the SIP group and the TUBA group are going to be able to come togeth­er and reach a con­sen­sus solution?

Ford: I cer­tain­ly hope so. I believe that we in the TUBA group see some things that are very good about the SIP pro­pos­al. You know, they’ve done a good job of engi­neer­ing. It’s not a bad pro­pos­al. The weak­est part of that pro­pos­al in com­par­i­son to the TUBA pro­pos­al I think is we would put for­ward that variable-length address­ing is very impor­tant. It basi­cal­ly allows you to antic­i­pate for the future. Whereas the SIP pro­pos­al pro­pos­es 64 bits. One could imag­ine a very inter­est­ing com­bi­na­tion of the two pro­pos­als if you were to com­bine a large variable-length address…the abil­i­ty to go larg­er than 64 bits, variable-length address­ing, in some­thing like the con­text of the SIP pro­pos­al. So I think it’s pos­si­ble to see that. And I think that’s what we’re going to work on inside of the IETF is to devel­op a con­sen­sus in terms of the require­ments that we have to meet, and make sure that we can meet them with the pro­to­col that comes out of the IETF.

Malamud: Let’s say such a con­sen­sus is reached. Would that con­sen­sus have to be entered back into the inter­na­tion­al process, and you think the inter­na­tion­al process could accom­mo­date a change in some­thing so fun­da­men­tal as its net­work lay­er protocol?

Ford: I think…you know, I think the whole thing is gat­ed by what the infor­ma­tion tech­nol­o­gy indus­try does. I don’t think that you know, by fiat or de jure you can dic­tate what the future Internet is going to be. I think it’s basi­cal­ly peo­ple build­ing great prod­ucts, good oper­a­tors turn­ing it on, and the end sys­tem users being able to sat­is­fy their require­ments for get­ting their jobs done. Or for that mat­ter hav­ing fun, with enter­tain­ment. So, I think that in fact what both orga­ni­za­tions have to do, both orga­ni­za­tions in this case being the Internet com­mu­ni­ty and the ISO com­mu­ni­ty, have to do is basi­cal­ly rec­og­nize that this is gonna hap­pen. And what­ev­er the tech­nol­o­gy base that con­sen­sus is devel­oped on is going to be de fac­to. And that they’re much bet­ter off stan­dard­iz­ing it so that peo­ple will have a rea­son­ably good doc­u­ment that if I’m a new com­pa­ny and I want to build an Internet prod­uct, if you will, they’ll have a great doc­u­ment to start out with her build­ing those prod­ucts and in effect if they build true to that spec, they will be able to inter­op­er­ate on the glob­al infrastructure.

Malamud: Peter Ford, you’ve been a par­tic­i­pant in the efforts to help define a new archi­tec­ture for the fed­er­al net­work­ing. In the past there was a back­bone to the Internet, it was the ARPANET, and then the NSFNET, and you’ve been one of the key par­tic­i­pants in help­ing to find a new archi­tec­ture based on NAPs, Network Access Points. Can you help explain what this archi­tec­ture is?

Ford: Well it’s an archi­tec­ture that you can see inside the NSFNET solic­i­ta­tion that was issued ear­li­er this year, in 1993. Essentially, the goal of NAPs is to pro­vide good neu­tral inter­con­nect points for net­work ser­vice providers of the Internet. So if you will, if we had four or five transcon­ti­nen­tal Internet providers in the United States, it would be nice if the interconnected…minimally in two or three places. And that basi­cal­ly helps them orga­nize their rout­ing, helps helped them under­stand how to do debug­ging of the net­work, helps them build a more reli­able net­work infra­struc­ture in the inter­do­main sense, so that in the event one of the neu­tral interconnects—let’s say it was in New York City—fell apart, that you could still get traf­fic but it might go through one of the oth­er inter­con­nects in the system.

Ford: Essentially they pop their routers onto the Ethernet and this gives them a place to inter­con­nect. What makes this inter­est­ing, and glob­al in the sense of the glob­al Internet exchange, is there’s also a lot of inter­na­tion­al con­nec­tiv­i­ty that comes into the Washington DC area. Specifically NSF has an inter­na­tion­al con­nec­tions pro­gram that has three European links—one for Stockholm, one for London, and one for Paris—that also down in the DC area. And so this pro­vides a very nice place for inter­con­nects. The glob­al Internet exchange is actu­al­ly anoth­er dis­cus­sion on inter­con­nects that was done basi­cal­ly in the inter­na­tion­al com­mu­ni­ty. There’s a group called the Internet International Engineering and Planning Group. It involves peo­ple from a lot of inter­na­tion­al net­works, places like NorgeNet, places like the Australian net­work AARNET, the Japanese net­works like WIDE. And you’ve had sev­er­al mem­bers of this com­mu­ni­ty on your show. 

Basically we get togeth­er about once or twice a year. We have our own mail­ing list, of course. And we dis­cussed what can we do to make the inter­na­tion­al net­work best. It was felt that a good thing to have was to focus on sol­id con­nec­tiv­i­ty, and intercon­nec­tiv­i­ty. And this is sort of the first imple­men­ta­tion of that. The moti­va­tion for NAPs, the moti­va­tion for GIXes are the same: the best pos­si­ble inter­con­nect for some of the mul­ti­ple providers that exist in the Internet today.

Malamud: In a par­tic­u­lar area or with­in a par­tic­u­lar scope. Now, pre­sum­ably if there’s one GIX in Washington, pre­sum­ably at some point you’ll need anoth­er GIX in Asia, or in Europe. Or do you envi­sion a sin­gle GIX?

Ford: No, I don’t envi­sion a sin­gle GIX. That’s actu­al­ly I think— We’ve tak­en a lot of flak on hav­ing mul­ti­ple NAPs because you know, if you don’t have one, how can you pos­si­bly posit more than one. And I think that points to the ques­tion that you pre­sent­ed which is, it’s clear you’re gonna need more than one. And I think one of the goals that we have in the NSFNET solic­i­ta­tion is to moti­vate peo­ple to build more than one. Because it solves real prob­lems. And we have that in Europe today. There’s a lot of dis­cus­sion going on on how to build yet anoth­er GIX in the European area. And the issues that come togeth­er for that is you know, where to site it, how do you do inter­con­nects, how do you flow glob­al rout­ing infor­ma­tion across the sys­tem. This essen­tial­ly is stress­ing the tech­nol­o­gy base that we have today. And it’s very excit­ing, because you know, you’re pre­sent­ed with real prob­lems, we get togeth­er, we do that in the IETF, we do that in the IEPG. We work on these prob­lems, we fig­ure out if we need new tech­nol­o­gy or if it’s stuff that can be con­trolled through topo­log­i­cal con­straints, and we go off and we do it. And there’s sev­er­al mem­bers that par­tic­i­pate in that. It’s very excit­ing work.

Malamud: How do you con­nect one GIX to anoth­er GIX, or one NAP to anoth­er NAP.

Ford: Well, you know, this is the new Internet, right. It used to be when you only had a sin­gle back­bone you essen­tial­ly only had a sin­gle provider, typ­i­cal­ly the gov­ern­ment pro­vid­ed it. So you did­n’t wor­ry about if I was on one net­work, let’s say in Alabama and I want­ed to talk to some­body on a net­work in Oregon, you did­n’t wor­ry about inter-provider agree­ments and things of that sort. When you start talk­ing about a glob­al Internet that has thir­ty, forty, fifty, maybe hun­dreds of play­ers and net­works that are inter­con­nect­ed, it’s quite like­ly over time that we have to start think­ing about inter­con­ti­nen­tal and transcon­ti­nen­tal con­nec­tiv­i­ty providers. 

So for exam­ple, you could con­nect these things by bridg­ing them if you want­ed. The prob­lem with that is that you essen­tial­ly have a tran­sit prob­lem. Who pays for the traf­fic that cross­es between them? If you believe that the Internet is just one homo­ge­neous mass, every­one pays their share, and you build that bridge net­work as some­thing, that’s one way to approach the prob­lem of inter­con­nect­ing them. I don’t think that’s very real­is­tic. I think that there are com­pet­i­tive advan­tages for net­work providers that oper­ate in par­tic­u­lar areas to look for oth­er forms of transit.

Both of them will work. You can basi­cal­ly inter­con­nect GIXes, you know. I could be…oh let’s say NTT net­work and inter­con­nect the GIX in Stockholm with the GIX in DC, for exam­ple. And every­body who want­ed to tran­sit the net­work that I built between those GIXes could pos­si­bly pay that inter­me­di­ate network. 

Malamud: Could there be multiple—

Ford: Sure.

c —bridges between those GIXes?

Ford: There could be mul­ti­ple bridges or mul­ti­ple net­works between them. And in a sense what you get is a com­pet­i­tive mar­ket for inter-GIX con­nec­tiv­i­ty, if you will. And so I think that’s a very good thing. In the United States, for exam­ple, we have at least five net­works that are transna­tion­al, that basi­cal­ly can give you cov­er­age any place in the United States—and I’m sure five is a sig­nif­i­cant under­es­ti­mate. I’ve talked to many peo­ple who’re talk­ing about start­ing up sim­i­lar concerns.

Malamud: In many of these inter­con­nect arrange­ments, par­tic­u­lar­ly the Commercial Internet Exchange but also the glob­al Internet exchange, it’s based on the ​“I’ll take all your traf­fic and you take all my traf­fic” mod­el. In oth­er words there’s no set­tle­ments. Do you think we’re going to move to a world in which we start mea­sur­ing the amount of pack­ets that went one direc­tion and anoth­er and then a check gets writ­ten to account for the imbalance?

Ford: I guess what I would say is I would­n’t be sur­prised if that comes about. I don’t see an imme­di­ate need for it. As I said I think there’ll be mar­kets for this. And it’s not clear where this is all going to go. 

My gut-level feel­ing is that if you’re build­ing infra­struc­ture and you’re work­ing in a transna­tion­al sense, you’re going to want to have a mech­a­nism to make sure that you’re essen­tial­ly get­ting rev­enue to help cov­er the cost so that you can invest to help build your infra­struc­ture over time. That may be done by set­ting a price for oth­er providers. It does­n’t mean you have to use a Sender Keep All arrange­ment— Excuse me. You don’t have to use set­tle­ments to col­lect that mon­ey. You can essen­tial­ly just set the price. And so it does­n’t mean that we ever have to get to pay for bits.

I will point out, though, that from what I guess, most cus­tomers of the Internet actu­al­ly do in some sense pay for the bits they push across. A tremen­dous num­ber of our users of the Internet actu­al­ly dial into a place where they pay a charge per hour and things of that sort. And so they are pay­ing some usage-based charge. It may not be for bits, for some peo­ple it is by bits. And so, as I said ear­li­er, we have mar­kets that devel­op and peo­ple will charge a scheme, and if the cus­tomers come, great, and if they don’t they’ll prob­a­bly change their pric­ing schemes.

Malamud: That’s a very…market-oriented approach. This is very dif­fer­ent from a lot of the impres­sions peo­ple have of the Internet that this is essen­tial­ly a government-provided ser­vice with maybe a cou­ple leafs on the edge of it that are commercially-driven. Do you see the Internet as evolv­ing from a gov­ern­ment net­work into a true com­mer­cial mar­ket­place? Are we there yet?

Ford: You bet. I think we’re actu­al­ly— You know, if we’re not there we’re past it. You know, if you look at what we have in the US today, of course we have the NSFNET back­bone and it’s been a tremen­dous boost for get­ting the tech­nol­o­gy out there, prov­ing that it can be done, show­ing that you can pro­vide a reli­able ser­vice that peo­ple real­ly real­ly want. But there are a lot of par­al­lel net­works to the NSFNET. There’s PSI, there’s Alternet, there’s SprintLink, and in fact the provider for NSFNET, ANS, basi­cal­ly has a com­mer­cial arm as well. 

And so, we have a com­pet­i­tive mar­ket­place out there, you know. Anybody who wants to con­nect to the Internet has a whole list of peo­ple they can call today to pro­vi­sion them Internet ser­vice. Which is great, because I think the cus­tomers get you know, fair pric­ing for their product—they can actu­al­ly shop around, and they can also buy dif­fer­ent kinds of ser­vices. Some of these com­pa­nies are sig­nif­i­cant­ly dif­fer­en­ti­at­ed by the kind of ser­vices they offer. Some of them offer fair­ly low-cost but fair­ly low hand-holding type ser­vices, and oth­ers of them will do every­thing. They’ll come right on your site, they’ll run your routers, and in fact sev­er­al of them will consider—for a price—running your local area net­work. So I think we’re there.

There’s still a role for the gov­ern­ment in a lot of this in terms of tech­nol­o­gy devel­op­ment, in terms of bring­ing new appli­ca­tions online and bring­ing new com­mu­ni­ties that’re of nation­al inter­est onto the net­work. And I think that’s where you’ll see where the gov­ern­ment goes in the future on this.

Malamud: Well thank you very much. We’ve been talk­ing to Peter Ford, and this has been Geek of the Week.

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 email 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 pro­duc­er 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.