Incorporating P2P Networks in Service Provider Infrastructure - - PDF document

1

Incorporating P2P Networks in Service Provider Infrastructure

Alberto Leon-Garcia & Shad Sharma

University of Toronto

Why P2P for Service Providers?

“Virtual distributed servers” Autonomous execution of applications on

commodity resources

P2P Innovations & Benefits

KaZaA, BitTorrent, Skype Self-organizing, self-managing Reliability Scalability and Performance Cost savings

P2P Broad Applicability

Not limited to rogue operators

Carrier Class Challenges

Reliability, Performance, Security

2

Introduction

• Overlay Topology
• Application layer routing
• Nodes maintain logical neighbours to whom they forward messages
• P2P Applications
• Content Delivery
• Lookups and Search
• Service Virtualization

E.g. P2P HTTP server

Distributed Hashing

Hash table

Defines set of buckets that hold objects

Hash function

Distributes objects into buckets Objects distributed “uniformly” among buckets

Distributed Hash Table

Nodes are the buckets that store objects Objects: files/ resources/ things you want to

find/ store

Structured overlays well suited to providing DHT

services

Predefined positions assigned to peers Peers assigned hash values (buckets)

3

Introduction

TrebleCast Hybrid Overlay

+ Fast & efficient DHT search + Robust, reliable, fast insertion and removal + Resilient to churn

Chord

Structured DHT capable

• verlays

Rigid finger tables

Kademlia

Loosely consistent DHT overlay Relaxed finger tables

Structured Overlay

+ Fast & efficient DHT search O(logB(n)) search time O(logB(n)) search messages Routing table m aintenance required – Not robust under churn

Newscast

Epidem ic protocol based on gossiping

Montressor

Dual layer approach: Newscast substrate

Unstructured Overlays

+ Robust, reliable, fast insertion and removal – Broadcast based search O(m th root(n)) search time O(m x n) search messages

72 73 42 71 70 41 40 69 74 75 44 43 20 21 6 19 68 39 38 67 66 37 36 65 18 5 4 17 16 15 34 35 76 77 46 45 22 23 8 7 78 79 48 47 24 25 26 9 1 2 3 14 13 32 33 10 27 28 11 12 29 30 31 80 49 50 51 52 53 54 55 63 64 61 62 59 60 57 58 56

TrebleCast (1)

• Peers inserted in order in

spiral-like fashion

• Spiral - Notion of layers:
• Provides data redundancy
• Data stored at each layer
• Peers maintain 4 neighbours:
• In, out, left, right
• Successor:
• Peer responsible for replacing a

failed peer

• Successor moves “inwards”

(closer to core)

• Layer indicative of peer

reliability

• Peers closer to core

considered more reliable

4

TrebleCast (2)

• Dual layer approach:
• Newscast substrate
• Grid superstructure
• Adaptable to churn:
• Superstructure repaired through

gossip messages exchanged at Newscast substrate

• Fast adaptive search:
• Search messages exchanged at

superstructure layer

• Lookups under static conditions:

O(logB(n))

• Graceful search degradation

under increasing churn

• Flexible data storage policy:
• Choose location of stored data (at

core for instance)

• Permits flexibility allowing data

redundancy and load balancing

• Robustness and reliability:
• Build overlay around core of

reliable server-like peers

Implementation

TrebleCast implemented in Java Currently used for SIP virtualization

May implement any < key, value> pair storage

based mechanism

Register, store, retrieve, delete: O(log(n)) time

TrebleCast simulator implemented in Java P2P Monitor implemented in Java

Monitors peers in a P2P network Allows basic interaction with peers through virtual

console

5

Pareto Turnover

• Reliable peers

move to overlay core

• Core “protected”

from churn

• Improved search

time (less routing table maintenance)

High Death Rate Low Death Rate

Fast Adaptive Search

6

Static Search Comparison Chord Churn Search Comp.

10

• 1

10 10

1

10

2

10

3

5 10 15 20 25 30 35 40 45 50 55 Churn Rate (Arrival Rate - peers/sec) Average Search Time (# of Hops) Search Time vs. Churn Rate for Chord Networks of Mean Size 10000 (16384 max) Exponential Lifetime Pareto Lifetime

• Aggressive repair

mechanism implemented to maintain Chord structure

• Search degrades

exponentially as Churn rate increases past 10 peers/ sec

7

TrebleCast Churn Search Comp.

• TrebleCast search

degrades under exponential lifetime distribution

• Search remains

almost constant under Pareto lifetime distribution

• Note: Storage

policy chosen so that a core set of reliable peers are responsible for storage

10

• 1

10 10

1

10

2

10

3

2 3 4 5 6 7 8 9 Churn Rate (Arrival Rate - peers/sec) Average Search Time (# of Hops) Search Time vs. Churn Rate for TrebleCast Networks of Mean Size 10000 Exponential Lifetime Pareto Lifetime Exponential Lifetime w/ Bootstrap Server

Conclusions

Treblecast for service provider setting Resilient to churn Fast adaptive search: O(log(n)) Inherent support for data redundancy Flexible data storage & retrieval policy