The Design and Implementation of an intentional naming system

William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, Jeremy Lilley

MIT Lab of Computer Science

Presenter: Vincent Matossian - February 2002

INS- February 2002 Vincent Matossian CS5452/25

the context and the goal

Dynamic and mobile network Idea is:

Describe What to look for, not Where to find it Need for naming service that is

Expressive Responsive Robust Easily configurable

INS- February 2002 Vincent Matossian CS5453/25

naming language

Simple and lightweight Small set of operators

Hierarchy of Attributes and Values allows nodes providing a service to describe what they provide Consumers to describe what they require

INS resolution architecture designed independently of the query language

INS- February 2002 Vincent Matossian CS5454/25

overview

Decentralized network of resolvers (to discover names and route messages) self-configured into an application-level overlay network

Use of intentional names for routing soft-state periodic advertisements from services Not yet meant for WAN internet

INS- February 2002 Vincent Matossian CS5455/25

system architecture Every request goes to an INR (resolver) INRs self-configure into a spanning-tree overlay network using INR-to-INR

round trip time measurements INRs route clients to services

INS- February 2002 Vincent Matossian CS5456/25

name specifiers

• Hierarchical arrangement of attribute value pairs

•Providers announce descriptive names• Clients make queries

–Attribute-value matches–Wildcard matches–Ranges

INS- February 2002 Vincent Matossian CS5457/25

discovering names

Updates contain: IP address + [port number, transport-type] Application-advertised metric for late binding Next-hop INR and INR-to-INR round trip time AnnouncerID for differentiation between similar names

Advertisement on specific port Name information is treated as soft-state no need for

registration, deregistration Information dissemination done using a routing protocol

that includes periodic updates and triggered updates.

INS- February 2002 Vincent Matossian CS5458/25

name lookup

Lookup returns a name-record which includes IP address of destination advertising name + set of “routes” to next-hop INRs

Name trees store correspondence between name-specifiers and name-records

• Lookup – Tree-matching algorithm – AND operations among orthogonal

attributes• Polynomial-time in number of attributes

– O(nd) where n is number of attributes and d is the ½ depth of tree

INS- February 2002 Vincent Matossian CS5459/25

resolver network

INRs self-configure to form a spanning tree overlay-network over UDP tunnels

INR-pings send a small name between INRs and measure the time it takes to process this message and get a response

Domain Space Resolver (DSR) keeps track of all INRs in the system

INS- February 2002 Vincent Matossian CS54511/25

late binding

Mapping from name to location can change rapidly Overlay routing protocol uses triggered updates Resolver performs lookup-and-forward

lookup(name) is a route; forward along route Two styles of message delivery

Anycast Multicast

INS- February 2002 Vincent Matossian CS54512/25

intentional anycast

lookup(name) yields all matches Resolver selects location based on advertised

service-controlled metric E.g., server load

Tunnels message to selected node Application-level vs. IP-level anycast

Service-advertised metric is meaningful to the application

INS- February 2002 Vincent Matossian CS54513/25

intentional multicast

Use intentional name as group handle Each resolver maintains list of neighbors for a name Data forwarded along a spanning tree of the overlay

network Shared tree, rather than per-source trees

Enables more than just receiver-initiated group communication

INS- February 2002 Vincent Matossian CS54514/25

robustness

Decentralized name resolution and routing in “serverless” fashion

Names are weakly consistent, like network-layer routes Routing protocol with periodic & triggered updates to exchange

names Routing state is soft

Expires if not updated Robust against service/client failure No need for explicit de-registration

INS- February 2002 Vincent Matossian CS54515/25

load Balancing and Scaling

Name processing dominates lookup processing

•Virtual space: application-specified set of names that share some attributes in common

1 Mb/s link

INS- February 2002 Vincent Matossian CS54516/25

vspace=camera vspace=5th-floor

Delegate this to another INR

Routing updates for all names

routing Protocol Scalability

vspace = Set of names with common attributes Virtual-space partitioning: each resolver now

handles subset of all vspaces

Name-tree at resolver

INS- February 2002 Vincent Matossian CS54518/25

message header format

B: Binding bit flag {early, late}

D: Delivery bit flag {anycast, multicast}

Hop limit sets a time to live for each message

Cache lifetime : 0 disallows cache

INS- February 2002 Vincent Matossian CS54519/25

applications

Location-dependent mobile applications Floorplan: An map-based navigation tool Camera: A mobile image/video service Load-balancing printer TV & jukebox service

Sensor computing Network-independent “instant messaging”

INS- February 2002 Vincent Matossian CS54520/25

experimental results

Max = 900 lookups/sec

Min = 700 lookups/sec

For ra=3; rv=3, na=2 and d=3; strings were one 16 bit character

Size of Name-tree varies

From 0.5 MB to 3 MB!

INS- February 2002 Vincent Matossian CS54521/25

results

Time to discover a new network name is linear in the number of INR hops

Order of 10’s ms

100 packets: 82B Header+586B payload

15-second periodic updates

Local: [310ms,1.9s]

Remote, same vspace: ~ 1s

Remote, different vspace: 381 ms

INS- February 2002 Vincent Matossian CS54522/25

status Java implementation of INS & applications

Several thousand names on single Pentium PC; discovery time linear in hops

Integration with Jini, XML/RDF descriptions in progress Scalability

Wide-area implementation in progress Deployment

Hook in wide-area architecture to DNS Standardize virtual space names (like MIME for

devices/services)

INS- February 2002 Vincent Matossian CS54523/25

naming and service discovery Wide-area naming

DNS, Global Name Service, Grapevine Attribute-based systems

X.500, Information Bus, Discover query routing Service location

IETF SLP, Berkeley service discovery service Device discovery

Jini, Universal plug-and-play Intentional Naming System (INS)

Mobility & dynamism via late binding Decentralized, serverless operation Easy configuration

INS- February 2002 Vincent Matossian CS54524/25

conclusions 1/2

Presented an intentional naming scheme where applications describe what they are looking not where to find data. Expressiveness: Achieved through a simple naming language

based on av-pairs Responsiveness: by integrating name resolution and message

routing coping with mobility and performance changes Robustness: periodic service advertisements and soft-state

name dissemination protocols between replicated resolvers Ease of configuration: by deploying self-configuring name

resolvers

INS- February 2002 Vincent Matossian CS54525/25

conclusions 2/2 Three resolution types:

Early binding: like DNS Late Binding:

Intentional anycast: returns optimal node providing service Intentional multicast: distributes to all names satisfying a query

Java implementation performs: [100s,1000s] lookups/sec depending on name complexity Dissemination of new names in tens of milliseconds Name space partitioning improves the scalability of INS

No WAN deployment; No security; Improve name matching operations and soft-state dissemination protocol to take into account importance of certain names