Re: http-push-assets | draft-asilvas-http-push-assets-00.txt

Thanks Lucas.


Until we can test the two approaches side-by-side in real-world scenarios with tons of samples, it's hard (for me) to predict which is "better". But here are some tradeoffs:


* Cache Digest uses considerably fewer bytes per cached resource - significance of delta unknown

* Push-Assets is presumably simpler for client & server integrators, as it leverages HTTP Headers - potentially broader adoption

* Push-Assets can be URI "bucketed" to prevent wasted bytes over the wire for large and complex websites - potential big benefits for multi-app-per-domain websites, CDN's, etc

* Push-Assets can be tuned by the apps developers to only enable server-push for assets that make the most sense (for example, an app may decide that js & css should be pushed but images should not) - Cache Digest sends all state regardless if "push-enabled"

* Push-Assets can work for non-HTML resources - Potentially optimizing all HTTP traffic, such as API's, or more real-world scenarios like CSS with imports


Ultimately I believe both would be *very* positive solutions, as most visitors visit websites with few previously cached resources, and may greatly benefit from Server Push. A recent study was posted in this group which illustrates the point better than I can: https://if-report.shimmercat.com/dirhtml/


And regarding your question on the demo, no, that is without Push-Assets as the test demonstrates the value of Server Push when the cache is empty (forced server push). The demo depends on the browser, which does not support Push-Assets. But the demo demonstrates the value of the server having client state so that we can reap these benefits regardless of client state. I do have a non-browser client demo that also demonstrates the specific gains of client state (via Push-Assets), and I'll get that data added soon.



-aaron

________________________________
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Sent: Thursday, July 7, 2016 8:00:04 AM
To: ietf-http-wg@w3.org
Subject: RE: http-push-assets | draft-asilvas-http-push-assets-00.txt

Hello,

Thanks for the draft, I am interested in improvements to H2 Server Push so it is nice see other solution approaches. What do you see as the differences between Push-Assets and Cache Digest? I've read through the draft and the main differences seem to be: use of header field rather than H2 frame, and Push-Assets do not encode the information. I'm sure I'm missing out the subtleties though. I'm particularly interested in the perceived different tradeoffs between the two.

I've also looked at the results on the demo page, is it correct to assume the test variant "HTTP/2+TLS+Server Push" is using Push-Asset? How does the performance of normal H2 push compare to your Push-Assets?

Lucas

From: Aaron L. Silvas [mailto:asilvas@godaddy.com]
Sent: 06 July 2016 17:33
To: ietf-http-wg@w3.org
Subject: http-push-assets | draft-asilvas-http-push-assets-00.txt


Hello group,



Looking to gauge potential interest in HTTP/2 Push-Assets draft. I understand the draft overlaps that of Cache Digest, both aiming to address the lack of client state to optimize HTTP/2 Server Push, but does so in a radically different way. Both approaches have tradeoffs. I'm happy to discuss further and evolve the recommendations if there is interest!





Push-Assets Tracker - https://datatracker.ietf.org/doc/draft-asilvas-http-push-assets/

Push-Assets Draft - https://www.ietf.org/id/draft-asilvas-http-push-assets-00.txt




Working Node.js Server - https://github.com/asilvas/http2-push-assets-node#server

Working Node.js Client - https://github.com/asilvas/http2-push-assets-node#client

Demonstration of potential benefits - https://github.com/asilvas/http2-push-assets-demo








Regards,



Aaron Silvas

GoDaddy



----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------