Re: HTTP 2.0 and a Faster, more Mobile-friendly web

Thanks for sending this out Henrik! I appreciate the work you guys have
done to gather data here. There's a lot to say about this (and it looks
like Roberto already commented a lot on the test results themselves), and I
ought to sleep now, but I wanted to point out some initial things first.

On Sun, Jul 29, 2012 at 1:14 PM, Henrik Frystyk Nielsen <
henrikn@microsoft.com> wrote:

>  Dear All,****
>
> ** **
>
> We remain committed to the HTTP/2.0 standards process and look forward to
> seeing many of you this week at the IETF meeting in Vancouver to continue
> the discussion.  In the spirit of open discussion, we wanted to share some
> observations in advance of the meeting and share the latest progress from
> prototyping and testing. ****
>
> ** **
>
> There are currently three different proposals that the group is working
> through:****
>
> ** **
>
>    * SPDY (http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy),****
>
>    * HTTP Speed+Mobility (
> http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility),****
>
>    * Network-Friendly HTTP Upgrade (
> http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly). ****
>
> ** **
>
> The good news is that everyone involved wants to make the Web faster, more
> scalable, more secure, and more mobile-friendly, and each proposal has
> benefits in different areas that the discussion can choose from.****
>
> ** **
>
> --- A Genuinely Faster Web ---****
>
> ** **
>
> The SPDY proposal has been great for raising awareness of Web performance.
> It takes a “clean slate” approach to improving HTTP.****
>
> ** **
>
> To compare the performance of SPDY with HTTP/1.1 we have run tests
> comparing download times of several public web sites using a controlled
> tested study. The test uses publically available software run with mostly
> default configurations while applying all the currently available
> optimizations to HTTP/1.1. You can find a preliminary report on the test
> results here: http://research.microsoft.com/apps/pubs/?id=170059. The
> results mirror other
>
Is the PDF broken? I don't see a link to the dummy webpage in the report
PDF.


> data (http://www.guypo.com/technical/not-as-spdy-as-you-thought) that
> indicate mixed results with SPDY performance.****
>
> **
>
I find it very curious you mention these two results in conjunction when
discussing SPDY performance. The former relies heavily on pipelining,
which, if you believe Guypo's test results (which I more or less do,
although I don't necessarily agree with the title for his spdy post), show
that pipelining has mixed results. Please refer to
http://www.guypo.com/technical/http-pipelining-not-so-fast-nor-slow/.
Anyhow, I don't feel like we need to belabor pipelining too much, since it
seems like everyone's in support of multiplexing anyway, which I think is
great.

>  **
>
> Our results indicate almost equal performance between SPDY and HTTP/1.1
> when one applies all the known optimizations to HTTP/1.1. SPDY’s
> performance improvements are not consistent and significant. We will
> continue our testing, and we welcome others to publish their results so
> that HTTP/2.0 can choose the best changes and deliver the best possible
> performance and scalability improvements compared to HTTP/1.1.
>
I'm trying to understand the comments here. Can you clarify some
ambiguities?
- When you say SPDY's performance improvements are not consistent and
significant, are you saying compared to the HTTP+pipelining+minify results
or just compared to naive HTTP? I find the fact that Microsoft's synthetic
test results help validate what we've already known, that reducing
roundtrips is important. Lots of the pipelining and minify techniques are
designed to help reduce roundtrips. SPDY does this too via features like
multiplexing.
- Are you asserting that, because there are ways to workaround HTTP level
bottlenecks via application level optimizations, we shouldn't address HTTP
issues? While I do wish that more websites applied web performance
techniques and leveraged tools like mod_pagespeed, I think it's a sad
reality that most websites do not. It'd be great if we could resolve many
HTTP level performance bottlenecks so that all users of HTTP/2.0 get those
gains, not just the ones who are willing to put in extra time to obtain
them.

> ****
>
> ** **
>
> ** **
>
> --- Taking the Best from Each ---****
>
> ** **
>
> Speed is one of several areas of improvement. Currently, there’s no clear
> consensus that any one of the proposals is the clear choice or even
> starting point for HTTP/2.0 (based on our reading the Expressions of
> Interest and discussions on this mailing list. A good example of this is
> the vigorous discussion around mandating TLS encryption (
> http://tools.ietf.org/html/rfc5246) for HTTP/2.0. ****
>
> ** **
>
> We think a good approach for HTTP/2.0 is to take the best solution for
> each of these areas from each of the proposals.  This approach helps us
> focus the discussion for each area of the protocol. Of course, this
> approach would still allow the standard to benefit from the extensive
> knowledge gained from implementing existing proposals.  ****
>
> ** **
>
> We believe that the group can converge on consensus in the following
> areas, based on our reading of the Expressions of Interest, by starting
> from the different proposals.****
>
> ** **
>
> ------------------|------------------****
>
> Area              | Opinion that ****
>
>                   | seems to prevail****
>
> ------------------|------------------****
>
> 1. Compression    | SPDY or Friendly****
>
> ------------------|------------------****
>
> 2. Multiplexing   | SPDY****
>
> ------------------|------------------****
>
> 3. Mandatory TLS  | Speed+Mobility****
>
> ------------------|------------------****
>
> 4. Negotiation    | Friendly or****
>
>                   |   Speed+Mobility****
>
> ------------------|------------------****
>
> 5. Client Pull/   | Speed+Mobility****
>
>       Server Push | ****
>
> ------------------|------------------****
>
> 6. Flow Control   | SPDY****
>
> ------------------|------------------****
>
> 7. WebSockets     | Speed+Mobility****
>
> ------------------|------------------****
>
> ** **
>
> Below, we discuss each HTTP/2.0 element and the current consensus that
> appears to be forming within the Working Group.****
>
> ** **
>
> 1. Compression****
>
> ** **
>
> Compression is simple to conceptualize and implement, and it is important.
> Proxies and other boxes in the middle on today’s Web often face problems
> with it. The HTTP/2.0 discussion has been rich but with little consensus.*
> ***
>
> ****
>
> Though some studies suggest that SPDY’s header compression approach shows
> promise, other studies show this compression to be prohibitively onerous
> for intermediary devices. More information here would help us make sure
> we’re making the Web faster and better. ****
>
> ** **
>
> Also, an entire segment of implementers are not interested in compression
> as defined in SPDY.  That’s a challenge because the latest strawman for the
> working group charter (
> http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0784.html)
> states that the “resulting specification(s) are expected to be meet these
> goals for common existing deployments of HTTP; in particular, …
> intermediation (by proxies, corporate firewalls, ‘reverse’ proxies and
> Content Delivery Networks).” ****
>
> ** **
>
> We think the SPDY or Friendly proposals is a good starting point for
> progress.****
>
> ** **
>
> 2. Multiplexing****
>
> ** **
>
> All three proposals define similar multiplexing models. We haven’t had
> substantial discussion on the differences. This lack of discussion suggests
> that there is rough consensus around the SPDY framing for multiplexing.
>
Great!

> ****
>
> ** **
>
> We think that the SPDY proposal is a good starting point here and best
> captures the current consensus.****
>
> ** **
>
> 3. Mandating Always On TLS ****
>
> ** **
>
> There is definitely no consensus to mandate TLS for all Web communication,
> but some major implementers have stated they will not to adopt HTTP/2.0
> unless the working group supports a “TLS is mandatory” position. A very
> preliminary note from the chair (
> http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0601.html)
> states that there is a lack of consensus for mandating TLS. ****
>
> ** **
>
> We think the Speed+Mobility proposal is a good starting point here as it
> provides options to turn TLS on (or not).****
>
> ** **
>
> 4. Negotiation****
>
> ** **
>
> Only two of the proposals actually discuss how different endpoints agree
> to use HTTP/2.0. ****
>
> ** **
>
> (The SPDY proposal does not specify a negotiation method. Current
> prototype implementations use the TLS-NPN (
> http://tools.ietf.org/html/draft-agl-tls-nextprotoneg) extension.  While
> the other proposals use HTTP Upgrade to negotiate HTTP/2.0, some parties
> have expressed non-support for this method as well.) ****
>
> ** **
>
> We think either of the Friendly or Speed+Mobility proposals is a good
> starting point because they are the only ones that have any language in
> this respect.  ****
>
> ** **
>
> 5. Client Pull and Server Push****
>
> ** **
>
> There are tradeoffs between a server push model and a client pull model.
> The main question is how to improve performance while respecting bandwidth
> and client caches.
>
I want to re-emphasize that server push, as defined by SPDY, provides for
better inlining. Even Microsoft's tests results seem to leverage inlining
to reduce roundtrips. People complain about server push for not respecting
bandwidth and client caches, but current inlining techniques already do
that.

> ****
>
> ** **
>
> Server Push has not had the same level of implementation and
> experimentation as the other features in SPDY. More information here would
> help us make sure we’re making the Web faster and better.
>
Totally agreed, and we're working on this. I hope in the future we will be
able to contribute much more data here.


> ****
>
> ** **
>
> We think the Speed+Mobility proposal is a good starting point here,
> suggesting that this issue may be better served in a separate document
> rather than tied to the core HTTP/2.0 protocol. ****
>
> ** **
>
> 6. Flow Control****
>
> ** **
>
> There has only been limited discussion in the HTTPbis working group on
> flow control. Flow Control offers a lot of opportunity make the Web faster
> as well as to break it; for example, implementations need to figure out how
> to optimize for opposing goals (like throughput and responsiveness) at the
> same time. ****
>
> ** **
>
> The current version of the SPDY proposal specifies a flow control message
> with many settings are that are not well-defined. The Speed+Mobilty
> proposal has a simplified flow control model based on certain assumptions.
> More experimentation and information here would help us make sure we’re
> making the Web faster and better. ****
>
> ** **
>
> We think that the SPDY proposal is a good starting point here. ****
>
> ** **
>
> 7. WebSockets****
>
> ** **
>
> We see support  for aligning HTTP/2.0 with a future version of WebSockets,
> as suggested in the introduction of the Speed+Mobility proposal.****
>
> ** **
>
> ** **
>
> --- Moving forward ---****
>
> ** **
>
> We’re excited for the Web to get faster, more stable, and more capable,
> and HTTP/2.0 is an important part of that. ****
>
> ** **
>
> We believe that bringing together the best elements of the current SPDY,
> HTTP Speed+Mobility, and Network-Friendly HTTP Upgrade proposals is the
> best approach to make that happen. ****
>
> ** **
>
> Based on the discussions on the HTTPbis mailing list, we’ve suggested
> which proposals make the most sense to start from for each of the areas
> that HTTP/2.0 is addressing. Each of these areas needs more prototyping and
> experimentation and data. We’re looking forward to the discussion this week.
> ****
>
> ** **
>
> Sincerely,****
>
> ** **
>
> Henrik Frystyk Nielsen****
>
> Principal Architect, Microsoft Open Technologies, Inc.****
>
> ** **
>
> Gabriel Montenegro****
>
> Principal Software Development Engineer, Microsoft Corporation****
>
> ** **
>
> Rob Trace****
>
> Senior Program Manager Lead, Microsoft Corporation****
>
> ** **
>
> Adalberto Foresti****
>
> Senior Program Manager, Microsoft Open Technologies, Inc.****
>
> ** **
>
> ** **
>
Btw, since the subject of this email talks about a mobile friendly web, can
you speak to what features in HTTP/2.0 will help make the web more
mobile-friendly? I've got my own ideas, relating to SPDY, but I'm curious
what Microsoft thinks here, especially since HTTP S+M references mobile in
its name.