A Dependable Global Location Service using ... - CiteSeerX

A Dependable Global Location Service using Rendezvous on Hierarchic Distributed Hash Tables J. Risson1, S. Qazi1, T. Moors1, A. Harwood2 University of New South Wales, 2University of Melbourne [email protected], [email protected], [email protected], [email protected] 1

Abstract A location service is the part of a naming architecture that maps identifiers to network addresses. Ideally, the identifiers are globally unique, persistent and semantic-free. It has been acknowledged that Distributed Hash Tables (DHTs) enable, for the first time, the use of semantic-free identifiers in massive, global networks. We argue that hierarchy is essential for dependability in massive, geographically distributed DHTs. Existing hierarchic DHTs embed location information in identifiers. Consequently, if identifiers move between DHTs in the hierarchy, then the changes always propagate to the root DHT. This Location Information Plane (LIP) design is the first hierarchic DHT that contains "moves and changes" within the lower layers of the hierarchy. It protects the root DHT using the rendezvous abstraction. We show how it supports global internet telephony networks based on the Session Initiation Protocol (SIP).

1. Introduction A location service maps identifiers to network addresses. It is a key part of emerging name resolution architectures [1, 2]. It is increasingly recognized that the best identifiers for a massive location service are globally unique, persistent and semantic-free [3, 4]. A persistent object identifier does not change when an object moves or is replicated. A semantic-free identifier does not contain information about the organization, domain or set of nodes in which the object is located. Such identifiers are free from the ownership and legal disputes that hamper human-friendly internet names. Distributed Hash Tables (DHTs) make it possible to use semantic-free, flat identifiers in internet-scale name resolution architectures [3, 4]. We argue that hierarchy is important for dependability in massive, globally distributed DHTs. Consider two large internet data centers, each with thousands of nodes that are to participate in a global DHT. There should be strict guarantees that these nodes do not maintain neighbor relationships with distant ephemeral nodes. If one of the sites is isolated from the network, lookups within the site

should proceed without interruption. These dependability properties are only satisfied by hierarchic DHTs. Previously, hierarchic DHTs have been used for content locality, path locality or administrative autonomy [5-10]. The problem is that the leading hierarchic DHTs embed semantics in identifiers. DHT identifiers are commonly chosen from a circular key space, for example [0, 2160-1]. Sometimes the identifier itself determines which DHT in the hierarchy owns it [6]. Sometimes a “ring identifier” indicates the path from the root DHT to the target DHT [5]. Consequently, if an object with a persistent identifier moves between lower layer DHTs, the changes propagate up to the root DHT. By analogy, the DNS root has taught us to minimize the impact of “moves and changes”. This paper presents the first hierarchic DHT design that protects the root DHT from “moves and changes”. If an object moves between two DHTs, then the changes only propagate to the lowest common parent DHT. Such a design is necessary for a dependable, massive, geographically distributed location service that is tolerant of operational “moves and changes”. Section 2 shows that hierarchic DHTs are important for dependability. It outlines the design goals for a global location service and explains the “moves and changes” problem in existing hierarchic DHTs. Section 3 lays out the design of the Location Information Plane (LIP). By using the rendezvous abstraction with semantic-free identifiers, it mitigates the “moves and changes” problem. Section 4 shows how LIP supports internet telephony. Section 5 reviews related work on name resolution, peer-to-peer internet telephony and hierarchic DHTs. Section 6 concludes.

2. Requirements and Scope 2.1. Location Service A location service maps identifiers to addresses. In the Session Initiation Protocol (SIP), the location service provides a mapping from an address-of-record to a contact address, both of which are Uniform Resource Identifiers [2]. In Globe, the location service mapped object handles (Uniform Resource Names) to contact

addresses (Uniform Resource Locators) [1]. Location services here are not geographic databases. A location service is a subset of name resolution. Currently, there is primarily one level of name resolution in the internet: from user-level domain names to IP addresses. Distilling years of research on names, identifiers and addresses, Balakrishnan et al. argued that there should be up to three levels of name resolution: user-level descriptors to service identifiers (SIDs); SIDs to endpoint identifiers (EIDs); and EIDs to IP addresses [4]. Fig. 1 illustrates. User level name

User level name

Application layer Service ID (SID): User/Object mobility

Session layer Endpoint ID (EID): Host/Network mobility

Transport layer IP address Domain Name System

IP address Layered Naming Architecture

Figure 1. Internet Name Resolution [4] Users and objects are best identified by a flat, globally unique, persistent, semantic-free SID [3, 4]. Such identifiers enable objects, tied to hosts and domains in the current internet, to move and replicate across administrative boundaries. They do not change when an object moves or is replicated. Semantic-free identifiers are not humanly readable – they avoid legal disputes over ownership. As a result, SIDs should be chosen from flat, unstructured namespaces. DHTs have been proposed for the resolution of SIDs because “DHTs allow us, for the first time, to contemplate using flat namespaces” in internet-scale architectures [4]. EIDs were proposed to avoid overloading IP addresses [4, 11]. Currently, an IP address represents both the identity of a network interface and its location. Mobility and multi-homing of hosts is frustrated. EIDs alleviate this problem by decoupling the transport and network layers. Again, it has been proposed that these EIDs are flat [11, 12]. The resolution of EID to IP address requires changes to the transport layer whereas SIDs are managed by higher layers. This paper concentrates then on the core location service function: resolving flat identifiers to network addresses. We assume that the mapping from user-level names to SIDs is available by some out-of-band process. For example, the SID might be sourced from DNS, an email, a web page, or a peer-to-peer query response.

2.2. Hierarchic DHTs are Dependable The design assumes the need for DHTs and hierarchy at the outset. DHTs were assumed, despite the existence of alternatives for large-scale name resolution. For example, Globe [1] also provided a global location service, intended for one billion users with one thousand objects each. It mapped persistent object handles onto a static hierarchy of nodes. The recent DHTs let the set of nodes to grow more easily. Hierarchic DHTs are assumed because of the combination of dependability, scale and geographic distribution. Scale alone does not justify hierarchy. For example, even if one billion location records each took 1kbyte of memory, the global service could reasonably be implemented on a few thousand commodity PCs in a single DHT. Similarly latency does not justify hierarchy. For example, some might argue that a lookup in a single global DHT might involve unnecessary international hops, whereas an extra layer of national DHTs would ensure that national queries remain within national boundaries. However, one-hop DHTs would avoid these unnecessary hops. They have been shown to scale to as many as one million nodes [13]. To see how dependability, scale and geographic distribution together motivate hierarchy, consider two users within one organization on one site. If the site is disconnected from the internet, the two users should be able to communicate using the location service. If the location service relies on a single global DHT that transits the site, then it will be disrupted after site failure or recovery. The disruption may be acceptable if there are only a handful of nodes on the site – they quickly reform a local ring. If there are many hundreds or thousands of nodes, recovery will take much longer. However, if the location service is served by a subtended DHT within the site, then local queries and updates are not interrupted. In the remainder of this paper, we assume the DHT hierarchy of Fig. 2. User and infrastructure nodes can participate in DHT rings which support the location service queries and updates. “Rings” here are for easy reference only – we do not restrict the design to DHTs with circular identifier spaces. Ring A is a single global ring. Rings B to D illustrate the hierarchy that might be required in a massive administrative domain. It might be a service provider in which the location service supports many millions of internet telephony users. Ring E might be a single organization where the user PCs participate in the DHT that is the location service. Ring F illustrates an ad hoc location service, such as might be provided for internet telephony users at a conference. Here, the two stable nodes in Ring F that connect to the global Ring A are optional. The uplinks between rings are logical links, internal to nodes. For example, node x may be owned by

a service provider to handle location queries and updates in Ring B. It also participates in the global Ring A and acts as a gateway to it. A

x

F x

B

C

E

D

DHT Node Domain

Figure 2. Global Hierarchy of DHT Rings One can envisage counter-arguments to say that dependability does not require hierarchic DHTs. For example, it has been suggested that, for robustness, “all nodes without connectivity constraints should join the global ring” [5]. The implicit assumption is that there is a risk of a network partition when there are only a few gateway nodes between rings. However, our design assumes that all nodes in the global ring and all gateway nodes are dependable. A small number of gateways adequately protect against individual node failures. Alternatively, one might argue that some DHTs inherently support network locality, so hierarchy is unnecessary. For example, the nodes in Pastry’s routing table are “close” with high probability [14]. However, a Pastry node is deemed to have failed when it loses contact with its “leaf set”, that is, with its immediate neighbors in the nodeID space. In a single, global DHT, these neighbors are “remote” with high probability. Consider the case where many Pastry nodes on one site instantaneously lose contact with a global Pastry overlay. In such a site failure, it is likely that the leaf sets are not repaired. Since the leaf sets are important for the final hop towards a target key, there are no guarantees of finding a particular key, even if it is on a live node on the same site. Such locality improves routing efficiency, not dependability.

2.3. Existing Hierarchic DHTs do not support Object Mobility How does a query from one subtended ring find a location record in another ring? One option is to use the domain name to refer to the remote ring and a locally significant identifier for the target object in the remote ring. In taking this approach, the emerging internet telephony standards [2] localize the location service. Persistence requirements are also violated. References to a user or object may be widely dispersed on web sites or in private caches. When the user or object moves to a

different domain, these references become obsolete. References to a persistent SID would remain intact. Alternatively, one might embed locality in global ring and object identifiers. This approach stumbles when objects move between nodes and rings. For example, Mislove and Druschel proposed a hierarchic DHT in which the ring identifier is a concatenation of all ring identifiers from the root to the leaf [5]. In this case, if objects move amongst the leaf rings, then the global ring bears the brunt of the update load. Even worse, if the leaf ring moves to a different part of the hierarchy, or merges with other leaf rings, then the global ring sees a large number of instantaneous updates. The current internet has over 353 million hosts [15]. To support mobility at this scale, it would be better that the global ring not see every update. Garcés-Erice et al. proposed a hierarchy where the responsible subgroup in the top layer of the hierarchy is determined by the object’s key [6]. If the object moves to a different sub-tree, then a new key is required. Such an identifier is not persistent.

2.4. Rendezvous enables Object Mobility One fundamental mechanism is used in some form in many of the designs mentioned thus far [1, 5, 14]: rendezvous. Although elegant, the idea that a sender and receiver meet in the network is hardly new. The novelty here is in the support for the global hierarchy of DHT rings of Fig. 2. The significance is that, by coupling rendezvous with hierarchic DHT rings, the global location service will: • Expand more easily than location services on static trees [1]. DHTs can self-organize when nodes join and leave. • Be more dependable than single DHT rings. Because of the hierarchy, an intra-site DHT is not interrupted if the site is partitioned from the network. Similarly, it is not interrupted when other large site rings in the same organization fail. • Enable object mobility while protecting the global ring. Unlike a leading hierarchic DHT [5], the global ring is rarely involved when objects move between rings. The design supports mobility because of the use of rendezvous with semantic-free tags. Unlike other rendezvous-based designs for semanticfree name resolution [16], LIP does not need changes below the transport layer. It can be deployed incrementally and privately within administrative domains for massive location update and query rates. It supports ad hoc networks of commodity devices without stable infrastructure. It supports a global location service by aggregating nodes from participating organizations.

2.5. Goals The following design goals for the location service address dependability (1-2), latency (3), scalability (4). 1. Support high availability. The mean availability of an authoritative DNS server is 98.64% [17], so the expected downtime for replicated servers is 97 minutes per year. Because the location service is a subset of name resolution, the service downtime attributed to stable location servers should be considerably less than this DNS benchmark. 2. Support disconnected administrative domains and sites. For high availability, the intra-site and intradomain location queries should remain strictly within the site and domain respectively. Ad hoc meetings of user devices should be possible without server infrastructure. 3. Incur delays suitable for existing location services. Given that the location service is a subset of name resolution, its latency should at least fall within measured DNS bounds: median latencies of less than 100 msecs; 90th-percentile latencies of up to a few seconds [18]. The location service in internet telephony needs to support 99th percentile call setup delays of 1.5 secs [19] (Section IV-D). 4. Scale to support the global number of administrative domains, identifiers, owners and lookups per day. Mockapetris estimated that modern name resolution systems need to deal with 1012 identifiers, 1010 owners, and 1011 lookups per day [20]. Ballani and Francis estimated that there are 5000 service provider points of presence (PoPs) globally, based on 200 tier-1 and tier-2 ISPs and an average of 25 PoPs per service provider [21]. Assuming four gateways per POP, the design should cater for a global ring of at least 20,000 nodes.

20,000 nodes with 2 Gbytes of memory each can support the global index. Each ring also stores “gateway records”. For example, the gateway record for Ring C is shown in Ring A (Fig. 3). The ‘anycast’ EID for Ring C maps to the EIDs of the specific nodes that participate in both Ring A and Ring C. The benefit of the gateway record is that the gateways can be changed without altering the vast number of object forwarding records. Although the authoritative gateway record is homed at one node, it can be replicated across nodes in the ring to reduce lookup hop count. The memory overheads of this replication are modest, given that there are only 5000 POPs. O C

C (C)

3

A

4 E (E)

5 7 2 ? (?)

6

B

1

C

8 O E

Query

D

O O

9

E

10 O O

SID

EID

Contact address

O O

Contact record maps SID for object O to the contact address for object O O O

Forwarding record maps SID for object O to the target EID O E

Forwarding record maps SID for object O to the anycast EID for ring E E (E)

Gateway record maps the EID for ring E to the EID of ring E gateways

3. Design 3.1. Architecture Fig. 3 captures the overall Location Information Plane (LIP) architecture. Ring A is the global ring. Nodes from different organizations participate in the global ring. These same nodes are the gateways to subtended rings (B and C). There are several kinds of location records stored in the LIP. Object “forwarding records” each map a SID to an EID. We assume that SIDs and EIDs are 160 bits in length – a common DHT assumption that balances the risk of key collisions against memory requirements for the index [22]. The 1012 objects that need to be visible globally dominate the lookup table in the global ring. The EID identifies the next ring on the path to the contact address. Can the global ring store this number of forwarding records? If they are stored naively, they consume 40 bytes per record, or 40 terabytes for a nonreplicated, insecure global index. In approximate terms,

? (?)

Default forwarding record pointing to the upward gateways

Figure 3. Architecture of the Location Information Plane (LIP) The “contact records” – those with the actual contact address for a particular object - will generally be stored at leaf nodes. There are no contact records stored directly in the global ring. Records in the global ring are either forwarding or gateway records. When a contact record moves regularly between Rings D and E, it may be more efficient to store the authoritative contact address in the parent Ring C.

3.2. Queries To illustrate how a query moves through the LIP, consider the query for the contact address of object O, initiated on a node in Ring B of Fig. 3. This initial description assumes that there is no caching and that all rings are implemented using one-hop DHTs.

Initially, the originating node queries the node on Ring B that is responsible for the object’s SID (Step 1 in Fig. 3). It does not exist on that node, so the query is referred to the gateways to the parent Ring A (Step 2). The vertical lines between Ring A and Ring B each represent a gateway node that participates in the two DHT rings. All nodes in Ring B know the set of EIDs that represent gateways to the parent ring. Because the path to the global ring is used regularly, the set of gateways EIDs is “corrected-on-use” – a proactive multicasting scheme is not required. The gateway then hunts for the object’s forwarding record within the global ring (Step 3). It indicates that the contact record for object O is in Ring C or one of its subtended rings. The same gateway node iteratively polls for Ring C’s gateway record (Step 4). Step 4 will often not be required when the gateway records are multicast amongst all nodes in the same ring. Ring B’s gateway chooses one of the Ring C gateways and forwards the query to it (Step 5). We assume that the query response is to traverse the same sequence of gateways in the reverse direction – Ring C’s gateway will forward the query response directly to Ring B’s gateway. Iterative routing was chosen over recursive routing for intra-ring queries. There is no difference between the two in terms of hop count – both require 6 unidirectional hops in Ring A. However, iterative routing gives Ring B’s gateway greater operational visibility. If there is a fault on the lookups for the forwarding records or gateway records, then the Ring B gateway can more easily determine the location of the fault when routing is iterative. The query then traverses Ring C with a similar lookup sequence (Steps 6-8). The forwarding record and the gateway record for object O in Ring C both refer to Ring E. The query completes its forward path in Ring E. One of the gateway nodes between Rings C and E polls the forwarding record to find the EID of the node responsible for the location record. This node provides the target contact address and sends the query response via the same path of gateways (Steps 10, 8, 5 and 2 in the reverse direction).

4. Application: LIP for Internet Telephony Having reviewed the LIP design, we now show how it supports a massively distributed internet telephony network. We first consider motivation. What is the value of DHTs for internet telephony? Secondly, we review architecture. How does LIP fit with the network, data, and performance measures of internet telephony? Finally, we show how the LIP design supports an internet telephony call.

4.1. Motivation What motivates proposals for DHT-based internet telephony [23]? Bryan, Lowekamp and Jennings lamented that Voice over IP (VoIP) and instant messaging (IM) deployments are frustrated by central servers [24]. They cited several scenarios: small organizations don’t trust VoIP and IM services to central servers in other organizations; there may not be connectivity to central servers due to disaster or equipment failure; participants in an ad hoc meeting don’t want the hassle of configuring or connecting to a central server; access to central servers may be prohibited because of government censorship or competitive carrier tactics; central servers are inherently unscalable and failure-prone. Singh and Schulzrinne advocated a DHT-based design for its scalability, dependability and ease of configuration [25]. They acknowledged that DHT-based designs suit multiple deployment scenarios: in internet-wide peer-to-peer networks; in internet telephony service providers to distributed load; or for enterprise, telephony networks within a LAN. Matthews and Poustchi also focused on permanent enterprise telephony networks without costly, central servers [26]. Johnston proposed standardization of a peer-to-peer location service for internet telephony, so as to bypass central servers [27].

4.2. Network Scenarios How might LIP fit within an internet telephony network? One important protocol for internet telephony is the Internet Engineering Task Force’s Session Initiation Protocol (SIP) [2]. SIP is primarily about the control plane - initiating, updating and terminating sessions - rather than the data plane. In a SIP deployment, “a location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of-record keys to zero or more contact addresses” [2]. Consider a call from Alice to Bob in Fig. 4 [2]. The SIP INVITE message is sent from Alice’s user agent to the Atlanta.com proxy. The Atlanta.com proxy queries the Domain Name System (DNS) for the IP address of the Biloxy.com proxy and sends the INVITE message to it. The Biloxi.com SIP proxy server submits Bob’s address-of-record to the location service, which responds with his contact address . The IETF SIP specifications do not mandate a particular protocol for the location service. Though proxies and other intermediaries are used in most deployments, they are not mandatory – if Alice could locate Bob, it is entirely feasible that they

could signal directly between themselves to establish a session. Atlanta.com

Biloxi.com DNS

Location Service

a

Signalling Path

Otherc

SIP Proxy Server

Alice SIP User Agent

Bob

Figure 4. Internet Telephony Signaling in the Session Initiation Protocol [2] – Alice calls Bob via the Atlanta.com proxy then the Biloxi.com proxy. LIP can therefore support the SIP location service in multiple ways. LIP rings could be used to massively scale just the location service within one domain for a service provider. If SIP user agents could interact directly with LIP, then they could establish local ad hoc sessions amongst themselves without a SIP proxy. Alternatively, if users were in possession of persistent, semantic-free identifiers for other users, then they could use LIP to establish sessions globally.

4.3. Design: LIP in an Internet Telephony Call One of several possible LIP deployment scenarios is as a global location service. Fig. 5 shows the sequence of SIP signaling and LIP queries to setup an internet telephony session from a node in Ring B to a node in Ring E. The various optimizations, like replication of gateway records and caching, are omitted. All nodes in Rings A to E can initiate LIP queries and forward SIP messages. O C

C (C)

3

A

4 E (E)

5 7 2

B

1 ? (?)

6

C

8 O E

Query O O

LIP Query

SIP Call Setup

9 10

E

Figure 5. Call Setup using SIP and LIP. Given ample bandwidth, low churn rates and Accordion DHTs, intra-ring signaling usually requires only one hop (Steps 2, 5, 8 and 10). However, in massive rings with high churn rates, intra-ring signaling involves O(log n) nodes. However, the call setup path still only traverses one hop. The originating node in each ring iterates around the ring until it can send the SIP call setup message directly to the gateway or destination node in the same ring.

5. Related Work The LIP design was inspired by application research on name resolution and peer-to-peer internet telephony. It also builds on the growing base of hierarchic DHTs. LIP was influenced by prior work on name resolution, and more specifically on location services. Globe separated its naming service from its location service via a single indirection, the object handle [1]. Van Steen and Ballintijn used a static hierarchy of nodes in Globe, noting that in practice each node would probably be implemented by local clusters. LIP is a more scalable, dynamic stack of rings. Instead of local clusters, LIP uses massively distributed DHTs. Like the “layered naming architecture” [4], LIP uses two semantic-free identifiers - the SID and the EID. i3 used rendezvous and semantic-free identifiers on a single Chord ring for service composition and multicasting [16]. Unlike the “layered naming architecture” [4] and i3 [16], LIP does not require changes to the transport layer. Because DHTs provide good load balancing, fault tolerance and easier administration, Cox et al. used them in a DNS design, DDNS [28]. However at the time, DHTs typically used O(log n) hops per lookup – they concluded that such DHTs cannot meet DNS latency requirements. SFR used a single global Chord ring to provide location services [3]. CoDoNs built on a single Pastry ring to provide DNS services. Both SFR and CoDoNs used caching to reduce the latency of O(log n) DHTs. In contrast, LIP relies on caching and O(1) DHTs to reduce latency, multi-ring hierarchy to cope with correlated (site/domain) failures, and rendezvous for easier mobility of objects. LIP responds to open issues recently identified by peer-to-peer internet telephony researchers. There have been two SIP prototypes that use DHTs to reduce reliance on intermediaries [24, 25]. Both use single Chord rings. One uses iterative lookups [24], the other is recursive [25]. Johnston argued the need for standardization of a global location service for SIPbased internet telephony and hinted that DHTs are a part of the solution [27]. For future work, Bryan, Lowekamp and Jennings [24] had proposed an investigation of hierarchical routing to interconnect SIP P2P realms. Singh and Schulzrinne identified the need for low latency DHTs for internet telephony [25]. LIP differs from prior proposals for hierarchic DHTs in its motivation, its use of semantic-free keys, its application to both structured and unstructured DHTs, and its support for object mobility. Superficially, LIP is most similar to the hierarchic rings of Mislove and Druschel [5]. However, there are important differences: they confined their work to structured DHTs; they embedded semantics of the ring hierarchy in Ring IDs;

their motivation was path and content locality for administrative control. Garcés-Erice et al. proposed hierarchic DHTs to improve routing performance [6]. To move an object to a different group, a new key needs to be assigned. When groups merge, keys and their related objects will move to different nodes. Coral used multiple rings but did not guarantee data locality [8]. Skipnet [9] builds a hierarchy of rings but embeds locality in keys, violating the requirement for persistent, semantic-free keys. Ratnasamy et al. grouped nodes into ‘bins’ to minimize lookup latencies [10]. Brocade associated nodes with nearby supernodes, to reduce point-to-point routing distances a minimize bandwidth [7]. LIP’s advantages over prior hierarchic DHTs stem from its use of rendezvous with semantic-free keys. If LIP rings merge, or if an object moves between lower layer rings, then updates are usually not required in the global ring. LIP was motivated by dependability, in particular, locality during catastrophic failure rather than locality during normal routing. If one organization has two massive site rings and one site fails, then LIP ensures that lookups within the remaining site’s ring are not interrupted. It also ensures that recovery traffic on the remaining site is minimized when the failed site recovers. At the same time, LIP inherits the strict guarantees in [5] on data and path locality during normal routing.

6. Conclusions We presented a design for a global Location Information Plane (LIP) to manage globally unique, persistent, semantic-free identifiers. It is the first design that simultaneously minimizes the impact of catastrophic failures and operational “moves and changes”. The hierarchic DHT design limits DHT maintenance traffic during and after catastrophic failures. The rendezvous abstraction protects the critical root of the DHT hierarchy from “moves and changes”. These two properties – dependability and object mobility – are essential for location services in practical, global networks.

Acknowledgment We thank Dr. Egemen Tanin (University of Melbourne) for discussions during the formative stages of this paper.

References [1] [2]

M. van Steen, F. Hauck, P. Homburg, and A. Tanenbaum, "Locating Objects in Wide-Area Systems," IEEE Communications Magazine, 1998. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol," IETF Request for Comment 3261, 2002.

[3] [4] [5] [6] [7] [8] [9]

[10] [11] [12] [13] [14] [15] [16] [17]

[18] [19] [20] [21] [22] [23] [24]

[25] [26] [27] [28]

M. Walfish, H. Balakrishnan, and S. Shenker, "Untangling the web from DNS," Proc. First Symp. on Networked Systems Design and Implementation NSDI'04, 225-238, March 29-31, 2004. H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S. Shenker, I. Stoica, and M. Walfish, "A Layered Naming Architecture for the Internet," SIGCOMM'04, Portland, Oregon, USA, Aug 30-Sept 3, 2004. A. Mislove and P. Druschel, "Providing administrative control and autonomy in structured peer-to-peer overlays," The 3rd Int'l Workshop on Peer-to-Peer SystemsJune 9-12, 2004. L. Garces-Erice, E. W. Biersack, K. Ross, P. Felber, and G. Urvoy-Keller, "Hierarchical P2P Systems," Proc. ACM/IFIP Int'l Conf. on Para. and Dist. Comp.Aug, 2003. B. Zhao, Y. Duan, L. Huang, A. Joseph, and J. Kubiatowicz, "Brocade: landmark routing on overlay networks," First Int'l Workshop on Peer-toPeer Systems IPTPS'02March, 2002. M. Freedman and D. Mazieres, "Sloppy Hashing and Self-Organizing Clusters," Proc. 2nd Int'l Workshop on Peer-to-Peer Systems IPTPS '03February, 2003. N. Harvey, M. B. Jones, S. Saroiu, M. Theimer, and A. Wolman, "SkipNet: A Scalable Overlay Network with Practical Locality Properties," Proc. Fourth USENIX Symp. on Internet Technologies and Systems USITS'03March, 2003. S. Ratnasamy, M. Handley, R. Karp, and S. Shenker, "Topologicallyaware overlay construction and server selection," Proc. IEEE Infocom, 312, 2002. R. Moskowitz and P. Nikander, "Host Identity Protocol Architecture," IETF Internet Draft, , June 27, 2004. B. Ford, "Unmanaged Internet Protocol: taming the edge network management crisis," ACM SIGCOMM Computer Communication Review, vol. 34, iss. 1, pp. 93-98, 2004. A. Gupta, B. Liskov, and R. Rodrigues, "Efficient Routing for Peer-toPeer Overlays," First Symp. on Networked Systems Design and Implementation NSDI March, 2004. A. Rowstron and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems," IFIP/ACM Middleware 2001Nov, 2001. "Domain Survey Information, Internet Systems Consortium," available at http://www.isc.org/index.pl?/ops/ds/, accessed October, 2005 I. Stoica, D. Adkins, S. Zhuang, and S. Shenker, "Internet indirection infrastructure," IEEE/ACM Trans. on Networking, vol. 12, iss. 2, pp. 205218, 2004. J. Pang, J. Hendricks, A. Akella, R. De Prisco, B. Maggs, and S. Seshan, "Availability, usage and deployment characteristics of the domain name system," Proc. of the 4th ACM SIGCOMM conference on internet measurement, 1-14, 2004. J. Jung, E. Sit, H. Balakrishnan, and R. Morris, "DNS Performance and the Effectiveness of Caching," ACM SIGCOMM Internet Measurement Workshop, November, 2001. T. Eyers and H. Schulzrinne, "Predicting internet telephony call setup delay," Proc. of the First IP Telephony WorkshopApril, 2000. P. Mockapetris, "The internet and identifiers," ACM SIGCOMM Computer Communication Review, vol. 35, iss. 4, pp. 325-325, 2005. H. Ballani and P. Francis, "Towards a global IP anycast service," Proc. of ACM SIGCOMM 2005Aug 22-26, 2005. J. Li, J. Stribling, R. Morris, and F. Kaashoek, "Bandwidth-efficient management of DHT routing tables," Proc. 2nd Symposium on Networked Systems Design and ImplementationMay 2-4, 2005. S. Baset, H. Schulzrinne, E. Shim, and K. Dhara, "Requirements for SIPbased peer-to-peer internet telephony," IETF Internet Draft, draft-basetsipping-p2preq-00Oct 28, 2005. D. Bryan, B. Lowekamp, and C. Jennings, "SOSIMPLE: a serverless, standards-based P2P SIP communication system," Proc. of the international workshop on Advanced Architectures and Algorithms for Internet Delivery and ApplicationsJune 15, 2005. K. Singh and H. Schulzrinne, "Peer-to-peer internet telephony using SIP," Proc. of the international workshop on network and operating systems support for digital audio and videoJune 13-14, 2005. P. Matthews and B. Poustchi, "Industrial-Strength P2P SIP," IETF Internet Draft, vol. draft-matthews-sipping-p2p-industrial-strength-00.txt, 2005. A. Johnston, "SIP,P2P and internet communications," IETF Internet Draft (expired) draft-johnston-sipping-p2p-ipcom-01, Mar 17, 2005. R. Cox, A. Muthitacharoen, and R. Morris, "Serving DNS using a Peerto-Peer Lookup Service," First Int'l Workshop on Peer-to-Peer Systems (IPTPS)March, 2002.