W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Re[2]: HTTP2 Expression of Interest : Squid

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 16 Jul 2012 13:03:45 -0700
Message-ID: <CAP+FsNchS6gK_acwryTrRi_TiUcbs60Gs1ZvzSkDRQFwC-Zu5g@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Amos Jeffries <squid3@treenet.co.nz>, Willy Tarreau <w@1wt.eu>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, tom <zs68j2ee@gmail.com>, Adrien de Croy <adrien@qbik.com>, James M Snell <jasnell@gmail.com>, Mike Belshe <mike@belshe.com>
On Mon, Jul 16, 2012 at 12:24 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> In message <CAP+FsNcoyx7=
> EfXLezzHGq-3_+BWTwhLQj8dGObvKpSsHMMarg@mail.gmail.com>
> , Roberto Peon writes:
>
> >but you must know about all possible resources that
> >the dynamic page will generate at the time you create the bundle.
>
> Building a zip(-like) archive on the fly has the same complexity
> as building the server-push stream, but the benefit of not making
> life complex for everybody else.
>

With a zip-like archive, you'd not be able to interleave delivery, thus you
cannot change your mind about what should be pushed (if, for instance, one
discovers that multiple things require subresource A and only one thing
requires subresource B), the user-agent cannot cancel receipt/delivery of
the streams, and so instead of potentially wasting at most a BDP's worth of
bytes, we waste potentially the sum of the size of all objects within the
zip-like archive.

I see a significant loss of flexibility and am unclear on the gain.
So, how does a zip-like archive make life easier, and what are the
tradeoffs? What am I missing?



> But yes, it's not without problems, which is why I think we should
> stick to the strict request-response model.
>

We know that the trend towards higher available bandwidth continues across
a broad spectrum of the 'net and we know that the speed of light hasn't
appreciably changed.
So, basically, we know that what we have today is significantly imperfect
in a latency sense and getting worse and worse.

We can acknowledge that it is a problem and engineer a solution, or we can
decide to not solve this problem, in which case we'll be forcing everyone
to inline everything all the time. Bleh. Inlining is easy to mess up and
when messed up, can slow down page rendering time horribly.

I see a problem which exists today where we can engineer a solution that
will allow the infrastructure to do the right thing on behalf of the site
developers, which gives much better fine-grained control over which
resources arrive in what order (which is important for above-the-fold user
experience), and which solves the 'empty pipe' problem that currently
exists with HTTP. I'm not in favor of punting on this simply because the
problem is difficult. :)

-=R


> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
Received on Monday, 16 July 2012 20:04:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 16 July 2012 20:04:20 GMT