Subject: Consensus on Deploying QUIC v1 with HTTP/3

From: Lucas Pardue <[email-masked]>
Date: Thu, 6 May 2021 00:18:34 +0100

Dear QUIC WG,

(HTTP WG is bcc'd)

As you may be aware, the QUIC v1 specifications entered AUTH48 state
recently and they are making good progress (thanks editors!). The HTTP/3
and QPACK documents have a dependency on the "HTTP core" documents being
worked on in the HTTP WG, so we expect them to take a little longer.

The drafts submitted to the RFC editor define QUIC version "0x00000001" [1]
and HTTP/3 ALPN identifier "h3". They include the clear instruction "DO NOT
DEPLOY THIS VERSION OF {QUIC, HTTP/3} UNTIL IT IS IN AN RFC".

HTTP/3 is explicitly tied to a version - the "h3" identifier is expected to
be used with QUIC "0x00000001". As several folks have observed on the list
[3][4] or in Slack, once the QUIC RFCs are published, 0x00000001 can be
used in deployment. But the longer lead time for HTTP/3 RFC creates some
grey area on what ALPN to use. Waiting for the HTTP/3 RFC delays deployment
of QUIC version 1 at the earliest convenience, which is unfortunate given
that the design has IETF consensus.

The Chairs have tracked various discussions and we believe there is
significant deployer interest in deploying "h3" as soon as the QUIC RFCs
are published and before the HTTP/3 RFC is published. Furthermore, on
balance of the information at hand, we observe a minimal perceived risk
with deploying "h3" before the HTTP/3 RFC.

This email commences a formal consensus call for permitting the deployment
of QUIC "0x00000001" with HTTP/3 ALPN identifier "h3" *once the QUIC RFCs
are published*. The call will end on May 13. Please reply to this thread on
the QUIC WG list with any additional comments, thoughts or objections
before then.

Cheers,
Lars, Lucas & Matt
QUIC WG Chairs

[1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34
[2] https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34
[3] https://mailarchive.ietf.org/arch/msg/quic/AQM3or1TNnInYhWe8UEx5B6nrgw/
[4] https://mailarchive.ietf.org/arch/msg/quic/M_uWXd2yvucnZwFs66g15ZbpJaM/

---

From: David Schinazi <[email-masked]>
Date: Wed, 5 May 2021 16:51:25 -0700

I support this proposal.

Though I have to ask: does this mean you're going to turn off h3 on
www.cloudflare.com until the QUIC RFC ships?

David

On Wed, May 5, 2021 at 4:19 PM Lucas Pardue <[email-masked]>
wrote:

> The drafts submitted to the RFC editor define QUIC version "0x00000001"
> [1] and HTTP/3 ALPN identifier "h3". They include the clear instruction "DO
> NOT DEPLOY THIS VERSION OF {QUIC, HTTP/3} UNTIL IT IS IN AN RFC".
>
> HTTP/3 is explicitly tied to a version - the "h3" identifier is expected
> to be used with QUIC "0x00000001". As several folks have observed on the
> list [3][4] or in Slack, once the QUIC RFCs are published, 0x00000001 can
> be used in deployment. But the longer lead time for HTTP/3 RFC creates some
> are published*. The call will end on May 13. Please reply to this thread
> on the QUIC WG list with any additional comments, thoughts or objections
> before then.
>
> Cheers,
> Lars, Lucas & Matt
> QUIC WG Chairs
>
>
> [3]
> https://mailarchive.ietf.org/arch/msg/quic/AQM3or1TNnInYhWe8UEx5B6nrgw/
> [4]
> https://mailarchive.ietf.org/arch/msg/quic/M_uWXd2yvucnZwFs66g15ZbpJaM/
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 6 May 2021 05:36:10 +0200

Am 06.05.2021 um 01:18 schrieb Lucas Pardue:
> [1] and HTTP/3 ALPN identifier "h3". They include the clear instruction
> "DO NOT DEPLOY THIS VERSION OF {QUIC, HTTP/3} UNTIL IT IS IN AN RFC".
>
> list [3][4] or in Slack, once the QUIC RFCs are published, 0x00000001
> can be used in deployment. But the longer lead time for HTTP/3 RFC
> creates some grey area on what ALPN to use. Waiting for the HTTP/3 RFC
> delays deployment of QUIC version 1 at the earliest convenience, which
> is unfortunate given that the design has IETF consensus.
>
> This email commences a formal consensus call for permitting the
> deployment of QUIC "0x00000001" with HTTP/3 ALPN identifier "h3" *once
> the QUIC RFCs are published*. The call will end on May 13. Please reply
> to this thread on the QUIC WG list with any additional comments,
> thoughts or objections before then.
> ...

You may want to clarify what *exactly* you mean by "the QUIC RFCs".

Best regards, Julian

---

From: Matt Joras <[email-masked]>
Date: Wed, 5 May 2021 21:09:29 -0700

> You may want to clarify what *exactly* you mean by "the QUIC RFCs".

Lucas was referring to C430:
https://www.rfc-editor.org/cluster_info.php?cid=C430

---

From: Matt Joras <[email-masked]>
Date: Wed, 5 May 2021 21:11:26 -0700

> https://www.rfc-editor.org/cluster_info.php?cid=C430
...Excepting the qpack and http documents. I hit the send button too
quickly.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 May 2021 09:16:39 -0500

Hi, Lucas,

> on the QUIC WG list with any additional comments, thoughts or objections

I hope this qualifies as a thought. I'm mostly sending it because of
interactions with Martin Duke on Section 6.9 of
https://datatracker.ietf.org/doc/html/draft-irtf-panrg-what-not-to-do-19,
and Martin IS an active TSV AD :-)

That section is talking about the (long and sad) deployment experience with
ECN, but the relevant part to this consensus call is:

   With these expansions, the two lessons, taken together, could be more
   helpfully summarized as "plan for failure" - anticipate what your
   next step will be, if initial deployment is unsuccessful.

The extended discussion of Section 6.9 is summarized in Section 4.13.
Planning For Failure. The relevant sentence is

   In addition to testing, partial deployment for a subset
   of users, implementing instrumentation that will detect degraded user
   experience, and even "failback" to a previous version or "failover"
   to an entirely different implementation are likely to be helpful.
   (See Section 6.9).

I am aware that QUIC and HTTP/3 have been deployed at scale with all the
instrumentation one could hope for when deploying Internet-Drafts, but I
have to ask - if people identify a (presumably rare) problem using HTTP/3
ALPN identifier "h3" with QUIC "0x00000001", what do we do then?

Best, as always, and thank you and the working group for thinking about
this before the last minute (same deal as Martin Thompson asking
about reserving the short varint values (0x00-0x3f) for RFCs in the
registry for transport parameters).

Spencer

---

From: Julian Reschke <[email-masked]>
Date: Thu, 6 May 2021 16:24:02 +0200

Am 06.05.2021 um 06:11 schrieb Matt Joras:
>     <https://www.rfc-editor.org/cluster_info.php?cid=C430>
>

See? That's why I was asking.

So we're discussing just -invariants, -transport, -tls, and -recovery,
right?

Best regards, Julian

---

From: Ian Swett <[email-masked]>
Date: Thu, 6 May 2021 10:33:03 -0400

This seems sensible to me.

> So we're discussing just -invariants, -transport, -tls, and -recovery,

Yes, only -invariants, -transport, -tls, and -recovery

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 6 May 2021 15:54:04 +0100

Hi Julian.

> So we're discussing just -invariants, -transport, -tls, and -recovery,

Thanks for pointing this out. The email was written from a position
familiar with the current documents' status. I should have been more clear
and explicit.

Yes, the -invariants, -transport, -tls, and -recovery, are the QUIC
documents that are presently in AUTH48 and we expect to be published as
RFCs before -http and -qpack. Other documents adopted by the QUIC WG are
not in scope for this discussion (the applicability drafts, datagram
extension, etc.). So to restate the original position more clearly:

This email commences a formal consensus call for permitting the deployment
of QUIC "0x00000001" with HTTP/3 ALPN identifier "h3" *after* -invariants,
-transport, -tls, and -recovery have been published as RFCs but *before *-http
and -qpack are published as RFC. The call will end on May 13.

Cheers,
Lucas

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 May 2021 10:18:32 -0500

Speaking from painful experience ...

> familiar with the current documents' status. I should have been more clear

I've spent literally decades trying to explain to people who weren't
familiar with the IETF standards track what "TCP" means - and, now, 40
years later, "Standard TCP", STD 7, is still RFC 793, with no other RFCs
that update it included in the standard.

I was still having that conversation with IETF participants in other areas
who just wanted to reference "TCP", after several discussions during IESG
Evaluation balloting, RFC 793 was the right answer.

Yes, https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ is in
WGLC, but that's not my point.

The QUIC working group could reasonably do a short Applicability Statement (
https://datatracker.ietf.org/doc/html/rfc2026#section-3.2) that (as part of
the RFC 2026 description)

   An AS identifies the relevant TSs and the specific way in which they
   are to be combined, and may also specify particular values or ranges
   of TS parameters or subfunctions of a TS protocol that must be
   implemented.  An AS also specifies the circumstances in which the use
   of a particular TS is required, recommended, or elective (see
section <https://datatracker.ietf.org/doc/html/rfc2026#section-3.3>
   3.3 <https://datatracker.ietf.org/doc/html/rfc2026#section-3.3>).

And THEN, we could just refer to one specification that explained what we
mean when we say "QUICv1", or "core QUIC", or whatever we want to call it,
and everyone would know what we mean, without having to guess. This would
be especially helpful for participants in other SDOs, but not only for
them.

I'm not sure whether the QUIC community would ever advance QUICv1 to full
Internet Standard, when it would become eligible for a STD  designation
that could include the relevant RFCs, but even if you do, that's probably
years in the future (and a lot of successful IETF protocols don't advance
beyond Proposed Standard).

If that was the right thing to do, I'd be happy to knock out a -00. Please
advise.

Best,

Spencer

> of QUIC "0x00000001" with HTTP/3 ALPN identifier "h3" *after*
> -invariants, -transport, -tls, and -recovery have been published as RFCs
> but *before *-http and -qpack are published as RFC. The call will end on
> May 13.
>
> Cheers,
> Lucas
>
>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 6 May 2021 16:51:23 +0100

Hi Spencer,

Thanks for sharing.

> ALPN identifier "h3" with QUIC "0x00000001", what do we do then?

Speaking as an individual.

There are possibilities for things to go wrong. HTTP has a mild safety by
means of Alt-Svc, its upgrade and fallback mechanism should insulate end
users from problems. QUIC can, however, be used for many applications so
the story isn't complete.

One failure root cause class is due to implementation - those things can
typically be detected and fixed. Another failure root cause class could be
in the QUIC protocol itself. There may be a need to fix such a problem in a
new version and that's partly why the WG is placing energy into the version
negotiation document (draft-ietf-quic-version-negotiation) [1] As I
mentioned up thread, the "h3" ALPN identifier is explicitly linked to only QUIC
0x00000001. Some of the recent version negotiation discussion has touched
on what HTTP/3 ALPN identifier we might use with a new version of QUIC.

So I don't have all the answers but I'm encouraged by the attitude to the
version negotiation work, in anticipation of the need to support QUIC
protocol revisions. Anyone with ideas or suggestions on that topic please
review or contribute to discussion on appropriate list thread or the GitHub
repository https://github.com/quicwg/version-negotiation/issues

Cheers,
Lucas

[1] -
https://datatracker.ietf.org/doc/html/draft-ietf-quic-version-negotiation

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 6 May 2021 17:06:02 +0100

Hi Spencer,

On Thu, May 6, 2021 at 4:18 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

>
> The QUIC working group could reasonably do a short Applicability Statement
> (https://datatracker.ietf.org/doc/html/rfc
> <https://datatracker.ietf.org/doc/html/rfc2026#section-3.2>
> 2026#section-3.2
> <https://datatracker.ietf.org/doc/html/rfc2026#section-3.2>) that (as
> part of the RFC 2026 description)
>
>    of a particular TS is required, recommended, or elective (see section <https://datatracker.ietf.org/doc/html/rfc2026#section-3.3>

The document draft-ietf-quic-transport contains in the first paragraph of
Section 1:

>   QUIC is a secure general-purpose transport protocol.  This document
>   defines version 1 of QUIC, which conforms to the version-independent
>   properties of QUIC defined in [QUIC-INVARIANTS].

Subsequent paragraphs go on to explain how -tls and -recovery relate to the
-transport document. That seems to cover your goal of pointing people to a
single document explaining the relationships between documents. But if I'm
overlooking something please say.

Cheers
Lucas

---

From: David Schinazi <[email-masked]>
Date: Thu, 6 May 2021 09:38:17 -0700

> but *before *-http and -qpack are published as RFC. The call will end on

Hi Lucas, since this is a formal consensus call, can you formally define
what you meant by "deployment"? Some clarifying questions:
- Is running a 1% experiment on clients before then OK?
- Is running a 1% experiment on servers before then OK?
- Is running 0x00000001+h3 on your main production server today OK if you
don't use Alt-Svc?
What we're describing is effectively a flag day, and it would be good to
define its parameters clearly.

Thanks,
David

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 6 May 2021 18:29:27 +0100

Hi David,

On Thu, May 6, 2021 at 5:38 PM David Schinazi <[email-masked]>
wrote:

>> deployment of QUIC "0x00000001" with HTTP/3 ALPN identifier "h3" *after*

These are excellent questions. So far the WG discussion has focused on the
0x00000001+h3 question. There is ambiguity in the transport-34 and http-34
definition of deployment and to date there wasn't much discussion of that.
The chairs would appreciate the WG to respond specifically to this point.

Cheers
Lucas

---

From: David Schinazi <[email-masked]>
Date: Thu, 6 May 2021 11:29:48 -0700

My personal opinion is that once we open the floodgates we can't close
them. More specifically, if someone ships an implementation to production
in a way that they cannot guarantee that it can be updated, then the
version used is now immutable. In practice, that means that if you ship a
client device that uses software updates, because some users do not update,
then that would lock us in. In that regards, I could see a world where:

1) Deploying on your server today is OK as long as you can guarantee that
if the protocol changes you'll be able to disable h3 or deploy a fix in
under 14 days
2) Deploying a client-side experiment today is OK as long as that
experiment will automatically stop after 14 days if the client device stops
hearing confirmation that the protocol is still OK to use
3) Once -invariants, -transport, -tls, and -recovery have all been
published as RFCs, then deploying everywhere is OK
4) Lack of Alt-Svc doesn't change points 1-3

Thoughts?
David

On Thu, May 6, 2021 at 10:29 AM Lucas Pardue <[email-masked]>
wrote:

>>> but *before *-http and -qpack are published as RFC. The call will end
>>> on May 13.
>>>
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 May 2021 14:31:48 -0500

Hi, Lucas,

On Thu, May 6, 2021 at 11:06 AM Lucas Pardue <[email-masked]>
wrote:

>> The QUIC working group could reasonably do a short Applicability
>> Statement (https://datatracker.ietf.org/doc/html/rfc
>> If that was the right thing to do, I'd be happy to knock out a -00.
>> Please advise.
>>
>
> Subsequent paragraphs go on to explain how -tls and -recovery relate to
> the -transport document.
>

Understood (and I had seen that text previously). So, that's a fine start.

> That seems to cover your goal of pointing people to a single document
> explaining the relationships between documents. But if I'm overlooking
> something please say.
>

I'd ask about these points:

draft-ietf-quic-transport is (checks -34) over 180 pages long. This
material is at the beginning of the Introduction (that's good), but it's a
tiny bit less clear how someone who's not familiar with the QUIC document
suite knows to start there (yes, having QUICv1 published as RFCs at least
makes that a bit more obvious on the documents page, at least at first).

At the bottom of Section 1.1, I find this text,

   This document defines QUIC version 1, which conforms to the protocol
   invariants in [QUIC-INVARIANTS
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34#ref-QUIC-INVARIANTS>].

   To refer to QUIC version 1, cite this document.  References to the
   limited set of version-independent properties of QUIC can cite
   [QUIC-INVARIANTS
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34#ref-QUIC-INVARIANTS>].

but that's following the description of the structure of
draft-ietf-quic-transport. Maybe just moving these paragraphs to Section 1
would be useful?

I note that people who understand QUIC much better than I do had to ask
what "the QUIC RFCs" were in this thread, so I was hoping that might be an
indication that things could be a bit clearer for us all! :-)

Do The Right Thing, of course.

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 May 2021 11:55:01 +0100

WG members,

> 4) Lack of Alt-Svc doesn't change points 1-3

Does anyone have any additional thoughts wrt to David's posits?

Cheers
Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 17 May 2021 12:19:45 +0100

All,

> https://mailarchive.ietf.org/arch/msg/quic/M_uWXd2yvucnZwFs66g15ZbpJaM/

Hearing no pushback, the chairs declare consensus on permitting the QUIC
wire version "0x00000001" to be deployed with the HTTP/3 ALPN identifier
"h3", once -invariants [1], -transport [2], -tls[3], -recovery[4] are
published as RFC.

The chairs note that a separate question was raised during the consensus
call, about QUIC deployment before -invariants [1], -transport [2],
-tls[3], -recovery[4] are published as RFC. There wasn't much engagement on
this topic, so the current instruction - DO NOT DEPLOY - still stands. If
folks have opinions in this respect, please take it to a different thread
on this list.

Regards
Lucas

[1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-invariants
[2] https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport
[3] https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls
[4] https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery