A caching hierarchy requires ISPs to invest in caches. But ISPs and Content distribution networks (e.g. Akamai [2]) are aggressively introducing caches throughout the world in order to reduce average latency and bandwidth usage. Furthermore, no fundamental changes need to be made to TCP/IP or routers in order to introduce caches into the Internet. On the other hand, multicast protocols operate at the network and transport layers. Because multicast requires fundamental changes in the Internet, widespread deployment of multicast in the Internet continues to be far way.
One of the applications of multicast is the distribution of Web documents. In this chapter we showed that unless a Web document changes very frequently, caching distribution gives lower latency and bandwidth usage than multicast. The reduced latency is mainly due to the fact that with multicast the transmission rate for a document is the bottleneck rate between server and client; for caching, the transmission rate is the bottleneck rate between the nearest cache with the document and the client. If a document changes very frequently, then CMP gives lower average latency than a cache hierarchy. This is because in a cache distribution
when a document changes very frequently, an up-to-date document will rarely be available in a nearby cache. Additionally, requests for frequently changing documents will travel through top-level caches that can be congested, resulting in high queuing delays.
In this chapter we assumed a typical3-tier caching hierarchy. However, our analysis can be easily extended to consider a caching hierarchy with a different number of cache tiers (See Chapter 3). Intuitively, the higher the number of cache tiers, the higher the probability to find an up-to-date document in a nearby cache, with high transmission rates. Therefore, when the number of cache tiers increases, the update period for which CMP performs better than hier-archical caching becomes even smaller. In this chapter we also assumed a lossless network.
In the case of a lossy network where reliability is required, the relative latency performance of hierarchical caching and multicast would not be modified since reliability increases the mean number of transmissions per packet by a similar factor [76]. However, the relative bandwidth usage of reliable multicast versus reliable hierarchical caching would increase since multicast servers need to keep transmitting information through the International path until the most lossy client has reliably received the document.
Chapter 3
Further Advantages of Caching Infrastructures
In the previous chapter we showed that except for hot and frequently changing information, hierarchical caching has lower latencies and bandwidth usage than multicast. In this chapter we further study the performance advantages of hierarchical caching and extend our model to take into account different factors of a hierarchical caching such as the number of cache tiers or the disk requirements at the caches. In particular we study how a caching infrastructure can reduce the number of polls to the origin server when documents are frequently and randomly updated and clients must receive the most up-to-date information. In the case where popular information is frequently updated and changes randomly , the number of if-modified-since polls may overload top-level caches and origin servers. For this scenario we present new schemes for performing a push distribution using a caching infrastructure. We show how a caching hierarchy with a small number of tiers (i.e. three of four) can implement an application-level multicast distribution, mimicing the performance of IP-multicast. In the case where intra-domain multicast is available inside an ISP, we also explain how to combine a caching hierarchy with an intra-domain multicast distribution among cache tiers. This caching and multicast distribution scales very well with the number of documents, requiring only a small and fixed number of intra-domain static multicast trees.
61
3.1 Introduction
One of the main drawbacks of caching is that receivers may obtain stale documents. The current HTTP 1.0 protocol provides several mechanisms to keep cache consistency. Each document has a time-to-live (TTL) which is set by the server and indicates for how long the document will remain unchanged. If the server updates its content at fixed known intervals (i.e. periodically) the cache knows exactly when the document is fresh or stale without con-tacting the server. However, many times the origin server can not foresee when its documents are going to change and therefore it can not provide an accurate time-to-live. In this situation when the TTL expires the cache checks the document’s consistency with the server. The cache can send an “if-modified-since” request to the origin server with a time-stamp. Upon reception, the server checks whether the document has been modified since the time-stamp.
If so, the server returns the code “200” and the new copy; otherwise, the server returns the code “304”, which stands for document unmodified.
The difficulty with the TTL approach is that it is often hard to assign the appropriate time-to-live of a document. If the value is too small, the server is burdened with many “if-modified-since” messages, even if the document is not changed. If the value is too large, the probability that the user sees a stale copy increases. The adaptive TTL approach tries to handle this problem by allowing the cache manager to assign a time-to-live value based on the observed lifetimes of the document. If caches are asked to deliver the most up-to-date copy to the receivers, a pooling every time mechanism must be used. The cache sends an
“if-modified-since” request every time that a request for a document hits the cache [58].
Some new protocol headers concerning caching have been introduced in version 1.1 of HTTP [41], which is currently being deployed. This new headers provide significant im-provement over the mechanisms used in HTTP 1.0. The new headers allow the origin servers to specify the maximum time that a document may be kept at the caches (max-age). Addi-tionally, clients can specify the degree of staleness acceptable for a certain document, which relaxes the inflexible reload option that always polls the origin server.
In this chapter we study the impact of hierarchical caching in reducing the number of
if-modified-since polls that arrive to the origin server when a polling every time mechanism is used and servers can set a certain max-age value. Using analytical models and trace-driven simulations we quantify the max-age interval that servers should set such that a caching hierarchy can filter out most of the if-modified-since polls to the origin server.
In the situation where documents change randomly or very fast, servers can not ensure even a small time interval during which a document is up-to-date and using a polling every time scheme generates too many poll requests to the origin server and does not scale. In this latter case, a push distribution should be implemented. In this chapter we consider how a caching hierarchy can implement a push distribution and present the benefits of using a caching hierarchy. Pushing through a caching hierarchy requires little state information at the origin server and the caches and requires little modifications to the existing infrastructure.
Though multicast may seem like a natural way of pushing information, when the number of documents delivered with multicast is high, it may lead to an unscalable IP-multicast architecture due to the high number of multicast trees. We present a new pushing scheme that combines a caching architecture and intra-domain multicast in between cache tiers. With a caching and multicast push, intermediate caches act as application level filters, only requiring a small and fixed number of static multicast trees, independently of the number of documents transmitted. In addition, the multicast trees are local to an ISP, thus, there is no need for a fully developed IP-multicast distribution.
The rest of this chapter is organized as follows. In Section 3.2 we extend our model from Section 2.2 so we can study the impact of other parameters in hierarchical caching.
In Section 3.3 we calculate the total polling rate at the origin server with and without a caching hierarchy. We also calculate the disk space requirements at the caches. Section 3.4 describes the push scheme through a caching hierarchy and quantifies the state information required at the origin server and the caches. Section 3.5 studies a push scheme through a caching hierarchy combined with a multicast distribution among caching tiers for popular documents.