Carl Malamud: Internet Talk Radio, flame of the Internet. This is Geek of the Week and we’re talking today with Bob Hinton, who’s manager of Internet engineering at Sun Microsystems. That’s the group that comes up with the TCP/IP code that’s in your SPARCstation. He’s also the Area Director of routing for the Internet Engineering Steering Group. and he co-chairs the SIP effort, the Simple Internet Protocol. SIP is one of the key contenders as the candidate for the IP next generation, IPng as it’s being called. Welcome to Geek of the Week, Bob.
Bob Hinden: Hi Carl. Thank you.
Malamud: Maybe we could start by you can tell us a little bit about what SIP is and maybe how that differs from the current Internet protocol.
Hinden: Well SIP is really designed to be a step evolution from the current IP protocol. The notion behind it is to take a look at what needs improvement, and the thing that started all of this was having a protocol which could support a larger Internet, had larger addresses, had better routing facilities, and take a look at what IP had, what worked, what didn’t work, and do something which improves it a little bit but doesn’t take any radical steps. It sort of tries to take a low-risk backwards compatibility step.
Malamud: So, you just take…we need bigger addresses, you just double the address size and we’re done. What’s…what’s the big deal?
Hinden: I guess it— Maybe that’s what we thought too. There’s a lot of subtle issues that have to be dealt with. We’ve sort of taken some things out of the header, restructured things a bit, moved some of the things that aren’t used very much to optional headers to try to increase the performance. We’ve ended up with something which while it currently has addresses which are twice as large, the overall header’s only four bytes longer than IP, so it’s still relatively small and relatively simple.
Malamud: Well let’s go through a couple of those issues. You say the addresses are twice as large but the Internet is doubling every year. Did you just buy us an extra year by doubling the headers?
Hinden: Ah, that’s a good question. When you double the size of the addresses you don’t double the number of addresses, you multiply them together. Someone made a simple observation that the current— You know, we have a current system which will probably scale to…I guess we have total of a couple million network numbers. And you could probably have many more than that hosts. If you could allocate the addresses completely flatly, SIP would allow you to have four billion of the current Internets. So another way to say this is that every person on Earth today could have their own Internet as big as the current Internet technology will grow.
Malamud: Or alternatively there’s enough room in the SIP address space for every proton in the universe, I believe, or some number of the universe of that size.
Hinden: Well, the universe is a pretty big place. But certainly—
Malamud: Why do we need such a big address space?
Hinden: We need a big address space for two reasons. One is that there’s going to be a lot of things we need to address. The sort of a common notion that everywhere there’s a telephone today there’ll be a network. And the only thing that— That estimate might be too small. But in some sense anywhere there might be a computer you might want to be able to address it.
You also need bigger addresses because you can’t utilize them optimally so you need to allow room for creating hierarchies and administrative structure.
Malamud: And so we don’t need an address space big enough to have one address for every person, we need more room than that in order to provide that structure?
Hinden: We probably need an address space which is big enough that every person can have a number of computers. And exactly what that number is no one knows, but we need something that will provide enough growth in the foreseeable future. Sort of the question that comes up is do we need enough address space to…that we could never run out in any circumstances. And that’s… I believe in building things which run over in the domain which we can sort of understand and foresee but it’s real hard to predict what things will be like a long way in the future if the industry and the technology changes very quickly. If we look back ten or twenty years, you wouldn’t’ve imagined we’d be where we are today. So I suspect we can’t really imagine what it’s going to be like twenty years from now. So I think if we design a solution which looks like it can be can scale as far as we can reasonably imagine today I think that’s adequate.
It’s also an issue of solutions which tend to work well in today’s environment that scale are much better than solutions which build in a lot of inefficiency because they might be needed later. Those tend not to solve people’s problems very well.
Malamud: So you have a simple Internet protocol list, as you call it. But we’re asking more of our network players these days. For example, Steve Deering, your co-chair on the SIP Working Group is the father of multi-casting. By removing some of that functionality and simplifying things are you going to make it hard to support multicasting, for example?
Hinden: No, in fact just the opposite. We’re taking the things we think are important, like multicast in particular, other things like mobility and autoconfiguration, and we’re building those in from the start. There’s a lot of work going on to essentially add those things to the existing protocols, the existing IP version 4 we have now today, but when there’s a large installed base, you have to design what— You can’t change the protocol in ways that’re incompatible. When you get a chance to do something which there isn’t a big installed base, and if you can provide those things at the beginning, then you can require that all implementations do them from the start. So by deploying in particular SIP, we believe that we’ll be building a base that all implementations will do multicast, all implementations will be easy to configure, they’ll have a provision for supporting real-time traffic with flows. You know, there is some opportunity here to do the things that need to get done.
Malamud: Well how for example do you support autoconfiguration. What is it in SIP that makes it easy to do that kind of thing?
Hinden: Well, I think the biggest thing is again we get to, because it’s an area that IP version 4 doesn’t do, we get to define some new control protocol messages which allow host and routers to exchange the right information to do that.
Malamud: What about support for real-time data, now that we’re seeing video and other isochronous data on the network. How does SIP provide that support?
Hinden: Well SIP essentially, without anything new, makes it work as well as what IP version 4 does today. SIP has a placeholder for real-time traffic called up a flow labeler, flow identifier, which is intended to allow—with some setup or negotiation allows state information to be put into a router to either identify the traffic or to associate it with a particular flow so we can provide some guarantees of service and fair queuing. This is an area which is more in the research community but we’re confident enough in the idea that we think it’s important to allocate some space in the SIP header to allow that information to be used later as the work gets done. So we think it’s probably the answer—you know, there will be a solution based around flows that we’re providing the facility to add that without having to change the protocol.
Malamud: That’s one research area that you’ve looked at and said that looks fruitful and we’re gonna make room for that. Are there research areas you’ve looked at and said well, we don’t think that’s going far enough and we’re going to explicitly ignore this?
Hinden: Well, we’ve had the philosophy—and I give Steve Deering quite a lot of credit, which is he’s resisted putting things in that there aren’t very clear uses for or we have a good understanding of how they work. Um—
Malamud: What’s an example of that kind of thing that you’ve resisted?
Hinden: One example is there’s a field in IP called Time To Live, which is essentially the number of hops or routers that a particular package can go through. It’s used for loop detection. So if there’s a loop, the packet won’t go around the loop forever. When Steve was first designing SIP, people said, “Does that field need to be bigger?” And currently it’s eight bits and you can have 256 hops, which in the current Internet is by a factor of…probably in most cases several orders of magnitude but even in the most extreme cases probably factor of four.
Malamud: Yeah, twenty or thirty hops is really the outside potential diameter and that’s even…that’s really strange.
Hinden: Yes. But there were some comments that well gee, let’s make the field bigger, let’s make it so it could be sixteen bits or sixty-four thousand hops, and Steve and some of the other SIP developers resisted doing that because we just don’t think that’s… While yes, it would make the protocol more general, we don’t you can build Internet works where the traffic has to go for tens of thousands of hops. That’s just not gonna work. So we think having some constraints on the protocol that will constrain the topology of the network is in fact a good thing.
In some sense keeping the address size to sixty-four bits is also a similar thing. If you don’t understand the— If you don’t have absolute answers to all of the questions, one approach is to make things so general. You could have either extremely large addresses or variable-size addresses. And that’s sort of nice because it keeps it open-ended but you pay a price in performance and in table size. And if you can come up with a more limited more limited size address that still addresses everything you can reasonably imagine, I think it’s a better engineering solutions. So a lot of areas we’ve resisted making things general because just to make them general there had to be a real reason. You know, if someone could come and point out reasonable scenarios why what is there won’t work, or isn’t scalable enough, doesn’t have enough lifetime, we’re real open to change but there has to be pretty concrete reasons.
Malamud: The Internet has moved beyond being a research network. It’s very much an operational environment. Many of us really depend on that. I know your business depends on it and certainly mine is absolutely dependent on the Internet working. How are we gonna do a transition to SIP in a way that keeps the current world working?
Hinden: Well, one of my major interests in working in the IPng arena, and I’ve been involved with some other proposals which have sort of evolved into the current SIP group, is to do things that have backwards compatibility, make transition easy.
Malamud: How do you make IP version 4 and SIP worlds talk to each other? Or do you do that? I mean, do you just say, “We’re going to transition this network on a certain day,” or…
Hinden: No. We’ve built as many things in that are…where there was no reason to change them. Like the way do fragment packets. We’ve used the same semantics, so it’s easy to map from one to the other. The areas that are obviously different are addresses, and we have a transition scheme where for the period of time until IP version 4 addresses are no longer unique globally in the eco—the word we tend to use—that we will embed one of those in a SIP address—low order thirty-two bits, and this allows IP version 4 host to essentially address SIP hosts it’s a relatively easy mapping to map between them, so we’ve actually designed and implemented code that can translate from one protocol to the other.
Malamud: So the address of a SIP host is, if you take off the high thirty-two bits and there’s some prefix, what’s left is actually a valid IP address.
Hinden: Yes. And it’s our intent that until the world decides that IP addresses are no longer unique everywhere, essentially when they would have to get reused, that all SIP hosts that wanted to communicate with IP version 4 hosts would essentially be assigned an IP address.
Hinden: I guess the way I think about it is that I don’t want to require things to have software upgrades if they don’t need the functionality. So that…I mean computers, they don’t wear out but there comes a point where you throw them away. Or you know, you replace them for other reasons—the maintenance cost gets too high. When you put in a new computer with new software, it should come with a new protocol. But we don’t think there’s a need to force every host who doesn’t need to talk over the global Internet to do a software upgrade.
Malamud: So the easiest part of the transition is while the IP space is still globally unique.
Hinden: Yes. This gets a lot harder if we haven’t deployed the new protocol before we run out of addresses.
Malamud: How far along are you now?
Hinden: Well, I think we’re pretty far along. The thing… Maybe what this comes down to in all the different choices is the amount of risk associated with each proposal. I think SIP has the advantage that it’s real similar to IP. If you can understand the current IP you can understand SIP real clearly. It’s real simple. It has some new stuff in it but the basic operation is really the same ideas. A lot of the elements in the headers are exactly the same. And we have…I guess about seven or eight different implementations now. Most people have found that it’s really very easy to take their existing code and to add SIP to it. And it—
Malamud: And is this the case for for machines that maybe aren’t as network-aware as a SPARCstation? Can you do this on DOS for example?
Hinden: Yes. We have implementations on DOS and Windows. There’s VMS. There’s a Mac implementation. There’s several flavors of Unix.
Malamud: And have you tested these against each other? Do they actually work?
Hinden: Yes. We had what we called a SIP interoperability event before the previous IETF meeting. We did a demo then. We did a demo at this IETF meeting. So we’ve actually run the implementations against each other.
One of the real nice things about SIP is that because it uses IP version 4, it actually encapsulates your tunnels as part of its normal mechanism. You don’t need to deploy any new infrastructure in order to test it. So it means we get to test it over the Internet as normal operation. It’s sort of— We don’t have to put in special things to test it, it’s normal mode is to run this way. So it’s been real easy to plug machines in and do the testing. You don’t have to fool around with deploying lots of new things in order to set up the communication paths.
Malamud: You and several others at Sun are investing a considerable amount of time working on this. Why does it make sense for Sun to do this instead of waiting for the standards to come out and then just implementing them?
Hinden: Well, I— My view on this is that in this industry—I call it the the internetwork industry, communication industry—you know, it’s not a place where you win by having—or are successful by having proprietary solutions. You win— You become— You want to become a leader in the technology and you do it by doing things and having lots of other people use them. I think the areas where—I’ve been at Sun for I guess…it’ll be eighteen months in a little while. So I had been had been a Sun customer before I worked there. And I think the areas where Sun has had great success is where Sun has developed technology and then worked with other companies and seen it deployed on a very large scale, and not made any claims of…not licensed it, just make code and specs freely available. And I think in the Internet world it’s the same thing. You are successful by getting other people to use the same protocols, or the same technology. And if you then also deliver good products around them, you will be successful. So it’s not an area where you want to do things and don’t tell anyone what you’ve done, you want to be as cooperative with other people. So Sun’s interest in this is advancing the technology and providing a solution which we think is best for our customer base, of course. I mean, there’s certainly self interest in this. But we would like to see the IPng process end up with a solution which we think provides good solutions to our customers.
Malamud: You say the key is an open solution, everyone can implement it. It would seem to me the logical thing to do would be go and get the international standard, CLNP—the Connectionless Network Protocol which is already widely deployed around the world, and just use that. Why aren’t you using the ISO standard?
Hinden: Well that’s a good question. That’s the question the Internet community asked. And I gave this quite a lot of thought, and the problem with that is that I think some of the common assumptions that it’s widely deployed and it’s all done aren’t quite right. There’s a lotta details that aren’t done and all of this stuff is in the details. It’s not just the main protocol, it’s all the control protocols and the routing and the implementations and the testing.
Malamud: Well what kind of details are missing in the…in either the CLNP coming out of ISO or the modified version known as TUBA that the Internet community is considering as a possible candidate?
Hinden: Well, where I see the problems—this isn’t a direct answer your question—but where I see the problem is that CLNP is really IP five to ten years ago. It’s…you know, it’s been sort of slow in coming but there’s noth— It has larger addresses but everything else is approximately the same. It’s bigger but it provides about the same functionality.
And my concern, besides— Well I guess two concerns. One is that there is there is no, at least in my opinion, reasonable transition strategy that makes it easy to deploy and makes it easy to operate with the existing IP version 4 hosts. But the other problem is that I think if the Internet community adopts this the Internet is going to spend the next five years redoing all of the things that have been done for IP version 4, as opposed to spending five years moving the technology forward.
Malamud: So it’s it’s missing multicast and flow controls, for example, or autoconfiguration, or—
Hinden: It’s missing multicast, it has two routing protocols. IP version 4 has sometimes more than we can count. There isn’t much experience with it. There’s— Maybe this is the final thing, there really aren’t very many users who use CLNP in an operational mode.
Malamud: Well ISO has expressed its willingness to liaise with the Internet Engineering Task Force and come up with a combined thing. Now wouldn’t be a great political win if we could combine ISO and the IETF together into one super open system solution? Isn’t it worth giving up some of these flow control features in order to have this nice rapproachement?
Hinden: Well, I think that would be…for some value of “nice,” but I don’t want to sacrifice the existing base to do that. I think TCP/IP has essentially won in the marketplace. CLNP OSI has been…the market has had plenty of time to adopt it and to deploy it, and it hasn’t happened. I think there’s— I don’t think I’m the only one with this opinion, but I think that if the Internet does not choose the IPng solution, which is based on CLNP, my prediction is that CLNP doesn’t have much of a life left to it. I think this is the last big opportunity for the community which is pushing on CLNP.
And again, my view is that I would hate to see the Internet spend five years redoing all of the things that have made TCP/IP work over a large scale. You know, there’s solutions for large networks, there’s solutions for small networks, a lot of varied implementations, a lot of experience, a lot of sort of training and books and…a lot of people investment, I guess, not just software. Vendors are real good at writing software. But a lot of people understand it. And I would hate to see us spend a long time redoing all that and then at the end of the time be technically—the functionality be at the same place we are now, except we could have a bigger system. I think the world is not going to wait that period of five years. There are other things happening in the world that people will come up with other solutions and it would essentially obsolete this technology.
The area that I think is most interesting is the things that Apple and General Magic and people are talking about doing around cable TV systems who’re essentially putting networks and computers in everyone’s houses. And I suspect those are going to be the areas where the growth comes from. The current sort of commercial market of workstations and PCs and stuff is certainly gonna grow for a long time but there’s likely to be another big step function as people build very low-cost, very powerful computers that everyone gets—go into people’s houses, and those are all going to be networked. If we can provide an Internet solution that works in that arena, then I think everything will be will have sort of a unified, global internetwork that spans supercomputers down to hand-held devices. If we can’t provide a solution that the people building those products need, then they’ll do their own. And we’ll end up with another set of incompatible things. So I think our opportunity is to provide something which will scale not only in size but also into the kind of applications and the environments that we see the world going to.
Malamud: You have two functions in the IETF. On the one hand you’re an advocate; you’re the co-chair of the SIP group. You’re also a member of the Internet Engineering Steering Group, which will be making the decision about IPng. Does it make sense to have someone who’s actually going to make the decision also be involved in the work, or should you be somehow more neutral and kind of wait for the results to be presented to you?
Hinden: Well, it’s an interesting question. If you take it to extreme, then anyone who has any opinion or any knowledge shouldn’t be involved in the decision. And that clearly doesn’t work because you want to…this is not you know, picking A or B. All of the solutions are essentially optimized for different things, and the outcome—how well it works, will be…you know, they will do different things, they will have different effects. And you clearly want to have a very informed decision.
On the other hand you certainly don’t want— It’s important that when the decision is made, it’s important that it not be viewed from the outside as an inside job, as you know a backdoor solution and it favored insiders. So it’s very important that it be open and fair, and the process that made it be visible so it’s essentially beyond reproach. And even then that there be an appeals process. And in that sense it’s probably reasonable for the people who are obvious advocates of particular solutions to step aside from the decisionmaking process.
Malamud: Are you ready to decide it? Could you in good conscience say, “Okay, SIP is it, we’re ready to go.”
Hinden: Yeah, I’ve decided. I mean, I’m putting my energy working with other people chairing the group. I’m not doing this for fun. It’s a lot of work. I have other things to do. It’s not exactly my real job. But I think it’s important. I think it’s important for…you know, essentially for the Internet, for the country, for the world. I think it’s also important for the company I work for. I think Sun Microsystems has a stake in the outcome. We have a customer base, and we I think want solutions that work best in that environment.
I see sort of a couple of possible outcomes here. One is that the work gets done and the IESG picks one of the four. I mean in some sense it could be done at any time. There’s always going to be… At any point there’ll be a certain amount of information and if you waited there would be more. But if you take that philosophy then you could wait forever.
Another approach is that there’ll never be a decision. That the four contenders will go off and they will be deployed and the world will see four more protocols. And—
Malamud: Is that all bad?
Hinden: Um, I think it’s…
Malamud: I mean we have X.400 and 822 mail and they work, sort of.
Hinden: Well, and we have AppleTalk and we have IP and we have IPX, and…there’s a long list. I think that there’s a lot of benefit in having one major Internet layer protocol [crosstalk] that works on a global scale.
Malamud: Is the global connectivity, is that the key goal of doing that? Is global connectivity the reason we want one [crosstalk]protocol?
Hinden: Yes. We want one protocol because it makes it so that everyone can talk with each other easily, as opposed to all protocols having to be implemented.
Malamud: Well there you have it. This has been Geek of the Week and we’ve been speaking with Bob Hinden. Thanks a lot Bob.
This is Internet Talk Radio, flame of the Internet. You’ve been listening to Geek of the Week. You may copy this program to any medium, and change the encoding, but may not alter the data or sell the contents. To purchase an audio cassette of this program, send mail to firstname.lastname@example.org.
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, publishers of the Global Network Navigator, your online hypertext magazine. For more information, send mail to email@example.com. Network connectivity for the Internet Multicasting Service is provided by MFS DataNet and by UUNET Technologies.
Executive producer for Geek of the Week is Martin Lucas. Production Manager is James Roland. Rick Dunbar and Curtis Generous are the sysadmins. This is Carl Malamud for the Internet Multicasting Service, town crier to the global village.