A Scalable Web Cache Consistency Architecture

1. A Scalable Web Cache Consistency Architecture Haobo Yu, Lee Breslau, Scott Shenker SIGCOMM 99 Presentation : Cheolhyo Lee Internet Server

2. Contents • Introduction • Previous approach • Main approach • Analytical performance evaluation • Simulation • Additional design issue • Conclusion • Critiques Internet Server

3. Introduction • Multicast-based invalidation • Caching : • Advantages • lowers the load on servers • reduces the overall network B.W. required • lower the latency of responses • Disadvantages • inconsistent pages • Perishable pages - sensitive to being stale • Goal : Ensure relative freshness => demonstrate that a scalable web consistency architecture design is possible Internet Server

4. Previous Approaches : Time-To-Live • A request arrives at a cache after the TTL for the requested page has expired => the cache send IMS(If-Modified-Since) message to the server • Small TTL <-> mitigates the benefits of web cache • Poll-always : TTL=0 - generate IMS for every request • longer unmodified, longer likely to be unmodified=> Adaptive TTL :At the first request after each TTL expiration,TTL = K*(current time - last modification time) • Do not give an upper bound on the staleness of a page Internet Server

5. Previous Approaches : Invalidation • Invalidation Scheme - Servers to send explicit invalidation signal to caches when pages are modified. • Each servers keeps track of all clients who have requested a particular page -> when that page changes, notifies those client • Servers have an invalidation contract with the clients: scaling problem arise • Multicast - Assigning multicast group to each page • somewhat related with the idea of pushing content • another burden at routers : order of addresses, the rate at which clients would be joining and leaving • Another scheme - information including invalidation and delta-encoded page updates (for related pages ) Internet Server

6. Previous Approaches : Lease • Combine features of the TTL and invalidation • Whenever a cache stores a page, it requests a lease from the server • Whenever a page changes, the server notifies all caches who hold a valid lease of the page : the invalidation contract applies only while the lease is valid • If a cache receives a request for a page with an expired lease, it renews the page’s lease by sending an IMS to the server before responding to the request • While lease is valid : invalidation schemeThe expiration of leases resembles the TTL approach. • Two volume lease algorithms • long lease : every page, short lease : to sets of pages volumes • reduce the validation traffic of short leases Internet Server

7. Main approach • Proposed architecture=> Multicast-based invalidation + hierarchy of caches • multicast groups are associated with caches • caches send heartbeats to each other • the unit of our lease is all pages in a cache • caches maintain a server table to locate where servers are attached to the hierarchy • invalidation messages(sent up and down) for a page are filtered so as to limit the scope of distribution • client requests are forwarded through the caching hierarchy to the server or to the first cache containing a valid copy of requested page Internet Server

8. Main approach (cont’d) • 1) Simple description of protocol • all caches are infinite, all pages are part of this consistency arch. • There is single stable caching hierarchy with all caches having synchronized clocks, and no caches fail Internet Server

9. Main approach (cont’d) • Hierarchy • Fig.1 • Heartbeats • each group owner sends out a periodic heartbeat message to its associated multicast group T/t • T/t : t - time period between heartbeats, T - volume lease of length • current time - the last heartbeat’s timestamp > T : all pages from that server expires and all pages are marked as invalid Internet Server

10. Main approach (cont’d) • Invalidations • Read pages : invalidate pages that have been requested after they were last rendered invalid=> each heartbeat message contains a list of all read pages at the present cache within the last time period T • If a read page is rendered invalid at the parent cache at time t=0 then by time t=T, each child cache has either received a heartbeat with an invalidation for that page or has expired the lease from that parent cache • child cache that had previously valid copy of page will mark it invalid and propagate iff the page was previously read Internet Server

11. Main approach (cont’d) • Attaching servers • Primary cache : each web server is attached to a cache • each server reliably unicast a JOIN message to its primary cache • upward to the tip-level cache -> the parent cache source a server from a child cache • server routing table : each cache has a listing of those servers it sources -> Fig.2 Internet Server

12. Main approach (cont’d) • Fig. 2 Internet Server

13. Main approach (cont’d) • Attaching servers • top-level cache knows all servers attached • servers send (via unreliable unicast ) periodic heartbeats to their primary cache, also piggybacking invalidations of any read pages • every child cache who sources at least one server must unicast heartbeats to its parent with invalidations • each upstream cache is said to maintain an invalidation contract with its immediate downstream cache for any page that has been read by a downstream cache • LEAVE message : time period T has passed without cache C1 hearing from cache C2 from whom it sources a server - invalid Internet Server

14. Main approach (cont’d) • Handling requests • clients can attach to any cache : the client’s primary cache • when a client request a page, it sends the request to its primary cache • the primary cache checks to see if the page is resident in the cache • if it is not -> the cache forwards the request to the next cache designated by the server routing table • if the request is fulfilled -> the response takes the reverse path through the caching hierarchy towards the clients Internet Server

15. Main approach (cont’d) • 2. Discussion • Property 1 : If there are no invalidations in transit or waiting to be sent, then if a cache C in the hierarchy has a page P marked as invalid, then no downstream cache considers P valid • Property 2 : When a cache C receives an invalidation for a page P marked as invalid, it may safely discard the invalidation without affecting the resulting state of all downstream caches • Property 3 : Assume that each cache uses the same timeout period T. Assume that there are H cache hops between server S1 and client C2. The maximum staleness of a page is HT • Property 1 and 2 : reduce redundant invalidation traffic • Property 3 : set an upper bound of page staleness for every cache Internet Server

16. Main approach (cont’d) • 3. Adding push to the architecture • Pushing data : reduce first access latency • Selective push : push only the delta’s from the previous version of page • on the way up : via unreliable unicast • on the way down : use a single unreliable multicast sent to a cache’s multicast group • Selection for the push page • Ap : a counter for every cache(and the server) • push bit : for each of its push pages • if ‘1’ -> the cache will forward all pushed updates of the page to all of its downstream caches Internet Server

17. Main approach (cont’d) • A cache receive an invalidation of page P -> Ap = Ap - a • A cache receive a request for page P -> Ap = Ap + b • If Ap > threshold -> push bit = 1, otherwise 0 • let each downstream cache notify its immediate upstream cache when a pushed page is first read and forwarded recursively until they hit a read page. • CMP(Continuous Multimedia Push) • assigns unique multicast group to every popular page and continuously multicasts pages to their groups: when pages are popular and frequently change - good • LSAM • assigns one multicast group per topic Internet Server

18. Analytical performance evaluation • Assume • Caches are infinite, behavior on a per-page basis • message generation behavior for a given page is indpendent of what happens for all other pages • no delay between when invalidations are generated and their being sent out • Omniscient TTL(OTTL) • caches know when a page has been modified and only send the IMS request in those cases. • Poll-always(PA) - TTL=0 • BINV - basic invalidation scheme with no page pushing • PINV - invalidation scheme with pages always pushing Internet Server

19. Analytical performance evaluation ( cont’d ) • Patterns of read and writes arriving at a cache • WR, RR, WW, RW ( depend on the order of read and write) • Table 1 : • hit rate : PINV < BINV, OTTL < PA • response time : PINV < BINV, OTTL < PA • B.W. is less clear • OTTL : less B.W. • PA uses less B.W. than BINV iff 2r < w • B.W. of control messages can be ignored -> server hit counts and response times are main performance criteria between BINV and PA • PINV eliminates hit count and delays at the cost of increased B.W. Internet Server

20. Analytical performance evaluation ( cont’d ) • Table 1 Internet Server

21. Simulations • Simulator : ns simulator • BINV, SINV, PINV, PA, ATTL, FTTL, OTTL • User-centric metrics : client response time and staleness(maximum and average staleness, stale hit rate) • Infrastructure-centric metrics : total network B.W. ( in byte-hops), the B.W. at the server, the rate of request(GET and IMS) at the server • Low average staleness is a performance requirement and how much B.W. and delay are incurred by the protocols to achieve a particular level of staleness Internet Server

22. Simulations ( cont’d ) • 1) Two-level caching hierarchy • The workload in our basic scenario to have only single page • The performance of the consistency protocols on the reading and writing patterns of a page • Write-dominated page : w/r = 10, read-dominated page : r/w = 5 • Fig.3 Internet Server

23. Simulations ( cont’d ) Internet Server

24. Simulations ( cont’d ) • RD case – Table 2 • WD case – Table 3 • BINV’s performance advantage is reduced • SINV : like BINB in the WD case, like PINV in the RD case • Major benefits of invalidation scheme : saving of response time and server hit count • Assume : h(heartbeat rate ) > wH (w:write time, H:# of cache hops) • 2) More complex topology – 3-level caching hierarchy • The basic relative trends is unaffected • BINV’s advantage are greatly reduced in WD case compared with the RD case Internet Server

25. Simulations ( cont’d ) Internet Server

26. Simulations ( cont’d ) • 3) More complex workload – Table 6, 7 • Until now, Poisson workload used • Compound pages : the page contains multiple objects, reading and writing processes that are heavy-tailed and processes that are uniformly distributed • Trace-driven workload consisting of the read sequence of a single page extracted from a real trace-> Poisson model with an average of one modification per hour • The popular page : write-dominated, unpopular page : read-dominated Internet Server

27. Simulations ( cont’d ) • 4) The effect of packet losses – Table 8, 9 • Both invalidations and pushed updates : via unreliable multicast • Invalidations are less vulnerable to packet loss than pushes • Increases the bandwidth and response time for all the protocols • Staleness and stale hit rate are a little increased. • 5) Related work • It takes less or the same B.W. as ATTL while achieving the same level of page staleness and resulting in much less server load and client response time • Single-page workload : precise effect of different reading and writing processes • Average staleness • Operating regimes with much lower staleness measures than previous studies Internet Server

28. Additional design issues • Clock skew • Finite cache • Failure recovery • Direct request • Multiple hierarchies and Multi-Homing • Supplying service to a subset of pages • Deploying in existing cache hierarchies Internet Server

29. Conclusion • Web cache consistency protocol based on invalidation • Previous work, multicast invalidation with volume lease + incorporating them within a caching hierarchy • Heartbeat rate h > the writing rate * the # of hops => The invalidation approach is very effective in keeping pages relatively fresh • Pages are write-dominated => offers few advantage • Pages are read-dominated => significant reduction in server hit counts and client response time • In both cases, similar or less B.W. than the TTL style protocol Internet Server

30. Critiques • Strong Point • Proposed scalable web cache consistency architecture : caching hierarchy and application-level multicast routing to convey the invalidation • Demonstrated technically feasible : consistency arch. • Well organized contents • Weak point • Use a set of relatively stable and well-managed caching hierarchies • Critiques • where the root cache should be located. • The imbalance architecture of tree. –> simple architecture is better Internet Server