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

From: Alcides Viamontes E <[email-masked]>
Date: Thu, 7 Apr 2016 20:55:59 +0200

Hi everybody,

Our company got a little bit of money from the the Swedish government  to
do some research on the general idea of cache digests and on anything that
helps this digests proposal evolve forward. As you may suspect, the results
will be public (source code under BSD 3 and technical report under Creative
Commons, AttributionShareAlike). So, regarding the current status of this
proposal, what would you consider the most urgent issue that needs to be
addressed/researched-further/solved ?

In advance, kind thanks for your time.

Alcides Viamontes E. PhD
Zunzun AB.

On Wed, Feb 10, 2016 at 8:26 AM, Kazuho Oku <[email-masked]> wrote:

> 2016-02-10 16:02 GMT+09:00 Stefan Eissing <[email-masked]>:
> > Is PUSHing a HEAD request, unconditional, not what you are looking for?
>
> Thank you for the suggestion.  I hadn't thought about using HEAD, but
> it sounds like an elegant solution.
>
> Pushing HEAD requests with validators stored in the responses would be
> much easier and straightforward to define and / or implement than
> trying to determine how to push conditional requests.
>
> Do the web browsers recognize pushed HEAD requests?
>
> >> Am 10.02.2016 um 02:50 schrieb Kazuho Oku <[email-masked]>:
> >>
> >> Hi,
> >>
> >> 2016-02-09 20:46 GMT+09:00 Alcides Viamontes E <[email-masked]>:
> >>>>> Not something that we've implemented yet, but it's a valid scenario.
> >>>
> >>> Pushing 304 works both in Chrome and Firefox:
> >>> https://drive.google.com/open?id=0B2F2m0rSqGCVWFJnTzRWOWFWQmc , we
> have been
> >>> doing it for some time.
> >>
> >> My understanding is that handling of pushed 304 in Chrome and Firefox
> >> is unreliable.
> >>
> >> When sending a push, a server cannot be 100% certain if the client has
> >> the resource cached.  In other words, there is always a possibility
> >> that the pushed response will be considered as a response to a
> >> non-conditional HTTP request on the client side.
> >>
> >> In other words, browsers that support 304 push should, when matching a
> >> pushed 304 response against a HTTP request, check that the request is
> >> conditional, and use the pushed response only if the request was
> >> conditional (additional checks might be necessary).  Otherwise, the
> >> pushed 304 request must be ignored, and the browser should pull the
> >> unconditional HTTP request.
> >>
> >> However, my understanding is that both Chrome (48.0.2564.103) and
> >> Firefox (44.0.1) don't do the check; they consider pushed 304
> >> responses to be a response to a unconditional HTTP request.
> >> Therefore, there is a chance that you would fail to deliver the
> >> correct content if you use 304 push today.
> >>
> >> --
> >> Kazuho Oku
> >>
>
>
>
> --
> Kazuho Oku
>

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 8 Apr 2016 22:44:28 +0900

2016-04-08 3:55 GMT+09:00 Alcides Viamontes E <[email-masked]>:
>
> Hi everybody,
>
> Our company got a little bit of money from the the Swedish government  to do
> some research on the general idea of cache digests and on anything that
> helps this digests proposal evolve forward.

Wow! Fantastic!

>  As you may suspect, the results

I think what we need most is a research on how large a cache digest would be.

If the size of an average digest is say, for example 100 octets, I
think many of us would be happy on adopting the draft.  On the other
hand if the result is 10,000 octets, I think we need to update the
draft so that a more fine-grained digest (e.g. a digest that only
contains resources that block the rendering path) can be created.

So the question boils down to two.

Q1. How many fresh resources exist per origin?

The size of the cache-digest is proportional to the number of fresh
resources being cached, and it would be of great help if we could find
out the number.

Q2. What is the appropriate value for P?

The size of the cache-digest is proportional to log2(P), so we would
like to select a small but effective value.

If, in average, a client needs to fetch 10 additional resources per
every pull request, a cache digest using P=2 might be still useful,
since in average 5 resources can be pushed.
On the other hand if in many cases a client needs to fetch 1 or 2
additional resources per every pull request, we would need to have a
greater default for P.

Of course there would be other things to look at, but IMO these two
questions are the ones many would be interested to know.

-- 
Kazuho Oku

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Apr 2016 10:53:56 -0300

> Q2. What is the appropriate value for P?

I have some others:

What is the effect of connection coalescing on this? When coalescing,
Is a client better off sending a separate digest for each origin, or
is a single large blob better?

---

From: Alcides Viamontes E <[email-masked]>
Date: Sun, 10 Apr 2016 10:14:28 +0200

Thanks Kazuho,

Regarding your question of how many fresh resources being cached, that will
change from site to site
but we already have some statistical data that we can use to model some
rough estimations.
We will add that to our report.
Also we will try to experiment a bit with a polyfill implementation (can
you point to any already existent one?)
exposed to a little bit of normal traffic,
and see where that get us.

On Fri, Apr 8, 2016 at 3:44 PM, Kazuho Oku <[email-masked]> wrote:

> >> 2016-02-10 16:02 GMT+09:00 Stefan Eissing <[email-masked]
> >:

---

From: Alcides Viamontes E <[email-masked]>
Date: Sun, 10 Apr 2016 10:16:00 +0200

Hello Martin,

We will take a closer look at this. But what is the state of coalescing
regarding browser implementations?

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Apr 2016 14:57:33 +0000

I believe that Chrome and Firefox coalesce when DNS/SANs permit.  Edge/IE currently does not.

From: Alcides Viamontes E [mailto:[email-masked]]
Sent: Sunday, April 10, 2016 1:16 AM
To: Martin Thomson <[email-masked]>
Cc: Kazuho Oku <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Submitted new I-D: Cache Digests for HTTP/2

Hello Martin,

We will take a closer look at this. But what is the state of coalescing regarding browser implementations?

On Fri, Apr 8, 2016 at 3:53 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

I have some others:

---

From: Alcides Viamontes E <[email-masked]>
Date: Mon, 11 Apr 2016 17:32:19 +0200

Thanks Mike,

Can you point to any public-facing website  where connection coalescing
is working?

We haven't been lucky at configuring connection coalescing in our website
and that have led me to believe (perhaps mistakenly) that browsers don't
implement it yet. This page (
https://www.shimmercat.com/en/blog/articles/data-density/ )  for example
pulls resources from three subdomains on the same wildcard certificate,
same web server. Chrome creates a separate connection* for each of them
(seen by looking to chrome://net-internals, also confirmed by looking to
the logs of ShimmerCat). As a side-note, we use SANs at development, and
there there is no coalescing either. Same situation with Firefox.

* Actually Chrome opens  an entire connection pool for media.shimmercat.com
with six sockets, of which only one is used.

On Mon, Apr 11, 2016 at 4:57 PM, Mike Bishop <[email-masked]>
wrote:

> *From:* Alcides Viamontes E [mailto:[email-masked]]
> *Sent:* Sunday, April 10, 2016 1:16 AM
> *To:* Martin Thomson <[email-masked]>
> *Cc:* Kazuho Oku <[email-masked]>; HTTP Working Group <
> [email-masked]>
> *Subject:* Re: Submitted new I-D: Cache Digests for HTTP/2
>
>
>
> Hello Martin,
>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Apr 2016 15:36:41 +0000

You’re correct – I see the same in Chrome; haven’t tried Firefox or sanity-checked the DNS records.  Anyone from the Googly side want to weigh in?

From: Alcides Viamontes E [mailto:[email-masked]]
Sent: Monday, April 11, 2016 8:32 AM
To: Mike Bishop <[email-masked]>
Cc: Martin Thomson <[email-masked]>; Kazuho Oku <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Submitted new I-D: Cache Digests for HTTP/2

Thanks Mike,

Can you point to any public-facing website  where connection coalescing   is working?

We haven't been lucky at configuring connection coalescing in our website and that have led me to believe (perhaps mistakenly) that browsers don't implement it yet. This page ( https://www.shimmercat.com/en/blog/articles/data-density/ )  for example pulls resources from three subdomains on the same wildcard certificate, same web server. Chrome creates a separate connection* for each of them (seen by looking to chrome://net-internals, also confirmed by looking to the logs of ShimmerCat). As a side-note, we use SANs at development, and there there is no coalescing either. Same situation with Firefox.

* Actually Chrome opens  an entire connection pool for media.shimmercat.com<http://media.shimmercat.com> with six sockets, of which only one is used.

On Mon, Apr 11, 2016 at 4:57 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
I believe that Chrome and Firefox coalesce when DNS/SANs permit.  Edge/IE currently does not.

From: Alcides Viamontes E [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, April 10, 2016 1:16 AM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: Kazuho Oku <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: Submitted new I-D: Cache Digests for HTTP/2

Hello Martin,

I have some others:

---

From: Patrick McManus <[email-masked]>
Date: Mon, 11 Apr 2016 12:05:10 -0400

Sometimes you will get race conditions - especially when bootstrapping
whether things are h2 or not, that result in connections that don't carry
any (or perhaps 1) transaction.. and then coalescing moves everything to
one connection going forward.. typically most of that information is cached.

When I load your page in firefox I see 46 streams ( a mix of push and pull)
associated with one connection, 0 streams associated with another, and 1
stream associated with api1.shimmercat.com.. that last one is considered an
anonymous channel and won't be coalesced into your non-anonymous mix...
firefox would in general cache that coalescing information for the rest of
the session (subject to whatever memory cached eviction logic goes on).

if that's not what you're seeing - I'm happy to work with you directly.

(related to the on topic query of cache digests.. they are per origin and
coalescing is cross origin (and as we see often late bound), so I think
sending them as multiple blobs makes the most sense.)

On Mon, Apr 11, 2016 at 11:32 AM, Alcides Viamontes E <[email-masked]>
wrote:

> * Actually Chrome opens  an entire connection pool for
> media.shimmercat.com with six sockets, of which only one is used.
>
> On Mon, Apr 11, 2016 at 4:57 PM, Mike Bishop <[email-masked]
> > wrote:
>

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 12 Apr 2016 15:11:25 +0900

> We will add that to our report.

Great!  I am eager to see that.

> Also we will try to experiment a bit with a polyfill implementation (can you
> point to any already existent one?)

AFAIK there is no client that exactly implements the cache digest
frame (as defined in the draft).
IIRC https://github.com/Jxck/dispenser.js is a work-in-progress SW
code that implements the H2O's variant of the cache digest that uses
Cookies.

-- 
Kazuho Oku

---

From: Alcides Viamontes E <[email-masked]>
Date: Tue, 12 Apr 2016 22:48:57 +0200

Thanks for the Github link Kazuho! It's a start.

On Tue, Apr 12, 2016 at 8:11 AM, Kazuho Oku <[email-masked]> wrote:

> >> I think what we need most is a research on how large a cache digest
> would
> >> be.
> >>
> >> >> >> In other words, browsers that support 304 push should, when
> matching
> >> >> >> a