On Mon, 9 Aug 1999, Peter Danzig wrote:
> Let me introduce an arguement for why Polygraph should not focus on
> measures of "staleness" other than incorrect interpretation of expire headers.
Peter,
I find it hard to use your OLD/NEW examples as an argument for
not measuring all forms of "staleness" in Polygraph. The examples
themselves are a good illustration of one possible attempt to solve or
reduce some of the HTTP/1.1 problems. We all are excited about what the
evolving approach can bring. However, IMO, a benchmark should try to
test the current practice rather than possible future models.
Many vendors, including NetApp, were pushing for adding IMS requests and
expiration model to Poly. If the consensus is that the model should
include only "correct" expiration times based on NEW VISION, then we
should postpone further development and switch to other urgent features.
We should be prepared for ``they model a dream world!'' kind of attacks,
but that is fine as there are worse things to fear. :)
If Poly users think that we should try to model todays traffic, then I
would argue for inclusion of non-precise Expire: headers and changeable
objects without LMT and/or Expires headers...
Once again, I agree that we should not _focus_ on measures of staleness
other than incorrect interpretation of expire headers, but I see no
reason why those measurements should not be collected and perhaps
reported.
Do you think that measuring the side-effects of HTTP ugliness implies
embracing poor consistency model? One could argue that it actually
highlights the disadvantages of the current approach and encourages
people to think of better alternatives...
In short, if there is a strong feeling that we should simulate "ideal"
object modification conditions, we would be happy to do that. If not,
let's measure as much "staleness" stuff as we can and then see if it is
interesting to report.
Please comment.
Thanks,
Alex.
On Mon, 9 Aug 1999, Peter Danzig wrote:
> OLD VISION: The concepts embedded in the HTTP/1.1 verification model lead to inherently poor
> web design. User's don't know how to set their expire times; web caches don't know
> when to verify content.
>
> NEW VISION: Web servers should automatically create unique names for their embedded
> content. These names can, for example, contain a content signature in the URL name,
> with an infinite expire time. Users never see these names; they appear
> for example, in embedded <img> </img> HTML references. Akamai uses this concept in their
> free flow service. This usage obviates the need for web caches and browser caches to
> validate cached content. This eliminates the staleness in browser caches and web caches.
>
> How does this work? These days, most HTML container pages are personalized and
> non-cachable anyway ( e.g. http://my.yahoo.com). What the web servers should do is to
> take gifs such as http://www.yahoo.com/yahoo.gif and internally map it to a unique name
> that depends on the gif's content signature: http://www.yahoo.com/yahoo.gif/005662256999cc801dde6e86ac12031f
> This uniquely named URL no longer needs to be verified. If the URL changes content, the
> URL in the container page changes: http://www.yahoo.com/yahoo.gif/4cfa72a3d395d8217142e06ae6042188
>
> As a caching community, we should encourage Apache, IIS, and Netscape to modify their web servers to
> assign permanent, unique URLs to embedded content. They may also want to modify
> their access logging to log the pretty name, rather than the unique name. If our
> community pushes this vision into the web server community, our hit rates soar,
> the fraction of validation traffic drops, and the web scales better.
>
> In summary, our community should help "fix" the web, rather than encourage people to use embrace
> a poor consistency model.
>
> I am interested in your comments. I'm more interested to have our community band together
> to lead Microsoft IIS, Apache, and Netscape to move towards a better model of web
> validity.
>
> With respect to polygraph, I don't think that polygraph should encourage fine grain measures
> of freshness/staleness, when we should be working to eliminate the very concept.
>
> Peter Danzig
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:08 MDT
