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

On Tue, Jan 13, 2015 at 2:18 PM, Ilya Grigorik <igrigorik@google.com> wrote:

> 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.
>

I'm going to leave comments inline below, but I think your read of this is
far too harsh, forecloses meaningful opportunities for developers and UAs,
and in general isn't trying to be as collaborative as I think those of us
who have worked on the design would hope for.


> ---- 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.
>

The presence of the package file is a hint. It's designed to be compatible
with legacy UAs which may issue requests for each resource, which the UA is
*absolutely allowed to do in this case*. It can implement whatever
heuristic or fetch is best.


> 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.
>

Assuming, as you mistakenly have, that fetching the package is the only way
to address the resource.


> 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).
>

Is the critique -- seriously -- that doing dumb things is dumb?


> (c) Packages break granular prioritization:
>

Only assuming that your server doesn't do something smarter.

One of the great things about these packages is that they can *cooperate* with
HTTP/2: you can pre-fill caches with granular resources and entirely avoid
serving packages to clients that are savvy to them. Your server can even
consume packages as an ordered set of resources to prioritize the sending
of (and respond with no-op packages to clients for which the package
wouldn't be useful).

Collaboration can yield huge benefits here. Nothing is either/or unless you
have the power to change the entire deployed infrastructure (which, having
tried with Chrome Frame, I can safely tell you I don't).


> 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/
>>
>>
>