Meridian a lightweight network location service without virtual coordinates
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

Meridian: A lightweight network location service without virtual coordinates PowerPoint PPT Presentation


  • 56 Views
  • Uploaded on
  • Presentation posted in: General

Meridian: A lightweight network location service without virtual coordinates. B. Wong, A. Slivkins and E. G ü n Sirer SIGCOM 2005 Presenter: F. E. Bustamante. The need for a network location service. Selecting node base on a set of network properties

Download Presentation

Meridian: A lightweight network location service without virtual coordinates

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Meridian a lightweight network location service without virtual coordinates

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

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


Common approach virtual coordinates

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


Meridian approach

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


Framework

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


Framework1

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


Common network location problems 1

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


Common network location problems 2

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


Common network location problems 3

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


Evaluation

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


Closest node discovery

Closest node discovery

Median error for discovering closest node

Relative error CDFs for different schemes

EECS 443 Advanced Operating SystemsNorthwestern University


Closest node discovery1

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


Central leader election

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


Multi constraint system

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


Conclusions issues

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


  • Login