Subject: [QUIC] New set of QUIC drafts

From: Jana Iyengar <[email-masked]>
Date: Fri, 8 Jul 2016 15:53:29 -0700

Dear all,

We have a new set of drafts that describes the various constituent parts of
QUIC:
QUIC transport protocol draft:
https://datatracker.ietf.org/doc/draft-hamilton-quic-transport-protocol/
QUIC congestion control and loss recovery draft:
https://datatracker.ietf.org/doc/draft-iyengar-quic-loss-recovery/
The use of QUIC as a transport for HTTP/2 is described in:
https://datatracker.ietf.org/doc/draft-shade-quic-http2-mapping/

In addition, the use of TLS1.3 for QUIC's crypto handshake is described in:
https://datatracker.ietf.org/doc/draft-thomson-quic-tls

- jana

(The earlier monolithic QUIC draft has been renamed, and is here:
https://datatracker.ietf.org/doc/draft-hamilton-early-deployment-quic/)

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Jul 2016 14:54:11 +0200

Hi there,

thanks for splitting the documents. Here are some early comments on 
draft-shade-quic-http2-mapping.

At some point we'll need to decide what HTTP/2-over-Quic is. Is it just 
a mapping to a different mapping to a different transport, or is it the 
next major revision of HTTP, thus essentially HTTP/3.

I'm asking because these seem to be conflicting goals, and it would be 
good to clarify that as soon as possible. That said:

The slides showed in the IETF Berlin Bof session specifically mentioned 
that a client success rate of 93% might be good enough (or close to 
that), as we can always fall back to HTTP/2-over-TLS. I do not disagree 
with that, but it essentially means that the client-visible semantics 
MUST be the same as for HTTP/2 (in particular as HTTP/2 over TLS in 
theory could fall back to HTTP/1.1 over TLS). The impact of this might 
be different for a browser such as Chrome compare to other users of HTTP.

Now looking at Section 2, "QUIC advertisement", specifically:

> 2.  QUIC advertisement
>
>    A server advertises that it can speak HTTP/2-over-QUIC via the Alt-
>    Svc HTTP response header.  It does so by including the header in any
>    response sent over a non-QUIC (e.g.  HTTP/2 over TLS) connection:
>
>    Alt-Svc: quic=":443"

Well, you'd need to register an ALPN identifiers "quic" for that. The 
problem is that (AFAIU) APLN tokens in theory are used to negotiate 
protocols over TLS, which is not the case here. I know that there are 
precedents with that, but if we really want to turn ALPN identifiers 
into a generic protocol negotiation mechanism, we really should talk to 
the TLS WG and potentially revise RFC 7301. (Alternatively, we could 
revise Alt-Svc, in which case you should talk to the HTTPbis WG).

>    In addition, the list of QUIC versions supported by the server can be
>    specified by the v= parameter.  For example, if a server supported
>    both version 33 and 34 it would specify the following header:
>
>    Alt-Svc: quic=":443"; v="34,33"

That would require registration in the "Alt-Svc Parameter Registry" (RFC 
7838, Section 7.3). That said, while working on HTTP/2 we did *not* use 
the final ALPN token, but just used the draft names as tokens; that 
seems to be much simpler, more robust, and doesn't require (a) 
registering an extension parameter and (b) properly parsing it.

> ...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Jul 2016 16:40:08 +0200

> On 22 Jul 2016, at 2:54 PM, Julian Reschke <[email-masked]> wrote:
> 
> Hi there,
> 
> thanks for splitting the documents. Here are some early comments on draft-shade-quic-http2-mapping.
> 
> At some point we'll need to decide what HTTP/2-over-Quic is. Is it just a mapping to a different mapping to a different transport, or is it the next major revision of HTTP, thus essentially HTTP/3.
> 
> I'm asking because these seem to be conflicting goals, and it would be good to clarify that as soon as possible. That said:
> 
> The slides showed in the IETF Berlin Bof session specifically mentioned that a client success rate of 93% might be good enough (or close to that), as we can always fall back to HTTP/2-over-TLS. I do not disagree with that, but it essentially means that the client-visible semantics MUST be the same as for HTTP/2 (in particular as HTTP/2 over TLS in theory could fall back to HTTP/1.1 over TLS). The impact of this might be different for a browser such as Chrome compare to other users of HTTP.

To be more explicit -- this turned out to be a sticky point in the HTTP/2 work; because we were chartered to be suitable for all common uses of HTTP, we needed to support it for both HTTP and HTTPS URLs, to the disappointment of those who felt that the new protocol was only suitable for HTTPS.

A fair amount of confusion / wrangling could be saved by some thoughtful chartering here, I suspect...

By the way, I wouldn't say "fall back to HTTP/1" -- it's more "fail to upgrade to HTTP/2."

Cheers,

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

---

From: Martin Thomson <[email-masked]>
Date: Sat, 23 Jul 2016 10:46:02 +0200

On 22 July 2016 at 14:54, Julian Reschke <[email-masked]> wrote:
> precedents with that, but if we really want to turn ALPN identifiers into a
> generic protocol negotiation mechanism, we really should talk to the TLS WG
> and potentially revise RFC 7301. (Alternatively, we could revise Alt-Svc, in
> which case you should talk to the HTTPbis WG).

Since we plan to use TLS, and to use ALPN for performing the integrity
check on version negotiation, this is OK in my view.  I think that in
the short term we will want to have something more specific than just
"quic".  I believe that someone at the BoF pointed out that getting
version negotiation in place early is important, and I agree with
that.  The draft numbering stuff we did with HTTP/2 might be something
we can lean on a little (as you point out).