CS491rhc – Security Reading Seminar Dec 11, 2002 Paper: Peer-to-Peer Caching Schemes to Address Flash Crowds Moderated by: Cristina Abad – cabad@uiuc.edu This paper presents Backslash, a collaborative web mirroring system run by a collective of web sites that wish to protect themselves from flash crowds. MOTIVATION: Flash Crowds can cause problems because websites cannot handle the sudden increase of popularity that sometimes occurs. So the question is: how can websites “cheaply” adapt efficiently to the changing resource demands? The proposed solution is to distribute files and/or requests among other peers so as to alleviate the work. HOW IT WORKS: Backslash is transparent to the client. Modifications are only needed on the webservers and reverse proxy caches. Backslash is built on a distributed hash table overlay and uses the structure of the overlay to cache aggressively a resource that experiences an uncharacteristically high request load. When an increased request load is perceived, the Backslash node switches into one of two special modes of operation: pre-overload and overload. In the pre-overload mode, the node sees un-characteristically high load so it diverts subsequent requests to associated resources (images…) away from itself. In overload mode the node is nearly over-run with requests so it redirects all requests it receives to surrogate Backslash nodes and otherwise serves no content. Every Backslash node runs a simplified DNS server to intercept DNS requests caused by URL rewrites. PROS: (Nobody sent me the PROS, so here are some that I remember) * Authors have thought about every issue of the problem * Seems like a reasonable way to approach the problem of flash crowds * Low-cost solution * Has a lot of future work CONS: (by Jalal Al-Muhtadi) 1. "flash crowds" are very short-term phenomena that usually happens when a web owner least expects. Is it justified to take all these precautions to prevent a rare phenomenon? 2. The paper ignores security issues that must be addressed in open solutions like this. How can the protocol handle misbehaving peers? How to prevent web owners from abusing the system and exploiting the protocol to provide them with additional bandwidth. Can the nodes be modified to detect possible abuse? How could malicious peers be prevented from tampering with the information they are caching and serving? Etc. 3. caching information at other locations may have serious legal implications when the data is deemed illegal in some jurisdictions, e.g. MP3, cracks, software serial numbers, porn, etc. 4. the paper describes the protocol at a very high-level, omitting the details and, thus, leaving many questions about the protocol unanswered.