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

[Kazuho Oku <[e-mail]>]

FWIW, I have implemented a simulator of the I-D, which is now
available at https://github.com/kazuho/h2-cache-digest.

When running `make`, it generates a command named
`h2-cache-digest-00`, which can be used as a simulator for the draft
version 00.

It accepts three mode: `--encode`, `--decode`, `--push`; each mode can
be used for encoding / decoding the frame as well as a simulator on
the server-side checking where if a URL should be push (or not be
pushed in case the resource is expected to be cached by the client).

A synopsis of how to use the command can be found on
https://github.com/kazuho/h2-cache-digest#h2-cache-digest-00

I hope this will help people understand how the draft can be
implemented.  Thank you in advance.


2016-01-08 16:17 GMT+09:00 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



-- 
Kazuho Oku