29
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?
Ongoing work in P2P Networks [email protected] 3
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
Ongoing work in P2P Networks [email protected] 4
Outline Motivation Protocols
routing: Chord, Tapestry/Pastry, etc… dynamic algorithms
Application Interfaces Ongoing Work Wrap-up
Ongoing work in P2P Networks [email protected] 5
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
Ongoing work in P2P Networks [email protected] 6
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
Ongoing work in P2P Networks [email protected] 7
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
Ongoing work in P2P Networks [email protected] 8
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)
Ongoing work in P2P Networks [email protected] 9
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
Ongoing work in P2P Networks [email protected] 10
Routing in Detail
2175
0880
0123
0157
0154
Neighbor MapFor “2175” (Octal)
Routing Levels1234
21712172
2170
21732174----
21762177
210x211x212x213x214x215x216x----
20xx----
22xx23xx24xx25xx26xx27xx
0xxx1xxx----
3xxx4xxx5xxx6xxx7xxx
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
Ongoing work in P2P Networks [email protected] 11
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
Ongoing work in P2P Networks [email protected] 12
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
Ongoing work in P2P Networks [email protected] 14
Outline Motivation Protocols Application Interfaces
distributed hash tables decentralized object location multi-tiered interfaces
Ongoing Work Wrap-up
Ongoing work in P2P Networks [email protected] 15
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
Ongoing work in P2P Networks [email protected] 16
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
Ongoing work in P2P Networks [email protected] 17
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
Ongoing work in P2P Networks [email protected] 18
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
Ongoing work in P2P Networks [email protected] 19
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
Ongoing work in P2P Networks [email protected] 20
Outline Motivation Protocols Application Interfaces Ongoing Work Wrap-up
Ongoing work in P2P Networks [email protected] 21
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
Ongoing work in P2P Networks [email protected] 22
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?
Ongoing work in P2P Networks [email protected] 23
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
Ongoing work in P2P Networks [email protected] 24
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?
Ongoing work in P2P Networks [email protected] 25
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
Ongoing work in P2P Networks [email protected] 26
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)
Ongoing work in P2P Networks [email protected] 27
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
Ongoing work in P2P Networks [email protected] 28
Outline Motivation Protocols Application Interfaces Ongoing Work Wrap-up
Ongoing work in P2P Networks [email protected] 29
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
