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

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

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 Key space: (8, 14] Chord D9, D11, D14 We want to keep data on P2P network

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

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

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)

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

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

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

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 Before stabilizingAfter stabilizingBefore joining [2]

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

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] (8, 14] (2, 14] (2, 8] Partial ability of replica consistency

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

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

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

Simulation Setups Rocketfuel topology (AS1755 )  492 peers Simulation time: s (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, , 1754, 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

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

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

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

Roadmap Background Related Works Problem Definition Chord Protocols Replica Management System Consistency Enhancements Evaluation 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

Q & A