W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: Report on HTTP Caching subgroup meeting (Feb 2 1996)

From: Carlos Horowicz <carlos@patora.mrec.ar>
Date: Thu, 22 Feb 1996 17:18:29 -0300 (ARG)
Message-Id: <199602222018.UAA01599@patora.mrec.ar>
To: fielding@avron.ICS.UCI.EDU (Roy T. Fielding)
Cc: mogul@pa.dec.com, http-caching@pa.dec.com

....

> 
> > ----------------------------------------------------------------
> > Issue: Cache hierarchies and bypassing
> > 
> > At one point during the day, K Claffy brought up an issue that
> > none of the rest of us had even considered, but we agreed ought
> > to be taken seriously.  This is the problem of how a hierarchical
> > cache, such as is being used in New Zealand, can optimize retrieval
> > latencies for non-cachable resources.
> > 
> > In the New Zealand case, since they have a very limited-bandwidth
> > connection with the rest of the world, they use a national cache
> > to avoid overloading this international link.  They also use
> > additional caches scattered around the country, which normally
> > go first to this national cache but are able to bypass it to
> > go directly to an overseas origin server if the national cache
> > isn't expected to have the appropriate cache entry.
> 
> Yep. [people should know, BTW, that I am half-Kiwi myself and much of
>       the protocol has been designed according to the requirements
>       identified by these hierarchical caching schemes]
> 
This is similar to the argentine case, which is probably worse: province
cities are far away from the capital (where the international links are),
and are connected to it through slow links. In order to optimize bandwidth 
rather than latency, I'm interested in cache replication (some servers
refresh other servers' cache via PUT by running logs of cache reloads),
but I'm not sure if it is an issue for this list.
 
Received on Thursday, 22 February 1996 20:32:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 November 2008 20:51:42 GMT