1. Refreshment Policies for Web Content Caches Edith Cohen AT&T Labs-Research Haim Kaplan Tel-Aviv University Presenting: Edith Cohen

2. Web Content Caches www.cnn.com AS Proxy cache

3. HTTP Freshness Control Cached copies have limited freshness lifetime (time since dispatched from origin until expiration) Expired copies must be validated before they can be used. Body (content) header Cache-directives

4. HTTP Cache Serving a Request No cached copy  GET a fresh copy   Stale cached copy  If-Modified-Since GET a fresh copy “Not-Modified”  update header   “Modified”  update content and header   Fresh cached copy   GET www.cnn.com/WEATHER/

5. “hits” and “misses” hit-rate: c-hit/(c-hit+c-miss) freshness-rate: f-hit/c-hit f-hitf-missc-miss Remote RTTs (latency…) XX Bandwidth usage to remote servers X “traditional”: c-hit ( hit )( miss )

6. Why Pre-Validate ? latency (c-miss) > latency (f-miss) >> latency (f-hit) freshness rate is 50%-70% (f-hits/c-hits) 90%-95% of IMS GET requests return “Not Modified” Low freshness rate impedes cache ability to reduce user-perceived latency Pre-validating (IMS GET) requires little bandwidth

7. How to Pre-Validate ? Strong consistency [….] –requires protocol, Web-server support Predictive pre-validations [….] –Require per-user or related-objects statistics (volumes), possibly server-support. Cache refreshment policies –Refresh selected cached objects as they expire –Implementation that resembles cache replacement policies; no need for Web-server/protocol support

8. Passive Vs. Proactive Passive: Proactive: Requests: Freshness Lifetime Duration: hitmissto origin

9. Refreshment policies What to refresh and how often? –By policy, based on: recency, frequency, freshness-lifetime... Tradeoff: increased traffic reduced latency We define several natural policies and evaluate them using trace-based simulations. Some vendors incorporate ad-hoc policies.

10. Refreshment Policies For each item D, maintain credit(D) When D expires: –If credit(D)>0 Validate(D) credit(D) -- /* decrement credit(D) */ When D is requested: –Update credit(D) (according to policy)

11. Policies passive : credit(D) = 0 recency(k): each request sets credit(D)=k freq(k): if current request is a miss under passive, do credit(D) += k th-freq(h) refresh if #misses_passive(t) > h*(t-t0)/T opt(k):

12. overhead (validations per eliminated f-miss) fraction of f-misses eliminated Simulation results (NLANR)

13. Summary Refreshment is simple and effective –No external support, no involved prediction models –Built-in destination overhead control (per-object: number of requests bounds number of validations). Frequency-based policies outperform Recency- based policies. 25%, 50% of f-misses can be eliminated with 1,2 extra validations per eliminated miss.

14. Future Minimizing pre-validations overhead –Refresh off-peak, group objects with same server. Refreshment policies and predictive pre- validations differ in implementation and scope (different sets of eliminated f-misses) –Refreshment exploits locality: effective on f-misses occurring within few freshness-lifetime durations after previous request. –Predictive pre-validations exploit correlations between objects. Potential for co-deployment