p2p Tutorial - networking

8/11/2019 p2p Tutorial - networking

http://slidepdf.com/reader/full/p2p-tutorial-networking 1/112

1

Peer-peer and Application-level

Networking

Don Towsley

UMass-Amherstwith help of lots of others (J. Kurose, B. Levine, J.Crowcroft, CMPSCI 791N class)

© Don Towsley 2002



2

0. Introduction

background

motivation outline of the tutorial



3

Peer-peer networking



4

Peer-peer networking Focus at the application level



5


Peer-peer applications

Napster, Gnutella, CAN: file sharing

ad hoc networks

multicast overlays (e.g., video distribution)



6


Q: What are the new technical challenges?

Q: What new services/applications enabled?

Q: Is it just “networking at the application-level”? “There is nothing new under the sun” (William Shakespeare)



7

Tutorial Contents

introduction client-server v. P2P architectures

centralized search• Napster

distributed search -flooding

• Gnutella

distributed search -

hashing• CAN, CHORD, …

application-levelmulticast

research issues security modeling more general

applications

summary



8

Client Server v. Peer to Peer(1)

RPC/RMI

synchronous assymmetric

emphasis on language

integration and bindingmodels (stubIDL/XDR compilersetc)

Kerberos stylesecurity – accesscontrol, crypto

messages

asynchronous symmetric

emphasis on service

location, contentaddressing, applicationlayer routing.

anonymity, highavailability, integrity.

harder to get right☺



9

Peer to peer systems actually

old IP routers are peer to peer.

routers discover topology, and maintain it routers are neither client nor server

routers continually talk to each other routers inherently fault tolerant

routers are autonomous



10

Peer to peer systems

nodes have no distinguished role

no single point of bottleneck or failure. need distributed algorithms for

service discovery (name, address, route, metric,etc)

neighbour status tracking

application layer routing (based possibly oncontent, interest, etc)

resilience, handing link and node failures

…



11

Ad hoc networks and peer2peer

wireless ad hoc networks have many

similarities to peer to peer systems no a priori knowledge

no given infrastructure

have to construct it from “thin air”!



12

Overlays and peer 2 peer

systems P2p technology often used to create

overlays offering services that could beoffered in the IP level

useful deployment strategy

often economically a way around otherbarriers to deployment

IP was an overlay (on telephone coreinfrastructure)

not all overlays are P2P (AKAMAI)



13

P2P Architecture Classification

centralized service location (CSL)

Napster distributed service location with flooding

(DSLF) Gnutella

distributed service location with hashing

(DSLH) CAN, Pastry, Tapestry, Chord



14

Centralized Search Architecture

centralized directoryservice

search

directory

Lord of theRings?

A, C

A

B

C

D

E



15

NAPSTER

the most (in)famous

not the first (c.f. probably Eternity, fromRoss Anderson in Cambridge)

but instructive for what it gets right, and

also wrong…

also has a political message…and economic

and legal…



16

Napster program for sharing files over the Internet

a “disruptive” application/technology?

history: 5/99: Shawn Fanning (freshman, Northeasten U.)

founds Napster Online music service

12/99: first lawsuit

3/00: 25% UWisc traffic Napster

2/01: US Circuit Court of

Appeals: Napster knew users

violating copyright laws 7/01: # simultaneous online users:

Napster 160K, Gnutella: 40K,

Morpheus: 300K



17

judge orders napsterto stop in July ‘01

other filesharing appstake over!

gnutella

napster

fastrack

8M

6M

4M

2M

0.0

b i t s

p e r s e c



18

Napster: how does it work

Application-level, client-server protocol over point-to-point TCP

Four steps:

connect to Napster server upload your list of files (push) to server.

give server keywords to search the full list with.

select “best” of correct answers. (pings)



19

Napster

napster.com

users

File list is

uploaded

1.



20

Napster

napster.com

user

Requestand

results

Userrequestssearch atserver.

2.



21

Napster

napster.com

user

pings pings

User pingshosts thatapparentlyhave data.

Looks forbest transfer

rate.

3.



22

Napster

napster.com

user

Retrievesfile

User

retrieves file

4.



23

Napster: architecture notes

centralized server:

single logical point of failure can load balance among servers using DNS

rotation

potential for congestion Napster “in control” (freedom is an illusion)

no security: passwords in plain text no authentication

no anonymity



24

Distributed Search/Flooding



25

Distributed Search/Flooding



26

Gnutella

peer-to-peer networking: applicationsconnect to peer applications

focus: decentralized method of searchingfor files

each application instance serves to: store selected files route queries (file searches) from and to its

neighboring peers respond to queries (serve file) if file stored

locally



27

Gnutella

Gnutella history:

3/14/00: release by AOL, almost immediatelywithdrawn too late: 23K users on Gnutella at 8 am this AM many iterations to fix poor initial design (poor

design turned many people off)what we care about:

how much traffic does one query generate?

how many hosts can it support at once? what is the latency associated with querying? is there a bottleneck?



28

Gnutella: how it works

Searching by flooding: if you don’t have the file you want, query 7 of your

partners. if they don’t have it, they contact 7 of their

partners, for a maximum hop count of 10. requests are flooded, but there is no tree

structure. no looping but packets may be received twice. reverse path forwarding(?)

Note: Play gnutella animation at:

http://www.limewire.com/index.jsp/p2p



29

Flooding in Gnutella: loop prevention

Seen already list: “A”



30

Gnutella: initial problems and fixes freeloading: WWW sites offering search/retrieval

from Gnutella network without providing file sharing

or query routing. Block file-serving to browser-based non-file-sharing users

prematurely terminated downloads:

long download times over modems modem users run gnutella peer only briefly (Napster

problem also!) or any users becomes overloaded fix: peer can reply “I have it, but I am busy. Try again

later” late 2000: only 10% of downloads succeed 2001: more than 25% downloads successful (is this success

or failure?)

www.limewire.com/index.jsp/net_improvements



31

Gnutella: initial problems and fixes (more) 2000: avg size of reachable network ony 400-800

hosts. Why so smalll? modem users: not enough bandwidth to provide search

routing capabilities: routing black holes

Fix: create peer hierarchy based on capabilities previously: all peers identical, most modem blackholes

connection preferencing:• favors routing to well-connected peers

• favors reply to clients that themselves serve large number offiles: prevent freeloading

Limewire gateway functions as Napster-like central serveron behalf of other peers (for searching purposes)

www.limewire.com/index.jsp/net_improvements



32

Gnutella Discussion:

architectural lessons learned?

anonymity and security? other?

good source for technical info/openquestions:http://www.limewire.com/index.jsp/tech_papers



33

Kazaa

hierarchical Gnutella

supernodes and regular nodesmost popular p2p app

>120M downloads

not well understood binaries

encryptedcommunications

supernodes



34

hash tables essential building block in software systems

Internet-scale distributed hash tables equally valuable to large-scale distributed

systems?• peer-to-peer systems– CAN, Chord, Pastry, …

• large-scale storage management systems

– Publius, OceanStore,, CFS ...• mirroring on the Web

Internet-scale hash tables



35

hash tables essential building block in software systems

Internet-scale distributed hash tables equally valuable to large-scale distributed

systems?• peer-to-peer systems– CAN, Chord, Pastry, …

• large-scale storage management systems

– Publius, OceanStore,, CFS ...• mirroring on the Web

Internet-scale hash tables



36

Content-Addressable Network

[Ratnasamy,etal]

introduction

design evaluation

strengths & weaknesses

ongoing work



37


(CAN)

CAN: Internet-scale hash table

interface insert(key,value) value = retrieve(key)



38


(CAN)

CAN: Internet-scale hash table

interface insert(key,value) value = retrieve(key)

properties scalable operationally simple good performance (w/ improvement)



39

Outline

introduction

design evaluation

strengths & weaknesses

ongoing work



40

K V

CAN: basic idea

K V

K V

K V

K V

K V

K V

K V

K V

K V

K V



41

CAN: basic idea

insert

(K1,V1)

K V

K V

K V

K V

K V

K V

K V

K V

K V

K V

K V





43

CAN: basic idea

(K1,V1)

K V

K V

K V

K V

K V

K V

K V

K V

K V

K V

K V



44

CAN: basic idea

retrieve (K1)

K V

K V

K V

K V

K V

K V

K V

K V

K V

K V

K V



45

CAN: solution

virtual Cartesian coordinate space

entire space is partitioned amongst all thenodes

every node “owns” a zone in the overall space

abstraction

can store data at “points” in the space can route from one “point” to another

point = node that owns the enclosing zone



46

CAN: simple example

1

0 1

1



47

CAN: simple example

1 2



48

CAN: simple example

1

2

3



49

CAN: simple example

1

2

3

4



50

CAN: simple example





52

CAN: simple example

node I::insert(K,V)

I



53

(1) a = hx(K)

CAN: simple example

x = a

node I::insert(K,V)

I



54

(1) a = hx(K)b = h y(K)

CAN: simple example

x = a

y = b

node I::insert(K,V)

I



55

(1) a = hx(K)b = h y(K)

CAN: simple example

(2) route(K,V) -> (a,b)

node I::insert(K,V)

I



56

CAN: simple example

(2) route(K,V) -> (a,b)

(3) (a,b) stores (K,V)

(K,V)

node I::insert(K,V)

I(1) a = hx(K)b = h y(K)



57

CAN: simple example

(2) route “retrieve(K)” to (a,b) (K,V)

(1) a = hx(K)b = h y(K)

node J::retrieve(K)

J



58

Data stored in the CAN is addressed byname (i.e. key), not location (i.e. IP

address)

CAN



59

CAN: routing table



60

CAN: routing

(a,b)

(x,y)



61

A node only maintains state for itsimmediate neighboring nodes

CAN: routing



62

CAN: node insertion

Bootstrapnode

1) Discover some node “I” already in CANnew node



63

CAN: node insertion

I

new node1) discover some node “I” already in CAN



64

CAN: node insertion

2) pick random

point in space

I

(p,q)

new node



65

CAN: node insertion

(p,q)

3) I routes to (p,q), discovers node J

I

J

new node



66

CAN: node insertion

newJ

4) split J’s zone in half… new owns one half



67

Inserting a new node affects only a singleother node and its immediate neighbors

CAN: node insertion



68

CAN: node failures

Need to repair the space

recover database (weak point)• soft-state updates• use replication, rebuild database from replicas

repair routing• takeover algorithm



69

CAN: takeover algorithm

simple failures know your neighbor’s neighbors when a node fails, one of its neighbors takes over its

zone

more complex failure modes simultaneous failure of multiple adjacent nodes scoped flooding to discover neighbors hopefully, a rare event

d f l



70

Only the failed node’s immediate neighborsare required for recovery

CAN: node failures



71

Design recap

basic CAN completely distributed self-organizing nodes only maintain state for their immediate neighbors

additional design features multiple, independent spaces (realities) background load balancing algorithm

simple heuristics to improve performance

E l



72

Evaluation

scalability low-latency load balancing

robustness

C N l bili



73

CAN: scalability

for a uniformly partitioned space with n nodes and d

dimensions per node, number of neighbors is 2d

average routing path is (dn1/d)/4 hops

simulations show that the above results hold in practice

can scale the network without increasing per-node

state

optimal choice of d for given n yields

~log(n) nbrs with ~log(n) hops

CAN l l



74

CAN: low-latency

#nodes

L a

t e

n c y

s t

r e t

c h

0

20

40

60

80

100

120

140

160

180

16K 32K 65K 131K

w/o heuristics

w/ heuristics

#dimensions = 2

0

2

4

6

8

10

#nodes16K 32K 65K 131K

#dimensions = 10

CAN l d b l i



75

CAN: load balancing

dealing with hot-spots popular (key,value) pairs nodes cache recently requested entries

overloaded node replicates popular entries atneighbors

uniform coordinate space partitioning uniformly spread (key,value) entries

uniformly spread out routing load

U if P titi i



76

Uniform Partitioning

added check at join time, pick a zone

check neighboring zones

pick the largest zone and split that one

CAN d i ti



77

CAN: node insertion

(p,q)

CAN d i ti



78

CAN: node insertion

CAN d i ti



79

CAN: node insertion

U if P titi i



80

0

20

40

60

80

100

Uniform Partitioning

V 2V 4V 8V

Volume

P e

r c e n

t a g

e

o f

n o

d e

s

w/o check

w/ check

V = total volumen

V16 V8 V4 V2

65,000 nodes, 3 dimensions

CAN R b t



81

CAN: Robustness

completely distributed no single point of failure ( not applicable to pieces of

database when node failure happens)

not exploring database recovery (in casethere are multiple copies of database)

resilience of routing

can route around trouble

St th



82

Strengths

more resilient than flooding broadcastnetworks

efficient at locating information

fault tolerant routing

node & Data High Availability (w/improvement)

manageable routing table size & networktraffic

can build variety of services (application

multicast)

M lti st



83

Multicast

associate multicastgroup with index, I

reverse pathforwarding tree

I

M lti st



84

Multicast

associate multicastgroup with index, I

reverse pathforwarding tree

send to (hx(I),h y(I))

I

W kn ss s



85

Weaknesses

impossible to perform a fuzzy search

susceptible to malicious activitymaintain coherence of all the indexed data

(network overhead, efficient distribution)

still relatively higher routing latency poor performance w/o improvement

nodes coming and going?

Summary



86

Summary

CAN

an Internet-scale hash table

potential building block in Internet applications

scalability O(d) per-node state

low-latency routing simple heuristics help a lot

robust

decentralized, can route around trouble

R l t d W k



87

Related Work

Tapestry Zhao, Kubiatowicz, Joseph (UCB)

Chord Stoica, Morris, Karger, Kaashoek,

Balakrishnan (MIT / UCB) Pastry

Druschel and Rowstron

(Rice / Microsoft Research)

Basic Idea of Chord



88

Basic Idea of Chord

m bit identifier space for both keys and nodes

Key identifier = SHA-1(key)Key=“LetItBe” ID=60SHA-1

IP=“198.10.10.1” ID=123SHA-1

node identifier = SHA-1(IP address)

both are uniformly distributed

how to map key IDs to node IDs?

Consistent Hashing [Kar er 97]



89

Consistent Hashing [Karger 97]

A key is stored at its successor: node with next higher ID

N32

N90

N123 K20

K5

Circular 7-bitID space

0IP=“198.10.10.1”

K101

K60Key=“LetItBe”

Consistent Hashing



90

Consistent Hashing

every node knows of every other node

requires global information

routing tables are large O(N) lookups are fast O(1)

N32

N90

N123

0

Hash(“LetItBe”) = K60

N10

N55

Where is “LetItBe”?

“A has K60”

K60

Chord: Basic Lookup



91

Chord: Basic Lookup

N32

N90

N123

0

Hash(“LetItBe”) = K60

N10

N55

Where is “LetItBe”?

“A has K60”

K60

every node knows its successor in the ring

requires O(N) time



“Finger Tables”



93

Finger Tables

finger i points to successor of n+2 i

table contains O(log N) entries

N120

N80

80 + 20

N112

N96

N16

80 + 21

80 + 22

80 + 23

80 + 24

80 + 25 80 + 26

Lookups are Faster



94

Lookups are Faster

lookups take O(Log N) hops

N32

N10

N5

N20

N110

N99

N80

N60

Lookup(K19)

K19

Issues



95

Issues

joins/leaves

load balancing…

Performance



96

Performance

several measurement studies (Napster,Gnutella) highly variable connection times

lots of freeloading

little analysis

Performance Modeling [Ge etal]



97

Performance Modeling [Ge, etal]

evaluation of different architectures

population of users cycle through on-off states

system provides common services (e.g., search) download services



98

1

M

think timecommonservices

file downloadservices

off-line

µs(Na)

µs(Na,·)

qf (Na,, )

Download Services



99

Download Services

heavy tailed, Zipf preference distribution,p

i

∝ 1/i α

service capacity proportional to popularity µf(Na,i) = pi Cf



Solution Methods



101

Solution Methods

bounding analysis

fixed point solutions

Comparison of Three



102

Architectures CSL has services

bottleneck

DSLF suffers fromoccasional failure tofind file

DSLH more scalable1

10

100

1000

1.E+04 1.E+05 1.E+06 1.E+07 1.E+08 1.E+09

Total Population: N

S y s t e m T

r o u g h p u t : T

CIA

DIFA

DIHA

CSL

DSLF

DSLH

Supernodes (Kazaa)



103

0

500

1000

1500

2000

2500

3000

0 1E+08 2E+08 3E+08 4E+08Total Population: N

S y s t e m T h

r o u g h p u t : T

capacity: supernode/other node = 10/1,

#supernode/#node=1/52.250capacity: supernode/other node = 2/1,

#supernode/#node=1/11.250

capacity: supernode/other node = 1/1,#supernode/#node=1/6.125

Supernodes (Kazaa)

hierarchy helps

placing well-

provisioned nodes attop good idea

Anonymity: Crowds [Reiter98]



104

Anonymity: Crowds [Reiter98]

decentralized P2P solution

anonymous within the Crowd jondo (John Doe)

Proxy

User path based

Path-basedI iti t

Packets passed from initiator, I, to peershi h d li th k t t th



105

Initiator

Anonymity

R

X

Y

Z

I

which deliver the packet to the

responder R.

Crowds • weighted coin flip



106

Paths

R

X

Y

Z

I

g p• spinner

Performance Issues



107

Performance Issues

routing in overlays incurs a performancepenalty can it be quantified?

can it be mitigated?

dynamic nature of user population robustness?

performance?

tradeoff between service location paradigms?

Performance Issues



108

Performance Issues

p2p file sharing vs. CDN/web (Akamai) compare robustness?

compare performance?

handling flash crowds?

p2p measurement kazaa!!

security of p2p how to measure/evaluate security

Wrapup discussion questions (1):



109

Wrapup discussion questions (1): What is a peer-peer network (what is not a peer-to-peer

network?). Necessary:

every node is designed to (but may not by user choice)

provide some service that helps other nodes in thenetwork get service

each node potentially has the same responsibility,functionality (maybe nodes can be polymorhpic)

some applications (e.g., Napster) are a mix of peer-peerand centralized (lookup is centralized, file service ispeer-peer) [recursive def. of peer-peer]

(logical connectivity rather than physical connectivity)routing will depend on service and data

Overlays?



110

Overlays?

What is the relationship between peer-peer and

application overlay networks? peer-peer and application overlays are different things.

It is possible for an application level overlay to be built

using peer-peer (or vice versa) but not always necessary overlay: in a wired net: if two nodes can communicate in

the overlay using a path that is not the path the networklevel routing would define for them. Logical network on

top of underlying network• source routing?

wireless ad hoc nets – what commonality is thereREALLY?

Wrapup discussion questions (3):



111

Wrapup discussion questions (3)

is ad hoc networking a peer-peer application? Yes (30-1)

why peer-peer over client-server? A well-deigned p2p provides better “scalability” why client-server over peer-peer

peer-peer is harder to make reliable

availability different from client-server (p2p is moreoften only partially “up”) more trust is required

if all music were free in the future (and organized), would we

have peer-peer. Is there another app: ad hoc networking, any copyrighted data,

peer-peer sensor data gathering and retrieval, simulation

evolution #101 – what can we learn about systems?



THANKS!

slides can be found athttp://gaia.cs.umass.edu/towsley/p2p-tutorial.pdf

Documents

p2p Tutorial - networking