DONA's Implications

A recent publication proposed a new architecture called DONA (Data Oriented Network Architecture.) The publication argues that users have several expectations that the Internet does not efficiently fulfill.

First, users expect that naming of resources be persistent. They don't like the disappointing 404 indicating that a resource has been moved, or that content has been re-hosted elsewhere. To remedy this problem, HTTP has the redirect functionality. However, this may not be the most efficient way to do this.

Users also rely on the availability of data, in that their data must be there, and be quickly available. A single server is not always adequate to supply a resource, when that resource is extremely popular. For that reason, CDNs and self-scalable file-sharing protocols like BitTorrent have been created. The Internet was designed to associate data to a location, and this is not consistent with such systems.

Third, users want their data to be authentic; unmodified, and having come from a reliable source. Today this is done by securing a channel, allowing two hosts to communicate securely.

DONA improves how the Internet achieves these goals. It introduces what it calls "flat, self-certifying names". What this means is that names for resources are no longer tied to addresses. Instead, they use principals, which have public/private key pairs, and allow for data authentication. Using these names allow for a resource to be queried independent of the location of the resource. This allows for content to be moved, and to be located in multiple places. In that way, data is persistent, available, and authentic.

Requests for data are routed by name, rather than by host. To facilitate this, there are a number of resolution handlers (RHs), entities that keep track of where data should be routed. This system obviates the need for DNS, speeding up the initial communication process.

With DONA explained, it leaves me with several questions. First is its scalability. The Internet has a large number of resource names; I imagine that the RHs will fill up and take a long time to look up where to route a request for a resource. Secondly, there may be downsides to decoupling a resource from a provider. A resource only need be unique within the provider's list of resources. This reduces the number of names that the Internet must account for. Third, if DONA is to replace the current system, can it be deployed incrementally and seamlessly without affecting the rest of the Internet?