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 ...