Carl Malamud: Internet Talk Radio, flame of the Internet. This is Geek of the Week and we’re talk­ing to Bob Braden, who’s at the Information Sciences Institute at the University of Southern California. Bob, wel­come to Geek of the week.

Bob Braden: Thank you.

Malamud: You’re the direc­tor of DARTNet, which is ARPA​’s…experimental net­work out there. Could you maybe tell us what DARTNet is and…what is it? I mean how does that relate to the rest of the Internet?

Braden: Okay, well direc­tor’s maybe a lit­tle strong. 

Malamud: Coordinator.

Braden: Coordinator is more accu­rate. I sort of fell into that because the DARTNet work came out of dis­cus­sions in the End-to-End Research Group of the IRTF that I chair. I’ve chaired it since the start.

Malamud: That’s the Internet Research Task Force.

Braden: Internet Research Task Force, right. And it is was a hotbed of Internet-related research pepole. And these peo­ple orig­i­nal­ly had the ARPANET to play with. And then they had the Internet play with. But the Internet became too suc­cess­ful to be a research vehi­cle any­more. And peo­ple don’t like us to break it. So ARPA agreed to cre­ate a net­work which we could break. And that’s DARTNet. It’s a cross-country TI net­work, a very sim­ple back­bone spine, that con­nects some ten research sites. We use Sun SPARCstations as pack­et switch­es. A very impor­tant part of it is that the pack­et switch­es are pro­gram­ma­ble. And so to do an exper­i­ment on DARTNet you typ­i­cal­ly move your own ver­sion of the oper­at­ing sys­tem, with its own net­work code, and take over the whole system—the whole network—and do experiments. 

Malamud: And what kind of exper­i­ments are done on there.

Braden: Well, most­ly exper­i­ments where you need to break the net­work. The cen­ter of inter­est has been in exper­i­ments con­cern­ing the dynam­ics of net­works. Issues of con­ges­tion, of mul­ti­plex­ing, of queu­ing, sched­ul­ing, now of resource preser­va­tion par­tic­u­lar­ly. There have been some exper­i­ments but not a lot in rout­ing, because it does­n’t have a very inter­est­ing topol­o­gy and so it isn’t ter­ri­bly use­ful for rout­ing. And in factof the kinds of things you want to do in rout­ing besides sim­ple demon­stra­tions that it works involve scal­ing issues, and for that you real­ly need stim­u­la­tions because you can’t afford to put togeth­er a hundred-thousand-node net­work for scal­ing exper­i­ments. But you can do a lot of real­ly use­ful sci­en­tif­ic work on packed sched­ul­ing kind of issue. If you get a bunch of pack­ets of dif­fer­ent traf­fic class­es, which ones get for­ward­ed. So gen­er­al gen­er­al­ly that’s been the area.

Malamud: So that’s the area of resource reser­va­tion or…is this real­ly are we reserv­ing band­width here, or are there are oth­er tech­niques that are being looked at?

Braden: Well, there were exper­i­ments with fair queu­ing, which is not reser­va­tion but has to do with the dynam­ics of traf­fic, and con­ges­tion. And more recent­ly we’ve been doing explic­it­ly resource preser­va­tion exper­i­ments. Our goal is to devel­op a tech­nol­o­gy which can be used in the entire Internet to allow us to do voice and video accept­ably, with rea­son­able qual­i­ty across the entire Internet. 

Malamud: There’s a con­ven­tion­al wis­dom that says the Internet has worked and it’s fine for non-real-time ser­vices: mail, and FTP—

Braden: Yeah.

Malamud: —and one can even con­sid­er tel­net to be some­what non-real-time. But when it comes to voice and video, that won’t work and we’re gonna have to move back to a connection-oriented sys­tem. Do you think the Internet is going to have to make that about-face or we’re gonna have to kind of get rid of pack­et switch­ing and move back to connection-oriented networks?

Braden: Well, don’t think any­one believes that any­more. There has been— Well. You need to dis­tin­guish the dis­ci­pline you use for for­ward­ing packets—who goes in what queue and when you fill and when you emp­ty the queues—from the ques­tion of the set­up protocol—the way the way you actu­al­ly make the reser­va­tions. For the first issue, the sched­ul­ing of pack­et for­ward­ing real­ly doesn’t…isn’t connectionless…can be done a con­nec­tion­less way. We can do this with IP pack­ets, IPng pack­ets, or CLNP pack­ets. It does­n’t make any difference. 

But you need state in the switch­es which reflect the class­es or the ses­sions for which you’re gonna reserve band­width. And there’ve been two gen­er­al approach­es sug­gest­ed for set­ting up that state. One is a connection-oriented approach rep­re­sent­ed by SD2[?]. And now we’re cur­rent­ly devel­op­ing a con­nec­tion­less approach called RSVP, and that’s the work being done on DARTNet now. 

And over the years we’ve tend­ed to come to believe very strong­ly in con­nec­tion­less approach­es as pro­vid­ing more robust ser­vice, and ser­vice which allows plug-and-play, which allows peo­ple to con­nect stuff togeth­er, built by a vari­ety of dif­fer­ent ven­dors with only a mod­est amount of care­ful engi­neer­ing and have it work correctly. 

Malamud: Well how does RSVP work? What are some of the tech­niques you’re look­ing at to do this con­nec­tion­less resource reservation?

Braden: Well basi­cal­ly you send pack­ets along the path of your data to set up the reser­va­tion, and that cre­ates state in the routers along the path. And that state times out. There’s no hard mech­a­nism to remove that state; it sim­ply times out. And you refresh it. You peri­od­i­cal­ly resend the same data before it times out. And if for exam­ple a route changes, then the refresh pack­ets fol­low the new path and set up the state on that new path. And the state on the old path which is now not in use times out. So it’s all done on a sort of soft-state basis.

Malamud: And do these pack­ets guar­an­tee that you’ll have a cer­tain amount of band­width? Is it a best-effort guar­an­tee, if one can use that oxymoron?

Braden: That’s an issue of the sched­ul­ing algo­rithm you use, the mod­el for traf­fic con­trol. And that’s inde­pen­dent of the way you do the actu­al set­up. The set­up arti­cle car­ries along what we call flow spec, which defines the qual­i­ty of ser­vice you want. And you may of course get back an error mes­sage say­ing, ​“I’m sor­ry, I can’t pro­vide that ser­vice.” But it’s still pret­ty much an area of research what the qual­i­ties of ser­vice need to be. There is a mod­el which is very pop­u­lar which is devel­oped by Dave Clark at MIT and Lixia Zhang and Scott Shenker at Xerox PARC, we call it the CSZ mod­el, which is the one we’re pur­su­ing but there are oth­er proposals.

Malamud: If we’re look­ing at class­es of ser­vice and reserv­ing resources, or cer­tain­ly at least say­ing we’d like some resources, the Internet cur­rent­ly is based on flat fees. Users don’t pay, or users pay a cer­tain amount per month. Does that mean if we have dif­fer­ent class­es of ser­vice every sin­gle user is going to say, ​“We want the best pos­si­ble ser­vice of course?” And how do we han­dle that with the cur­rent charg­ing mod­el? Is there a dichoto­my there?

Braden: Well that’s a very impor­tant issue. The researchers in this area believe, quite clear­ly, that resource reser­va­tion can only work if there is some feed­back to the user. Now, that does­n’t have to mean charg­ing. But there has to be some felt cost to the user with the ask for a better-quality ser­vice. Because oth­er­wise as you say, the sys­tem would just break down; every­one’ll ask for the best qual­i­ty of ser­vice and then nobody’ll get any­thing. So that some sort of a usage-based resource feed­back is essen­tial. And well, we say that and so far we haven’t done any­thing about it.

Malamud: What kind of feed­back might that be? obvi­ous­ly tak­ing your mon­ey is a good way of doing feed­back. Are there oth­er ways of doing that? Does the screen get mud­di­er if you want bet­ter service? 

Braden: Well of course it’s prob­a­bly true that the Internet is gonna move towards a real-dollar basis for most peo­ple. So at some lev­el there’s going to be mon­ey exchanged. It may be… Well. When I go to work and I pick up the phone to make a phone call, I’m not aware direct­ly of the cost of that call. Now, I may get a month­ly sum­ma­ry from my com­pa­ny say­ing that my depart­ment spent so much or even my tele­phone spent so much. If I start mak­ing a lot of long-distance calls after hours to Japan, or if the phone bill begins to mount up in some par­tic­u­lar area, some admin­is­tra­tor may ask you know, what’s going on. The com­pa­ny may decide to buy a dif­fer­ent local phone sys­tem. A dif­fer­ent PBX which is able to opti­mize the traf­fic in some way, like it tries dif­fer­ent ser­vices or gets the best—the cheap­est ser­vice, is able to com­pute which car­ri­er to use at what time of day.

I think that net­work charges will prob­a­bly be anal­o­gous to this. That com­pa­nies will get bulk charges which they may or may not reflect—probably gen­er­al­ly reflect down to the indi­vid­ual user, but there will be some­one in charge who is look­ing at the costs and opti­miz­ing them. And decid­ing that well gee, maybe we ought to buy this bet­ter FTP pro­gram which which will save us 20% on our aver­age costs. Or maybe we can’t afford quite the same qual­i­ty of ser­vice as a whole. So there will be some indi­rect admin­is­trate feed­back. I think most peo­ple won’t see it directly.

Malamud: If we’re look­ing at con­trol­ling costs in a net­work, or assign­ing costs, we’re imply­ing account­ing in some respect. How are we going to account for the use of resources in the Internet? Is this going to be some­thing that every sin­gle router will main­tain a log of every pack­et. Is it going to be sim­ply the end­points where we keep a log of FTP ses­sions? Or is it some­place in between or some­place different?

Braden: That’s a con­tro­ver­sial issue. And we haven’t…really thought enough about it, or done enough exper­i­ments. So I don’t real­ly know the answer except that we believe in general…what it costs in some sense, by some met­ric whether it’s real mon­ey or some usage mea­sure. What it costs has to reflect what you do, what you ask for. If you ask for a bet­ter qual­i­ty of ser­vice, it has to cost in some sense more.

Malamud: And any ideas on how we might do account­ing? Because right now the Internet is based on a—this is prob­a­bly unfair, but a no secu­ri­ty, no account­ing, open mod­el. How might we begin doing account­ing? Do you have any at least ideas if not answers?

Braden: I think a rea­son­able mod­el might be the sort of usage feed­back is only nec­es­sary for peo­ple who ask for better-than-minimum ser­vice. So if you only ask for the vanil­la best-efforts ser­vice, we may not both­er. But if you ask to reserve band­width for a video sig­nal, now that’s a sig­nif­i­cant resource. And it needs to be account­ed to you in some way. 

As I say, we— Well. The fact that you have to ask for reser­va­tions, whether you do it in a con­nec­tion­less or a connection-oriented way, in either case you have to explic­it­ly set up a reser­va­tion. And that act pre­sum­ably trig­gers some sort of account­ing. Now, whether you actu­al­ly count pack­ets or whether you only— Whether the cost is based upon usage or upon reser­va­tion is one of the basic ques­tion. And there are argu­ments both ways. In oth­er words if you reserve 64 kilo­bits over cer­tain path, and you have the right to use 64 kilo­bits, do you get charged on that basis regard­less of whether you use it, or do you only get charged on the pack­ets you use?

Malamud: You’re look­ing at a vari­ety of research issues on how the net­work will func­tion. We’re cur­rent­ly going through a process of engi­neer­ing the next gen­er­a­tion of an Internet protocol.

Braden: Yes.

Malamud: And that’s based on a cri­sis in the address space, and in the rout­ing tables. There is some dis­agree­ment as to whether we should just solve that address prob­lem, or whether we should at the same time while we’re going through that tran­si­tion try to tack­le some of these more long-term issues. How do you see that com­ing out?

Braden: Well I think that the address-based prob­lem. which is actu­al­ly real, is get­ting a lot of atten­tion because peo­ple under­stand it. The net­work oper­a­tors under­stand it very painful­ly and they see that com­ing. Or least the lim­i­ta­tion of their growth, and for them that’s a very seri­ous issue. But I think that peo­ple are not pay­ing enough atten­tion to the explo­sion of that, the use of video and audio, and the fact that all our work­sta­tions now are begin­ning to come with audio and video built in. And soon tha’ll be absolute­ly stan­dard. And that’s a tremen­dous traf­fic gen­er­a­tor and this stuff is nice—peo­ple use it. We use it because we’re devel­op­ing this tech­nol­o­gy in DARTNet. A num­ber of us on DARTNet have an open chan­nel for audio at all times when DARTNet’s not being bro­ken by some­body. And…we just use it. And we use video quite a lot and it’s very helpful. 

s. So by an open chan­nel, it’s as if you’re in a room with all these oth­er people—

Braden: Essentially. Except we keep our mics mut­ed most of time. And if I want to talk to Steve Kasner[sp?] on the oth­er side of my build­ing or Steve Deering in Palo Alto I just say— I can’t just say ​“Steve,” I have to say, ​“Steve Deering are you there?” and we chat. And that’s very handy.

Malamud: And that’s going to be…all over the world, that same type of service.

Braden: I believe so. And now, trav­el is just hor­ren­dous. We can’t do all— There are too many meet­ings and too much trav­el. And the only thing which is stand­ing in the way at this point is the qual­i­ty is rather poor because we don’t have band­width reser­va­tion. As soon as we begin to have band­width reser­va— Well the oth­er thing is that peo­ple are more and more begin­ning to use this on their LANs. It going to become more and more pop­u­lar on LANs. And then they’re going to say, ​“Well why can’t we use this the wide Internet?” So I think that very short­ly there’s gonna be great pres­sure on the ven­dors and on the oper­a­tors to pro­vide resource reser­va­tion ser­vice Internet-wide.

Malamud: Well how are we gonna do that? Do we know how to do that?

Braden: Well, that’s the research which I’ve been talk­ing about on DARTNet. And our intent is to pro­vide a set of algo­rithms and pro­to­type rou­tines and pro­to­cols which then can be intro­duced into the IETF process. And I believe that— My cur­rent read­ing is that it would be a very good idea to get that in sync with the IPng work.

Malamud: There’s a sense of urgency about IP Next Generation, about get­ting it out there and avoid­ing the address cri­sis. Will the resource reser­va­tion work be ready in time or would that slow down the process of decid­ing on the next IP? Can we afford to wait for resource reservation?

Braden: Well, that’s… Would you like to peer into my crys­tal ball. As not­ed at last night’s IP [indis­tinct], there’s a great deal of uncer­tain­ty about how soon we have to we get IPng devel­oped. It looks like CIDR​’s going to save us for a while, but we don’t know how long a while is. I guess I— It seems clear— We need to move ahead with all delib­er­ate speed on IPng. And I think we have a chance. I think we have a chance to get the resource reser­va­tion stuff far enough along in time that it can be fac­tored into the deci­sion and devel­op­ment of IPng. Our goal has been to begin to intro­duce the resource reser­va­tion work into IETF— Well actu­al­ly, at one point our goal was to do it this fall. We’re not gonna make that, but by ear­ly next year; ear­ly cal­en­dar ​’94. And I think we ough­ta syn­chro­nize the two efforts.

Malamud: How long do we have before the address­ing and rout­ing table explo­sion problem…kill us? How long do— How bad is the cri­sis? I know you don’t have an answer but do you have a range? Are we gonna run out of address­es in fifty years? Are we’re gonna run out next month?

Braden: Well I think the num­bers which have been men­tioned recent­ly range from what, two to five, six years. And [indis­tinct; crosstalk]—

Malamud: That’s if we deploy CIDR and if it works.

Braden: Yeah, assum­ing CIDR, yeah. 

Oh, CIDR will work, but how effec­tive it will be we don’t know yet. 

Malamud: You’re exec­u­tive direc­tor of the Internet Architecture Board, and in fact you’re a long-time mem­ber of the IAB.

Braden: A char­ter mem­ber, actually.

Malamud: Charter mem­ber. That’s about as long as you can get.

Braden: Since 1981 when it started.

Malamud: How does a group like the IAB mon­i­tor the tremen­dous out­put com­ing out of the IETF? How do you judge and review secu­ri­ty and rout­ing and resource dis­cov­ery, and X.500 at the same time? 

Braden: It was only in the old world order that we did all that. And the answer would have to be fair­ly poor­ly. But in the new world order, we play much more of a man­age­ment kind of a role. We are tasked to wor­ry about—or to do some long-range plan­ning, try to step back and think about the archi­tec­ture and about the gen­er­al prin­ci­ples of what’s going on. And we also are tasked to serve as a sort of court of appeals, basi­cal­ly, to that the IESG that has pri­ma­ry respon­si­bil­i­ty on standards. 

Malamud: Do you see that func­tion being…[crosstalk] exer­cised a lot? 

Braden: So we watch an lis­ten a lot.

Malamud: You watch and lis­ten, and if nec­es­sary use you step in when the IESG can’t make a deci­sion or was chal­lenged its decision.

Braden: Well that’s the prin­ci­ple. I mean in fact it has­n’t yet hap­pened, so we don’t know how well that’s going to work. But that selec­tion process I think is real­ly impor­tant. And it’s real­ly impor­tant to the com­mu­ni­ty that that work. 

Malamud: The Internet has always been a real dynam­ic lab­o­ra­to­ry, a place where new things hap­pen and we’re not afraid to try to move for­ward. And now it’s becom­ing a glob­al pro­duc­tion ser­vice, very oper­a­tional. We’re see­ing tele­phone com­pa­nies offer­ing IP ser­vice. Is that gonna change the Internet? Is it gonna be a dif­fer­ent place?

Braden: Well that’s an impon­der­able. When there’re such big bucks involved it’s hard to see how we can be allowed to con­tin­ue to play the way we have. 

Malamud: Isn’t play­ing good?

Braden: Well I mean, we’ve been tremen­dous­ly suc­cess­ful. We’ve built a great thing. Without wear­ing suits and ties. But there’re an awful lot of suits and ties in the world, and when there’s such big bucks involved and big polit­i­cal— When the Vice President of the Unites States starts talk­ing about it, and when you find jokes in The New Yorker which talk about the Internet with no fur­ther expla­na­tion, you know you’re in trouble.

Malamud: This is dog joke that—

Braden: Yeah the dog joke, right.

Malamud: There was a car­toon in The New Yorker in which one dog is sit­ting on a chair and look­ing at a ter­mi­nal, and there’s anoth­er dog on the floor, and the dog on the chair says, ​“On the Internet, nobody knows you’re a dog.”

Braden: [groans] But what was remark­able about that was it appeared in The New Yorker and it used the term ​“Internet” with­out any com­ment, with­out expla­na­tion. And it— Well, I read a lot of arti­cles about the Internet today in The New York Times. It’s part of the dis­course. It’s becom­ing part of dis­course of the nation. 

Malamud: You start­ed work­ing on the Internet when?

Braden: Um…

Malamud: Were you part of the orig­i­nal ARPANET team?

Braden: Yes. Well I actu­al­ly start­ed net­work­ing back in 1970 when the ARPANET start­ed. I was at UCLA and in charge of sys­tems pro­gram­ming for what was a super­com­put­er in those days, an IBM ³⁶⁰⁄₉₁. And ARPA want­ed to have a super­com­put­er on the ARPANET as a resource, because ARPANET was sup­posed to be about resource shar­ing; remote access to com­put­ing resources. Which were then very expen­sive, rel­a­tive­ly. And so they came to the com­put­ing cen­ter at UCLA and asked us if we would make our IBM sys­tem a host on the ARPANET. So, I was in charge of that and I got inter­est­ed in the prob­lem of pro­to­cols and got inter­est­ed in— I worked on FTP pro­to­col and was respon­si­ble for imple­ment­ing the whole suite. I did­n’t do the work at that point. I was a man­ag­er. But I went to work­ing group meet­ings and got to know John Postel and Steve Crocker and the very cre­ative group of peo­ple who start­ed all that. So I have some num­ber of RFC writ­ten back in the 100s, the 200s in the ear­ly 70s. And we were some­thing like fifth or I don’t know, tenth host on the ARPANET. And about 1973 I guess we are ful­ly oper­a­tional. Those were very excit­ing days, inter­est­ing days.

Malamud: Did you have any idea that the Internet would grow like it did?

Braden: Well. This was the ARPANET, and the ARPANET grew in sort of pre­dictable ways. But then in 1974, the Internet idea was devel­oped at ARPA by Bob Kahn, and Vint Cerf wrote the clas­sic paper on Internet pro­to­cols in 1974, and then 1975 they start­ed the Internet research pro­gram. And about 1977 I guess, I got an ARPA con­tract to change our host soft­ware at UCLA to sup­port TCP/IP. So I wrote the TCP/IP for the IBM sys­tem. And this time I did type the code. 

And so I became part of Internet research pro­gram at that point. I was actu­al­ly in the TCP end. Vint went to ARPA. He sep­a­rat­ed the IP and the TCP groups to work sep­a­rate­ly and I was in the TCP group. 

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