Meridian: A lightweight network location service without virtual coordinates

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

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 SystemsNorthwestern 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 SystemsNorthwestern 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 SystemsNorthwestern University

5. ri A Ri 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: ri = alpha * si-1 and outer Ri = alpha * si ) • 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 EECS 443 Advanced Operating SystemsNorthwestern 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 SystemsNorthwestern 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 SystemsNorthwestern 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 davg • Inter-node latencies of targets are not known EECS 443 Advanced Operating SystemsNorthwestern 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 SystemsNorthwestern 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 SystemsNorthwestern University

11. Closest node discovery Median error for discovering closest node Relative error CDFs for different schemes EECS 443 Advanced Operating SystemsNorthwestern 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 log1.6N EECS 443 Advanced Operating SystemsNorthwestern 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 SystemsNorthwestern 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 SystemsNorthwestern 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 EECS 443 Advanced Operating SystemsNorthwestern University