In this paper, we address the question: what should the architecture be for deploying advanced distributed services across the Internet? We argue for a programmable naming abstraction called Active Names that combines location and transport of resources, provides end-to-end programmability, supports composibility of different extensions, and supports mobile location-independent code.
This approach is motivated both by efforts to extend the current Internet Domain Naming System, DNS [39], and by other recent efforts to interpose services between clients and servers. Historically, DNS was developed to support a simple one-to-one mapping from machine names to IP addresses, but today Internet services identified by a single name are often distributed across many machines. This has lead researchers to enhance applications [8], routers [15], and DNS [34] to support more complex mappings. More broadly, academic and industrial researchers have proposed a bewildering array of new services for mediating between clients and servers, including dynamic redistribution of replicas over the wide area [50], compression and distillation of multimedia content [4,23], proxy cache extensions such as support for hit counting and dynamic content [12,49], client customization of web content [55], network address translators (NATs) [21], packet delivery services for mobile hosts [14], and so forth.
One approach to deploying such extensions would be to develop a new protocol that closely coordinates browsers, proxies, servers, and the name system to support these extensions. But such a system would be complex and difficult to modify, given the ongoing demand for improvements to existing services and the development of new services. To address this need for rapid deployment and extensibility of Internet services, a variety of proposals have been made to support ``active'' (dynamically migratable) computation inside the network, leveraging machine-independent languages such as Java [24]. Example ``active'' networking proposals include Active Networks [54], Active Caches [12], Active Services [4], RentAServer [50], and others. In addition, a number of proposals have been made for single point (non-migratable) extension code, such as HTTP front ends [23], NATs, and router-based load balancing [15]. These approaches have varied in where in the protocol stack the computation is applied - from packet filtering to connection filtering to transparent proxies to giving up on transparency and making the application responsible for everything.
If active computation can be applied anywhere in the protocol stack, where in the protocol stack should it be done? In this paper, we argue for active naming as a unifying principle to efficiently support the composibility of a wide variety of new services while providing correct end-to-end behavior. Our Active Names system maps a name to a chain of mobile programs responsible for locating the remote service and transporting its response to the destination. A service owning a portion of the namespace has complete control over which protocols are used to access the service along with control over where in the network those protocols run. Similarly, a client machine can use Active Names to customize how services are presented to the user. For example, when a mobile user with a small screen and expensive wireless connection in Europe refers to ``cnn.com'', the user probably wants to go to a different replica, fetch different data, and transform that data differently than a user in the United States with a large screen and T3 connection.
To illustrate our approach, we have constructed a prototype Active Naming system and have used it to implement and study a set of complex distributed services including (i) replica selection based on end-to-end performance observations, (ii) image retrieval protocols that migrate distillation code dynamically around the network to optimize client response time, and (iii) a cache enhanced to support both client customization and caching of active content. These experiments demonstrate up to five-fold performance improvements for end-users of our system relative to protocols in widespread use today.
Of course, no performance improvement can ``prove'' that extensibility is a good idea; any algorithm that demonstrates large gains in an extensible system could, in principle, be deployed as part of a new, non-extensible protocol. Instead of trying to resolve the argument of whether extensibility is desirable, we begin with the premise that it is, and then focus on how best to support advanced, extensible and high performance Internet services. First, our experiments show that our Active Names system is ``complete'' in that a wide variety of extensions can be easily implemented in our system, and that these extensions can significantly improve performance compared to existing protocols. Second, our experiments suggest that high performance demands a combination of three features found together in Active Names but only individually in other systems: location-independent program execution, efficient composibility of extensions, and end-to-end semantics.
One might argue that a significant drawback to Active Names is that we modify the existing naming abstraction. Traditionally, Internet name resolution returns an IP address; the application uses the IP address to establish a socket connection to the end host. With Active Names, name resolution and retrieval of the specified resource is a single step that combines location and transport. A similar debate on the structure of naming has occurred in file systems and databases; the conclusion has been that it is dangerous to separate naming from use [43]. Superficially, it can seem simpler to have the naming system return an ID (IP address, inode number, or physical memory location) that is then used by the system to access the named resource. However, if the ID is visible to applications, the ID becomes hard state, something that must continue to be supported by the system even after the binding has changed or the reference has become invalid. Of course, to support legacy applications, the change to support unified naming and transport usually can be hidden inside an application-specific proxy; for example, web browsers can be configured to connect to a proxy that mediates the browser's interaction with the network.
The remainder of this paper covers these issues in more detail. We first discuss the strengths and weaknesses of Active Names by contrasting it to two popular alternatives. We next outline the architecture of our system; we then describe several applications we have built on top of our system. We conclude with related work and a summary of our contributions.