ICANN Considered Boring

Last week was the World Summit on the Information Society in Tunisia (“the land of civilization, culture and enlightened thinking”, according to the official Web page). It has been reported that the conference was supposed to be about narrowing the digital divide. Croquet architect and all-around Computer God Alan Kay presented a model of the dynabook, er, $100 laptop to UN Secretary General Kofi Annan, while his buddy Nicholas Negroponte presented one to the Pope. Picture here. (And there was much amusement in the Stearns household when we realized that this made me one degree of separation from Annan and two from the Pope.) A lot of world leaders were taking this theme very seriously, but I hear the conference turned out to be all about US control over the ICANN system for Internet domain names. Even more leaders were taking seriously this idea, as argued by countries like China and Iran, that the world can’t accept ICANN to be under the control of a rogue state that practices state censorship, executions, unilateral invasion, torture, use of chemical weapons, etc. President Bush chose not to attend, in order to that he might visit Asia and criticize China regarding human rights.

The ICANN flap is interesting in several ways. There’s the timely main story in the news about the relationship between the US and the rest of the world. Then there’s the timeless backstory about the idea that progress is not achieved by consensus or committee, but by someone actually doing something that works. That’s what the US did. We only got into trouble because it was successful. I’m fascinated by this idea lately as it relates to development within Croquet. It’s hard for people who feel excluded to do other than to demand sharing, and particularly hard for them to realize that nobody “anointed” the folks who are producing the stuff they want to be shared. People do stuff and it works. Then other people want it. The trick, if it were possible to optimize such things, would be to share when things aren’t yet working so that others might join in the creative fun. But too many cooks and the management cost of such “optimization” can easily spoil the soup. It’s a dicey thing. I know, because I’m on both sides of the problem right now.

But the most noteworthy thing of all, to my mind, is that the ICANN flap is all so unecessary. US officials say the current system works just fine, technically, and they’re sort of right, except that the rest of the world says it doesn’t, and they’re right too. But I think there’s a much better way to handle the mapping of addresses, which we’re currently trying to build out in Croquet. Whether we’re the ones to do it or not, there’s no technical reason that the whole thing can’t be done in a way that makes the whole political argument moot.

The Internet itself was designed to route messages to a given address (e.g., 24.240.65.200). The Domain Name System (DNS) sits on top of this and is intended to solve two completely different problems, which don’t really have anything to do with each other, and it does them both suboptimally.

One problem that comes to folks’ minds is that people don’t want to use numbers, so the domain name system provides a mapping from “nice” letterful names like “www.google.com” to digitful addresses like “80.190.192.24”. But of course, this goal was not achieved by DNS. First of all, “www.google.com” doesn’t get you the specific information you want. That’s something horrible like “http://www.google.com/search?hl=en&lr=&client=safari&rls=en&q=domain+name+system&btnG=Search“. Redirecting just the part between the second slash and the third isn’t really going to help. It sucks so bad, that nobody types this stuff in. Either you already have a link somewhere, buried in a page (or email or bookmark) so that you don’t have to see the name or the address, or you search using a language (e.g., English) that doesn’t have anything to do with .com or .edu or .iq or .ch or anybody else. Either way, the name to address mapping provided by DNS is irrelevant on this count.

The other problem is that we all want a stable ”address” or identifier to put in links and such, which does not change over time. When we actually follow such a link, we want to get connected to whatever machine is currently handling such queries, and this can change over time. There are many levels at which this can be done. On the Web, stable Universal Resource Names (URNs) feature another table of indirections, and have struggled to catch on as a replacement for the more volatile Universal Resource Locators (URLs). URLs themselves can get remapped by changing the domain name to machine address mapping in the Domain Name System. But both URN and DNS mappings can change only very slowly. It takes a lot of cooperation by a lot of expensive machines and administrators to control even this slow-to-keep-up mapping. Yet machines go up and down all the time. Geeky guys have to do around frobbing switches and stuff to patch around this.

And of course, it doesn’t even really work. The Internet was intended to have at least a stable fixed IP address for each machine. For a number of reasons (multiplexing of the limited number of addresses, broken ideas about security, Murphy’s law,…) most of us do not have a fixed IP address assigned. So even if I can convince the US to convince ICANN to convince a set of administrators around the world to agree that stearns.com should be mapped to an address that I give them, it won’t work because my laptop is hardly ever at a fixed IP address.

So, if we can find a better way to map from stable identifiers to current locations, then DNS and ICANN would be completely pointless. Here’s what we’re thinking for Croquet, but the idea is general.

Each Croquet World (or Web page, if you like) has a globally unique identifier. You do want, say, administrators to be able to type the thing if they really had to, but you and I are never going to do that, I hope. We’ll follow links (portals, in Croquet) or use search engines, or whatever. (Remember that in Croquet, I can make a copy of a portal and hand it to you. You can carry it around in your pocket and pull it out when you want to use it.) Since we don’t have to type the darn thing, it can be something that is automatically machine generated to be unique across all other identifiers created in the same way by anyone in the World. (If you hand-create your own ID, all bets are off.) Since it’s machine generated, it’s gibberish. No arguments about who controls stearns.com. (Of course, if you really want to put another layer on top, like AOL keywords, you can do that. But of course, no one actually uses AOL keywords anymore. They just don’t matter, and neither should domain names.)

OK, so I give you a globally unique identifier for a World to visit, and you want to go there. Now what? You need to get connected to the machine that will let you participate in the Croquet World coordinated by that machine. (No, it doesn’t really have to be just one machine, but you’re getting ahead of the story.) Note that the identifiers are associated with the virtual World itself (e.g., the content, or collaboration) not the particular machine by which it is accessed, and certainly not the particular Internet address that machine may happen to be using at the moment. So the real problem is getting the connection to this other machine, given the identifier. Having an address as a string (e.g., what DNS provides) isn’t going to be good enough. The address can change. It might be behind a firewall that allows outgoing connections to be formed by the other machine, but rejects random incoming connection requests (e.g, from you). That’s actually the typical case. This paper describes how to do this. Basically, you have an Introducer machine somewhere on a fixed IP address, not behind a firewall, so that you and I can both reach it. In fact, everyone on the Internet can reach it. Everyone who wants to make stuff available will contact the Introducer (e.g., when they start a new World, or when they want to connect to one), thus opening an outbound connection from ourselves to the Introducer. We keep this connection open so that the Introducer can tell us stuff later without our firewall blocking it. When you want to connect to me, your machine tells the Introducer (using your connection). The Introducer makes two responses:

1. The Introducer tells you (over the previously established connection) the connection information (e.g., current address) of the World you want to contact (mine).
2. At the same time, the Introducer tells me (over my previously established connection) the corresponding information about you.

We both then try to initiate a connection to the other. One of these may fail, because of blocking by a firewall, but at least one will be allowed through, because it looks like a response to an outbound request. We keep the first connection that works.

The result is that you and I get directly connected to each other, regardless of the silly little boxes that now populate the net, and neither of us has to administer anything. Not our boxes. Not some DNS server. Nothing. Yes this works. David Reed coded this up and used it during a virtual and real meeting centered in Boston last August. (With Croquet inspired by various versions of a computing model called TeaTime, the event was called the Boston Tea Party.) We’re using this now on both Mac and Windows.

Of course, someone does have to run this Introducer, and it has a lot of connections to keep open! But this can be distributed. As described above, the Introducer has to keep a table where each row is a globally unique identifier, a set of current address information, and an open connection to the object at that GUID (called a socket). To distribute the table, we’ll need a bunch of machines at fixed IP addresses and not behind firewalls. Any institutional machine at a University or company will do, and anyone can play. The demands are light. Folks like you and me contact an Introducer machine (aka node) that we know about, and asks for an appropriate node to hold open a connection with. (Maybe Croquet keeps a small cache of the last few of these that worked, to use for a random choice of who to use next time for that initial contact. But this is a detail.) So we contact who we’re told, and that node holds the row of the table dealing with us. (If we find that the connection fails because that node goes down, there’s no problem. We use one of our contacts to get a new node to register with.) When we tell it later that we want to connect to someone, the node figures out which other node has that connection, and asks it to tell the other guy about us. The whole set of nodes is self coordinating as nodes drop in and out. There’s some math that covers this, which I’ll skip for now.

We have not yet built this distributed part yet, and we won’t until we actually need it (e.g., when our one-node Introducer starts getting overwhelmed). I’ve probably misunderstood and mis-described a bunch of stuff, but I’ll bet anything that there’s a whole bunch of better papers around describing reinventions of the same thing. As network stuff goes, this is pretty tame. But the point is that DNS and ICANN can be packed up. The designers of DNS were wise, and it has worked well, but the composition of the Internet and our use of it have changed. The conditions giving rise to the architecture described here will also change someday. When things change, there’s no need for international consensus or a timetable to replace it. Someone will just quietly build the thing, and then DNS can become irrelevant.