Ongoing Work on Peer-to- Peer Networks June 19, 2015 Prof. Ben Y. Zhao [email protected].

Ongoing Work on Peer-to-Peer Networks

April 18, 2023

Prof. Ben Y. [email protected]

Ongoing work in P2P Networks [email protected] 2

Large-scale Network Applications Context

trend: applications increasing in scale (clients, distribution) examples: wide-area real-time multicast (PayPerView), data

dissemination (PointCast), large distributed FS mutual sharing of data, inter-node communication

Challenges as networks scale how does A find a particular piece of data?

start with simple name (complex queries later)

how does node A send message to B?IP addresses are too static, need app-level location independent names

how do we make communication reliable?


Adding Name-based Structure to Networks

No network structure any node can connect to any node: flexible scalability issue: too many routing table entries need more flexible naming, IP address too static

Trade off flexibility for scalability name all nodes with application level nodeIDs route incrementally to destination use nodeID as measure of routing progress


Outline Motivation Protocols

routing: Chord, Tapestry/Pastry, etc… dynamic algorithms

Application Interfaces Ongoing Work Wrap-up


Assign random nodeIDs and keys from secure hash incrementally route towards destination ID each node has small set of outgoing routes, e.g. prefix routing

Structured Peer-to-Peer Overlays

To: ABCD

ID: ABCE

A930AB5F

ABC0


What’s in a Protocol? Definition of name-proximity

each hop gets you “closer” to destination ID prefix routing, numerical closeness, hamming distance

Size of routing table amount of state kept by each node as f (N), N = network size

# of overlay routing hops worst case routing performance (in overlay hops, not IP)

Network locality does choice of neighbor consider network distance impact on “actual” performance of P2P routing

Application Interface


Chord NodeIDs are numbers on ring Closeness defined by numerical

proximity Finger table

keep routes for next node 2i away in namespace

routing table size: log2 n

n = total # of nodes

Routing iterative hops from source

at most log2 n hops

0

512

256

128896

768

640 384

Node 0/1024


Chord II Pros

simplicity Cons

limited flexibility in routing neighbor choices unrelated to network proximity

* but can be optimized over time Application Interface:

distributed hash table (DHash)


Tapestry / Pastry incremental prefix routing

11110XXX00XX 000X0000

routing table keep nodes matching at least i

digits to destination

table size: b * logb n

routing recursive routing from source

at most logb n hops

0

512

256

128896

768

640 384

Node 0/1024


Routing in Detail

2175

0880

0123

0157

0154

Neighbor MapFor “2175” (Octal)

Routing Levels1234

2171

2172

2170

2173

2174

----

2176

2177

210x

211x

212x

213x

214x

215x

216x

----

20xx

----

22xx

23xx

24xx

25xx

26xx

27xx

0xxx

1xxx

----

3xxx

4xxx

5xxx

6xxx

7xxx

2175 0 1 2 3 4 5 6 7

0880 0 1 2 3 4 5 6 7

0123 0 1 2 3 4 5 6 7

0154 0 1 2 3 4 5 6 7

0157 0 1 2 3 4 5 6 7

Example: Octal digits, 212 namespace, 2175 0157


Tapestry / Pastry II Pros

large flexibility in neighbor choicechoose nodes closest in physical distance

can tune routing table size and routing hops using parameter b

Cons more complex than Chord to implement

Application Interface Tapestry: decentralized object location Pastry: distributed hash table


Lots and Lots of Protocols Other designs: Kademlia, Coral, etc… For network locality

SkipNet / Skip graphs LAND

For theory Viceroy (dynamic adaptation of butterfly network) Symphony Ulysseus

For performance One-hop / Two-hop Routing (static hierarchy) Brocade (two layered approach for WAN routing) XRing / ZRing


Questions?


Outline Motivation Protocols Application Interfaces

distributed hash tables decentralized object location multi-tiered interfaces

Ongoing Work Wrap-up


How Do We Use Them? Key-based Routing layer

Large sparse ID space N(160 bits: 0 – 2160 represented as base b)

Nodes in overlay network have nodeIDs N Given k N, overlay deterministically maps k

to its root node (a live node in the network)

Main routing call route (key, msg) Route message to node currently responsible for key

Leveraging KBR storage: pick a node by name to store data routing: route messages between nodes by nodeID


Storage: Distributed Hash Tables P2P layer = a hash table

key is object ID write (key, data)

store data at k nodes closest in name to key k is system parameter (replication factor)

data = read (key) read data from any of k nodes close to key


DHT II Pros

simplicity, just store and forget rely on storage layer to keep data available across changes

in node membership servers generally distance in network and fault-

independent Cons

P2P layer controls parameterswhere data is stored, how many replicasone size rarely fits all

lack of network locality


backbone

let application choose where to store data P2P layer provides directory service to locate objects

redirect data traffic using log(n) in-network redirection pointers average # of pointers/machine: log(n) * avg files/machine

k

kpublish(k)

routeobj(k)

routeobj(k)

Storage: Decentralized Object Location


DOLR II Pros

application has control over data placementcan optimize location, replication factor for performance

Cons directory pointers require state in network additional complexity in managing data


Outline Motivation Protocols Application Interfaces Ongoing Work Wrap-up


Many Structured P2P Applications Data storage

file systems, FS backup, stegnographic FS Web Caches, CDNs, DNS services

Search on P2P service discovery, P2P databases

Routing application-level multicast, pub/sub resilient routing tunnels

Others spam-filtering, collaborative network measurement,

machine fault diagnosis


But Few (if any) Are Deployed Deployment outside of research networks

still file-sharing based (Kenosis/BitTorrent, E-Donkey) Why? Is P2P only good for file-sharing?

Consider some factors killer app with real user demand usability (software engineering) incentives vs. per user cost security

How do we do about this?


Addressing P2P Security The problem

lots of users, spread over wide-area, multiple network domains no uniform security policy or management capability result: expect compromised nodes in normal operation

Existing work secure routing: trade off efficiency for improved resilience against collusion prognosis is bleak

one against many (colluding attackers)

An alternative balance the scale: many against many form trusted groups to collaboratively stave off attackers incrementally build trust groups with anonymous verification


P2P Security cont. Mechanisms

highly dynamic collaborative reputation system todo

anonymous communication in P2P under development: Cashmere

Policies / algorithms how to perform anonymous verification how to derive / adapt online reputations

A related topic what are the weaknesses of current P2P systems what are the main methods of attack? how do we perform / protect against these attacks?


Finding the Right Incentive/Cost Model Deployment

current focus on infrastructure services need useful, light-weight apps for home users

Design and implement Quartz lightweight p2p data sharing system store your most critical files (<100MB) online use simple application-specific handlers to provide fast data

synchronization (a la CVS) synchronize your HTML bookmarks across machines synchronize your papers, homework files, financial records

end to end encryption


Other Directions Understanding unstructured P2P systems

understanding content-based centralization and its implications

edge-based measurements of Freenet studies of Maze, an academic P2P system from China

More P2P applications Reliable and efficient event propagation

(large-scale distributed gaming) P2P Ebay, (secure online commerce)


Other Directions cont. Applying decentralized algorithms elsewhere

routing and data management in sensor and ad-hoc networks reduce routing state and flooding traffic energy efficient data aggregation in sensor nets

spectrum allocation and MAC-layer device coordination


Outline Motivation Protocols Application Interfaces Ongoing Work Wrap-up


Finally… Structured Peer-to-Peer Networks are useful (& fun)

holds promise for self-maintaining decentralized networks at Internet scales

relevance to numerous areas in CS sensor networks, ad-hoc routing, security, theory

For more information … see the webpage for my Winter 290

http://www.cs.ucsb.edu/~ravenben/classes/290F see papers from IPTPS:

http://iptps05.cs.cornell.edu/http://iptps04.cs.ucsd.eduhttp://iptps03.cs.berkeley.edu

Ongoing Work on Peer-to- Peer Networks June 19, 2015 Prof. Ben Y. Zhao [email protected].

Documents

Transcript of Ongoing Work on Peer-to- Peer Networks June 19, 2015 Prof. Ben Y. Zhao [email protected].