Paper #: 2.2.11
Title: Making World Wide Web Caching Servers Cooperate

1. Problems
At the time this paper was written, caching was fairly one-to-one with a lot of bottlenecks and not a lot of efficiency. Also, whether or not your neighbor had cached the same information was irrelevant when you went looking for information. Too many direct downloads were occuring.

2. New Idea and Strengths
-This paper proposes a cooperative network for caching, so that a local network can act as a large, fast cache. This makes sense, since one can assume that any users sharing a network will have at least some similar surfing patterns.
-The need for proxies to be able to redirect is definitely mandatory. Any kind of clustering would need for the client to know to redirect to another server for downloading.
-It seems strange that multicasting amonst proxies wasn't already common by this point, but maybe it just seems obvious in hindsight.

3. Weaknesses and Extensions
-I'm not completely sold that the client needs to know that they are being served by a different proxy. I think it could be done invisible to the client, which would also be beneficial since it would work well with existing browsers / technology.
-I think that beginning the download immediately before hearing from the other proxies is not as negative as the authors make it seem. If the "master" proxy can cease the download when a positive response is received, the total time spent downloading is only equal to the time waiting for a response. When accessing a collection of images at the same page that hasn't been cached, it might take equal amounts of time to download as to find out if each item is in the cache.
-The authors don't talk about making sure the cache is not out of date. What kinds of problems will they encounter while trying to make sure that an old image isn't brought up from the cache?