Re: HTTP/2 Expression of luke-warm interest: Varnish

On Jul 16, 2012 8:17 AM, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
>
> This "we're everywhere" bias showed up in the initial release of
> SPDY numbers, which looked wonderful, thanks the the fact that Google
> has low RTT to anybody in the world, and thus could "afford" the
> TLS-RTT penalty, a luxury not many websites have.

That is backwards for much content -- something which multiplexes is more
beneficial to things experiencing higher RTT.

Basically the expectation was that less optimized sites (either code or
location) would benefit more from SPDY than sites which were already well
connected and whose pages are well optimized

>
> But my major problem with SPDY is simply that it is additive,
> it just adds another 50 pages of sediment to the pile of RFCs
> necessary to implement HTTP.
>
> SPDY does nothing to address problems like User-Agent, Cookie,
> ASCII representation of timestamps, it just throws it all
> into deflate and hopes for the best.

It is just a start. If we'd attempted all of that in the beginning I think
we'd have a failed effort by now.

I'm happy to get changed whatever we can so long as it improved things and
is deployable. This has always been the mantra, but at this venue and at
this period in time the scope if then changes which can be considered has
broadened.

>
> Take the discussion going on about "non-GMT" timestamps right
> now as example:  Resolving that is probably going to add another
> 20 lines of text to clarify.
>
> If HTTP/2.0 defines all timestamps as a POSIX::time_t binary
> timestamp, you can rip out the entire section 8 out of part2,
> eliminate tons of weird error-cases and their handling, and
> everybody in the HTTP-chain will save cpu cycles.
>
> That is the sort of improvement I expect from HTTP/1 to HTTP/2
> and SPDY does not deliver it.
>
> --
> 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.
>
 On Jul 16, 2012 8:17 AM, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:

> In message <
> CABaLYCswvXipBNsjFDnmEUR2AbVow6uLe+7uLJ0RD2wY_8US_w@mail.gmail.com>
> , Mike Belshe writes:
>
> >You've got it in your
> >head that a the people that started on this work are idiots and unopen to
> >public debate.
>
> No, I'm very impressed by what the SPDY has done, I've said so
> repeatedly.
>
> >Do you think the other companies - from Facebook to Twitter [...]
>
> I think they are all very big companies with world wide distribution
> of http-server facilities.
>
> Most websites have only one geographical location.
>
> This "we're everywhere" bias showed up in the initial release of
> SPDY numbers, which looked wonderful, thanks the the fact that Google
> has low RTT to anybody in the world, and thus could "afford" the
> TLS-RTT penalty, a luxury not many websites have.
>
> But my major problem with SPDY is simply that it is additive,
> it just adds another 50 pages of sediment to the pile of RFCs
> necessary to implement HTTP.
>
> SPDY does nothing to address problems like User-Agent, Cookie,
> ASCII representation of timestamps, it just throws it all
> into deflate and hopes for the best.
>
> Take the discussion going on about "non-GMT" timestamps right
> now as example:  Resolving that is probably going to add another
> 20 lines of text to clarify.
>
> If HTTP/2.0 defines all timestamps as a POSIX::time_t binary
> timestamp, you can rip out the entire section 8 out of part2,
> eliminate tons of weird error-cases and their handling, and
> everybody in the HTTP-chain will save cpu cycles.
>
> That is the sort of improvement I expect from HTTP/1 to HTTP/2
> and SPDY does not deliver it.
>
> --
> 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.
>
>