Re: H3 ALPN?

David Schinazi <dschinazi.ietf@gmail.com> Mon, 03 May 2021 18:32 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572AC3A202D; Mon, 3 May 2021 11:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3R6FmRKxpLR; Mon, 3 May 2021 11:32:52 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA2F3A2014; Mon, 3 May 2021 11:32:49 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id e2so3308178plh.8; Mon, 03 May 2021 11:32:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KCctgMMr9hPUHRbFnABRMqefYVhnggv3jmFQeew4CMY=; b=sm9KCQK6FlyJWZ7lrcu4uGi9Bn3GSMIfAorPZ6r6HnzVyCufrz8HVlxoXiKi1+XA+k nHQFWtvAM++CND9s4IwU4GCcnQG/wyzqCoKPb0Hp+nso+cvy61Gtj/0Y9cC3XvgHHTH6 ftwzfCF6cjG4Qab6JvqdX7rdG9l0vsulvPLAwLvahmAcq7AMvMy9Jralo+gwf5EUa6lx hmJ6aXcJ1KQVvuuGcDzEkSrp8e94mlAhALDtPhIxPGiY3uqxAHaeN7AWCw8Zm1tnB8I0 XlPH39xCWcroIQZVcbzp2UxLWL1stjftuzTtkN1arXryfyOpV9bSYzgBSjiMP+OSJyBt q3FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KCctgMMr9hPUHRbFnABRMqefYVhnggv3jmFQeew4CMY=; b=D+aJooG1/Z9dJi5DPl6iXACs5A3cLKNEtvCVSkB1nEz31PR7Q3fc44OmOwmnL4sL6J mrwMMqq8lHcilAvH8cvDYXzgN6s5Ec+s1K+eGDozc61hVg7CJYu/cnEVa8MgJ0RniOzV 3GQR+OuZO3iwnR5U+I8krc1dCkAvhTM/qx8IALZRVOSW7dwATVTHOTLXFBgr4UZ4c3RD PIEwVT4QBU73Ev3ue9XbuSgVDir2HB8etS32RP6LFXxlOweGwvnVuGlvPZMn6f3tgbUp 9kpP8Mm4rM89ETHk8UeZ54K5MkfVTHTF7nD4K9l+/49LQgUDS2I4qYKINYapLbYYTI5b UKOw==
X-Gm-Message-State: AOAM53260wl//0OTJEWQGZr1KToKOF/9gp8ByTCrm2ObWsb7uZKMsXXE HyDV/9OrCZ61Sg6bGc8o4BBYol8wdLHwJepCVykEClcZ
X-Google-Smtp-Source: ABdhPJx6HtaK3hxpyrogJ3zyEL+j9dzoMxohlrvI/PbI3PFcKdQFtuP5lghJQxq73YECrtpbotAmO357dQeklSASmu4=
X-Received: by 2002:a17:902:d2cc:b029:ed:2984:d73c with SMTP id n12-20020a170902d2ccb02900ed2984d73cmr21793125plc.54.1620066767561; Mon, 03 May 2021 11:32:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxRFzsuhCfXeeuEp2Yyd396b2cLKhK=erxaRm-MC3CUo6A@mail.gmail.com> <CAM4esxRuPdhC_Ur+RA5C6QZFaof0ywsdmNtkr3HzPAmyw4Ov0w@mail.gmail.com> <CAM4esxS4ZwAGEnTUgKgLzcOUKwzrWOqt3+vdLkakLUVfFEjbjg@mail.gmail.com> <CAPDSy+6gUsWn6m0c7KPLu1eDG2p6kh5X9Z1-FkZuo_NHPqoR5Q@mail.gmail.com> <CAM4esxQ5S0OGFUov_3VE6sBmMa2-1MQ4gDKgyF3L-+M_OKD4fQ@mail.gmail.com> <CAG0m4gTphKdmBCBMw2Z6KSDy1a4hUZpkME2tEZQCFryUkvfG+Q@mail.gmail.com>
In-Reply-To: <CAG0m4gTphKdmBCBMw2Z6KSDy1a4hUZpkME2tEZQCFryUkvfG+Q@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 3 May 2021 11:32:36 -0700
Message-ID: <CAPDSy+7yn04JGM5Q6yEgjBYN2-f2WbkDz7yT4j7hro=3QkU8Rg@mail.gmail.com>
Subject: Re: H3 ALPN?
To: WG Chairs <quic-chairs@ietf.org>
Cc: Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000031679005c1713040"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ETlEGjkH0lS02TLEkSDH4b94PKc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2021 18:33:02 -0000

Hi QUIC chairs,

Could you please provide some guidance here? Ideally in the form of
official consensus?

I'm already seeing folks deploying production h3 servers ahead of the RFC
shipping so we could also just give up and open the flood gates.

David

On Thu, Apr 29, 2021 at 1:50 AM Dragana Damjanovic <
dragana.damjano@gmail.com> wrote:

>
>
> On Wed, Apr 28, 2021 at 4:28 PM Martin Duke <martin.h.duke@gmail.com>
> wrote:
>
>> I misremembered the previous discussion; it was on the list, not on
>> Slack, so it's archived. It starts here:
>>
>> https://mailarchive.ietf.org/arch/msg/quic/AQM3or1TNnInYhWe8UEx5B6nrgw/
>>
>> I believe the conclusion was that we would use 0x00000001/h3 as soon as
>> QUIC RFCs shipped, before H3 RFCs shipped.
>>
>>
> That works for me as well.
> The neqo(our quic/http3 library)  already implements this. This is
> currently not exposed in Firefox.
>
> Dragana
>
>
>> On Wed, Apr 28, 2021 at 7:22 AM David Schinazi <dschinazi.ietf@gmail.com>
>> wrote:
>>
>>> Google's implementation uses a 1:1 mapping between
>>> an h3 ALPN and a QUIC version. Because of this, when
>>> we ship QUIC 0x00000001, it'll be with ALPN=h3.
>>>
>>> Our code supports v1/h3 already, but v1/h3 is disabled by default.
>>> We'd like to align with everyone to pick a date when we start
>>> enabling v1/h3 in production though.
>>>
>>> From the conversations I've had, I think everyone agrees that
>>> when draft-ietf-quic-http ships as RFC, everyone will be allowed
>>> to ship v1/h3. I think everyone also agrees that we shouldn't do
>>> that before draft-ietf-quic-transport ships as RFC.
>>>
>>> The open question is: do we wait for draft-ietf-quic-http or do we
>>> move forward when draft-ietf-quic-transport ships?
>>>
>>> David
>>>
>>> On Tue, Apr 27, 2021 at 4:04 PM Martin Duke <martin.h.duke@gmail.com>
>>> wrote:
>>>
>>>> QUIC, sorry the confusion. The original message in this thread included
>>>> HTTPbis, and you should reply to that one to keep everyone in the loop.
>>>>
>>>> On Tue, Apr 27, 2021 at 3:59 PM Martin Duke <martin.h.duke@gmail.com>
>>>> wrote:
>>>>
>>>>> Damn it, wrong http
>>>>>
>>>>> On Tue, Apr 27, 2021 at 3:40 PM Martin Duke <martin.h.duke@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> In the quicdev slack channel today, we realized that we had a
>>>>>> disconnect on what ALPN to use in the interval between the QUIC RFCs
>>>>>> publishing and the HTTP/3 RFCs being ready (due to a MISREF with
>>>>>> http-semantics, etc).
>>>>>>
>>>>>> It's lost in the slack archives now, but I *think* we had concluded
>>>>>> that once the QUIC RFCs ship the endpoints should use 0x00000001/h3, not
>>>>>> h3-29 or h3-32, because the chance of something in http-semantics breaking
>>>>>> interoperability was nil. I personally don't really care how we converge,
>>>>>> as long as we converge.
>>>>>>
>>>>>> To summarize the choices, in the ~months between the RFCs, are
>>>>>> endpoints doing a QUIC version + ALPN of
>>>>>> 1) 0x00000001/h3 or
>>>>>> 2) 0x00000001/h3-xx
>>>>>>
>>>>>> Can we come to an agreement on this point?
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>