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

This is Geek of the Week and we’re talk­ing with Christian Huitema, who’s a researcher at the Institut National de Recherche en Informatique et en Automatique. Did I do that any­where close? 

Christian Huitema: No, that’s quite correct.

Malamud: Well thank you. Welcome to Geek of the Week, Christian. You’re the chair of the SIP Working Group. The Steve’s IP, or Simple IP, or one of the can­di­dates for the next gen­er­a­tion Internet pro­to­col. I was won­der­ing if we could talk a bit about what you think some of the require­ments are for the next gen­er­a­tion of an Internet protocol.

Huitema: Oh. I think the one rea­son why we want to change IP is growth. I mean, we have so many IP sta­tions with a growth of 10% a month. So if you [indis­tinct 1:12] a growth of 10% a month, there is a point in time at which we can­not allo­cate more net­works. And that point is…well, some­where with­in four or five years, depend­ing on the counts and the tech­nol­o­gy we use. But we have to pre­pare for that point now. And if we want a wider Internet, we need wider address­es. As we need wider address­es, we have to redo the pack­et for­mat. As we redo the pack­et for­mat, we have to do it well, so that we incor­po­rate the result of research which occurs between [A75?] and now. Like mul­ti­cast, like mobil­i­ty, like resource reser­va­tion, and also we have to get clean. Remove func­tion­al­i­ty that we don’t need. That we get fast. So, that’s SIP.

Malamud: Well but That sounds like a very sim­ple edit­ing process. All you do is dou­ble the address size and get rid of a cou­ple unused fields. Do you need more than that? Do we need to change the mod­el of what the net­work lay­er does.

Huitema: Eh, pre­cise­ly the idea is to be as sim­ple as pos­si­ble because… I would com­pare that to the RISC phi­los­o­phy. That in order to get fast you had bet­ter get sim­ple. And for exam­ple you have a much sim­pler han­dling of the options. You have a much sim­pler han­dling of segmentation—or you don’t do seg­men­ta­tion in most cas­es. Basically by expe­ri­ence we have learned what is used and what is not. And we don’t want to make a pipe dream on paper, we want to reuse what we have experimented.

Malamud: Well how do you make a tran­si­tion to this new envi­ron­ment with SIP? Are we gonna lose con­nec­tiv­i­ty for parts of the Internet dur­ing a tran­si­tion peri­od? Are we gonna for some kind of a changeover?

Huitema: Well that’s the chal­lenge. And in fact that’s not some­thing I’ve done per­son­al­ly, that’s some­thing which has been designed in the IP group by Bob Hinden and Dave Crocker in the past. The idea is that the IP address will be embed­ded in the SIP address. And doing the over­lap­ping two or three years dur­ing which we could still do IP but we have to pre­pare for the tran­si­tion to 64 bit, dur­ing the point where we need only 32 bits and before we need 43, while we install the 64 bits so that we can gain in bet­ter rout­ing and eas­i­er man­age­ment, and we’ll have trans­la­tion tables so we can trans­late a 64 bit into a 32 bit address trans­par­ent­ly to the user. In fact that is already being demon­strat­ed. If you go to the ter­mi­nal room in the IETF you can see that being demon­strat­ed. A SIP host talk­ing to an IPv4 host, and vice ver­sa. It’s ful­ly transparent.

Malamud: You men­tioned resource reser­va­tion as one of the areas that a new IP might need to sup­port. Resource reser­va­tion sounds a bit like you’re set­ting up a con­nec­tion and reserv­ing those resources. Are we mov­ing away from pack­et switch­ing and going back to some form of connection-oriented net­work service?

Huitema: Well there are sev­er­al schools there. At one very extreme you have say the ATM school, that you will do a vir­tu­al cir­cuit and you will [pre­size?] that you want a delay of fifty sec­onds plus or minus 5%, no more, and that you want a through­put of 100 kilo­bits except that from time to time you will need to 200, etc. You make a very pre­cise reser­va­tion. And…well that’s one school. And indeed you could mim­ic that in the Internet. You don’t nec­es­sar­i­ly need to do a vir­tu­al cir­cuit to mim­ic that. You can essen­tial­ly do some iden­ti­fi­ca­tion of your pack­ets as belong­ing to a reser­va­tion group. And you route them as nor­mal data­grams. But they are queued as part of a reser­va­tion group. To put it short­ly, they get a bet­ter pri­or­i­ty. To get a bet­ter pri­or­i­ty as long as they stay with­in with­in the resources. That’s what is being done by resource reser­va­tion protocols.

I per­son­al­ly do not believe that you need very strict resource reser­va­tion to do most of the thing we want to do. I mean, we have been devel­op­ing video soft­ware, we have been [indis­tinct] video exper­i­ments, pre­cise­ly because we want­ed to gain first-hand expe­ri­ence in that. Because while you read in the papers that you need megabits to do video, you need resource reser­va­tion. And yet you observe that if you just put up a video codec and put that on the Internet, pro­vid­ed you have some con­trol of the codec, well it just works.

Malamud: What do you mean it just works. Don’t you need more band­width? Don’t you need guar­an­teed resources? What hap­pens if you drop packets?

Huitema: If you look at the video codecs we have today, I mean if you look at the [NV inter­face of ?] or if you look at the ivs inter­face which we have devel­oped in my team, you will find that there is a but­ton which says ​“What’s the band­width you require?” And you can place the but­ton any­where between say 2 megabits and some­thing like 20 kilo­bits. You can even go at a low speed. [To me?] what you do is that you can have a con­tin­u­ous qual­i­ty arbi­tra­tion between bet­ter bits, bet­ter qual­i­ty, a crisper image, and more bits in the net­work, or less bits in the net­work. Indeed you have a very fine qual­i­ty if you are send­ing 2 megabits per sec­ond of video. But to if you make less bits per pix­el, if you spend more time doing more CPU cycles for your com­pres­sion, then you can have a much low­er throughput. 

So what that means is if you have this but­ton in the inter­face now it means that you can do man­u­al selec­tion of of your through­put. The next step, what we are cur­rent­ly research­ing in my team, is to have a feed­back algo­rithm on the Internet so that you’ll send your pack­et but at the same time you probe the net­work, and accord­ing to what you find as avail­able capac­i­ty, then you increase or reduce your through­put. And, well…

Malamud: Well you men­tioned 2 mil­lion bits per sec­ond and 20,000 bits per sec­ond as two extremes. What would a 2 megabit pic­ture look like? What’s the res­o­lu­tion and the frames per sec­ond and the shades of gray or color?

Huitema: Well, cur­rent­ly the high­est through­put we have reached was some­thing like 500 kilobits.

Malamud: Okay. What’s that look like, then?

Huitema: It looks like… It looks essen­tial­ly like the pre­ci­sion of a video-type image.

Malamud: Okay. So is thir­ty frames a sec­ond? Is that a—

Huitema: Well it’s not thir­ty frames a sec­ond now, although we are get­ting close. I mean, when we first did ivs on a Sun IPX, we were able to do 1.5 to 2 images per sec­ond. If you’re using a Sun 10, and espe­cial­ly if you are using a large machine, we can do four or five images. If you’re using a more pow­er­ful work­sta­tion, a top-of-the-class work­sta­tion now, you can do some­thing like ten images per sec­ond. Which means that twen­ty images or forty images a sec­ond is some­thing you will get in say one year or two. 

Malamud: So the bot­tle­neck there is the CPU and not the network?

Huitema: The bot­tle­neck is the CPU, yes.

Malamud: Now what about 20,000 bits per sec­ond. What kind of an image do you get out of the very very low through­put like that?

Huitema: The prob­lem you have is that in order to get 20 kilo­bits per sec­ond you have to do delta encod­ing. So you only send the deltas, and in fact you also do data reduc­tion. You send less-complex images. For exam­ple you send a less­er num­ber of lev­els of gray. You only send gross fre­quen­cies. So…well it’s not very good. I mean if you move very fast, you’ll see the phan­tom of your ini­tial posi­tion still on the screen and it will clear after a time. But it’s usable. It’s still usable if you’re doing say video phone applications. 

Malamud: So talk­ing heads, that’ll work. 

Huitema: Talking head works, yes.

Malamud: Okay.

Huitema: Star Wars does not.

Malamud: You’re lis­ten­ing to Geek of the Week. Support for this pro­gram is pro­vid­ed by O’Reilly & Associates, rec­og­nized world­wide for defin­i­tive books on the Internet, Unix, the X Window System, and oth­er tech­ni­cal topics. 

Additional sup­port for Geek of the Week comes from Sun Microsystems. Sun, the net­work is the computer.

Malamud: Now you men­tioned the user could throt­tle the through­put up and down. What hap­pens if every user gets this tool and nat­u­ral­ly they’ll say well you know, ​“Give me the best, of course.” Is the net­work going to be able to han­dle that, or do we need some­thing in the net­work to reg­u­late the…

Huitema: I pre­sume you heard Dave Clark speak­ing yes­ter­day at the IETF ple­nary. And he was men­tion­ing sev­er­al pos­si­bil­i­ties. One pos­si­bil­i­ty is to have a resource reser­va­tion pro­to­col. ​“I have bought that many resources. I have bought 500 kilo­bits. I’ve paid for that. So let me use it, and I will find a [match?].” Well that’s a fine mod­el, pro­vid­ed you pay for it. Indeed, if you can have it with­out pay­ing, every­body would ask for it and that won’t be enough of it. 

So, what Dave was men­tion­ing— He’s a bet­ter English speak­er than I am. And he was men­tion­ing that you want to ask for a good ser­vice with­out exact­ly spec­i­fy­ing the num­bers. And what you request is that the net­work exhibits some pre­dictabil­i­ty. That it enables you to do feed­back con­trol and tune in on what is exact­ly avail­able. That means that we have some research to do in the net­work on a load-sharing algo­rithm in the net­work, so that you don’t queue exact­ly the same way a video and an FTP, so that if some­body tries to steal all the bandwidth…well he can­not, he’s con­strained not to do it, etc. There is still research going, but it’s a good chance that this will be deployed by next year or some­thing like that.

Malamud: And is this part of a more gen­er­al area of wor­ry­ing about pol­i­cy con­straints with­in the rout­ing lay­er? The ques­tion of I want to pay for resources, or I want fast through­put, or reload jit­ter, or I don’t want to cross the ANS back­bone or…

Huitema: I’m not a great fanat­ic of try­ing to express your require­ments with fif­teen vari­ables, because if you try to actu­al­ly ful­fill the fif­teen vari­ables you’re get­ting a com­pu­ta­tion­al com­plex­i­ty in the routers which…is not real­is­tic. So I don’t think that if you reserve capac­i­ty, you will be able to reserve much more than reserve band­width. And pol­i­cy rout­ing is a loaded word. It means many things. band­width is one way to choose a [?]. The nor­mal thing you do is that if you want to pick a route in a net­work you will pick that one which gives you the bet­ter bandwidth. 

But you can pick a route accord­ing to oth­er prin­ci­ples. For exam­ple if you have done reser­va­tion, you want to pick a route in order to use exact­ly the resource you reserved. For exam­ple if you reserved 500 kilo­bits on the link between Paris and New York, you don’t want your pack­ets to be rout­ed by the link between Madrid and Miami. That would­n’t go. So you have to do some con­straints— So this reser­va­tion stuff implies that you have some way to con­trol the rout­ing of your packets. 

The oth­er rea­son why you might want to con­trol the rout­ing of your pack­ets has to do with economics—that you have sub­scribed to one provider, not the oth­er one. And it has also to do with gen­er­al poli­cies that you don’t want to send data which is exchanged between the DOD and its part­ner in France by a link that goes through…I don’t know, say Israel. That would not be required. Maybe [indis­tinct].

Malamud: So are we going to be able to do that, in the net­work? That’s a fairly…large set of dif­fer­ent poli­cies you’ve enun­ci­at­ed there. Are we going to be able to fill all those?

Huitema: Eh… I hope we will. We had bet­ter be able. There is a lot of work going on. I’m not exact­ly at the top of doing this work now. You should bet­ter ask that to peo­ple like say…[indis­tinct name] for exam­ple has pro­duced a num­ber of papers on that recent­ly. Jacob [indis­tinct] or peo­ple like [two indis­tinct names]. Many peo­ple are work­ing on that. So there’s good hope that we’ll see some­thing being done.

Malamud: Well there’s a very obvi­ous ques­tion which comes to mind when we look at your efforts in SIP. Why are we invent­ing a new net­work pro­to­col when we have CLNP already out there and deployed. Is there room for mul­ti­ple can­di­dates for next gen­er­a­tion IP? Or should we just be focus­ing our areas on on exist­ing protocol?

Huitema: The prob­lem of the next gen­er­a­tion pro­to­col is that you want to have larg­er address­es, but you want­ed to send them to have larg­er through­puts. And if you want to have larg­er through­put, you want to have some­thing sim­ple, that can be pro­grammed eas­i­ly, that takes advan­tage of your pre­vi­ous knowl­edge and of the [indis­tinct] research. And the prob­lem was that CLNP was essen­tial­ly the designed ten years ago. And it does not take advan­tage of the recent dis­cov­er­ies. It’s rel­a­tive­ly com­plex. It’s some­what of— The address­es are larg­er, okay, but we don’t nec­es­sar­i­ly need address­es which are five times larg­er. I mean, if with 32 bits you could encode one mil­lion address­es, which is the num­ber we have in the Internet now, you can expect that with 64 bit you could encode two times 32 bits, that’s one mil­lion of mil­lions of address­es. And that’s…well, we don’t expect to have many more than that, many more hosts than that. And that’s some­thing like ten to the pow­er of twelve. With the same algo­rithm, if CLNP had the same address­ing effi­cien­cy as IP, we could have the pos­si­bil­i­ty to encode ten to the pow­er of thir­ty address­es. Well, that’s some­thing like each per­son in the uni­verse. We don’t need that. It’s too much. And that will [?] so many costs. And it would­n’t— We won’t get to that point. I mean, we’ll have the bizarre sit­u­a­tion where we have this brand new tool in order to cope with the mil­lions of mil­lions of address­es, and we will not be able to use that in more than…a cou­ple mil­lions, because peo­ple can’t afford the cost of it.

Malamud: So you think sim­plic­i­ty is key.

Huitema: Yes.

Malamud: I’ve noticed that the Simple Network Management Protocol, the Simple Internet Protocol… ​“Simple” seems to be the key word. But we lose func­tion­al­i­ty when we do that. It’s not feature-rich. Is that a good tradeoff?

Huitema: In fact we don’t lost func­tion­al­i­ty with SIP, we just do it dif­fer­ent­ly. The same way you don’t lose func­tion­al­i­ty with a RISC proces­sor. Instead of hav­ing a set of very com­plex instruc­tion which cost very much in being pro­grammed, you have a set of sim­ple instruc­tion that you can com­bine. And there is noth­ing that you can do with CLNP that you could not do with SIP, in fact we can do more. You can do options, you can do secu­ri­ty, you can sup­port mobil­i­ty, you can sup­port source rout­ing. But sim­ply you do that dif­fer­ent­ly. You pile up sep­a­rate pro­to­cols, where each of them is very effi­cient. And you don’t have to have this com­bi­na­tion effect that you have to look for. Each option in every pack­et and this…is eas­i­er to imple­ment. The proof it’s eas­i­er to imple­ment is that it was not exist­ing six months ago, and we have six intero­prat­ing imple­men­ta­tion now.

Malamud: What RISC does is takes a lot of the func­tion­al­i­ty and push­es it up the stack, if you will. It says let the microc­ode do what­ev­er, let the appli­ca­tion wor­ry about this func­tion rather than embed­ding it down in the hard­ware. Are we try­ing to move some of that func­tion­al­i­ty up into the upper parts of the pro­to­col stack? And if so what do we need in the top parts of the pro­to­col stack? Do we need ASN.1, do we need full-blown pre­sen­ta­tion layers…?

Huitema: Well, I don’t think that ASN.1 has much to do with SIP. It’s anoth­er part. There is a gen­er­al ten­den­cy to move func­tion­al­i­ty up the stack. And… Provided you have a sim­ple enough net­work that that is [?-less] Move pack­ets around, then you’re fine. The equiv­a­lent of up the stack for this is not so much the ASN.1 or the pre­sen­ta­tion lay­er, it’s the pol­i­cy rout­ing. You will most prob­a­bly imple­ment pol­i­cy rout­ing or mobil­i­ty sup­port or this kind of thing as an extra pro­gram which is up the stack, that push­es more infor­ma­tion, addi­tion­al head­ers, or some­thing like that, and moves infor­ma­tion around [in?] controls.

Malamud: Give me an exam­ple of that. 

Huitema: Well a very basic exam­ple, sup­pose you want to do provider selec­tion. The way to do provider selec­tion in SIP is very sim­ple. You have one address which is some kind of an any­cast address which is matched by any router which is with­in a cer­tain pre­fix. So, if you do provider selec­tion, you just send your pack­et to that router, any of these routers. And the first router in the provider domain will take that, peel off the first head­er, and go to the next head­er which says where it real­ly goes. And that way you will have imple­ment­ed the selec­tion of your ini­tial provider. Without hav­ing to mod­i­fy your rout­ing tables, with­out hav­ing to mod­i­fy your pro­to­cols, and with good effi­cien­cy because only one router will have to peel of the head­er and do the thing.

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 & Associates, and by Sun Microsystems. 

Malamud: Let’s get back to this top of the protest pro­to­col stack issue. The TCP/IP suite has been a bit sparse up there. We have a remote pro­ce­dure call mech­a­nism incor­po­rat­ed by ref­er­ence from Sun’s NFS. But there isn’t a real­ly well-developed set of ser­vices. Do we need those ser­vices between the appli­ca­tion and the low­er lev­els of the net­work? Or is that just added com­plex­i­ty that does­n’t help?

Huitema: Oh, the low­er lev­els of the net­work don’t have to know what you are doing an RPC or that you are doing— They specif­i­cal­ly don’t have to know whether you are using say Sun RPC, or [OSFTC?] or ASN.1 or what­ev­er. And it’s good [?] It’s good that peo­ple which want to try a new RPC can do so. For the Internet side, yes we have a prob­lem that we don’t have one com­mon tech­nol­o­gy that can be used to devel­op RPCs. If you look at the suc­cess­ful appli­ca­tions of the Internet, they are pret­ty much done and ad hoc fash­ion. Things like SNMP, or MIME, which is [?] encod­ings. But say, you don’t have one big design. 

Big design is some­thing you do in research, as what we try to do now. But that’s a bit… If you look at it— One of the rea­sons why you don’t have that is that it costs a lot to devel­op an RPC suite. And if you look at the ASN.1 com­pil­er we devel­oped, we have incor­po­rat­ed some­thing like ten man-years [for the net?]. So it’s not quite the typ­i­cal thing that you find in the Internet, yeah. A ver­sion which is done in six months by a set of vol­un­teers and which is giv­en to the com­mu­ni­ty. You can give a six months’ effort to the com­mu­ni­ty. Giving a ten man-year effort to the com­mu­ni­ty is a bit more complex.

Malamud: So you wan­na sell it.

Huitema: Yes, you want to sell it. And so the oth­er thing is that his­tor­i­cal­ly the peo­ple which have done RPC, have done RPC you know, to sell it. So each provider sells its own RPC. It has its own lan­guage. What we need to have is some­thing like a com­mon lan­guage which comes with dif­fer­ent com­pil­ers. You can buy your C com­pil­er by Microsoft, by Borland, by a num­ber of oth­ers. And ide­al­ly what you would need to have is an RPC lan­guage that you can buy from sev­er­al providers. The clos­est thing we to that is the ASN.1 com­pil­er. But ASN.1 is a lan­guage which has been spec­i­fied by a thir­ty par­ty, ISO, and for which you can buy com­pil­ers by some­thing like four or five dif­fer­ent sources. The prob­lem is it’s a bit on the com­plex side.

Malamud: But is that some­thing we should be insist­ing that our appli­ca­tions in the Internet begin using? Do we need to start spec­i­fy­ing that as a stan­dard, or just make it available?

Huitema: Well many appli­ca­tions already use it. SNMP does use it, for one thing. WAIS uses it. Eh…let me quote anoth­er one. LDAP also uses it for X.500. So it’s used by already a num­ber of appli­ca­tions. It might be a good idea to try to push the tech­nol­o­gy. Or specif­i­cal­ly what might be a good idea would be to try to put a sim­ple pro­file of ASN.1, some­thing which is easy to imple­ment, get rid of much of the vari­a­tions, com­plex­i­ty, which are just to accom­mo­date a num­ber of needs of var­i­ous OSI pro­to­cols. You’ll have some­thing sim­ple. That could be the basis for doing an appli­ca­tion devel­op­ment framework.

Malamud: One of the areas you’ve done a lot of work in is nam­ing ser­vices. You imple­ment­ed X.500, you have one of the more pop­u­lar imple­men­ta­tions of that. Do you think we need to begin mov­ing the Internet from reliance on just the Domain Name System and mov­ing it into an X.500-based environment?

Huitema: Well X.500 and the Domain Name System are not quite cov­er­ing the same needs.

Malamud: Well what are the dif­fer­ences between the two?

Huitema: I would say that X.500 has a mod­el which is con­cep­tu­al­ly very sim­ple. That’s his idea that an entry has a set of attrib­ut­es, and that you just pick a cou­ple of these attrib­ut­es to devel­op a name and you orga­nize them hier­ar­chi­cal­ly. But this sim­plic­i­ty is aber­rant. What you have then is an open com­plex­i­ty as com­plex as SNMP. The same way SNMP has a very large num­ber of [meat?], X.500 has a large num­ber of attrib­ut­es. So imple­ment­ing a full X.500 serv­er means that you have to sup­port all these attrib­ut­es, all the search rules asso­ci­at­ed with the attrib­ut­es. And that can get quite large. While that’s not undoable, we could imag­ine that you will spe­cial­ize in a program.

The oth­er thing which was dif­fi­cult with X.500 is that it had to run on the top of the seven-layer stack. So I’ve been [affordin] the Internet to pro­vide sim­pler spec­i­fi­ca­tions. The LDAP effort uses X.500 over TCP with­out pre­sen­ta­tion and ses­sion lay­ers, with­out even the RS? lay­er. That may be a way to go. So that the pro­to­col spec­i­fi­ca­tion is better. 

You still have two prob­lems with X.500. It uses basi­cal­ly the same kind of hier­ar­chi­cal nav­i­ga­tion that DNS uses. But the DNS is sim­ple. You can put up a DNS key on your screen. You can remem­ber it, peo­ple put it on their busi­ness cards. It’s no prob­lem. If you were to put your X.500 name on your busi­ness card, your busi­ness card will be quite larg­er than what it is now. And so the X.500 mod­el is that you don’t real­ly have a name, you have a set of servers which enables you to do [dis—] search­es. And these [?] search­es have one big prob­lem. It’s that you are only autho­rized to search accord­ing to hier­ar­chi­cal rules. So if you could have some­thing like X.500 with­out the hier­ar­chi­cal rules, and autho­riz­ing entries to be locat­ed any­where in the Internet, well that might be a very pow­er­ful technology. 

Malamud: But if we did that we would need larg­er wal­lets to hold our larg­er busi­ness cards.

Huitema: No, you won’t need to. Basically you will need to present your address on your busi­ness card. What is on the busi­ness card already would suf­fice. It would be carlmalamud@…uh…what’s the name of your com­pa­ny, by the way?

Malamud: The Internet Multicasting Corporation.

Huitema: Oh yeah. So you would read ​“Carl Malamud”, you will tap at the Internet Multicasting Corporation, at Reston, Virginia, and that would be it. So you won’t need any­thing else. But indeed, you will have a pow­er­ful search going on to locate to who is hold­ing infor­ma­tion on com­pa­nies in Virginia, or who is hold­ing infor­ma­tion on com­pa­nies deal­ing with mul­ti­cast, and to enter progress in the tree, look at that. And that’s not quite what X.500 does today. So I believe that there is a pos­si­bil­i­ty to do a merge between the X.500 tech­nol­o­gy, the algo­rithms which are devel­oped in the [wheeze++] group, and end up with a very pow­er­ful nameser— Well, not name­serv­er. I would say a [wide pitch] service.

Malamud: Now how do you do that? Do you go to the CCITT and sub­mit some changes, or do you just grab their stan­dards and uni­lat­er­al­ly mod­i­fy them to do some­thing different?

Huitema: Yeah, it depends what you want to do. If you want to pre­tend you’re doing X.500, you have to go to CCITT. If you want to do a [wide patch] ser­vice for the Internet, you can say that you have tak­en X.500 as one of the pos­si­ble inputs, and then you go on defin­ing your own oper­a­tion. I think the lat­ter is a bet­ter way to proceed.

Malamud: Is there an advan­tage in hav­ing that offi­cial CCITT stamp on a standard?

Huitema: Well CCITT— It has an advan­tage to be CCITT—compatible, the advan­tage that you can speak with PTT-pro­vid­ed ser­vices. But apart from that are not that many advantages.

Malamud: Would the PTTs ever start adopt­ing Internet services?

Huitema: Well some already do. They may. 

Malamud: But do you see rea­sons that the Internet process, for exam­ple, should either merge or get endorsed by offi­cial groups like the CCITT? Is there a ben­e­fit to the Internet in doing that?

Huitema: Oh that’s a loaded ques­tion. As an IAB—

Malamud: Of course it’s a loaded question.

Huitema: As an IAB mem­ber I don’t know if I should respond to that. I mean— Do you want the IAB offi­cial to say, ​“Well, we want all the world’s peo­ple to be friends and have a nice peri­od of coop­er­a­tion, indeed?”

Malamud: Well there you have it. We’ve been speak­ing with Christian Huitema, a mem­ber of the IAB, an offi­cial mem­ber of the IAB. Thanks for being on Geek of the Week.

Huitema: Thank you.

Malamud: This has Geek of the Week, brought to you by Sun Microsystems and by O’Reilly & Associates. To pur­chase an audio cas­sette or audio CD of this pro­gram, send elec­tron­ic mail to mail to radio@​ora.​com.

Internet Talk Radio. The medi­um is the message.