Re: Consensus on Deploying QUIC v1 with HTTP/3

David Schinazi <dschinazi.ietf@gmail.com> Thu, 06 May 2021 18:30 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 5CB343A2BD5 for <quic@ietfa.amsl.com>; Thu, 6 May 2021 11:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 byr38vw2Px73 for <quic@ietfa.amsl.com>; Thu, 6 May 2021 11:30:01 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 CA1DE3A2BD4 for <quic@ietf.org>; Thu, 6 May 2021 11:30:01 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id t2-20020a17090ae502b029015b0fbfbc50so3936801pjy.3 for <quic@ietf.org>; Thu, 06 May 2021 11:30:01 -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=/Qpjzs/YRcA6ct2Vb4B39xsx6RmneGoZUnB3v64UYmI=; b=B8fq3SUYhVT6rHKsYEcvXBmkY+/t2slj3xkGa8QA8uJjCLQE9YWdi4hEPtzop+fPtc 15yhJlc5rHDkPdzGrdOhwsPTIHtilhx5B6gPY8AzBRJ5/Mi00w7jBEbE8iiCLdHGD//T 16haqCVEjEGuxPh9Ikd4rMM+Hhdk9NmEWwmNNvf3hFN/Wt5v9owW+yj7QXxZ5M/ihvWm RQHgxCuRizazXvxT7dsYJr2KSrf6i33D84hObkR9OsEmyDeJdHNEtRrRzYV8sS6t8757 RpsM8tr69C5l+05cGnBqYRvR8fO0Q7YGoDrWmAyy1lrdlBhj7U3M9u6eQK5VhTXAWyXs qI8w==
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=/Qpjzs/YRcA6ct2Vb4B39xsx6RmneGoZUnB3v64UYmI=; b=UCWitHr22LVRxHeaSJaZIejRP+1huPg/g0HWFAR+EBoLXFKxDKRbJwp3aj8FU8fu5G v1DAq/BcWTPK0wglNXZiG50A/00Rw2z3Y9GEeH5o0D/Mc8+B1coUx23qmGTSJdczO5gd Rqa3MNSjLxjPzmeSIJARZUs3pVNDVG9OZqJCLpPHbziWjPHOqGYsk04oniwKMc+TORFT Q5OKxqmmfWJXbYqIEkhmXCCS8elcXS2sP6j2BoCqWT7VCDBbVsndGqzJnu5hKkvSYQAo rd9ru6c7AC/Trs59RA+pjZl5NeA2Yjn5drfVD27/ZpO/lJY1f6EgyUHQ53vjyhMR8Cjc 8Y9g==
X-Gm-Message-State: AOAM532w4yZ64ekmLbXAJ/YHvEViCPH+tsqv22zksYoGiB8DQoXIT2hX OQe4WEwVWR+y9vJhYkG4TtNYvePE7j56kQxSRlE=
X-Google-Smtp-Source: ABdhPJxnA9hlczR7avqXIezun9m3i8L7alD32sqr+Ra/NLcli5+T+dbNGGKLvbFYA2nCgptwu1D+hWRyj6DhkNW57hc=
X-Received: by 2002:a17:90a:fd88:: with SMTP id cx8mr6146440pjb.190.1620325799506; Thu, 06 May 2021 11:29:59 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9obE-Dbm5Rwmr=h_34vaps1pcv36Jg0MTS_o0mZHEF1FvA@mail.gmail.com> <6740dcaa-3c43-faf2-826e-1cb3bb113aff@gmx.de> <CADdTf+gKZwcZD12he2YaGpWpOePZp_EB4J0QoXL6ozfx0BgJDg@mail.gmail.com> <CADdTf+h=iEjJ6k6FmDBOhYY7iLTjyDPWBejdU+ocyUCiGA09yQ@mail.gmail.com> <6b0ce1c8-bbe4-f8cd-b9c9-8e2eb378bd6d@gmx.de> <CALGR9oag_Q-yj2jVvqrKfswAJn4FiNQ_A4H20_dHxmrrCPV80A@mail.gmail.com> <CAPDSy+5Ce2NgnUFtHHO0FoEue7t9zph1HZQRe3_Yf3yzncAD9A@mail.gmail.com> <CALGR9obNLjWeD_+SxfhjbckPHS7u1nUHUta0aFRNzfzgbbD6WQ@mail.gmail.com>
In-Reply-To: <CALGR9obNLjWeD_+SxfhjbckPHS7u1nUHUta0aFRNzfzgbbD6WQ@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 6 May 2021 11:29:48 -0700
Message-ID: <CAPDSy+7DxJcaKd9e_hCgxcZbk3dwSALT8uu2QxCUjJUcUeoJ9Q@mail.gmail.com>
Subject: Re: Consensus on Deploying QUIC v1 with HTTP/3
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b3364105c1ad7faf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hQABYTP4bZFOr9O_-3wY2h2GTWg>
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: Thu, 06 May 2021 18:30:04 -0000

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 <lucaspardue.24.7@gmail.com>
wrote:

> Hi David,
>
> On Thu, May 6, 2021 at 5:38 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>>
>>
>> On Thu, May 6, 2021 at 7:54 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>
>> 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.
>>
>
> 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
>
>
>