Subject: Next Steps for HTTP/2.0

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 Feb 2013 15:20:29 +1100

At the interim meeting, we developed a plan to get the HTTP/2.0 work moving. The goal is to get a draft marked for implementation soon, so that we can gather some implementation and deployment experience. Several folks at the meeting indicated that they would be implementing.

The plan we came up with is in the draft minutes, but I've separated it out below to kick off discussion, and to make sure we're all on the same page.

We identified the items below as goals for inclusion in that first implementation draft (expressed as a delta from the current WG draft):

* Upgrade
  - For now, we'll use NPN (until TLSWG gives us something to replace it with) for TLS connections.
  - For non-TLS connections, we'll use the "upgrade dance" as outlined in Gabriel's draft.
  - The DNS and Alternate-Protocol approaches are still under discussion, but won't be in this revision.

* Header Compression
  - We'll converge on a delta-based approach first; both Roberto and Herve have action items to publish drafts and show example code. The expectation is that we'll start with a fairly basic delta approach, and then tweak/evolve it over time.
  - Binary encoding of headers based upon their understood syntax is still under consideration, but won't be in this revision. We want to get experience with delta before adding complexity.

* Flow Control
 - Will is on the hook to produce a detailed proposal for session-level flow control, in addition to stream-based flow control.

* Settings
 - We'll mark settings persistence between sessions as "at risk", as it was felt that the added complexity and risk may not be worth the gains.
 - We'll document that it's mandatory to send the settings frame first upon connection establishment.

* Frame Changes
 - We'll remove the protocol version from the individual frame, but
 - We'll add magic at the beginning of session establishment (exact sequence TBD) to identify the protocol in use, and fast fail HTTP/1.x.
  - We'll rearrange frames so that they have uniform length and alignment as follows:
     - length: 16
     - type or opcode: 8
     - flags: 8
     - control: 1
     - session id: 31
  - priority will be changed to 32 bits (1st reserved).
  - Roberto is on the hook for a proposal for a "push promise" control frame as discussed.

Note that we are NOT yet firmly choosing any particular path; rather, we're working on proposals in code as well as text, based upon discussion to date. As such, we're likely to have several such implementation drafts that progressively refine the approach we're taking. I.e., we don't have to agree that the above is what we want HTTP/2.0 to look like -- only that it's interesting to make these changes now, so that we can test them.

The expectation that we set in Tokyo was that we'd have this nailed down in a draft sometime around the Orlando meeting, so that implementations could be finished soon thereafter, allowing us to start working on initial interop and data gathering. We'd then re-convene (possibly for another Interim) to discuss those results and discuss further work.

Please have a look through; if there's something else you think needs to be in this *first* implementation draft, please speak up.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Mon, 4 Feb 2013 21:19:02 -0800

On Mon, Feb 4, 2013 at 8:20 PM, Mark Nottingham <[email-masked]> wrote:

> [snip]
> * Header Compression
>   - We'll converge on a delta-based approach first; both Roberto and Herve
> have action items to publish drafts and show example code. The expectation
> is that we'll start with a fairly basic delta approach, and then
> tweak/evolve it over time.
>   - Binary encoding of headers based upon their understood syntax is still
> under consideration, but won't be in this revision. We want to get
> experience with delta before adding complexity.
>
>
One thing that I think we need to decide upon now is... is the header
compression mechanism going to be mandatory as THE way of encoding headers
in a session, or will the compression mechanism be optional. (Please say
that we're only going to have a single way of encoding headers).

We also need to lay out some fundamental goals for this. For example, I
think there's near universal agreement that tuning for maximum compression
ratios is not necessary the most important goal.. especially if it comes at
the cost of complicated and potentially expensive state management and
processing costs.

[snip]

>  - We'll add magic at the beginning of session establishment (exact
> sequence TBD) to identify the protocol in use, and fast fail HTTP/1.x.
> Note that we are NOT yet firmly choosing any particular path; rather,
> we're working on proposals in code as well as text, based upon discussion
> to date. As such, we're likely to have several such implementation drafts
> that progressively refine the approach we're taking. I.e., we don't have to
> agree that the above is what we want HTTP/2.0 to look like -- only that
> it's interesting to make these changes now, so that we can test them.
>
> The expectation that we set in Tokyo was that we'd have this nailed down
> in a draft sometime around the Orlando meeting, so that implementations
> could be finished soon thereafter, allowing us to start working on initial
> interop and data gathering. We'd then re-convene (possibly for another
> Interim) to discuss those results and discuss further work.
>
> Please have a look through; if there's something else you think needs to
> be in this *first* implementation draft, please speak up.
>
>
I think it would be good to have the host header /
combined-method-host-port-path discussion down for this first
implementation draft. If we can nail down the approach to dealing with the
most critical headers, it ought to make it easier for us to collect data
and tune things later on in the header encoding and compression tasks.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 Feb 2013 16:34:00 +1100

On 05/02/2013, at 4:19 PM, James M Snell <[email-masked]> wrote:

> One thing that I think we need to decide upon now is... is the header compression mechanism going to be mandatory as THE way of encoding headers in a session, or will the compression mechanism be optional. (Please say that we're only going to have a single way of encoding headers).

That was the sense I had.

> We also need to lay out some fundamental goals for this. For example, I think there's near universal agreement that tuning for maximum compression ratios is not necessary the most important goal.. especially if it comes at the cost of complicated and potentially expensive state management and processing costs.

That was very much the sense at the F2F, and was the motivation behind avoiding binary encoding for now. 

A fair number of people share your concerns about the cost of state management; I anticipate that much of the discussion going forward is going to be about containing and controlling it.

> I think it would be good to have the host header / combined-method-host-port-path discussion down for this first implementation draft. If we can nail down the approach to dealing with the most critical headers, it ought to make it easier for us to collect data and tune things later on in the header encoding and compression tasks.

Seems reasonable, if we don't block on it.

Cheers,