Re: Call for Adoption: Cache Digests for HTTP/2

Our report on cache digests for HTTP/2, partially funded by the Swedish
Internet Development fund:

https://if-report.shimmercat.com/dirhtml/

The main content of the report are some numbers regarding per-site cache
size, which can be used to estimate the size of the cache digest.  Hope it
can be of some use.

Best regards,

./Alcides.


On Mon, Jun 27, 2016 at 3:20 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 27/06/2016 8:21 p.m., Alcides Viamontes E wrote:
> > I just came gain over these emails and there are a few things which I
> don't
> > completely understand.
> >
> >
> >> Also, since cache digests are scoped to the lifetime of the connection
> >> they're sent within, they can't grow indefinitely, in practical terms.
> And,
> >> of course, servers can discard digests if they don't want to keep the
> state.
> >>
> >
> > Isn't the cache supposed to contain assets obtained during previous
> visits?
> > In that case, wouldn't the cache digest contain assets that the browser
> > obtained in a previous connection?
> >
>
> If viewed that way, yes. However the digest itself is not the objects it
> lists. It is supposed to be regenerated from the cache state at the
> beginning of the newer connection. So objects which have been dropped
> out of the cache since that older connection are not even considered for
> the new digest.
>
>
>
> >
> >>
> >> Finally, clients aren't required to represent the complete state of
> their
> >> cache in a digest; they're allowed to choose what representations to
> >> include, so (for example) a very large cache can use a heuristic to
> include
> >> only the most likely candidates in a digest, to limit its size.
> >>
> >>
> >>> We turn on cache digests during development, and we have seen the cache
> >> digests grow due to the accumulation of different versions of assets.
> >> Because we are using a cookie implementation, we can have the server
> reset
> >> the cookie when it gets too big. Would that be possible  with the
> current
> >> draft?
> >>
> >> Yes; see the RESET flag.
> >>
> >
> > I went to the draft to understand better the RESET flag. What is the
> > typical scenario that this flag is intended for? I can see that RESET
> helps
> > if something happens to the cache; then the browser can use the flag to
> > tell the server. But is the browser supposed to clear the cache often in
> > the middle of a connection? If not, how is this substantially better than
> > just resetting the connection? .. Both Chrome and Firefox reset
> connections
> > when the user clears the cache.
>
> Resetting the whole connection is a huge overhead. Frames with digest
> should not really be frequent enough to warrant a whole connnection
> close and re-open cycle just to optimize away a single bit per frame.
>
> Having the frame cleared when that huge overhead is being paid anyway
> makes sense. But having the dependency the reverse way around would be a
> major pain.
>
>
> >
> > Also, if the server idea of assets held by the browser is bigger than the
> > assets actually held by the browser, the assets won't be pushed, but the
> > browser can just request them "normally".
> >
> > What I was alluding before was close to having the RESET in the other
> > direction, from server to browser, to ask the browser to clear its cache
> > for the current origin. This could be good for a number of use cases, not
> > least of them decreasing the chance of false positives in queries to the
> > digest. But adding a mechanism for the server to clear the browser's
> cache
> > may be a bit out of scope :-( ...
> >
>
> I susect you are mistaking what "cache" is referring to. There are two
> caches involved with these drafts.
> * a cache of URL + objects. Stored on the browser.
> * a cache of digest values. Stored on the server.
>
> The RESET flag on these frame is about sender controlling the cache of
> digest values on the recipient. So it makes no sense to send it from the
> agent which holds the cache, to the agent which does not.
>
> It can be used to indicate to the server that the browser objects cache
> just got wiped for some unspecified and otherwise irrelevant reason.
>
> Amos
>
>
>


-- 
Alcides Viamontes
www.shimmercat.com