- From: David W. Morris <dwm@shell.portal.com>
- Date: Wed, 3 Jan 1996 17:19:14 -0800 (PST)
- To: HTTP Caching Subgroup <http-caching@pa.dec.com>
On Wed, 3 Jan 1996, Jeffrey Mogul wrote: > I've almost finished a lengthy writeup on this, but here's a summary > for now (although Dave Morris seems to have had a similar idea, > with a few different details): As in missing or not as appropriate ... ;-:) >[...] > What about network delay? I.e., the server could say "Fresh-until: > 10" but the response could take 20 seconds to get to the cache. We > can solve this by having the cache interpret the delta relative to > when it sends the REQUEST to the server, not when it receives the dah! obviously! We should describe this in such a way that any cache which chooses to more accurately estimate latency would be allowed to do so. I do still believe that 'freshness' is usually not that important for information that changes so fast that network latency overwhelms the fresh interval. On such data freshness is simply a moving window like a delayed ticker tape. The stock market demonstrated major unstability a few years ago, apparently in part at least because programs were attempting to act on data that was already out of date before the action could be completed. In the interest of stability, perhaps the minimum fresh interval (for cachable entities) should be something like twice the time between when the REQUEST is sent until the last byte of the RESPONSE is received. Or a weighted moving average of the same. I hypothesize that over time this will tend to improve caching which will tend to reduce network load which will tend to allow more rapidly updated data to have a shorter fresh interval. Dave Morris
Received on Thursday, 4 January 1996 01:32:53 UTC