HTTP/2.0 makes a great step forward in Vancouver, but this is just the beginning!

From:

Henrik Frystyk Nielsen
Principal Architect, Microsoft Open Technologies, Inc.

Rob Trace
Senior Program Manager Lead, Microsoft Corporation

Gabriel Montenegro
Principal Software Development Engineer, Microsoft Corporation

We just came back from the IETF meeting in Vancouver, where the HTTP working group was meeting to decide on the way forward for HTTP/2.0. We are very happy with the discussions and overall outcomes as reflected in the meeting minutes and as summarized by the Chair, Mark Nottingham. At the meeting, the working group clarified the direction for HTTP/2.0 and began to draft a new charter. The group agreed that seven key areas need deep, data-driven discussion as part of the HTTP/2.0 specification process, and the resulting standard will not be backward compatible with any existing proposals (SPDY, HTTP Speed+Mobility, and Network-Friendly HTTP Upgrade). The charter calls for a proposed completion date for the standard of November 2014. In other words, while we are excited about where we are, it is clear that we are just at the beginning of the process toward HTTP 2.0.

Seven Key areas under discussion

The meeting outlined clearly the need for discussions and consensus over seven key technical areas such as Compression, Mandatory TLS, and Client Pull/Server Push. This list of issues is aligned with the position that Microsoft’s Henrik Frystyk Nielsen outlined in an earlier message to the HTTP discussion list (see excerpts below). Overall, we believe there needs to be robust discussions about how we bring together the best elements of the current SPDY, HTTP Speed+Mobility, and Network-Friendly HTTP Upgrade proposals.

HTTP/2.0 specification must be data-driven

We are particularly gratified to see this language in the proposed charter:

“It is expected that HTTP/2.0 will:
* Substantially and measurably improve end-user perceived latency in most cases, over HTTP/1.1 using TCP.”

This supports Microsoft’s position that the HTTP update must be data-driven to ensure that it provides the desired benefits for users. . The SPDY proposal has done a good job of raising awareness of the opportunities to improve Web performance.

Almost equal performance between SPDY and HTTP 1.1

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 data (http://www.guypo.com/technical/not-as-spdy-as-you-thought) that indicate mixed results with SPDY performance.

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.

We discussed those results in Vancouver and it was great to see the interest that this research received from the community on the IETF mailing list and on Twitter.

Existing proposals will change a lot – No backward compatibility

In light of the discussions and the proposed charter, HTTP2.0 will undoubtedly not be backward compatible with any of the current proposals (SPDY, Speed+Mobility, Friendly); in fact, we expect that it might differ in substantial ways from each of these proposals. Consequently, we caution implementers against embracing unstable versions of the specification too eagerly. The proposed charter calls for an IETF standard by November 2014.

We are happy that the working group decided, for practical reasons, to use the text from http://datatracker.ietf.org/doc/draft-mbelshe-httpbis-spdy/ as a starting point. The discussions around the previously cited seven design elements will deeply modify this text . As the Chair wrote, “It’s important to understand that SPDY isn’t being adopted as HTTP/2.0” . This is in line with the Microsoft approach: Our HTTP Speed+Mobility proposal starts from both the Google SPDY protocol (a separate submission to the IETF for this discussion) and the work the industry has done around WebSockets, and the main departures from SPDY are to address the needs of mobile devices and applications.

Looking ahead

We’re excited for the web to get faster, more stable, and more capable. HTTP/2.0 is an important part of that progress, and we look forward to an HTTP/2.0 that meets the needs of the entire web, including browsers, apps, and mobile devices.

 Henrik Frystyk Nielsen, Gabriel Montenegro and Rob Trace

Message to the IETF mailing list from Henrik

“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 data (http://www.guypo.com/technical/not-as-spdy-as-you-thought) that indicate mixed results with SPDY performance.

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.

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

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.

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.

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