From eyh5@ee.cornell.edu Wed Oct 31 22:05:54 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA135qR10231 for ; Wed, 31 Oct 2001 22:05:52 -0500 (EST) Received: from james (james.ee.cornell.edu [128.84.236.65]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fA135aJ02595 for ; Wed, 31 Oct 2001 22:05:36 -0500 Date: Wed, 31 Oct 2001 22:04:13 -0500 (EST) From: Edward Hua To: egs@CS.Cornell.EDU Subject: 615 Paper # 30 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The Design and Implementation of an International Naming System William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, and Jeremy Lilley This paper presents an intentional naming system (INS) that may be used to quickly seek out resource discovery and service location in mobile networks. It features the following design objectives: expressiveness, responsiveness, robustness, and easy configuration. The INS resolution architecture makes three contributions: 1)integration of resolution and routing, which allows applications to seamlessly handle node and service mobility; it provides flexible group communication using an intentional name as the group handle, 2)self-configuration of resolvers into an overlay network and incoporation of load-balancing algorithmsl and 3)Maintaining weak consistency among replicated resolvers using soft-state message exchanges. The resolution of intentional names is faciliated by the name specifier. A name specifier can be used to identify the desired destination in a message header. Its attribute-value pair forms the foundation of the specifier, which then is expanded to establish a name tree. There are a sequence of events that take place in the INS. First, the intentional name of the destination service application is discovered; once the request reaches the destination, the intentional name resolver (INR) performs a lookup on the destination name-specifier in its name tree and returns the name-record. The INS also addresses the issues of load balancing and scaling in the system. Load balancing is resolved by allowing INRs to spawn instances on other candidate but inactive resolvers, and killing themselves if they are not loaded. The scaling arises when INRs exchange name information with other resolvers on a periodic basis and triggered updates. In this situation, the technique of virtual space is used. The idea is to partition the namespace into virtual spaces, ensuring that each resolver only needs to route for a subset of all the active virtual spaces in the system. Therefore, one INR is responsible a single virtual space, reducing the overlapping among multiple INRs. An interesting observation in the performance analysis of the INS is that when measuring the routing time as a function of the number of names in virtual spaces, the time is virtually constant when the recipient of the packets resides in a different virtual space than the sender. Furthermore, from Figure 15, it can be seen that the time it takes to route packets to a remote destination in a different virtual space is much less than the time it takes to route pakcets to a destination in the same virtual space as the sender. There are no explanations given to this phenomenon. From ramasv@CS.Cornell.EDU Wed Oct 31 23:35:17 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA14ZGR28920 for ; Wed, 31 Oct 2001 23:35:16 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: cs615 PAPER 30 Date: Wed, 31 Oct 2001 23:35:15 -0500 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301E7F288@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cs615 PAPER 30 Thread-Index: AcFijpppeH7QfIyOR8G9omjf9Kws+w== From: "Venu Ramasubramanian" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id fA14ZGR28920 The Design and Implementation of an Intentional Naming System This paper describes a service discovery system designed for a dynamically changing network such as mobile network. This system acheives its objectives by employing an attribute-value based naming scheme called intentional names to specify services. The system employs name resolvers distributed on an overlay network on top the existing network. Significant gain is achieved by avoiding static binding between the specified name and services found. The intentional naming scheme is an attribute-value based naming scheme much like a query in a database. AV based naming does make specifying services much easier for the end users. In this system, the name is described in terms of a tree structure that makes name resolution quick and easy. However this does reduce the expressibility of the names. This naming scheme does not seem to allow queries with not, or to be specified as a name for a resource. The name is resolved by name resolvers distributed on an overlay network. The services are expected to periodically broadcast their characteristics (AV pairs) that are stored by the name resolvers and used to compare with queries. The name resolvers form something similar to routers in an ad hoc network. The routing between the INRs take place by means of a proactive distance vector algorithm. The cost of the proactive algorithm is kept down by controlling the number of INRs in the overlay network. New INRs are created when the current number is not sufficient to resolve queries. The INRs are divided into virtual sets to keep the cost of proactivity and query resolution down. I believe that sperating the binding between name and service providers is very interresting. This helps them acheive the dynamic adaptability and change bindings from one server to another as the dynamics of the system changes. However, i believe using a overlay like network to resolve names may affect overall performance if the number of virtual spaces increase or if the number of INRs increase. From teifel@csl.cornell.edu Thu Nov 1 11:03:30 2001 Return-Path: Received: from disney.csl.cornell.edu (disney.csl.cornell.edu [132.236.71.87]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA1G3TR09602 for ; Thu, 1 Nov 2001 11:03:29 -0500 (EST) Received: from localhost (teifel@localhost) by disney.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id fA1G3BP26394 for ; Thu, 1 Nov 2001 11:03:11 -0500 (EST) (envelope-from teifel@disney.csl.cornell.edu) X-Authentication-Warning: disney.csl.cornell.edu: teifel owned process doing -bs Date: Thu, 1 Nov 2001 11:02:45 -0500 (EST) From: "John R. Teifel" To: Subject: 615 PAPER 30 Message-ID: <20011101110211.E10685-100000@disney.csl.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Intentional naming system: This paper discusses the design and implementation of the Intentional Naming System (INS), which is a resource discovery and service location system for mobile networks. The goals of such a system is to be able to describe and make requests based on types of services, respond to network connectivity changes, fault-tolerant, and configurable. Applications use the INS language to describe the services they are looking for and it is up to INS to find out where these services are and if they are available. To do this INS utilizes a late binding mechanism that integrates name resolution and message routing. INS supports three types of resource resolution: early binding with IP addresses, late binding with intentional anycast and intentional multicast. They present an algorithm for efficient name lookups in this environment. INS provides a practical way for applications to keep track of services in a dynamic network environment. Motivation for implementing this type of system, though, is weak and they did not really provide a lot of inspiration for doing so, other than the fact that it is technically feasible. From avneesh@csl.cornell.edu Thu Nov 1 11:36:26 2001 Return-Path: Received: from capricorn.ds.csl.cornell.edu (capricorn.csl.cornell.edu [132.236.71.92]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA1GaOR14313 for ; Thu, 1 Nov 2001 11:36:24 -0500 (EST) Subject: 615 Paper 30 Date: Thu, 1 Nov 2001 11:38:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <97C142C1212ED545B0023A177F5349C4053B32@capricorn.ds.csl.cornell.edu> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: 615 Paper 30 Thread-Index: AcFi85M6kK156WyzRSW4TvNN2Z/X3g== From: "Avneesh Bhatnagar" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id fA1GaOR14313 Design and implementation of an intentional naming system This paper describes the design of an intentional naming system (INS), which can be used as an expressive, robust, responsive and easily configurable resource discovery system in a mobile environment. The main idea is that application should be able to describe what kind of service,they are looking for and the location of these services. The system is implemented through an overlay network which incoroprates soft state messages i.e state that is refreshed upon receiving newer data, or discarded after a certain lifetime of inactivity. The intentional name is resolved using a name specifier, which consists of an attribute value pair, a set of which establish a name tree. The application might use intentional anycast or intentional multicast to request information. There are two ways to foward information to a specific device: a. Early binding. Returns list of IP addresses corresponding to the desired name. b. LAte binding (uses the two mechanisms mentioned above). This handles more dynamic situations and also facilitates load balancing, since the INRs can spawn instances on inactive resolvers. The method used is virtual spaces, the resolver needing only a subset of the total namespace. Virtual spaces can overlap. Routig within the overlay is done using a the DBF algorithm.I felt that the simulation studies were a bit lacking in terms of the explanation for some of the observed events. e.g in fig 15, routing time to differnt virtual spaces is lesser than other routing times. Secondly what is the effect of user density, i.e how does this system scale? However I also think that this idea is very interesting and there are a number of applications that could potentially benefit from the service-provider binding that this system provides. From samar@ece.cornell.edu Thu Nov 1 11:45:36 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA1GjYR15838 for ; Thu, 1 Nov 2001 11:45:34 -0500 (EST) Received: from descartes (descartes.ee.cornell.edu [128.84.236.60]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fA1GjFJ16085 for ; Thu, 1 Nov 2001 11:45:15 -0500 Date: Thu, 1 Nov 2001 11:44:21 -0500 (EST) From: Prince Samar X-Sender: samar@descartes.ee.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 30 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 30) The Design and Implementation of an Intentional Naming System This paper presents the design, implementation and evaluation of the Intentional Naming System (INS), a resource discovery and service location system for a mobile network. INS is a useful naming system when a source only knows what it is looking for and the location of the data is unknown. INS uses a simple language based on attributes and values (caller av-pairs) for naming. The design goals for INS have been: * Expressiveness: applications should be able to express arbitrary service descriptions and queries. * Responsiveness: the naming system should be able to quickly adapt to node mobility or service mobility. * Robustness: Failures of a few name resolvers and services should not have any significant effect on the network. * Easy configuration: The name resolvers should be able to automatically configure themselves. The INS service model supports - early binding to obtain a list of IP addresses for for a name and - late binding which include intentional anycast and intentional multicast. For intentional anycast, an INR (Intentional Name Resolver) forwards a packet to the "best" node satisfying the query based on the specified application controlled metric. Intentional multicast forwards the packet to all the names satisfying the query. INS integrates resolution and routing, facilitating applications to handle node and service mobility and provide efficient group communication. Services periodically advertise their intentional names to the system to describe what they provides. The INRs self configure, forming an application-level overlay network among themselves over which they send updates of valid names in the system. The INRs also incorporate load balancing algorithm to perform well. INS maintains weak consistency amongst replicated resolvers using soft-state message exchanges. The authors also described the design and analysis of an efficient algorithm that performs name look-ups and show that an implementation can perform between several hundred to a few thousand name-lookups per second. Using intentional names with intentional unicast/mulitcast is a neat way to discover resources in a dynamic, mobile network. However, the INS is not scalable to a wide area deployment. Also, the name resolvers have to proactively update and maintain information, which may affect the overall performance of the network. From daehyun@csl.cornell.edu Thu Nov 1 11:46:01 2001 Return-Path: Received: from wilkes.csl.cornell.edu (wilkes.csl.cornell.edu [132.236.71.69]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA1GjxR15867 for ; Thu, 1 Nov 2001 11:45:59 -0500 (EST) Received: (from daehyun@localhost) by wilkes.csl.cornell.edu (8.9.3/8.9.2) id LAA28619 for egs@cs.cornell.edu; Thu, 1 Nov 2001 11:45:54 -0500 (EST) (envelope-from daehyun) From: Daehyun Kim Message-Id: <200111011645.LAA28619@wilkes.csl.cornell.edu> Subject: 615 PAPER 30 To: egs@CS.Cornell.EDU Date: Thu, 1 Nov 2001 11:45:54 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This paper presented a the Intentional Naming System (INS) which supports a resource discovery and service location systems for mobile network. The design goals INS are expressiveness, responsiveness, robustness and easy configuration. The main idea of INS is to separate service names and locations. Applications describe services what they are looking for, not locations where to find them. Then name resolvers find the appropriate locations by maintaining a mapping between service descriptions and their locations. This is a good approach for the mobile networks where applications do not know the exact locations of the services. INS uses an intentional name languages based on a hierarchy of attributes and values, called name specifiers. Name specifiers are composed of attribute and values. They form an av pair and have a hierarchical tree-like structure. Intentional Name Resolvers (INR) form an overlay network among themselves, over which they send intentional naming information. Services periodically advertise their intentional names and INRs maintain those information. When client make name resolution requests INRs resolve the requests. INS supports three types of resolution: early binding, intentional anycast and intentional multicast. In my opinion, the main contribute of this paper is that it provides a naming systems which can support mobile ad hoc systems efficiently. As they said in the paper, the separation of service names and locations can deal with dynamic environment flexibly. From ranveer@CS.Cornell.EDU Thu Nov 1 11:52:02 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA1Gq1R17042 for ; Thu, 1 Nov 2001 11:52:01 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: 615 PAPER 30 Date: Thu, 1 Nov 2001 11:52:00 -0500 Message-ID: <706871B20764CD449DB0E8E3D81C4D430213A7C0@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 30 Thread-Index: AcFi9YHdtWCom8v9EdW5awCQJ59Etw== From: "Ranveer Chandra" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id fA1Gq1R17042 The design and implementation of an intentional naming system This paper presents an interestng concept: decoupling the IP address from the resource name. Clients of a resource need not keep track of changes in IP address or network route to the resource server. A request for a resource is specified as a name or descriptive attribute. The request is routed to the resolver which further routes packets to the resource matching the request attribute. The address of the resource is either sent back to the client in the case of early binding or the request is further sent to one or many resources depending on the late binding mechanism specified: anycast or multicast. The resolvers maintain an overlay network that keep a consistent view of the available resources. The idea of decoupling server IP addresses from the resource name is a very interesting concept. This scheme would be specially beneficial in mobile applications where the servers offering the same resource might change over time based on the location. The intentional naming scheme borrows the idea of the SFS and is an effective model for resource requests. However, the main drawback of INS is the proactive maintenance of the overlay network. If used in an ad hoc setting, this scheme would be increasingly expensive, at least as expensive as maintaining a multicast tree. Maintaining such overlay networks for different virtual spaces would definitely affect the scalability of INS. In my opinion, an interesting modification to INS could be a reactive approach, with caching, to search for resources, such that frequently used resources are stored in cache and the updates for lesser used ones do not congest the network. From papadp@ee.cornell.edu Thu Nov 1 11:55:27 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA1GtQR17331 for ; Thu, 1 Nov 2001 11:55:26 -0500 (EST) Received: from ee.cornell.edu (hegel.ee.cornell.edu [128.84.236.63]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fA1Gt7J16369 for ; Thu, 1 Nov 2001 11:55:07 -0500 Sender: papadp@ece.cornell.edu Message-ID: <3BE17E60.136D2FDF@ee.cornell.edu> Date: Thu, 01 Nov 2001 11:54:56 -0500 From: Panagiotis Papadimitratos Reply-To: papadp@ece.cornell.edu Organization: Cornell University X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: el, fr-FR, en MIME-Version: 1.0 To: Emin Gun Sirer Subject: 615 PAPER 30 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Review of: "The design and implementation of an intentional naming system," by W.A.Winoto, E.Schwartz, H.Balakrishnan, and J. Lilley Panagiotis Papadimitratos papadp@ece.cornell.edu The proposed architecture falls in the group of works that intend to decouple names from object locations, and a system for resource discovery and service location is presented. The Intentional Naming System (INS) functionality is implemented by the Intentional Name Resolvers (INR's) that request and discover services and provide the corresponding data to the querying application/client. The INR's form an overlaid network, i.e., a virtual topology above the actual network-layer topology, exchange and forward service advertisements and locally cache such descriptions. The entire system relies on attribute-value pairs organized into 'Name-Tree' structures, which INR's look up into. When a 'name specifier' arrives at an INR the look-up returns the the IP address of the advertiser(s) of the sought resource/service. The lookup algorithm is one of the technical challenges of this work, and is experimentally evaluated. The operation of the system assumes the presence of an entity (DSR) that maintains the list of all INR's present in the network. A new INR contacts DSR (Domain space resolver) in order to acquire this information and then establishes links with the rest of the INR's in order to form the necessary connectivity. The apparent need for proactiveness clearly impedes the scalability of the scheme, especially in a dynamically changing environment, and the authors propose the partitioning of the name space into domains, i.e., virtual spaces. In any case, the INR's have to make routing decisions at the level of the overlaid network, this done at the publication of the paper with a local construction of a spanning tree. The use of DBF is mentioned also as an alternative. The amount of the overhead maybe significant, while the goal of optimality is not clearly supported, especially because of the apparent independence of routing decisions at the INS and network layer. There is also the 'paradoxical' result that the lookup delay is higher if two INR's reside at the same node. From c.tavoularis@utoronto.ca Thu Nov 1 11:59:07 2001 Return-Path: Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA1Gx5R18080 for ; Thu, 1 Nov 2001 11:59:05 -0500 (EST) Received: from webmail1.ns.utoronto.ca ([128.100.132.24] EHLO webmail1.ns.utoronto.ca ident: IDENT-NOT-QUERIED [port 59787]) by bureau6.utcc.utoronto.ca with ESMTP id <238473-27960>; Thu, 1 Nov 2001 11:58:51 -0500 Received: by webmail1.ns.utoronto.ca id <126208-22902>; Thu, 1 Nov 2001 11:58:33 -0500 To: COM S 615 Subject: 615 PAPER 30 Message-ID: <1004633906.3be17f32b40c6@webmail1.ns.utoronto.ca> Date: Thu, 01 Nov 2001 11:58:26 -0500 (EST) From: c.tavoularis@utoronto.ca MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT User-Agent: IMP/PHP IMAP webmail program 2.2.3 The Intentional Naming Service (INS) for resource discovery uses a simple language to associate descriptive attributes and values to services in the network. Intentional name resolvers (INRs) match clients desiring a service to the appropriate service based on the attributes and perform the routing to the destination service. INRs form a spanning tree and update each other periodically to support large networks of resources. Intentional names describe services using name-specifiers consisting of attributes and values forming an av-pairs. INRs maintain mappings between intentional names and network locations in the form of IP addresses. An INR supports node mobility and allows IP addresses to change, and will also react to load changes which might cause it to choose a different service location. Clients use intentional names to request services, and are oblivious to who is providing the service and changes in mapping due to mobility. Clients can request late-binding so that the binding to a location is made at message delivery time. From this, a client can request an intentional-anycast, so that the location of service is chosen by the optimality of an application- controlled metric. Intentional-multicast delivers to all locations. INRs send periodic and triggered messages to each other to keep information fresh and are capable of performing load balancing. Some applications of INS include Floorplan which provides users with an up-to-date map of their current location. Camera allows a user to ask for images from specific cameras, or can use intentional multicast to query all the cameras in an area. INS works well to respond quickly and distribute workload amongst the INRs. INS appears to successfully achieve its goals of expressiveness, responsiveness, robustness and ease of configuration for its naming system. Since it works over IP unicast, it could easily be integrated into existing networks. I think the main contribution of multicast is that it combines routing and naming and employs application-level information to effectively provide resource discovery in large networks. It employs DBF shortest path routing, which could be replaced with other routing techniques, and therefore could possibly accommodate ad hoc routing. From andre@CS.Cornell.EDU Thu Nov 1 12:56:13 2001 Return-Path: Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA1HuBR27099; Thu, 1 Nov 2001 12:56:11 -0500 (EST) Received: from khaffy (d2040.dialup.cornell.edu [132.236.155.40]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id MAA15940; Thu, 1 Nov 2001 12:56:08 -0500 (EST) Received: from andre by khaffy with local (Exim 3.31 #1 (Debian)) id 15zGU2-0000IX-00; Thu, 01 Nov 2001 12:58:06 +0100 Date: Thu, 1 Nov 2001 12:58:05 +0100 From: =?iso-8859-1?Q?Andr=E9?= Allavena To: egs@CS.Cornell.EDU Cc: andre@CS.Cornell.EDU Subject: 615 PAPER 30 Message-ID: <20011101125805.A1116@khaffy> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.20i Sender: =?iso-8859-1?Q?Andr=E9_Allavena?= The design and implementation of an intentional naming system This paper describes a scheme or localisating services in a adhoc network. There are a set of generic attributes (a tree in fact), and a service advertise itself by filling some of the attributes (printer, Ithaca, etc.) There are INS servers which store the available list of services, and make it available to clients upon queies, and t the other INS. I really don't like their scheme becase it is really inefficient in terms of bandwidth. There is a distributed Bellman Ford running between the different INS servers, and all the updates are sent to everybody (this is analog to proactive routing, and tunrs out to be ineficient wihth mobile nodes). Further more, does anybody care if there is another printer on the other side of the network when there already are several nearby? There are talking of an application advertised metric for choosing the best instance of the service the application need. Who chooses this metric? t doesn't seem to be any application, the way they have implemented it, it is the service provider and or the INS servers which choose it. 2.2 I read a "rapid change due to node mobility quickly propagate trough the system and new info replaces old information". I am not convinced. What about a on demand service discovery? -- André Allavena (local) 154 A Valentine Place École Centrale Paris (France) Ithaca NY 14850 USA Cornell University (NY) (permanent) 879 Route de Beausoleil PhD in Computer Science 06320 La Turbie FRANCE From gupta@CS.Cornell.EDU Thu Nov 1 13:00:25 2001 Return-Path: Received: from ringding.cs.cornell.edu (ringding.cs.cornell.edu [128.84.96.109]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fA1I0OR27836 for ; Thu, 1 Nov 2001 13:00:24 -0500 (EST) From: Indranil Gupta Received: (from gupta@localhost) by ringding.cs.cornell.edu (8.11.3/8.11.3/C-3.2) id fA1I0No15892 for egs@cs.cornell.edu; Thu, 1 Nov 2001 13:00:23 -0500 (EST) Message-Id: <200111011800.fA1I0No15892@ringding.cs.cornell.edu> Subject: 615 PAPER 30 To: egs@CS.Cornell.EDU Date: Thu, 1 Nov 2001 13:00:23 -0500 (EST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The design and implementation of an intentional naming system, Adjie-Winoto, Schwartz, Balakrishnan, Lilley. Reviewer: Indranil Gupta This paper presents an architecture for object naming and location on a dynamic network (a mildly static network is considered for experiments). Objects are named using a series of attribute-value pairs, nested where there are dependencies. The entire attribute-value search space is effectively a (very large) tree with (potentially unbounded) degree. Updates to the tree (new attributes or values, new objects, etc.) are propagated periodically from their source, and entries at other nodes (the INResolvers) time out. Any client wishing to access an object contacts an INR on the INR overlay network, which either replies back directly or passes on the query. Intentional resource discovery and multicast are both supported. Comments: The main contribution of the paper is a proof-of-concept implementation. Interesting research issues such as a search over a search tree replicated only partially at every INR are not looked into. This model would yield great benefits when nodes are short-live or have small memories, and the size of the entire global search tree is too large to maintain at any single node.