Translucent Caching 

A well-known problem in caching architectures is how proxies and
caches find the "next-hop" cache.  An approach to solve this problem
is to have all caches and servers of a given application join a
multicast group.  A proxy or cache multicasts requests to the group
and waits for the closest cache or server to reply.  Clearly, this
approach does not scale and causes high overhead.  Other solutions to
the next-hop cache probelm using IP multicast support are currently
being investigated [Sally's Adaptive]

Traditionally, system designers have avoided solutions that result in
modifications to a widely deployed infrastructure, such as the IP
infrastructure.  Following this design philosophy, solutions to the
next-hop cache problem assume no support from the underlying network.

In our approach, we assume support from routers.  The idea is to make
a request stumble across caches on its way from a client to a server.
If a cache hit occurs, the request does not go any further.  We use
the fact that intermediate routers are on the best path between a
given source-destination pair.  Thus a cache that is close to an
intermediate router should be a good next-hop cache.

Our approach works as follows.  Routers along the way intercept
ICP (or other caching protocol) requests and echo back the
address of the next-hop cache.  The previous hop can then send the
request to the indicated next-hop cache.  This can be done by opening
a (persistent) TCP connection.  Intermediate cache servers cache
next-hop information for future use.  Like any cached object, cached
next hops are assigned a time-to-live, so that they are refreshed
periodically.  Since we don't expect cache location to change very
often, these time-to-live can be set to large values.

The question then becomes how to find the next-hop cache.  Routers
tunnel intercepted ICP requests to a process that keeps information
about nearby cache servers.  This process can be co-located with the
router.  ICP packets are forwarded to the destination if the next-hop
cache is not ``cached''.

Finding nearby cache servers is an open research issue we plan to
investigate.  However, manual configuration `a la Harvest
cache~\cite{harvest-cache} is a reasonable strategy: due to their high
cost, it is unlikely that there will be very many large caches
deployed.  They will probably be located at ``well-known
intersections'' of the Internet.  

For performance, we plan to restrict the number of next-hop cache
lookups along the path between a source-destination pair.  If a
request goes through say 2 or 3 next-hop lookups without hitting a cache,
it is forwarded straight to its destination bypassing any other
next-hop lookups.

We are currently working on a prototyping and deployment solution for
our scheme.  We anticipate that implementing a prototype will be
fairly simple.  For that we need to implement ICP on Apache so that 
commonly used Web servers become ICP-capable.  For routers, we plan to
use Linux which already incorporates an implementation of ICP.