exploiting route redundancy via structured peer to peer overlays n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Exploiting Route Redundancy via Structured Peer to Peer Overlays PowerPoint Presentation
Download Presentation
Exploiting Route Redundancy via Structured Peer to Peer Overlays

Loading in 2 Seconds...

play fullscreen
1 / 19

Exploiting Route Redundancy via Structured Peer to Peer Overlays - PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on

Exploiting Route Redundancy via Structured Peer to Peer Overlays. Ben Y. Zhao, Ling Huang, Jeremy Stribling, Anthony D. Joseph, and John D. Kubiatowicz University of California, Berkeley ICNP 2003. Challenges Facing Network Applications. Network connectivity is not reliable

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Exploiting Route Redundancy via Structured Peer to Peer Overlays' - ramona-robles


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
exploiting route redundancy via structured peer to peer overlays

Exploiting Route Redundancy via Structured Peer to Peer Overlays

Ben Y. Zhao, Ling Huang, Jeremy Stribling, Anthony D. Joseph, and John D. Kubiatowicz

University of California, Berkeley

ICNP 2003

challenges facing network applications
Challenges Facing Network Applications
  • Network connectivity is not reliable
    • Disconnections frequent in the wide-area Internet
    • IP-level repair is slow
      • Wide-area: BGP  3 mins
      • Local-area: IS-IS  5 seconds
  • Next generation network applications
    • Mostly wide-area
    • Streaming media, VoIP, B2B transactions
    • Low tolerance of delay, jitter and faults
    • Our work: transparent resilient routing infrastructure that adapts to faults in not seconds, but milliseconds

ravenben@eecs.berkeley.edu

talk overview
Talk Overview
  • Motivation
  • Why structured routing
  • Structured Peer to Peer overlays
  • Mechanisms and policy
  • Evaluation
  • Summary

ravenben@eecs.berkeley.edu

routing in mesh like networks
Routing in “Mesh-like” Networks
  • Previous work has shown reasons for long convergence [Labovitz00, Labovitz01]
  • MinRouteAdver timer
    • Necessary to aggregate updates from all neighbors
      • Commonly set to 30 seconds
    • Contributes to lower bound of BGP convergence time
  • Internet becoming more mesh-like [Kaat99,labovitz99]
    • Worsens BGP convergence behavior
  • Question
    • Can convergence be faster in context of structured routing?

ravenben@eecs.berkeley.edu

resilient overlay networks mit
Resilient Overlay Networks (MIT)
  • Fully connected mesh
  • Allows each node full knowledge of network
    • Fast, independent calculation of routes
    • Nodes can construct any path, maximum flexibility
  • Cost of flexibility
    • Protocol needs to choose the “right” route/nodes
    • Per node O(n) state
      • Monitors n - 1 paths
    • O(n2) total path monitoring is expensive

D

S

ravenben@eecs.berkeley.edu

leveraging structured peer to peer overlays
Leveraging Structured Peer-to-Peer Overlays

source

0

  • Key based routing (IPTPS 03)
    • Large sparse ID space N (160 bits: 0 – 2160)
    • Nodes in overlay network have nodeIDs  N
    • Given some key k  N, overlay deterministically maps k to its root node (live node in the network)
    • route message to root (k)

root(k)

k

  • Distributed Hashtables (DHT) is interface on KBR
    • Key is leveraging underlying routing mesh

ravenben@eecs.berkeley.edu

proximity neighbor selection
Proximity Neighbor Selection
  • PNS = network aware overlay construction
    • Within routing constraints, choose neighbors closest in network distance (latency)
    • Generally reduces # of IP hops
  • Important for routing
    • Reduce latency
    • Reduce susceptibility to faults
      • Less IP links = smaller chance of link/router failure
    • Reduce overall network bandwidth utilization
  • We use Tapestry to demonstrate our design
    • P2P protocol with PNS overlay construction
    • Topology-unaware P2P protocols will likely perform worse

ravenben@eecs.berkeley.edu

system architecture

O V E R L A Y

v

v

v

v

v

v

v

v

v

v

v

v

v

System Architecture
  • Locate nearby overlay proxy
  • Establish overlay path to destination host
  • Overlay traffic routes traffic resiliently

Internet

ravenben@eecs.berkeley.edu

traffic tunneling

register

register

get (hash(B))

P’(B)

put (hash(B), P’(B))

put (hash(A), P’(A))

Traffic Tunneling

A, B are IP addresses

Legacy

Node B

Legacy

Node A

B

P’(B)

Proxy

P’(B) = B

P’(A) = A

Proxy

Structured Peer to Peer Overlay

  • Store mapping from end host IP to its proxy’s overlay ID
  • Similar to approach in Internet Indirection Infrastructure (I3)

ravenben@eecs.berkeley.edu

tradeoffs of tunneling via p2p
Tradeoffs of Tunneling via P2P
  • Less neighbor paths to monitor per node: O(log(n))
    • Large reduction in probing bandwidth: O(n)  O(log(n))
    • Increase probing frequency
    • Faster fault detection with low bandwidth consumption
  • Actively maintain path redundancy
    • Manageable for “small” # of paths
    • Redirect traffic immediately when a failure is detected
    • Eliminate on-the-fly calculation of new routes
    • Restore redundancy when a path fails
  • End result
    • Fast fault detection + precomputed paths = increased responsiveness to faults
  • Cons
    • Overlay imposes routing stretch (more IP hops), generally < 2

ravenben@eecs.berkeley.edu

some details
Some Details
  • Efficient fault detection
    • Use soft-state to periodically probe log(n) neighbor paths
    • “Small” number of routes  reduced bandwidth
    • Exponentially weighted moving averagein link quality estimation
      • Avoid route flapping due to short term loss artifacts
      • Loss rate Ln = (1 - )  Ln-1 +   p
      • p = instantaneous loss rate,  = hysteresis factor
  • Maintaining backup paths
    • Each hop has flexible routing constraint
      • Create and store backup routes at node insertion
    • Restore redundancy via “intelligent” gossip after failures
    • Simple policies to choose among redundant paths

ravenben@eecs.berkeley.edu

first reachable link selection frls
First Reachable Link Selection (FRLS)
  • Use estimated loss results to choose shortest “usable” path
  • Sort next hop paths by latency
  • Use shortest path withminimal quality > T
  • Correlated failures
    • Reduce with intelligent topology construction
    • Key is to leverage redundancy available

2225

2299

2274

2286

2046

2281

2530

1111

ravenben@eecs.berkeley.edu

evaluation
Evaluation
  • Metrics for evaluation
    • How much routing resiliency can we exploit?
    • How fast can we adapt to faults?
    • What is the overhead of routing around a failure?
      • Proportional increase in end to end latency
      • Proportional increase in end to end bandwidth used
  • Experimental platforms
    • Event-based simulations on transit stub topologies
      • Data collected over different 5000-node topologies
    • PlanetLab measurements
      • Microbenchmarks on responsiveness
      • Bandwidth measurements from 200+ node overlays
      • Multiple virtual nodes run per physical machine

ravenben@eecs.berkeley.edu

exploiting route redundancy sim
Exploiting Route Redundancy (Sim)
  • Simulation of Tapestry, 2 backup paths per routing entry
  • Transit-stub topology shown, results from TIER and AS graphs similar

ravenben@eecs.berkeley.edu

responsiveness to faults planetlab

660

300

Responsiveness to Faults (PlanetLab)
  • Response time increases linearly with probe period
  • Minimum link quality threshold T = 70%, 20 runs per data point

ravenben@eecs.berkeley.edu

link probing bandwidth planetlab
Link Probing Bandwidth (Planetlab)
  • Medium sized routing overlays incur low probing bandwidth
  • Bandwidth increases logarithmically with overlay size

ravenben@eecs.berkeley.edu

related work
Related Work
  • Redirection overlays
    • Detour (IEEE Micro 99)
    • Resilient Overlay Networks (SOSP 01)
    • Internet Indirection Infrastructure (SIGCOMM 02)
    • Secure Overlay Services (SIGCOMM 02)
  • Topology estimation techniques
    • Adaptive probing (IPTPS 03)
    • Peer-based shared estimation (Zhuang 03)
    • Internet tomography (Chen 03)
    • Routing underlay (SIGCOMM 03)
  • Structured peer-to-peer overlays
    • Tapestry, Pastry, Chord, CAN, Kademlia, Skipnet, Viceroy, Symphony, Koorde, Bamboo, X-Ring…

ravenben@eecs.berkeley.edu

conclusion
Conclusion
  • Benefits of structure outweigh costs
    • Structured routing lowers path maintenance costs
      • Allows “caching” of backup paths for quick failover
    • Can no longer construct arbitrary paths
      • Structured routing with low redundancy gets very close to ideal in connectivity
      • Incur low routing stretch
  • Fast enough for highly interactive applications
    • 300ms beacon period  response time < 700ms
    • On overlay networks of 300 nodes, b/w cost is 7KB/s
  • Future work
    • Deploying a public routing and proxy service on PlanetLab
    • Examine impact of
      • Network aware topology construction
      • Loss sensitive probing techniques

ravenben@eecs.berkeley.edu

questions
Questions…
  • Related websites:
    • Tapestry

http://www.cs.berkeley.edu/~ravenben/tapestry

    • Pastry

http://research.microsoft.com/~antr/pastry

    • Chord

http://lcs.mit.edu/chord

  • Acknowledgements
    • Thanks to Dennis Geels and Sean Rhea for their work on the BMark benchmark suite

ravenben@eecs.berkeley.edu