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
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
2
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
3
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
4
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
ri
A
Ri
Ring membership management
– Each node also keeps a list of l candidates
– To increase geographic diversity, begin with hypervolume of (k+l) vertices and greedily eliminate the
one that leads to the smallest reduction, l times
EECS 443 Advanced Operating Systems
Northwestern University
5
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
6
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
7
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 Systems
Northwestern University
8
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
9
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
10
Closest node discovery
Median error for
discovering closest node
Relative error CDFs for
different schemes
EECS 443 Advanced Operating Systems
Northwestern University
11
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 Systems
Northwestern University
12
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
13
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
14
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 Systems
Northwestern University
15