1. Ongoing Work on Peer-to- Peer Networks June 19, 2015 Prof. Ben Y. Zhao ravenben@cs.ucsb.edu

2. Ongoing work in P2P Networksravenben@cs.ucsb.edu2 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?

3. Ongoing work in P2P Networksravenben@cs.ucsb.edu3 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

4. Ongoing work in P2P Networksravenben@cs.ucsb.edu4 Outline  Motivation  Protocols routing: Chord, Tapestry/Pastry, etc… dynamic algorithms  Application Interfaces  Ongoing Work  Wrap-up

5. Ongoing work in P2P Networksravenben@cs.ucsb.edu5  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 A930 AB5F ABC0

6. Ongoing work in P2P Networksravenben@cs.ucsb.edu6 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

7. Ongoing work in P2P Networksravenben@cs.ucsb.edu7 Chord  NodeIDs are numbers on ring  Closeness defined by numerical proximity  Finger table keep routes for next node 2 i away in namespace routing table size: log 2 n n = total # of nodes  Routing iterative hops from source at most log 2 n hops 0 512 256 128 896 768 640 384 Node 0/1024

8. Ongoing work in P2P Networksravenben@cs.ucsb.edu8 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)

9. Ongoing work in P2P Networksravenben@cs.ucsb.edu9 Tapestry / Pastry  incremental prefix routing 1111  0XXX  00XX  000X  0000  routing table keep nodes matching at least i digits to destination table size: b * log b n  routing recursive routing from source at most log b n hops 0 512 256 128 896 768 640 384 Node 0/1024

10. Ongoing work in P2P Networksravenben@cs.ucsb.edu10 Routing in Detail 2175 0880 0123 0157 0154 Neighbor Map For “2175” (Octal) Routing Levels 1234 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 012 3 45 6 7 0880 012 3 45 6 7 0123 012 3 45 6 7 0154 012 3 45 6 7 0157 012 3 45 6 7 Example: Octal digits, 2 12 namespace, 2175  0157

11. Ongoing work in P2P Networksravenben@cs.ucsb.edu11 Tapestry / Pastry II  Pros large flexibility in neighbor choice choose 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

12. Ongoing work in P2P Networksravenben@cs.ucsb.edu12 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

13. Ongoing work in P2P Networksravenben@cs.ucsb.edu13 Questions?

14. Ongoing work in P2P Networksravenben@cs.ucsb.edu14 Outline  Motivation  Protocols  Application Interfaces distributed hash tables decentralized object location multi-tiered interfaces  Ongoing Work  Wrap-up

15. Ongoing work in P2P Networksravenben@cs.ucsb.edu15 How Do We Use Them?  Key-based Routing layer Large sparse ID space N (160 bits: 0 – 2 160 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

16. Ongoing work in P2P Networksravenben@cs.ucsb.edu16 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

17. Ongoing work in P2P Networksravenben@cs.ucsb.edu17 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 parameters where data is stored, how many replicas one size rarely fits all lack of network locality

18. Ongoing work in P2P Networksravenben@cs.ucsb.edu18 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 k publish(k) routeobj(k) Storage: Decentralized Object Location

19. Ongoing work in P2P Networksravenben@cs.ucsb.edu19 DOLR II  Pros application has control over data placement can optimize location, replication factor for performance  Cons directory pointers require state in network additional complexity in managing data

20. Ongoing work in P2P Networksravenben@cs.ucsb.edu20 Outline  Motivation  Protocols  Application Interfaces  Ongoing Work  Wrap-up

21. Ongoing work in P2P Networksravenben@cs.ucsb.edu21 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

22. Ongoing work in P2P Networksravenben@cs.ucsb.edu22 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?

23. Ongoing work in P2P Networksravenben@cs.ucsb.edu23 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

24. Ongoing work in P2P Networksravenben@cs.ucsb.edu24 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?

25. Ongoing work in P2P Networksravenben@cs.ucsb.edu25 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

26. Ongoing work in P2P Networksravenben@cs.ucsb.edu26 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)

27. Ongoing work in P2P Networksravenben@cs.ucsb.edu27 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

28. Ongoing work in P2P Networksravenben@cs.ucsb.edu28 Outline  Motivation  Protocols  Application Interfaces  Ongoing Work  Wrap-up

29. Ongoing work in P2P Networksravenben@cs.ucsb.edu29 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 http://www.cs.ucsb.edu/~ravenben/classes/290F see papers from IPTPS: http://iptps05.cs.cornell.edu/ http://iptps04.cs.ucsd.edu http://iptps03.cs.berkeley.edu http://iptps05.cs.cornell.edu/ http://iptps04.cs.ucsd.edu http://iptps03.cs.berkeley.edu