Routing Algorithms for DHTs: Some Open Questions

Even though they were introduced only a few years ago, peer-to-peer (P2P) filesharing systems are now one of the most popular Internet applications and have become a major source of Internet traffic. Thus, it is extremely important that these systems be scalable. Unfortunately, the initial designs for P2P systems have significant scaling problems; for example, Napster has a centralized directory service, and Gnutella employs a flooding-based search mechanism that is not suitable for large systems. In response to these scaling problems, several research groups have (independently) proposed a new generation of scalable P2P systems that support a distributed hash table (DHT) functionality; among them are Tapestry [15], Pastry [6], Chord [14], and ContentAddressable Networks (CAN) [10]. In these systems, which we will call DHTs, files are associated with a key (produced, for instance, by hashing the file name) and each node in the system is responsible for storing a certain range of keys. There is one basic operation in these DHT systems, lookup(key), which returns the identity (e.g., the IP address) of the node storing the object with that key. This operation allows nodes to put and get files based on their key, thereby supporting the hash-table-like interface.1 This DHT functionality has proved to be a useful substrate for large distributed systems; a number of projects are proposing to build Internet-scale facilities layered above DHTs, including distributed file systems [5, 7, 4], application-layer multicast [11, 16], event notification services [3, 1], and chat services [2]. With so many applications being developed in so short a time, we expect the DHT functionality to become an integral part of the future P2P landscape. The core of these DHT systems is the routing al-