Fabián E. Bustamante, 2007 Meridian: A lightweight network location service without virtual coordinates B. Wong, A. Slivkins and E. Gün Sirer SIGCOM 2005 Presenter: F. E. Bustamante

EECS 443 Advanced Operating Systems Northwestern University 2 The need for a network location service Selecting node base on a set of network properties A useful building block for many distributed systems –Locate closest game server –Distributed web-crawling to nearby hosts –Perform efficient application level multicast –Satisfy a service level agreement –Provide inter-node latency bounds for clusters Simple collecting global info is infeasible for large-scale systems

EECS 443 Advanced Operating Systems Northwestern University 3 Common approach: Virtual coordinates Maps high-dimensional network measurements (latencies) into a smaller Euclidean space –GNP, Vivaldi, Lighthouse, Virtual Landmarks, PIC, NPS, etc Reduces number of real-time measurements Practical problems –How many landmarks, how many measurements, …? –Introduces inherent embedding error –A snapshot in time of the network location of a node Coordinates become stale over time Latency estimates based on coordinates computed at different times can lead to additional errors –Needs additional service to solve network location problems w/o centralized servers or O(N) state

EECS 443 Advanced Operating Systems Northwestern University 4 Meridian approach Avoid most problems with coordinates by going back to active measurements Avoid the scalability problem of all-to-all measurements via –A loosely-structured overlay –Avoiding reconcile latencies seen into a globally consistent coordinate space Avoid the need for additional service by combining query routing w/ active measurement

EECS 443 Advanced Operating Systems Northwestern University 5 Framework Multi-resolution rings –Each node keeps track of a fixed number of other nodes –Organized into a set of concentric, non-overlapping rings of increasing radius (inner: r i = alpha * s i-1 and outer R i = alpha * s i ) –Each ring with k peers Ring membership management –Each node also keeps a list of l candidates –To increase geographic diversity, begin with hyper- volume of (k+l) vertices and greedily eliminate the one that leads to the smallest reduction, l times A riri RiRi

EECS 443 Advanced Operating Systems Northwestern University 6 Framework Gossip based node discovery –Each node randomly picks one per ring and sends list of randomly chosen others per ring –Recipient node probes its distance to those nodes and the source –The interval between gossip cycles gradually increases to a common value Bootstrapping –Need to know of at least one node already in –Get this node’s list and bin them based on its own measurements

EECS 443 Advanced Operating Systems Northwestern University 7 Common network location problems (1) Closest node –Discovering the closest node to a targeted reference point –Can be use by CDNs, multiplayer games, P2P overlays, … –Meridian Multihop search similar to finding the closest identifier in a DHT Each hop exponentially reduces the distance to the target –Determine distance d to target –Ask all peers within (1-/+beta)*d, anybody closer? repeat Reduction threshold beta (+,<1) – when to stop

EECS 443 Advanced Operating Systems Northwestern University 8 Common network location problems (2) Central leader –Locate the center point of a region defined by a set of nodes –To pick the leader of a cluster when forming multicast trees –Meridian Minimizes avg latency to a set of targets instead of one target Replace d with d avg Inter-node latencies of targets are not known

EECS 443 Advanced Operating Systems Northwestern University 9 Common network location problems (3) Multi-constraint –Locate nodes in the intersection of a set of constraints such as set of latencies to well-known peering points –You have some room here, e.g. when trying to satisfy a SLA –Meridian Add range and use sum of max(0, d - range) 2, for all u constraints

EECS 443 Advanced Operating Systems Northwestern University 10 Evaluation In simulation –2500 DNS servers –Use 500 of them as targets –Internode latency measure using the King measurement technique –Compare using GNP, Vivaldi and Vivaldi with height Also deployed in PlanetLab – closestnode.com –Over 166 nodes, now over more than 300 nodes with all applications

EECS 443 Advanced Operating Systems Northwestern University 11 Closest node discovery Median error for discovering closest node Relative error CDFs for different schemes

EECS 443 Advanced Operating Systems Northwestern University 12 Closest node discovery Accuracy maybe couple with low query latencies Avg. query latency determined by slowest node in each ring Here k is set to log 1.6 N

EECS 443 Advanced Operating Systems Northwestern University 13 Central leader election Only 2 and 8 targets; authors argue that relative error decreases with increasing number of targets

EECS 443 Advanced Operating Systems Northwestern University 14 Multi-constraint System Categorized multi-constraint queries by its difficulty Success rate for queries that can be satisfied by only 0.5% of nodes

EECS 443 Advanced Operating Systems Northwestern University 15 Conclusions & Issues You don’t need coordinates to solve some useful practical problems “The accuracy of Meridian’s closest node discovery protocol [and everything else, therefore] depends on several parameters, such as the number of nodes per ring, …” Effect of churn Firewalled hosts are excluded form ring membership on other firewalled hosts Length of bootstrapping process Accuracy of service meanwhile