Re: Experiences with HTTP/2 server push

[Kazuho Oku <[e-mail]>]

Hi,

2016-08-04 9:21 GMT+09:00 Tom Bergan <[e-mail]>:
> Hi all,
>
> Our team has been experimenting with H2 server push at Google for a few
> months. We found that it takes a surprising amount of careful reasoning to
> understand why your web page is or isn't seeing better performance with H2
> push. We also encountered a lack of good documentation: How should one go
> about using H2 push? What are the best practices? We tried to distill our
> experiences into five "rules of thumb" that are described in this doc:
> https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0

Sorry for the late response. I have recently had a chance to discuss
the details of the document.

It is a great summary of what the issues related to push are. On the
other hand, it makes me sad that the fifth rule states "Consider
Preload Instead of Push".

While I understand that not using push could be a short term answer on
some deployments, I think we need to discuss how we should fix the
issues (detailed as first four rules) to make the Web faster using
push in the long term.

And my take against the issues raised in the document are as follows:


"Rule 1: Push Enough to Fill Idle Network Time, and No More":

Technically, HoB caused by a low-priority stream is an issue irrelevant to push.

Consider the case where a large HTML that loads a CSS is sent over the
wire. In a typical implementation, the server will pass a block of
HTML much larger than INITCWND to the TCP stack before recognizing the
request for CSS. So the client would need to wait for multiple RTTs
before starting to receive the CSS.

It is only the case that such inversion of priority (a
lower-prioritized response blocking a higher one) might happen more
frequently when push is used.

That said, as discussed at the workshop, it is possible to implement a
HTTP/2 server that does not get affected by HoB between the different
streams (see https://github.com/HTTPWorkshop/workshop2016/blob/master/talks/tcpprog.pdf).

I would suggest that regardless of whether or not push is used, server
implementors should consider adopting such approach to minimize the
impact of HoB.

It should also be noted that with QUIC such HoB would not be an issue
since there would no longer be a send buffer within the kernel.


"Rule 2: Push Resources in the Right Order"

My take is that the issue can / should be solved by clients sending
PRIORITY frames for pushed resources when they observe how the
resources are used, and that until then servers should schedule the
pushed streams separately from the client-driven prioritization tree
(built by using the PRIORITY frames).

Please refer to the discussion in the other thread for details:
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0453.html


"Rule 3: Don’t Push Resources the Client has Already Cached"

As the document states, the short-time solution would be for a server
to track what it has pushed to the client, and ultimately (and
hopefully) the standardization of cache-digests would solve the issue.


"Rule 4: Use the Right Cookies"

I think this is a very interesting point.

As a server implementor, I have always dreamt of cancelling a push
after sending a PUSH_PROMISE. In case a resource we want to push
exists on a dedicate cache that cannot be reached synchronously from
the HTTP/2 server, the server needs to send PUSH_PROMISE without the
guarantee that it would be able to push a valid response.

It would be great if we could have an error code that can be sent
using RST_STREAM to notify the client that it should discard the
PUSH_PROMISE being sent, and issue a request by itself.

With such an error code, it would be possible for a server to
speculatively push a resource by fetching it on behalf of the client
(without cookies etc.) and if it fails, then let the client fetch the
resource (with all the appropriate credentials / conditions).

> The doc is a little long, but the first two pages give a decent tl;dr. I
> suspect the ideas and conclusions will be "obvious" to many people on this
> mailing list, at least in hindsight. Hopefully other folks interested in H2
> server push will find this useful. Let us know if you have any comments.
>
> -Tom, Simon, and Michael



-- 
Kazuho Oku