Cache Digests
Two of the protocols discussed so far, ICP and HTCP, incur a lookup delay for every cache miss. Before a cache miss can be forwarded, the selection process takes about one network round-trip time to query the neighbor caches. Depending on the proximity of the neighbor caches, this could take anywhere from 10 to 300 milliseconds. Such a delay can be significant, especially for a web page with many embedded images.
The lookup delay exists because a cache doesn’t know a priori which neighbors hold a particular object. Furthermore, it cannot predict which, if any, would return a cache hit for the object. If we can give a cache this advance knowledge about its neighbors, then we can eliminate the delays. We want the best of both worlds: hit predictions without delays.
As mentioned previously, CARP has no forwarding delays. However, it does not meet our requirements because the next-hop cache is chosen based solely on the requested URL. CARP does not care whether the request will be a cache hit or miss. This means, for example, that CARP is not usable in a sibling relationship.
To predict hits in a neighbor, a cache needs to know which objects are stored there. A neighbor’s cache contents can be represented as a database or directory. These directories must be exchanged between neighbors. By looking up objects in the directory, we can predict cache hits. Since a cache’s content changes over time, the directories must also be updated. A primary goal of our new protocol is ...
Get Web Caching now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.