Subject: Getting (Officially) Started on HTTP/2.0

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Oct 2012 17:48:06 +0100

As you may have seen, our re-charter has been approved by the IESG. 

If you aren't familiar with the final text, please take a moment and carefully read it:
  http://datatracker.ietf.org/wg/httpbis/charter/

First and foremost, we will continue working on the revision of the HTTP/1.1 specification. Roy has recently finished his work on p1, and should finish p2 soon. As such, we'll be entering WGLC on these documents and prioritising any discussion on them until finished. Stay tuned for details.

Work on HTTP/2.0 will start by creating draft-ietf-httpbis-http2-00, based upon draft-mbelshe-httpbis-spdy-00. That draft will list Mike Belshe and Roberto Peon as authors, to acknowledge their contribution.

However, we will have a separate editorial team in charge of the Working Group's drafts. After extensive discussions and consultation with our AD, I've asked Julian Reschke, Alexey Melnikov and Martin Thomson to serve as editors of the HTTP/2.0 draft.

Concurrently, we should start gathering issues against the draft for discussion; just as with the previous work, I'd like to structure as much of our discussion as possible around concretely identified issues. 

I'll kick that process off by nominating obvious discussion points like the upgrade mechanism, header compression, intermediaries, and server push, but of course anyone can raise a new issue, using the guidelines on our wiki page <http://trac.tools.ietf.org/wg/httpbis/trac/wiki>.

There are two things that we need to settle fairly quickly:

1. How we identify the protocol on the wire. It's likely that we're going to have a few different revisions of what we specify implemented as we move along, and I want us to be crystal-clear about how that will be managed, so we're not stuck with interop problems down the road.

2. What requirements we have for negotiation of HTTP2 within TLS. As you should have seen, that portion of the work has been given to the TLS Working Group, and we need to give them some guidance about what we need.

Following that, I suspect it'll be most useful to work on the upgrade mechanism (which will also help with #1 above). Patrick sent out what I think most people agree is a good starting point for that discussion here: <http://www.w3.org/mid/1345470312.2877.55.camel@ds9>. 

We'll start these discussions soon, using the Atlanta meeting as a checkpoint for the work. If its' going well by then (i.e., we have a good set of issues and some healthy discussion, ideally with some data starting to emerge), I'd expect us to schedule an interim meeting sometime early next year, to have more substantial discussion.

More details to follow. Thanks to everybody for helping get us this far, as well as to Martin, Alexey and Julian for volunteering their time.

Regards,

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

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 03 Oct 2012 14:54:47 +1300

On 03.10.2012 05:48, Mark Nottingham wrote:
> First and foremost, we will continue working on the revision of the
> HTTP/1.1 specification. Roy has recently finished his work on p1, and
> should finish p2 soon. As such, we'll be entering WGLC on these
> documents and prioritising any discussion on them until finished. 
> Stay
> tuned for details.
>
> Work on HTTP/2.0 will start by creating draft-ietf-httpbis-http2-00,
> based upon draft-mbelshe-httpbis-spdy-00. That draft will list Mike
> Belshe and Roberto Peon as authors, to acknowledge their 
> contribution.
>
> However, we will have a separate editorial team in charge of the
> Working Group's drafts. After extensive discussions and consultation
> with our AD, I've asked Julian Reschke, Alexey Melnikov and Martin
> Thomson to serve as editors of the HTTP/2.0 draft.
>
> Concurrently, we should start gathering issues against the draft for
> discussion; just as with the previous work, I'd like to structure as
> much of our discussion as possible around concretely identified
> issues.
>
> I'll kick that process off by nominating obvious discussion points
> like the upgrade mechanism, header compression, intermediaries, and
> server push, but of course anyone can raise a new issue, using the
> guidelines on our wiki page
> <http://trac.tools.ietf.org/wg/httpbis/trac/wiki>.
>
> 1. How we identify the protocol on the wire. It's likely that we're
> going to have a few different revisions of what we specify 
> implemented
> as we move along, and I want us to be crystal-clear about how that
> will be managed, so we're not stuck with interop problems down the
> road.
>
> 2. What requirements we have for negotiation of HTTP2 within TLS. As
> you should have seen, that portion of the work has been given to the
> TLS Working Group, and we need to give them some guidance about what
> we need.
>

3) The explicit session frames setup/teardown is a bit of unnecessary 
verbose state and bandwidth. Potentially adding extra RTT at times. 
There is no need for request and session setup to be different frames 
unless you want to throw away the stateless nature of HTTP. We can have 
A-to-B sessions[1] for free with per-hop request/flow ID and connection 
pinning support in the implementations. We can have client to origin 
session with negotiated headers.

Where the client assigns a connection-specific ID and the server uses 
that to construct any session ID needed at its end. This was discussed 
by the WG earlier. Similar (but not the same) as described in 
network-friendly draft. WG discussion, and development since the drafts 
were submitted has led to a some significant improvements on this over 
what network-friendly and WebSockets use, and shown that it allows for 
seamless use of HTTP/2 as stateless or stateful flows with both server- 
or client-push as optional extensions.
  eg we can write server-push as a separate (new) part-N section draft 
with the core pt1-2 HTTP/2 draft(s) containing a framing structure and 
flow control which are able to support server-push for when it is needed 
without breaking the HTTP/1 semantics requirements.

I would like to propose an updated frame layout pulling in the best 
framing details of the WebSockets, network-friendly, and speed+mobility 
proposals. This is almost ready for WG discussion, given a few more days 
to work the wording of it into the draft-mbelshe-httpbis-spdy-00 texts. 
This also proposes a few details for your (1) below.

4) I'll stick my neck out and voice it. Cross-request LZ compression 
needs to go.

The other drafts proposed a few alternative options there, per-header 
differential add/replace/remove flags.
IIRC Robert was working on something there as well?

> Following that, I suspect it'll be most useful to work on the upgrade
> mechanism (which will also help with #1 above). Patrick sent out what
> I think most people agree is a good starting point for that 
> discussion
> here: <http://www.w3.org/mid/1345470312.2877.55.camel@ds9>.
>
> We'll start these discussions soon, using the Atlanta meeting as a
> checkpoint for the work. If its' going well by then (i.e., we have a
> good set of issues and some healthy discussion, ideally with some 
> data
> starting to emerge), I'd expect us to schedule an interim meeting
> sometime early next year, to have more substantial discussion.
>
> More details to follow. Thanks to everybody for helping get us this
> far, as well as to Martin, Alexey and Julian for volunteering their
> time.
>
> Regards,
>
> --
> Mark Nottingham
> http://www.mnot.net/

AYJ

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Oct 2012 08:29:46 +0200

Amos,

> IIRC Robert was working on something there as well?

I don't think you're sticking your neck out very far ;-)  Mike had sent
a message to this list about this issue on the 14th of September.  While
I could see some small potential for abuse within the same security
context, I would be more concerned if a dictionary were shared across
contexts, where one might have different properties or the risk of MITM
is elevated for one reason or another.  I didn't think either of these
scenarios was seriously considered in SPDY.  Am I not being paranoid enough?

Eliot

---

From: Roberto Peon <[email-masked]>
Date: Wed, 3 Oct 2012 00:15:17 -0700

On Tue, Oct 2, 2012 at 6:54 PM, Amos Jeffries <[email-masked]> wrote:

>>   http://datatracker.ietf.org/**wg/httpbis/charter/<http://datatracker.ietf.org/wg/httpbis/charter/>
>>
>> documents and prioritising any discussion on them until finished. Stay
>> tuned for details.
>>
>> Belshe and Roberto Peon as authors, to acknowledge their contribution.
>>
>> <http://trac.tools.ietf.org/**wg/httpbis/trac/wiki<http://trac.tools.ietf.org/wg/httpbis/trac/wiki>
>> >.
>>
>> going to have a few different revisions of what we specify implemented
> verbose state and bandwidth. Potentially adding extra RTT at times. There
> is no need for request and session setup to be different frames unless you
> want to throw away the stateless nature of HTTP. We can have A-to-B
> sessions[1] for free with per-hop request/flow ID and connection pinning
> support in the implementations. We can have client to origin session with
> negotiated headers.
>
> Where the client assigns a connection-specific ID and the server uses that
> to construct any session ID needed at its end. This was discussed by the WG
> earlier. Similar (but not the same) as described in network-friendly draft.
> WG discussion, and development since the drafts were submitted has led to a
> some significant improvements on this over what network-friendly and
> WebSockets use, and shown that it allows for seamless use of HTTP/2 as
> stateless or stateful flows with both server- or client-push as optional
> extensions.
>  eg we can write server-push as a separate (new) part-N section draft with
> the core pt1-2 HTTP/2 draft(s) containing a framing structure and flow
> control which are able to support server-push for when it is needed without
> breaking the HTTP/1 semantics requirements.
>
> proposals. This is almost ready for WG discussion, given a few more days to
> work the wording of it into the draft-mbelshe-httpbis-spdy-00 texts. This
> also proposes a few details for your (1) below.
>
>
> 4) I'll stick my neck out and voice it. Cross-request LZ compression needs
> to go.
>

Yep-- what I've been doing is whole-key or whole-value delta-encoding with
static huffman coding, with an LRU of key-value pairs. A set of headers is
thus simply a set of references to the items in the LRU.
The set of operations is:
  add a new hey-value line into the LRU by specifying a new key-value
      this looks like:  {opcode: KVStore, string key, string val}.
  add a new key-value line into the LRU by referencing a previous
key-value, copying the key from it and adding the specified new value
      this looks like:  {opcode: Mutate,int lru_index, string val}.
  toggle visibility for a particular LRU entry for a particular header set
      this looks like:  {opcode: Toggle,int lru_index}.
  toggle visibility for a contiguous range of LRU entries for a particular
header set
      this looks like:  {opcode: Toggle,int lru_index_start, int
lru_index_end}.

Note that the actual format of the operations isn't exactly like what I'm
describing above- I'm just trying to indicate generally what is involved.

The resulting compression is a bit worse than gzip (with large window size)
on my current test corpus, but compares pretty well with gzip in the Chrome
implementation of SPDY.
It has CPU advantages in that the huffman encoding is static, thus for
proxies there is no re-encoding necessary. Additionally, much or all of the
decompressor state can be shared with a compressor (if proxying, for
instance).
Finally, I expect (though I've yet to prove it yet, as I'm still doing the
c++ implementation) that the compression is more CPU efficient than gzip.
Decompression should be similar... but.. much of the time you need not
reconstitute an entire set of headers-- instead, since we're sending deltas
anyway, you simply ammend your state based on what changed and thus become
more efficient there as well.

If clients/servers were a bit more naive in terms of when they
added/removed headers, the delta-coding would be more efficient and it'd
approach or exceed gzip compression.. at least I think so :)
As far as I (or thusfar anyone with whom I've spoken) can tell, the
approach here does not allow probing of the compression context, and is
thus robust in the face of known attacks.

Anyway, that is what I've been working on.
-=R

>> I think most people agree is a good starting point for that discussion
>> here: <http://www.w3.org/mid/**1345470312.2877.55.camel@ds9<http://www.w3.org/mid/1345470312.2877.55.camel@ds9>
>> >.
>>
>> good set of issues and some healthy discussion, ideally with some data

---

From: Roberto Peon <[email-masked]>
Date: Wed, 3 Oct 2012 00:17:31 -0700

> also proposes a few details for your (1) below.

Sorry for splitting this up into a separate email, but I figure these will
end up as separate conversations.
I've also reworked the framing used in SPDY, which was not as regular as it
could be (and thus annoyed me a bit).
I'll present that here soon as well.

-=R