Subject: Divergence from HTTP/2

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Mar 2017 02:16:07 +0000

At this point, I don't think anyone expects that HTTP/QUIC and HTTP/2 are the same protocol.  However, the draft currently still attempts to define them as close cousins.  In PR #363<https://github.com/quicwg/base-drafts/pull/363>, I've consolidated almost all of the "different from HTTP/2" text into a new section and excised a lot of stuff about "HTTP/2 has this, but HTTP/QUIC doesn't need it" from the main body of the document.  Martin has advocated making a clean break from HTTP/2 and defining our own IANA registry for frame types and settings, just as we already have for errors.  We can, out of respect for legacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.

I think that's a good idea, and it's a fairly small step from the current state of #363.  I've created PR #376<https://github.com/quicwg/base-drafts/pull/376> to actually make that split.

Comments from the WG about either would be welcome.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Mar 2017 18:31:14 -0800

On Wed, Mar 8, 2017 at 6:16 PM, Mike Bishop <[email-masked]>
wrote:

> At this point, I don’t think anyone expects that HTTP/QUIC and HTTP/2 are
> the same protocol.
>

Hmm.. I'm still hoping we can in fact converge them or at least maximize
overlap.

That said, I'll take a look at this PR and send comments.

-Ekr

> However, the draft currently still attempts to define them as close
> cousins.  In PR #363 <https://github.com/quicwg/base-drafts/pull/363>,
> I’ve consolidated almost all of the “different from HTTP/2” text into a new
> section and excised a lot of stuff about “HTTP/2 has this, but HTTP/QUIC
> doesn’t need it” from the main body of the document.  Martin has advocated
> making a clean break from HTTP/2 and defining our own IANA registry for
> frame types and settings, just as we already have for errors.  We can, out
> of respect for legacy, use the same values where appropriate and reserve
> existing values currently in use on the HTTP/2 side.
>
>
>
> I think that’s a good idea, and it’s a fairly small step from the current
> state of #363.  I’ve created PR #376
> <https://github.com/quicwg/base-drafts/pull/376> to actually make that
> split.
>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Mar 2017 02:41:48 +0000

…and validating assumptions like that is part of why we have a mailing list.  ??

Sent from my Windows 10 phone

From: Eric Rescorla<mailto:[email-masked]>
Sent: Wednesday, March 8, 2017 6:31 PM
To: Mike Bishop<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Divergence from HTTP/2

On Wed, Mar 8, 2017 at 6:16 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
At this point, I don’t think anyone expects that HTTP/QUIC and HTTP/2 are the same protocol.

Hmm.. I'm still hoping we can in fact converge them or at least maximize overlap.

-Ekr

However, the draft currently still attempts to define them as close cousins.  In PR #363<https://github.com/quicwg/base-drafts/pull/363>, I’ve consolidated almost all of the “different from HTTP/2” text into a new section and excised a lot of stuff about “HTTP/2 has this, but HTTP/QUIC doesn’t need it” from the main body of the document.  Martin has advocated making a clean break from HTTP/2 and defining our own IANA registry for frame types and settings, just as we already have for errors.  We can, out of respect for legacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.

I think that’s a good idea, and it’s a fairly small step from the current state of #363.  I’ve created PR #376<https://github.com/quicwg/base-drafts/pull/376> to actually make that split.

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 9 Mar 2017 10:07:23 +0100

Thanks for separating this out, Mike. For spare time folks this makes following this aspect easier.

My first impression is that any hope to have http/2 over tcp and quic needs to be abandoned. Which will give the world a third protocol to carry http semantics.

What does that mean for the evolution of http, I wonder.

-stefan

> Am 09.03.2017 um 03:16 schrieb Mike Bishop <[email-masked]>:
> 
> At this point, I don’t think anyone expects that HTTP/QUIC and HTTP/2 are the same protocol.  However, the draft currently still attempts to define them as close cousins.  In PR #363, I’ve consolidated almost all of the “different from HTTP/2” text into a new section and excised a lot of stuff about “HTTP/2 has this, but HTTP/QUIC doesn’t need it” from the main body of the document.  Martin has advocated making a clean break from HTTP/2 and defining our own IANA registry for frame types and settings, just as we already have for errors.  We can, out of respect for legacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.
>  
> I think that’s a good idea, and it’s a fairly small step from the current state of #363.  I’ve created PR #376 to actually make that split.
>

---

From: Ian Swett <[email-masked]>
Date: Thu, 9 Mar 2017 09:28:14 -0500

Thanks for sending this out to the list.  I always hoped we could keep HTTP
over QUIC as similar to H2 as possible, but as you've pointed out
previously, a lot of HTTP/2 was adding transport features such as multiple
streams and flow control on top of an existing transport.  Switching to
QPACK would be another dramatic departure.

I'm not excited about QUIC abandoning HTTP2, but it may make enough
technical and documentation sense to be the right thing to do.  I am
concerned this could expand the scope of the HTTP mapping too much, so if
we're going to make this choice, I'd like to know what types of changes are
in scope.

On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <[email-masked]

> My first impression is that any hope to have http/2 over tcp and quic
> needs to be abandoned. Which will give the world a third protocol to carry
> http semantics.
>
> the same protocol.  However, the draft currently still attempts to define
> them as close cousins.  In PR #363
> <https://github.com/quicwg/base-drafts/pull/363>, I’ve consolidated
> almost all of the “different from HTTP/2” text into a new section and
> excised a lot of stuff about “HTTP/2 has this, but HTTP/QUIC doesn’t need
> it” from the main body of the document.  Martin has advocated making a
> clean break from HTTP/2 and defining our own IANA registry for frame types
> and settings, just as we already have for errors.  We can, out of respect
> for legacy, use the same values where appropriate and reserve existing
> values currently in use on the HTTP/2 side.
>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Mar 2017 15:59:28 +0000

To me, it’s a mostly editorial difference – do we try to contort the IANA registry to claim these are two variants of the same protocol, or do we just tell IANA they’re different protocols with different registries?  I don’t see that one choice implies a larger scope than the other.  I think the mission is still the same – deliver HTTP semantics over QUIC.

We’ve already decided we’re willing to make a number of departures from HTTP/2 because it makes technical sense in each individual case.  Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional streams in each direction) the HTTP mapping would do likewise in response (see branch unidirectional2).

From: Ian Swett [mailto:[email-masked]]
Sent: Thursday, March 9, 2017 6:28 AM
To: Stefan Eissing <[email-masked]>
Cc: Mike Bishop <[email-masked]>; [email-masked]
Subject: Re: Divergence from HTTP/2

Thanks for sending this out to the list.  I always hoped we could keep HTTP over QUIC as similar to H2 as possible, but as you've pointed out previously, a lot of HTTP/2 was adding transport features such as multiple streams and flow control on top of an existing transport.  Switching to QPACK would be another dramatic departure.

I'm not excited about QUIC abandoning HTTP2, but it may make enough technical and documentation sense to be the right thing to do.  I am concerned this could expand the scope of the HTTP mapping too much, so if we're going to make this choice, I'd like to know what types of changes are in scope.

On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for separating this out, Mike. For spare time folks this makes following this aspect easier.

-stefan

Am 09.03.2017 um 03:16 schrieb Mike Bishop <[email-masked]<mailto:[email-masked]>>:
At this point, I don’t think anyone expects that HTTP/QUIC and HTTP/2 are the same protocol.  However, the draft currently still attempts to define them as close cousins.  In PR #363<https://github.com/quicwg/base-drafts/pull/363>, I’ve consolidated almost all of the “different from HTTP/2” text into a new section and excised a lot of stuff about “HTTP/2 has this, but HTTP/QUIC doesn’t need it” from the main body of the document.  Martin has advocated making a clean break from HTTP/2 and defining our own IANA registry for frame types and settings, just as we already have for errors.  We can, out of respect for legacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 9 Mar 2017 13:21:23 -0500

Mike, I think it would be good if you resent the question - particularly
the bit about registries - in a new email with full background to both the
quic and httpbis lists... That community might have opinions as well and
QUIC wg is chartered explicitly to work closely with them.

my opinion has solidified over time to the "separate protocols but same
semantics (i.e. hq==h3)" position - esp wrt qpack which I think will be
very valuable for hq.

-P

On Thu, Mar 9, 2017 at 10:59 AM, Mike Bishop <[email-masked]>
wrote:

> To me, it’s a *mostly* editorial difference – do we try to contort the
> IANA registry to claim these are two variants of the same protocol, or do
> we just tell IANA they’re different protocols with different registries?  I
> don’t see that one choice implies a larger scope than the other.  I think
> the mission is still the same – deliver HTTP semantics over QUIC.
>
>
>
> We’ve already decided we’re willing to make a number of departures from
> HTTP/2 because it makes technical sense in each individual case.
> Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional
> streams in each direction) the HTTP mapping would do likewise in response
> (see branch unidirectional2).
>
>
>
> *From:* Ian Swett [mailto:[email-masked]]
> *Sent:* Thursday, March 9, 2017 6:28 AM
> *To:* Stefan Eissing <[email-masked]>
> *Cc:* Mike Bishop <[email-masked]>; [email-masked]
> *Subject:* Re: Divergence from HTTP/2
>
>
>
> Thanks for sending this out to the list.  I always hoped we could keep
> HTTP over QUIC as similar to H2 as possible, but as you've pointed out
> On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <
> [email-masked]> wrote:
>

---

From: Wenbo Zhu <[email-masked]>
Date: Thu, 9 Mar 2017 10:44:32 -0800

The HTTP mapping draft states:

"Connectivity problems (e.g. firewall blocking UDP) may result in QUIC
connection
establishment failure, in which case the client should gracefully fall back
to HTTP/2"

If QUIC and its HTTP mapping serve effectively as HTTP/3, then it seems to
me that QUIC should define its own TCP fallback (as "slow" and simple as it
needs be) .. .or will doing so create yet again another protocol variant
for what http mapping is concerned?   ( p.s. sorry if this has already been
discussed before ...)

---

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Mar 2017 18:54:31 +0000

Well, since we’re talking about failing to connect to an alternative, we could just say that the client should fall back to the origin or a different alternative, per RFC7838.  That removes any mention of a particular transport or a particular HTTP version.

From: Wenbo Zhu [mailto:[email-masked]]
Sent: Thursday, March 9, 2017 10:45 AM
To: Mike Bishop <[email-masked]>
Cc: Ian Swett <[email-masked]>; Stefan Eissing <[email-masked]>; [email-masked]
Subject: Re: Divergence from HTTP/2

"Connectivity problems (e.g. firewall blocking UDP) may result in QUIC connection establishment failure, in which case the client should gracefully fall back to HTTP/2"

If QUIC and its HTTP mapping serve effectively as HTTP/3, then it seems to me that QUIC should define its own TCP fallback (as "slow" and simple as it needs be) .. .or will doing so create yet again another protocol variant for what http mapping is concerned?   ( p.s. sorry if this has already been discussed before ...)

On Thu, Mar 9, 2017 at 7:59 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
To me, it’s a mostly editorial difference – do we try to contort the IANA registry to claim these are two variants of the same protocol, or do we just tell IANA they’re different protocols with different registries?  I don’t see that one choice implies a larger scope than the other.  I think the mission is still the same – deliver HTTP semantics over QUIC.

From: Ian Swett [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 9, 2017 6:28 AM
To: Stefan Eissing <[email-masked]<mailto:[email-masked]>>
Cc: Mike Bishop <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Divergence from HTTP/2

-stefan

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 9 Mar 2017 22:56:32 +0100

I think registering frame types and whatnot as a new protocol for carrying http semantics is wise. Keeping frame names/numbers with same semantics is good for it can ease understanding, it is not mandatory. 

I would hope that new frame types can be deployed in http/2 without also reserving them in hq (and vice versa). Otherwise the burden for people making extensions might be unnecessarily high.

As an implementor, the question is how to make the abstractions work inside a product supposed to support several transports for http applications. but that is outside the scope of the WGs and maybe rightly so.

Interestig times.

-stefan

> Am 09.03.2017 um 19:21 schrieb Patrick McManus <[email-masked]>:
> 
> Mike, I think it would be good if you resent the question - particularly the bit about registries - in a new email with full background to both the quic and httpbis lists... That community might have opinions as well and QUIC wg is chartered explicitly to work closely with them.
> 
> my opinion has solidified over time to the "separate protocols but same semantics (i.e. hq==h3)" position - esp wrt qpack which I think will be very valuable for hq.
> 
> -P
> 
> 
>> On Thu, Mar 9, 2017 at 10:59 AM, Mike Bishop <[email-masked]> wrote:
>> On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <[email-masked]> wrote:
>>

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 Mar 2017 00:51:45 +0000

We’ve talked a little bit about that.  Probably not, for the primary reason that most of the differences between HTTP/2 and HTTP/QUIC exist because QUIC is different from TCP.  If you’re running over TCP, you should just use HTTP/2.  That calculus might change if we start also bringing in major new features to HPACK, but even then I’d expect it to be a backport of particular features; HTTP/2.1 if you will.  “HTTP/QUIC” over TCP just doesn’t seem worth investment.

However, on the “still needs TCP” note, you might want to look at PR#348<https://github.com/quicwg/base-drafts/pull/348>.  That proposes an httpq:// scheme to accommodate scenarios where you don’t want/need to have dual TCP/QUIC stacks.  There’s currently no way to have an authoritative HTTP origin over QUIC if client and server can’t first speak TCP to exchange an Alt-Svc header.  This seems divided enough that I don’t expect to incorporate it in draft -02, but is definitely worth discussing at some point.  (To be clear, this will basically never be a web scenario; I envision this as being primarily used to identify service endpoints of HTTP APIs that choose to be served over QUIC.)

Sent: Thursday, March 9, 2017 4:04 PM

On Thu, Mar 9, 2017 at 3:23 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Actually, that’s almost exactly what the draft already says:
On receipt of an Alt-Svc header indicating HTTP/QUIC support, a client MAY
attempt to establish a QUIC connection to the indicated host and port and, if
successful, send HTTP requests using the mapping described in this document.

Connectivity problems (e.g. firewall blocking UDP) can result in QUIC connection
establishment failure, in which case the client SHOULD continue using the
existing connection or try another alternative endpoint offered by the origin.

Is there something you think we need to add to that?
No. The editor copy looks good.  (sorry for commenting on the wrong copy).

===

Given that http/quic is not http2/quic, protocols that want quic will likely have to support both http/quic (or quic) and http/2 as transports. I wonder if a better situation would be for quic to provide its own TCP alternative, or such an alternative would end up being as difficult as doing http2/quic.

From: Wenbo Zhu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 9, 2017 2:39 PM

To: Mike Bishop <[email-masked]<mailto:[email-masked]>>
Cc: Ian Swett <[email-masked]<mailto:[email-masked]>>; Stefan Eissing <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Divergence from HTTP/2

On Thu, Mar 9, 2017 at 10:54 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Well, since we’re talking about failing to connect to an alternative, we could just say that the client should fall back to the origin or a different alternative, per RFC7838.  That removes any mention of a particular transport or a particular HTTP version.
Yes, mentioning RFC-7838 will be good.

From: Wenbo Zhu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 9, 2017 10:45 AM
To: Mike Bishop <[email-masked]<mailto:[email-masked]>>
Cc: Ian Swett <[email-masked]<mailto:[email-masked]>>; Stefan Eissing <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Divergence from HTTP/2

-stefan

---

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Mar 2017 23:23:15 +0000

-stefan

---

From: Wenbo Zhu <[email-masked]>
Date: Thu, 9 Mar 2017 14:38:53 -0800

On Thu, Mar 9, 2017 at 10:54 AM, Mike Bishop <[email-masked]>
wrote:

> Well, since we’re talking about failing to connect to an alternative, we
> could just say that the client should fall back to the origin or a
> different alternative, per RFC7838.  That removes any mention of a
> particular transport or a particular HTTP version.
>

>
> *From:* Wenbo Zhu [mailto:[email-masked]]
> *Sent:* Thursday, March 9, 2017 10:45 AM
> *To:* Mike Bishop <[email-masked]>
> *Cc:* Ian Swett <[email-masked]>; Stefan Eissing <
> [email-masked]>; [email-masked]
> "Connectivity problems (e.g. firewall blocking UDP) may result in
> QUIC connection establishment failure, in which case the client
> should gracefully fall back to HTTP/2"
>
>
>

---

From: Wenbo Zhu <[email-masked]>
Date: Thu, 9 Mar 2017 16:04:22 -0800

===

Given that http/quic is not http2/quic, protocols that want quic will
likely have to support both http/quic (or quic) and http/2 as transports. I
wonder if a better situation would be for quic to provide its own TCP
alternative, or such an alternative would end up being as difficult as
doing http2/quic.

> *Sent:* Thursday, March 9, 2017 2:39 PM
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Mar 2017 10:38:43 +1100

The goal should remain as you say: to keep the differences minimal.  I
don't see us creating a protocol that doesn't have a stream for each
request, for example.  At some level, the abstractions will have to be
the same (it's HTTP after all), but ideally we keep more common pieces
than that.

There are some things that just don't hold any more. You can't rely on
absolute order between frames when they cross streams for instance.
Unfortunately, that means that we can't assume that extension frames
or settings will work automatically.  Mike's text on this actually
helps clarify this quite a lot, which should mean that new designs for
h2 can be made with hq in mind so that they won't need any adjustment.

On 10 March 2017 at 08:56, Stefan Eissing <[email-masked]> wrote:
> I think registering frame types and whatnot as a new protocol for carrying
> http semantics is wise. Keeping frame names/numbers with same semantics is
> good for it can ease understanding, it is not mandatory.
>
> I would hope that new frame types can be deployed in http/2 without also
> reserving them in hq (and vice versa). Otherwise the burden for people
> making extensions might be unnecessarily high.
>
> As an implementor, the question is how to make the abstractions work inside
> a product supposed to support several transports for http applications. but
> that is outside the scope of the WGs and maybe rightly so.
>
> Interestig times.
>
> -stefan
>
> Mike, I think it would be good if you resent the question - particularly the
> bit about registries - in a new email with full background to both the quic
> and httpbis lists... That community might have opinions as well and QUIC wg
> is chartered explicitly to work closely with them.
>
> semantics (i.e. hq==h3)" position - esp wrt qpack which I think will be very
> valuable for hq.
>
> -P
>
>
>> To me, it’s a mostly editorial difference – do we try to contort the IANA
>> registry to claim these are two variants of the same protocol, or do we just
>> tell IANA they’re different protocols with different registries?  I don’t
>> see that one choice implies a larger scope than the other.  I think the
>> mission is still the same – deliver HTTP semantics over QUIC.
>>
>>
>>
>> HTTP/2 because it makes technical sense in each individual case.  Obviously,
>> if QUIC takes a dramatic turn (e.g. unrelated unidirectional streams in each
>> direction) the HTTP mapping would do likewise in response (see branch
>> unidirectional2).
>>
>>
>>
>> them as close cousins.  In PR #363, I’ve consolidated almost all of the
>> “different from HTTP/2” text into a new section and excised a lot of stuff
>> about “HTTP/2 has this, but HTTP/QUIC doesn’t need it” from the main body of
>> the document.  Martin has advocated making a clean break from HTTP/2 and
>> defining our own IANA registry for frame types and settings, just as we
>> already have for errors.  We can, out of respect for legacy, use the same
>> values where appropriate and reserve existing values currently in use on the
>> HTTP/2 side.
>>
>>
>>
>> state of #363.  I’ve created PR #376 to actually make that split.
>>
>>
>>