September 24, 2007The 3 rd CSAIL Student Workshop Byzantine Fault Tolerant Cooperative Caching Raluca Ada Popa, James Cowling, Barbara Liskov Summer UROP CSAIL, MIT

September 24, 2007 The 3 rd CSAIL Student Workshop 2 Outline Introduction Motivation System Description Discussion Conclusions

September 24, 2007 The 3 rd CSAIL Student Workshop 3 Introduction Cooperative caching: multiple peers coordinate their caches Efficiency Scalability Byzantine client: any client that does not behave properly Our contribution is to add Byzantine fault tolerance to cooperative caching

September 24, 2007 The 3 rd CSAIL Student Workshop 4 Motivation Cooperative caching is useless with Byzantine clients  Clients can provide false data Our system is useful for a distributed safe storage system

September 24, 2007 The 3 rd CSAIL Student Workshop 5 System Setting Many clients request/modify pages  Some are Byzantine A storage server  Runs BFT Clients commit transactions at the server Clients implement cooperative caching Need efficient Byzantine fault tolerant cooperative caching on the peer side

September 24, 2007 The 3 rd CSAIL Student Workshop 6 System Overview Optimistic approach  Few Byzantine clients in the common case  Reputation system for efficiency Exploit locality  Organize peers in locality regions

September 24, 2007 The 3 rd CSAIL Student Workshop 7 Optimistic Approach Assumes speculatively that clients are non- Byzantine Upon commit, the server checks if data used was up-to-date Rolls back if not Check is based on hashes Reputation system reduces the number of aborts

September 24, 2007 The 3 rd CSAIL Student Workshop 8 Locality Split peers in locality regions based on their coordinates (eg. Vivaldi) Look up a page in own locality region first Rationale 1. Common case: hot pages are in locality region 2. Fast fetch of data Locality Region Clients

September 24, 2007 The 3 rd CSAIL Student Workshop 9 Page Lookup Consistent hashing function in each locality region: Peer with metadata for Page ID knows which peers store the page Provides replication Page ID Peer with metadata for page ID

September 24, 2007 The 3 rd CSAIL Student Workshop 10 Maintaining Metadata Each client informs the appropriate metadata peer when fetching from the server, updating, or removing a page Metadata peers communicate Server sends periodic invalidation streams (e.g. peer membership)

September 24, 2007 The 3 rd CSAIL Student Workshop 11 Page Fetch Walk-through Server ?Page 5? Look in local cache Ask the metadata node in the locality region Ask the server hash

September 24, 2007 The 3 rd CSAIL Student Workshop 12 Reputation System Each client maintains reputation scores  Initial debit  Debit increased/decreased depending on behavior Is based on information from the server upon commit Fetch from highest reputation peer Clients sign messages

September 24, 2007 The 3 rd CSAIL Student Workshop 13 Discussion Byzantine resilience  Reputation system  Last check performed at server Efficiency  Three short network delays Scalability  Server is offloaded

September 24, 2007 The 3 rd CSAIL Student Workshop 14 Project Status Prototype is designed and implemented Need to evaluate  Efficiency of the reputation system  Average fetch time

September 24, 2007 The 3 rd CSAIL Student Workshop 15 Conclusions First Byzantine fault tolerant cooperative caching system Efficient and scalable We hope it will show good evaluation results

September 24, 2007 The 3 rd CSAIL Student Workshop 16 Thank You Questions?