Re: "Packing on the Web" -- performance use cases / implications

On Wed, Jan 7, 2015 at 8:25 AM, Mark Nottingham <mnotting@akamai.com> wrote:

> This doc:
>   http://w3ctag.github.io/packaging-on-the-web/
> says a number of things that about how a Web packaging format could
> improve Web performance; e.g., for cache population, bundling packages to
> distribute to servers, etc.
>

tl;dr: I think its introducing perf anti-patterns and is going against the
general direction we want developers to head. Transport optimization should
be left at transport layer and we already have much better (available
today!) solutions for this.

---- some notes as I'm reading through the latest draft:

(a) It's not clear to me how packages are updated after the initial fetch.
In 2.1.1. you download the .pack with a CSS file but then request the CSS
independently later... But what about the .pack? Wouldn't the browser
revalidate it, detect that the package has changed (since CSS has been
updated), and be forced to download the entire bundle once over? Now we
have duplicate downloads on top of unnecessary fetches.

In general, all bundling strategies suffer from one huge flaw: a single
byte update in any of its subresources forces a full fetch of the entire
file. Instead, we want to encourage *fine-grained* cache control and
revalidation policies such that only the bytes that need to be updated are
actually fetched.. this reduces data usage and loading speeds.

(b) Packages introduce another HoL bottleneck: spec talks about ordering
recommendations, but there is still a strict ordering during delivery (e.g.
if the package is not a static resource then a single slow resource blocks
delivery of all resources behind it).

(c) Packages break granular prioritization: if we give packages high
priority then all packaged assets within it inherit the same priority.. and
even low priority assets within (e.g. images) are now competing against
true high-priority assets (e.g. critical CSS). On the other hand, if we
give packages low priority then we run the risk of hurting performance by
penalizing high priority assets within the package... In short, mixing
content-types within a bundle breaks prioritization and hurts performance.

(d) "Scope" seems dangerous and underspecified: I can hijack requests to
any origin? E.g. an attacker can take over requests for <
popularwidget.com/assets> -- yikes?

(e) "Package-aware caches should delay requesting resources within the
scope of a package that they are downloading, until the package has been
processed... If a package contains another package that is recognized by
the package-aware cache, that package should be used to populate the cache
in the same way"...  Wouldn't that create a problem? For efficiency, the UA
would have to wait to process the package and all of its potential
sub-packages prior to initiating *any* other downloads since a sub-package
could claim an arbitrary scope? And if the UA doesn't defer the download,
now it runs the risk of downloading duplicate bytes: once for the
individual request, another as part the package.. this would be a huge
waste.

----

Out of the listed use cases, I think the compelling ones have the general
shape of "taking X offline" where you want to know all the resources that
you'll need to interact with an app later and/or offline. To address this,
we don't need "package streaming", we just need a manifest that contains
the list of all the files. I would propose dropping the streaming part
entirely and focus on that instead -- the added benefit is that this would
address all of the issues highlighted above. The transport bits of
optimizing connections is orthogonal and should be left to the transport
layer.

<hand waving for a user-triggered "package fetch">
- User clicks on a "package" link
- UA downloads manifest and pops up a dialog showing list of files + asks
if user wants to download them
- User accepts, UA fetches files using http/1.1 and http/2 transports as
available/applicable
- New folder appears on user's device containing all the files
</hand waving>

With http/2 we already have the necessary bits to implement the
programmatic variant (i.e. equiv to rel=package):
- server push eliminates need to request each resource individually
- client does not need to know what to request, server determines that
- all the power and compatibility with granular prioritization, caching
logic, no HoL, etc.

E.g. normalize.github.io... supported by all latest browsers (IE, FF,
Safari, Chrome). Arguably, the only thing missing is a JS API for handling
server push'ed resources -- something that's been brought up a few times
now and it seems like everyone is in agreement that such thing should
exist. Just needs to spec it and ship it.. :)

The "stop-gap" argument doesn't resonate with me.. Push is already here in
every modern browser and does not suffer from above limitations, whereas
new package format requires that we ship new features both on the UA and
server side -- it's neither a stop-gap nor an improvement over what we
already have. I don't see the point.

-----

In summary: "streamable package format" introduces a lot of perf-related
complications which are inherently at odds with the direction that the UA's
would like developers to take: we want granular caching policies,
prioritization, and downloads; we have existing solutions that address the
transport optimization concerns in a much better way.

ig

On Fri, Jan 9, 2015 at 8:09 AM, Mark Nottingham <mnotting@akamai.com> wrote:

>
> > On 8 Jan 2015, at 5:32 am, Yoav Weiss <yoav@yoav.ws> wrote:
> >
> > Hi Mark,
>
> Hey Yoav,
>
> > Thanks for bringing up that document to our attention. I wasn't aware of
> this effort.
> >
> > I've now reviewed the document and would submit detailed feedback to the
> doc's repo.
> >
> > I guess the main question for such a format would be if it's safe enough
> to deploy over plain-text HTTP, since it enables cache population under a
> certain path. Is it not something that can be abused, beyond the current
> possible abuse of HTTP cache in MITM scenarios?
> > If it's safe enough, then I guess packaging can replace the current
> cache-hostile practice of resource concatenation, as a stop-gap until
> HTTP/2 push saves the day. That cache-hostility is often tackled by using
> localStorage as a cache replacement, but I see how native cache population
> would be better.
>
> Very good question - I’d suggest raising an issue on the repo.
>
> > Do we have some data/predictions regarding the time it would take to get
> us to, let's say, 50% server-side HTTP/2 deployment? That'd enable us to
> see the value of working on a stop-gap measure now.
>
> Not yet; I suspect we’ll know a lot more in ~6 months.
>
> Cheers,
>
>
> >
> > Yoav
> >
> >
> > On Wed, Jan 7, 2015 at 5:25 PM, Mark Nottingham <mnotting@akamai.com>
> wrote:
> > Hi all,
> >
> > This doc:
> >   http://w3ctag.github.io/packaging-on-the-web/
> > says a number of things that about how a Web packaging format could
> improve Web performance; e.g., for cache population, bundling packages to
> distribute to servers, etc.
> >
> > Have people in this community reviewed it?
> >
> > Regards,
> >
> >
> > --
> > Mark Nottingham    mnot@akamai.com   http://www.mnot.net/
> >
> >
>
> --
> Mark Nottingham    mnot@akamai.com   http://www.mnot.net/
>
>

On Fri, Jan 9, 2015 at 8:09 AM, Mark Nottingham <mnotting@akamai.com> wrote:

>
> > On 8 Jan 2015, at 5:32 am, Yoav Weiss <yoav@yoav.ws> wrote:
> >
> > Hi Mark,
>
> Hey Yoav,
>
> > Thanks for bringing up that document to our attention. I wasn't aware of
> this effort.
> >
> > I've now reviewed the document and would submit detailed feedback to the
> doc's repo.
> >
> > I guess the main question for such a format would be if it's safe enough
> to deploy over plain-text HTTP, since it enables cache population under a
> certain path. Is it not something that can be abused, beyond the current
> possible abuse of HTTP cache in MITM scenarios?
> > If it's safe enough, then I guess packaging can replace the current
> cache-hostile practice of resource concatenation, as a stop-gap until
> HTTP/2 push saves the day. That cache-hostility is often tackled by using
> localStorage as a cache replacement, but I see how native cache population
> would be better.
>
> Very good question - I’d suggest raising an issue on the repo.
>
> > Do we have some data/predictions regarding the time it would take to get
> us to, let's say, 50% server-side HTTP/2 deployment? That'd enable us to
> see the value of working on a stop-gap measure now.
>
> Not yet; I suspect we’ll know a lot more in ~6 months.
>
> Cheers,
>
>
> >
> > Yoav
> >
> >
> > On Wed, Jan 7, 2015 at 5:25 PM, Mark Nottingham <mnotting@akamai.com>
> wrote:
> > Hi all,
> >
> > This doc:
> >   http://w3ctag.github.io/packaging-on-the-web/
> > says a number of things that about how a Web packaging format could
> improve Web performance; e.g., for cache population, bundling packages to
> distribute to servers, etc.
> >
> > Have people in this community reviewed it?
> >
> > Regards,
> >
> >
> > --
> > Mark Nottingham    mnot@akamai.com   http://www.mnot.net/
> >
> >
>
> --
> Mark Nottingham    mnot@akamai.com   http://www.mnot.net/
>
>

On Fri, Jan 9, 2015 at 8:09 AM, Mark Nottingham <mnotting@akamai.com> wrote:

>
> > On 8 Jan 2015, at 5:32 am, Yoav Weiss <yoav@yoav.ws> wrote:
> >
> > Hi Mark,
>
> Hey Yoav,
>
> > Thanks for bringing up that document to our attention. I wasn't aware of
> this effort.
> >
> > I've now reviewed the document and would submit detailed feedback to the
> doc's repo.
> >
> > I guess the main question for such a format would be if it's safe enough
> to deploy over plain-text HTTP, since it enables cache population under a
> certain path. Is it not something that can be abused, beyond the current
> possible abuse of HTTP cache in MITM scenarios?
> > If it's safe enough, then I guess packaging can replace the current
> cache-hostile practice of resource concatenation, as a stop-gap until
> HTTP/2 push saves the day. That cache-hostility is often tackled by using
> localStorage as a cache replacement, but I see how native cache population
> would be better.
>
> Very good question - I’d suggest raising an issue on the repo.
>
> > Do we have some data/predictions regarding the time it would take to get
> us to, let's say, 50% server-side HTTP/2 deployment? That'd enable us to
> see the value of working on a stop-gap measure now.
>
> Not yet; I suspect we’ll know a lot more in ~6 months.
>
> Cheers,
>
>
> >
> > Yoav
> >
> >
> > On Wed, Jan 7, 2015 at 5:25 PM, Mark Nottingham <mnotting@akamai.com>
> wrote:
> > Hi all,
> >
> > This doc:
> >   http://w3ctag.github.io/packaging-on-the-web/
> > says a number of things that about how a Web packaging format could
> improve Web performance; e.g., for cache population, bundling packages to
> distribute to servers, etc.
> >
> > Have people in this community reviewed it?
> >
> > Regards,
> >
> >
> > --
> > Mark Nottingham    mnot@akamai.com   http://www.mnot.net/
> >
> >
>
> --
> Mark Nottingham    mnot@akamai.com   http://www.mnot.net/
>
>

On Fri, Jan 9, 2015 at 8:09 AM, Mark Nottingham <mnotting@akamai.com> wrote:

>
> > On 8 Jan 2015, at 5:32 am, Yoav Weiss <yoav@yoav.ws> wrote:
> >
> > Hi Mark,
>
> Hey Yoav,
>
> > Thanks for bringing up that document to our attention. I wasn't aware of
> this effort.
> >
> > I've now reviewed the document and would submit detailed feedback to the
> doc's repo.
> >
> > I guess the main question for such a format would be if it's safe enough
> to deploy over plain-text HTTP, since it enables cache population under a
> certain path. Is it not something that can be abused, beyond the current
> possible abuse of HTTP cache in MITM scenarios?
> > If it's safe enough, then I guess packaging can replace the current
> cache-hostile practice of resource concatenation, as a stop-gap until
> HTTP/2 push saves the day. That cache-hostility is often tackled by using
> localStorage as a cache replacement, but I see how native cache population
> would be better.
>
> Very good question - I’d suggest raising an issue on the repo.
>
> > Do we have some data/predictions regarding the time it would take to get
> us to, let's say, 50% server-side HTTP/2 deployment? That'd enable us to
> see the value of working on a stop-gap measure now.
>
> Not yet; I suspect we’ll know a lot more in ~6 months.
>
> Cheers,
>
>
> >
> > Yoav
> >
> >
> > On Wed, Jan 7, 2015 at 5:25 PM, Mark Nottingham <mnotting@akamai.com>
> wrote:
> > Hi all,
> >
> > This doc:
> >   http://w3ctag.github.io/packaging-on-the-web/
> > says a number of things that about how a Web packaging format could
> improve Web performance; e.g., for cache population, bundling packages to
> distribute to servers, etc.
> >
> > Have people in this community reviewed it?
> >
> > Regards,
> >
> >
> > --
> > Mark Nottingham    mnot@akamai.com   http://www.mnot.net/
> >
> >
>
> --
> Mark Nottingham    mnot@akamai.com   http://www.mnot.net/
>
>