Byzantine Fault Tolerant Cooperative Caching Raluca Ada Popa

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

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

Introduction n Cooperative caching: multiple peers coordinate their caches n n n 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 3

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

System Setting n Many clients request/modify pages q n A storage server q n n Some are Byzantine 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 5

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

Optimistic Approach n n n 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 7

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

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

Maintaining Metadata n n n 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 10

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

Reputation System n Each client maintains reputation scores q q n n n 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 12

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

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

Conclusions n n n 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 15

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