Hi, Lucas,
On Wed, May 5, 2021 at 6:19 PM Lucas Pardue <[email protected]>
wrote:
> 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.
>
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
> 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/
>
