Applying Sequential Consistency to Web Caching

Transcription

1 Applying Sequential Consistency to Web Caching Francisco J. Torres-Rojas and Esteban Meneses Abstract Web caches have several advantages for reducing the server load, minimizing the network traffic and lowering user latency. However, maintaining consistency among objects is one of the primary concerns when using web caches. To this purpose, some strategies have been adopted. One of them is using the TTL (time-to-live) of the object, which is a lapse of time during which a copy of the object could be considered valid. After that, the object becomes stale and it can be invalidated from the cache or be revalidated later. Moreover, it is important to consider the relationships among all objects in the cache, such that revalidation of some particular object could mean the invalidation of others. This paper presents two mechanisms for maintaining sequential consistency among operations in the objects, using the TTL scheme and logical clocks. Index Terms Web Caching, Sequential Consistency, Lifetime Based Consistency. I. INTRODUCTION Web caching is one of the key techniques to improve web utilization. Reducing the server load, minimizing the network traffic and lowering user latency are some products of web caching, as it is the need of keeping consistent the objects in the cache. Web cachers act as intermediaries between web clients and servers. Then, if a web browser needs some object, it must send a request to the origin server. According to some conditions, the origin server sends the required object to the client. If a web cacher is present, it can catch that object in such a way that the next time the object is required, it could be retrieved locally, avoiding a remote access to the origin server. Most of the time this cache is implemented as a proxy server. So, in this paper the web cacher will be referred as a proxy server. However, offering a web cache methodology implies having several copies of the same object dispersed around cachers. Every time the origin server Francisco J. Torres-Rojas (torres@ic-itcr.ac.cr), Costa Rica Institute of Technology and University of Costa Rica, Costa Rica. Esteban Meneses (emeneses@ic-itcr.ac.cr), Computing Research Center (CIC) - Costa Rica Institute of Technology, Costa Rica changes the object, all copies must be updated. This property is called the freshness of the web cache. Nevertheless, there are also relationships among the changes made to the objects that must be maintained and such a property is called consistency. Sequential Consistency [13] tries to impose a total ordering in all the events occurred in a distributed execution. Given that, some results about the validity of the objects can be guaranteed. This paper presents an application of sequential consistency to web caching, by using TTL to offer freshness and logical clocks to offer consistency. The papers begins with Section II, where web caching environment is explained, continuing with Section III about sequential consistency model. Then, logical clocks and some properties are presented in Section IV. After that, protocols B and C, for inducing sequential consistency in web caching, are presented at Section V. And finally, conclusions and future work are discussed at Section VI. II. WEB CACHING As it was mentioned, web caching is one of the most important features of an efficient web architecture. Following [22] there are several advantages in using web caching: 1) It reduces bandwidth consumption, so network traffic decreases and lessens network congestion. 2) It reduces access latency due to two factors: frequently accessed objects are fetched from a nearby proxy and non-cached objects are fetched in a relatively faster network. 3) It reduces the work load of remote servers. 4) If a remote server is no available, a copy of the requested object could be retrieved from a local proxy. 5) It provides an option to monitor web access pattern. In figure 1, it can be appreciated how a basic web caching scheme works. Clients are constantly making requests that web cachers can solve. But,

2 Client Proxy Cache request response These policies have several performance and scalability implications ([12], [10], [6]). Notice that, in general, it is not clear which consistency protocol is induced by these models. Origin Server Fig. 1. Basic scheme for web caching sometimes objects are not valid in the cache, so proxy cachers must request the object from the servers and then returning it to the client. Nevertheless, some disadvantages emerge as web caching is implemented [22]. One of these is possible lack of consistency. Several web caching models have been developed in the last ten years. Many of them are oriented by the time axis, not the order one. These two dimensions of consistency will be discussed in section III. Web caching schemes can be categorized into three different philosophies [12]: expiration, invalidation and polling. For each object X an original copy is maintained by some site, which will be called owner of X. The only valid operations are read, requesting to view the state of the item and write, updating the value for the item. Write operations are only allowed for the master replica, as read operations are valid for every copy. Here, these models are summarized: Expiration Protocol Client P requests object X from its owner Q at time t, Q sends a copy of the value of X with a time-to-live value. So, every requests for X could be satisfied by the local cache of P during the interval t t. After that interval, the copy of X in the cache expires and the next request must be sent to a remote server. Polling Protocol Client P must be validating object X with its owner periodically in order to see if the value of X has changed. Invalidation Protocol The owner of X remembers all the users of object X. When X changes it sends an invalidation message to all its users. The next request for X in a client P will trigger a downloading of fresh version of X from the owner. A. HTTP support The HTTP protocol [9] offers some capabilities for web caching. The central feature of HTPP for web caching is support for conditional requests. Such requests specify conditions in their headers and servers execute a conditional request and responds with the message body only if the condition is true. Otherwise, the server responds with a special status code 304 Not Modified [16]. Two conditional headers in HTTP for web caching permit making a more efficient a web architecture. The if-modified-since header contains the last modified date of the cached object. When a server receives a request with this header, the server only returns the object if the last modified date of the object at the server is different from the date contained in the if-modified-since header. Also, the if-none-match header contains the entity tag of the cached object. When receiving a request with this header, the server returns the object only if the object s entity tag on the server does not match the tag of the header. HTTP also provides headers for deciding when to check the validity of the cached objects. Thus, a HTTP server can supply an explicit time to live value for the object by using the expires or the max-age headers. The former gives an exact time and date when the object becomes stale, while the latter gives a number of seconds for the liveness of the object. However, there is a more general structure in HTTP. The cache-control header can contain multiple directives that control the use of all the caches that are situated between the client that originally issued the request and the origin server. Then, the list of the cache-control header is a list of directives with values for managing several issues on caches. III. SEQUENTIAL CONSISTENCY For analyzing consistency in web caching, it is convenient to consider the consistency models for distributed systems. After all, we can not ignore how

3 related these two worlds are[4]. In this section, the sequential consistency model will be reviewed. A distributed system consists of N user processes and a distributed data storage. A consistency model is understood as a contract between processes and the data storage.([1], [2], [11], [14], [18], [19]). The global history H of a distributed system is the partially ordered set of all operations occurring at all sites of the system. H i is the sequence of operations that are executed on site i and it is a totally ordered set. If a occurs before b in H i we say that a precedes b in program order. In order to simplify, we assume that all operations are either read or write, and that each value written is unique. These operations take a finite, non-zero time to execute, so there is a time elapsed from the instant when a read or write starts to the moment when such operation finishes. Nevertheless, for the purposes of this paper, we associate an instant to each operation, called the effective time of the operation. We will say that a is executed at time t if the effective time of a is t. If D is a set of operations, then a serialization of D is a linear sequence S containing exactly all the operations of D such that each read operation to a particular object returns the value written by the most recent (in the order of S) write operation to the same object. If is an arbitrary partially ordered relation over D, we say that serialization S respects if a, b D such that a b then a precedes b in S. Intuitively, one would like that any read on a data item X returns a value corresponding to the results of the most recent write on X. Assuming the existence of absolute global time, this behavior can be modeled with linearizability [11]: Definition 1: History H satisfies linearizability (LIN) if there is a serialization S of H that respects the order induced by the effective times of the operations. A weaker, but more efficient, model of consistency is sequential consistency as defined by Lamport in [14]: Definition 2: History H satisfies sequential consistency (SC) if there is a serialization S of H that respects the program order for every site in the system. SC does not guarantee that a read operation returns the most recent value with respect to realtime, but just that the result of any execution is the same as if the operations of all sites were executed in some sequential order, and the operations of each individual site appear in this sequence in the order specified by its program. In figure 2 it can be seen a sequentially consistent history in a), while the required serialization is presented in b). Consistency in distributed systems can be viewed through two different approaches: time and order [2]. The former is related with how fast the changes in one object are made visible to all copies, while the latter is related with the order relationships among the events in the system. This paper presents two protocols where these two axis are considered. A. Lifetime Based Consistency This technique [18] provides consistency across different but related set of objects. It is assumed an architecture where each object has a set of server sites that provide long term storage for the object and where client sites cache objects before accessing them. Cache misses are handled by a server site, which either has a copy of the requested object or can obtain it. Let C i denote the cache of site i, in which it stores copies of objects that have been accessed recently. If a cache miss occurs when accessing object X, some server provides a copy of its current version of X. Once this copy is stored in C i, we denote it as X i. The start time of X i, denoted as X α i is the time when the value of X i was written. The latest time when the value stored in X i is known to be valid is its ending time and it is denoted as X ω i. The interval X α i X ω i is the currently known lifetime of the value stored in X i. The values of X i and Y i (cached in C i ) are mutually consistent if max X α i Y α i min X ω i Y ω i, i.e., their lifetimes overlap and, thus, they coexisted at some instant. C i is consistent if the maximum start time of any object value in C i is less than or equal to the minimum ending time of any object value in C i, i.e., every pair of object in C i is mutually consistent. In general, the lifetime of arbitrary object values is not known. When site i updates object version X i at time t, timestamp t is assigned to both X α i and X ω i. It must be discovered as it goes that no object copy X j (i j) has been overwritten and use this information to advance X ω i.

4 Site Site 1 w 0 (B) w 0 (C)6 r 0 (A)9 r 0 ( B)5 r 1 (B)2 r 1 (A)0 w 1 (A)9 r 1 (B)5 r 1 (C) Site w 2 (C)3 r 2 (A)0 w 2 (B)5 w 2 (C)7 w 2 (A)8 w 2 (A)10 Site r 3 (B)0 w 3 (B)1 r 3 (A)0 r 3 (B)2 r 3 (B)5 Site r 4 (C)0 w 4 (B)2 r 4 (C)3 r 4 (C)6 r 4 (C)7 a) Sequentially Consistent Execution r 4 (C)0 r 3 (B)0 w 0 (B)4 w 2 (C)3 r 2 (A)0 w 3 (B)1 r 3 (A)0 w 4 (B)2 r 4 (C)3 r 3 (B)2 r 1 (B)2 r 1 (A)0 w 0 (C)6 w 1 (A)9 r 0 (A)9 w 2 (B)5 r 1 (B)5 r 0 ( B)5 r 3 (B)5 r 4 (C)6 w 2 (C)7 r 4 (C)7 r 1 (C)7 w 2 (A)8 w 2 (A)10 b) Serialization that respects program order Fig. 2. A sequentially consistent execution objects Fig. 3. X Y Z W Context lifetimes Object in cache using lifetime approach Figure 3 shows several objects in a cache, where all lifetimes have been calculated and Context variable have been updated according to them. IV. LOGICAL CLOCKS In this section two kinds of logical clocks are presented, in order to use them for the consistency protocols of section V. A local timestamp variable called Context i is associated with C i. Its initial value is 0, and it is updated with the rules: 1) When a copy of object X is brought into C i (becoming X i ): Context i : max X i α Context i 2) When object copy X i is updated at time t: Context i : X i α : t Context i keep the latest start time of any object value that is or has been stored in C i. When a copy of object X is brought into C i, its ending time must not be less than Context i, if necessary, other servers or client sites are contacted until a version of X that satisfies the condition is found. Furthermore, any object Y i C i such that Y i ω Context i is invalidated. It is proved in [18] that this protocol induces SC on the execution. A. Vector Clocks Vector clocks ([8], [15], [3], [17]) consist of a mapping between events in a distributed history H and integer vectors. Each site i keeps its own vector clock V i with N entries, where N accounts for the number of sites in the system. Entry V i i maintains the local clock of site i, while V i j keeps track of the activity at site j, from the point of view of site i. Each time an event occurs at site i, its local clock ticks and a vector clock is associated with that event. Also, every message sent in the system is piggybacked with the vector clock corresponding to the send event. Site i updates its vector clock obeying the following rules: V i j 0 0 j N 1 - Initial value.

5 Site 0 <1,0,0> <2,0,0> <3,0,0> <4,0,0> <5,1,3> B. Plausible Clocks Site 1 Site 2 Fig. 4. <0,1,0> <0,2,0> <3,3,0> <3,4,0> <0,0,1> <0,1,2> Vector clock timestamping <0,1,3> <0,1,4> <3,4,5> Each time an internal event occurs: V i i V i i (typically =1) When a message with timestamp T is received: V i j max V i j T j 0 j N 1 V i i V i i Let a H i. We say that a has timestamp V(a), where V(a) is the value of V i at the instant when a was executed. Vector clocks are compared following these rules: v w v j w j 0 j N 1 v w v j w j 0 j N 1 v w v w and j such that v j w j v w k such that v k w k and j such that v j w j Mattern showed in [15] that there is an isomorphism between timestamps obtained from a vector clock when events are executed, and the causality relationship among events in H. Thus, vector clocks satisfy the Strong Clock Condition, where a and b H : 1) a = b V(a) = V(b) 2) a b V(a) V(b) 3) a b V(a) V(b) Definition 3: If v and w are two vector clocks, we say that t is the maximum of them, denoted as max V (v,w), if these conditions hold: v t and w t It doesn t exist a vector clock z such that v z w z z t The definition for minimum (denoted as min V ) is analogous to the one given for maximum. It can be easily verified that given vector clocks v and w, t is maximum(v,w) iff t[k] = max(v[k],w[k]), 0 k N 1, and that u is minimum(v,w) iff u[k] = min(v[k],w[k]), 0 k N 1. In figure 4 it can be appreciated a distributed history where vector clocks timestamp the events. The vector clock techniques provides a logical clock that captures completely the causality relation between events in history H. However, vector clocks require one entry for each one of the N sites of the system. If N is large, several scalability and efficiency problems arise [17]. There are growing storage costs because each site must reserve space to keep its local version of the vector clock and, depending on the particular system, vector times associated with certain events and data structures must be stored as well. Every message must be tagged with the current vector clock of the sender site. Since it can be expected that the total number of messages exchanges increases when the communications of such systems. Charron-Bost proved in [7] that given a distributed system with N sites, it is always possible to find a distributed history whose causality can only be captured by vector clocks with at least N entries. Plausible Clocks [21] do not characterize causality completely, but they can be constructed with a small and constant number of elements and yet they can decide the causal relationship between arbitrary pairs of events with an accuracy close to vector clocks, in particular when the computation follow a Client/Server communication pattern. Definition 4: A logical clock P is plausible if a, b H : a = b a P b a b a P b In the last definition P and P are relations established by P. A plausible clock P assigns unique timestamps to each event. Besides, P never confuses the direction of causality between any two ordered events (i.e., it is an order-preserving map). Thus, if in fact a causally precedes b, P will always report a P b, or if b causally precedes a, P will always report a P b. If P states that a P b, this necessarily is correct, because if the actual causal relation were a b, a b or a b, it would have been reported as a P b, a P b or a P b, respectively [21]. Vector clocks are plausible clocks, but not every plausible clock P characterizes causality, since it is possible that a b, but instead P reports a P b or a P b. Several examples of plausible clocks are presented in [21].

6 Site 0 Site 1 Site 2 Fig. 5. <1,0> <2,0> <3,0> <4,0> <5,1> <0,1> <0,2> <3,3> <3,4> <1,0> <2,1> <3,1> <4,1> Plausible clock REV (R=2) timestamping C. R-Entries Vector (REV ) <5,4> The plausible logical clock REV uses vectors of fixed size R N, which is independent of the number of sites in the distributed system. Site i updates entry i modulo R, since R may be less than N then multiple sites share the same entry in the vector (other mappings between sites and entries of the vector are possible). The mechanisms for timestamp comparison and assignment are similar to those presented above for vector clocks. The timestamps in REV follow the form s V, where s uniquely identifies each site and V is a R-dimensional vector of integers. Definition 5: Let v sv V and w sw W be two REV timestamps, then: v REV w sv sw V sv modulo R W sw modulo R v REV w sv sw V sv modulo R W sw modulo R! #"$ sv sw V W V sv modulo R W sw modulo R w "% sv sw &"% sv REV sw "% sv REV sw Figure 5 presents the same distributed history of figure 4, but timestamped with plausible clock REV, with R=2. v REV V. CONSISTENCY PROTOCOLS In this section we review two consistency protocols that can be applied to web caching, one using vector clocks and the second with plausible clocks. A. Protocol B It is now proposed protocol B [20], whose purpose is to produce executions that satisfy SC by verifying that all the objects store in a cache are mutually consistent among themselves according to SC. Let Clock i be the current logical time of site i. In this case, each site maintains a vector clock. Clock i is copied to Xi α and Xi ω when the local copy X i is updated. Each cache C i has an associated timestamp Context i. When object copy X s is brought from server s into C i (becoming X i ) or when object X i is updated at site i, Context i becomes max V Xi α Context i. Any later start time of a different value of the same object will be after or concurrent with the assigned ending time. SC allows that for all objects X i C i, Xi ω advances as the logical time at the site i progresses. If site i has a cache miss when accessing object X, protocol B executes the following steps: 1) It is requested that a server s sends back a copy of X s such that "% Xs ω Context i 2) Context i is updated to max V Xi α Context i. 3) Y ω i max V Yi ω Clock i for all the local copies of objects Yi ω C i 4) All the local copies of objects Y i C i such that "% Xi α Yi α ' min V Xi ω Yi ω max V Xi α Yi α ( are invalidated. B. Protocol C Protocol C follows the same rules of Protocol B but, in order to use a logical clock whose size is constant and independent of the number of sites in the system, vector clocks are replaced with a plausible clock P. For instance, if the site i has a cache miss when accessing object X, protocol C executes the following steps: 1) It is requested that a server s sends back a copy of X s such that "$ Xs ω P Context i. This copy of X s is inserted in C i and from now on it is denoted as X i. 2) Context i is updated to max P Xi α Context i. 3) Yi ω max P Yi ω Clock i for all the local copies of objects Yi ω C i. 4) All the local copies of objects Y i C i such that "% Xi α P Y α i ) min P Xi ω Yi ω P max P Xi α Yi α ( are invalidated. C. Properties Formal correctness proofs about protocols B and C can be found in [20]. Both protocols induce sequentially consistent executions. That means, for every execution of any of these protocols, it is always possible to build a

7 linear sequence of operations such that local order is respected. SC has the advantage that it is a simple model for programmers, being easy to understand what is happening with the order of events. Protocol B uses vector clocks that are not scalable, but captures precisely all the causality relations among events. Protocol C, on the other hand, is inherently scalable, but some relationships cannot be captured. VI. CONCLUSIONS AND FUTURE WORK Our aim in this paper was to present a new possibility for offering consistency in web caching. It is based on the Lifetime Based Protocol, which uses time lapses for the validity of the object. Such lapses could be obtain with the HTTP protocol as TTL intervals. Additionally, the protocol B supposes the introduction of vector clocks in each site for checking consistency of objects, through order of events. Protocol C uses plausible clocks which are a scalable alternative that also induces SC executions. So, this approach will consider the two different axis of consistency, time and order. As far as we know, the only protocol that considers both senses is BTC (Based Token Consistency, [5]). We are building a consistency framework where the proposals of this papers could be implemented. We are participating in a research project (called SPREAD) in the Computing Research Center at Costa Rica Institute of Technology,which is focused on implementations and properties about consistency models in web caching. REFERENCES [1] Adve, S. and Gharachorloo, K. Shared Memory Consistency Models: A Tutorial. Western Research Laboratory, Research Report 95/7, [2] Ahamad, M. and Raynal, M. Ordering and liness: Two Facets of Consistency?, Future Directions in Distributed Computing, [3] Baldoni, R. and Raynal, M. Fundamentals of Distributed Systems: A Practical Tour of Vector Clocks Systems. IEEE Distributed Systems Online, February, [4] Birman, K. Like it or Not, Web Services are Distributed Objects!, Communications of the ACM. December, [5] Bradley, A. and Bestavros, A. Basis Token Consistency: Extending and Evaluating a Novel Web Consistency Algorithm. Proceedings of the Second Workshop on Caching, Coherence, and Consistency (WC3 02). June, [6] Cao, P. and Liu, C. Maintaining Strong Cache Consistency in the World Wide Web. Proceedings of the 17th International Conference on Distributed Computing Systems. May, [7] Charron-Bost, B. Concerning the size of logical clocks in Distributed Systems. Information Processing Letters 39, pp , [8] Fidge, C. Logical in Distributed Computing Systems. Computer, Vol 24(8), August, [9] Fielding, R., Berners-Lee, T. et al. Hypertext Transfer Protocol HTTP/1.1, Network Working Group RFC 2616, June, [10] Gwertzman, J. and Seltzer M. World-Wide Web Cache Consistency. Proceedings of USENIX Annual Technical Conference, [11] Herlihy, M. and Wing, J. Linearizability: A Correctness Condition for Concurrent Objects. ACM Transactions on Programming Languages and Systems. Vol 12(3), July [12] Kawash, Jalal. Consistency Models for Internet Caching.Proceedings of Winter International Symposium on Information and Communication Technology. ACM International Conference Proceedings Series, [13] Lamport, L., Clocks and the Ordering of Events is a Distributed System. Communications of the ACM, vol 21, July, [14] Lamport, L. How to make a Multiprocessor Computer that correctly executes Multiprocess Programs. IEEE Transactions on Computer Systems, C-28(9), [15] Mattern, F. Virtual and Global States of Distributed Systems. Proceedings of the International Workshop on Parallel and Distributed Algorithms, , [16] Rabinovich, M. and Spatscheck, O. Web Caching and Replication. Addison-Wesley: United States, [17] Schwarz, R. and Mattern, F. Detecting Causal Relationships in Distributed Systems: In Search of the Holy Grail. Distributed Computing, [18] Torres-Rojas, F. J., Ahamad, M. and Raynal, M. Lifetime Based Consistency Protocols for Distributed Objects. Proceedings of the 12th International Symposium on Distributed Computing, DISC 98.September, [19] Torres-Rojas, F. J., Ahamad, M. and Raynal, M. d Consistency for Shared Distributed Objects. Annual ACM Symposium on Principles of Distributed Computing PODC 99, Atlanta, Georgia, [20] Torres-Rojas, Francisco J. Scalable Aproximations to Causality and Consistency of Distributed Objects. PhD Thesis, College of Computing, Georgia Institute of Technology, Atlanta, Georgia, [21] Torres-Rojas, F. J. and Ahamad, M. Plausible Clocks: Constant Size Logical Clocks for Distributed Systems. Distributed Computing. December, [22] Wang, J. A Survey of Web Caching Schemes for the Internet.