Submitted new I-D: Cache Digests for HTTP/2

[Kazuho Oku <[e-mail]>]

Hello,

Yesterday, Mark and I have submitted a new draft named "Cache Digests
for HTTP/2."
https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest/

The draft proposes a new HTTP/2 frame named CACHE_DIGEST that conveys
client's cache state so that a server can determine what should be
pushed to the client.

Quoting from the introduction of the I-D:
    HTTP/2 allows a server to "push" synthetic request/response pairs
into a client's cache optimistically. While there is strong interest
in using this facility to improve perceived Web browsing performance,
it is sometimes counterproductive because the client might already
have cached the "pushed" response.

My estimation is that in some cases a server may be able to push
hundreds of kilobytes of asset files critical to the rendering path
(e.g. CSS and script files) before the main content (i.e. HTML) is
returned from the application server, and having such fingerprint is
essential for determining what to push (for better
perceived-performance) and for determining what not to push (to not
waste the bandwidth).

A more detailed explanation of how it works can be found in the link
below, which describes the test I conducted using H2O HTTP/2 server's
cache-aware server-push feature (this I-D is essentially an effort to
standardize the feature).
http://blog.kazuhooku.com/2015/12/optimizing-performance-of-multi-tiered.html

You may be also interested in the following slides explaining how the
feature is implemented in H2O version 1.5.
http://www.slideshare.net/kazuho/cache-awareserverpush-in-h2o-version-15

Source code of the Golomb-Rice encoder used in the cache-aware
server-push of H2O can be found at:
https://github.com/kazuho/golombset/ (note: it encodes "N" and "P"
differently from the steps defined in the I-D since in the H2O's
implementation the server is capable of maintaining "N" out-of-band).

Please let us know how you think about the proposal.  Thank you in advance.

-- 
Kazuho Oku