Hi,
At the recent IRCACHE workshop, there was a BOF on setting up
serves which cache information on behalf of the content providers
(rather than user communities). I've included the BOF description
below. At the conclusion of the BOF, there was sufficient interest in
working on this set of issues to set up a mailing list for further
discussion. This is an informal working group, though somewhat under
the rubric of the IRCACHE effort. The mailing list is available at:
surrogates-request@equinix.com (Majordomo syntax). I encourage anyone
from this group interested in those issues to join the mailing list.
regards,
Ted Hardie
Summary: This BOF is intended to explore the possibility of deploying
cache systems which act primarily on behalf of content providers.
Current cache hierarchies typically work by aggregating user
communities. By pooling the results of content requests from within a
community, caches elminate the need to cross non-local networks for
repetitive requests; by creating cache hierarchies, caching systems
create larger and larger communities. No matter what the size of the
hierarchy, though, these systems act as proxies for the user
communities and endeavor primarily to provide benefits for the
networks serving those communities.
Current caching systems do, of course, help networks serving content
hosts by reducing the traffic they must send to the networks served by
caches. Content networks must still, however, provide transit for
requests by users not served by traditional caches and for requests by
each of the different user communities. As a result, an outward-facing
proxy, or "surrogate", placed at the network border could
significantly reduce internal transit for many networks. Aggregating
content through surrogates would provide a context-sensitive method
for providing benefits to the networks serving the content hosts
similar to those which are currently provided by proxies to the
networks serving user communities.
Since this type of caching is undertaken by an agent with which the
content providers already have a relationship, many of the legal and
economic problems related to the current proxy caching model can be
eliminated. Many of the technical problems, however, remain, albeit in
a slightly skewed form. The formost question is: How does traffic get
to the surrogate? Are layer four switches appropriate for this method
of content delivery? If so, are the problems in this application
(IPSEC, in particular) any easier to solve than in the current proxy
caching paradigm? If transparent redirection is not the answer, how
can we accomplish lightweight notification of surrogate availability?
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:25 MST