Data Consistency in the Structured Peer-to-Peer Network

1. Data Consistency in the Structured Peer-to-Peer Network Cheng-Ying Ou, Polly Huang Network and Systems Lab 台灣大學電機資訊學院電機所

2. Roadmap • Background • Related Works • Problem Definition • Chord • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

3. Structured P2P • Distributed Hash Table (DHT) • A peer or data has a unique ID (key) • Key is generated by a hash function • A peer is responsible for a key space • Store data with keys within this range We want to keep data on P2P network Chord Key space: (8, 14] D9, D11, D14

4. The Challenge of Replica Consistency • Churn • Peers join, leave, fail randomly • Fault-tolerant • Replicas to restore lost data • Updated frequently • Inconsistency between replicas Data consistency problem

5. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

6. Replica Consistency Enhancements • B. Temkow, A.-M. Bosneag, X. Li, and M. Brockmeyer, “PaxonDHT: achieving consensus in distributed hash tables,” in Proceedings of the 2005 symposium on Applications and the Internet, 2006 • A. Muthitacharoen, S. Gilbert, and R. Morris, “Etna: a fault-tolerant algorithm for atomic mutable DHT data,” MIT-LCS-TR-933, Jun 2005 • Paxos • Each peer can do consensus • Request all values of replicas from other peers • Pick the latest version • Commit this value back to all replicas • Distributed consensus algorithm • 3-phases message exchanges (atomic updates)

7. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

8. Problem Definition • How much do these enhancements help to improve the data consistency?

9. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

10. Chord Protocols • Join • Find the successor by the key ID of the new peer • Stabilize • Check if the predecessor of the successor is itself periodically • If not, change the successor to the new one [2] I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan, “Chord: A Scalable Peer-To-Peer Lookup Service for Internet Applications,” in Proceedings of the 2001 ACM SIGCOMM Conference, 2001, pp. 149-160 Before joining Before stabilizing After stabilizing [2]

11. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

12. Replica Management System • Rely on the underlying DHT • N replicas • Stored on the first N successors • Update • Update the value of data in backup storages • Restore • Ping periodically • If the predecessor doesn’t response • Fetch the backup objects within new key space • Restore them into its storage • Expand its key space • Remove other backups (2, 8] Partial ability of replica consistency (8, 14] (2, 14] (2, 8] (2, 8] (2, 8]

13. Roadmap • Background • Related Works • Problem Definition • Chord • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

14. Replica Consistency Enhancement • Global Information • No message exchanges • Do consensus before restoring • Between whole backup storages • Compare all replicas • Keep the one with the latest value • Restore the lost ones to the backup storage D3 D3,D5 D3,D5 D3,D5

15. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

16. Simulation Setups • Rocketfuel topology (AS1755) • 492 peers • Simulation time: 240000s (5 rounds) • 5 replicas[3] • Churn • Session life length • Distribution: Pareto [4][5] • Average: 1, 2, 3, 4, 5 hours [4] [5] • From file sharing (eMule) to Skype superpeer • Inter-session life length • Distribution: Exponential [4][5] • Average: 438.5, 877, 1315.5, 1754, 2192.5 minutes [4] [5] [3] J.Li, J. Stribling, T.gil, R.Morris, and F. Kaashoek, “Comparing the performance of distributed hash tables under churn,” 2004 [4] S.Guha, N.Daswani, and R. Jain, “A experimental study of the skype peer-to-peer VoIP system,” 2006 [5] M. Steiner, E. W. Biersack, and T. Ennajjary, “Actively monitoring peers in KAD,” 2006

17. Metrics • Ratio of availability • Data are not lost and stored on correct peers • Ratio of inconsistency • Data don’t have latest version of value • Collected at the end of the simulation • Average of 5 results

18. Availability • Enhancement is useless • Replica management system • It is seldom that losing data in the backup storages

19. Inconsistency • Packets with acknowledgement & re-sending • If the updating packets cannot be delivered successfully, this peer will be thought as a failure peer.

20. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

21. Conclusion • Even when the churn rate is high • Replica consistency enhancement doesn’t perform better than the original one • A simple replica management mechanism is enough • Replica consistency enhancement appears to be overkill given its implementation complexity • Hopefully, our findings provide insights to the making of cost-effective design decisions

22. Q & A