Re: Greasing the QUIC Bit

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 02 July 2020 13:36 UTC

Return-Path: <spencerdawkins.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 74EEF3A0789 for <quic@ietfa.amsl.com>; Thu, 2 Jul 2020 06:36:19 -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, 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 TNt-a0-nGrvr for <quic@ietfa.amsl.com>; Thu, 2 Jul 2020 06:36:17 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 89E453A079B for <quic@ietf.org>; Thu, 2 Jul 2020 06:36:17 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id n23so32204317ljh.7 for <quic@ietf.org>; Thu, 02 Jul 2020 06:36:17 -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=7HmKu+FvIdAUv1KUnLA61K6QJaTrQZytR+/G4mXNemM=; b=HDHdSFLvAAhwPqhGTJl3jwtOvbgC3jLT8kGTexOfi6oCdbhFnwSCmK3ZjpC+6NYgAD iMhIqs7SIf3zt+amb9705a6C89I/BWsStMyIdKYdkPax/+V61VFT/5GWhtmCho8doeyh iskUMKXzUFrTSX94TGwxZgKssmly+Aj1PEUuL3Dc+4tDdS9ugnaxLoTVod35qrvNDnNr kKjV9UhAme4iAA7FqK6QD7jHoebz1iCuYllFxE22/l1kArOk4fJqlBFUVJhzYfxUD5rW MNX7RhmRyQrTsdvxMna8bqKXPbfAjgBnmXLKao+JpOJzmLL+PDKl6P61i39ws4q4TRPL +iag==
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=7HmKu+FvIdAUv1KUnLA61K6QJaTrQZytR+/G4mXNemM=; b=TZgf4e3Vzfpl+ke/C62pe+7DFx3RW6jgcIbqkTPUZzkVtSVVIHEWPowZSm+GdKyoF6 n/iNE7VsAs7ue8R8e8H1U/Sz/0m3rAmBEFRy//uw/ngPUUyb2qTM7Jou2X8Lc5VROlu+ afIVR2H5juNa2069mSXTpcYHLcx4Kqbq4rp5vOmdmSIEVtwTpuztiYaNxkSGNTUz6hL9 7qncY7AeCiSjLcYPKt6FAEY9FVE1jShhGHMMCXswHc7boGms4pt1oCpMY7+XNJtZfN+Q 7wLTUPrwbUQV2wH9T0bupVwHjFk7Fz3tVQ3kpHQannBPEYLPma7wv7UGdOsP8LaAq77t Achg==
X-Gm-Message-State: AOAM5330JYMxLf+hG9PTpxNXjFf7GG1k2hZEt9jaOhGsJXpcmMCFzi17 /rur72OxIedwWJj783/8VKDnu5+Q8ZVKFQFai7TM6BBO
X-Google-Smtp-Source: ABdhPJwcafYcLHOEBkEN4KOqdvNPfZrFcXT/GnocfjmYTXFmdhN8ic1KW99gyaDjVgqPv7Lf0iQHVf+7it/1aIUfLrs=
X-Received: by 2002:a2e:9b42:: with SMTP id o2mr15877388ljj.102.1593696975771; Thu, 02 Jul 2020 06:36:15 -0700 (PDT)
MIME-Version: 1.0
References: <5943e1bd-fba9-473b-a20f-7992ad0579ab@www.fastmail.com> <20200702125735.GA31502@nic.fr> <96495211-4618-4169-A45C-96EBD421AF18@trammell.ch>
In-Reply-To: <96495211-4618-4169-A45C-96EBD421AF18@trammell.ch>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 2 Jul 2020 08:35:48 -0500
Message-ID: <CAKKJt-f+w5DpQ7KoQXduB5q7DDqnwvJsqs7UwJ7KdsmvvZ23aA@mail.gmail.com>
Subject: Re: Greasing the QUIC Bit
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: IETF QUIC WG <quic@ietf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, Martin Thomson <mt@lowentropy.net>
Content-Type: multipart/alternative; boundary="0000000000001edd9205a9757e3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/3jXb928oomRP0Evbd538jxevrJA>
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, 02 Jul 2020 13:36:19 -0000

Hi, Brian,

On Thu, Jul 2, 2020 at 8:21 AM Brian Trammell (IETF) <ietf@trammell.ch>
wrote:

>
> > On 2 Jul 2020, at 14:57, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> >
> > On Thu, Jul 02, 2020 at 09:01:08PM +1000,
> > Martin Thomson <mt@lowentropy.net> wrote
> > a message of 7 lines which said:
> >
> >> That's a shame, so I wrote a draft explaining how that might not
> >> need to be true forever.
> >
> > Isn't it the point of draft-ietf-quic-invariants? If it is not an
> > invariant, it may change.
>
> Invariants is a normative declaration of what we won't change in the
> future. This draft is a proof of concept showing that we can keep the "QUIC
> bit" from being an accidental invariant (i.e., a practical invariant not
> normatively declared as such).
>
> I continue to fear that the demand for on-path discrimination of QUIC
> traffic will remain such that if:
>
> - there is no intentional invariant for distinguishing QUIC traffic from
> non-QUIC traffic by arbitrary on-path devices; AND
> - there is a trivially deployable method for blocking QUIC traffic which
> will result in negligible end-to-end availability risk and low impact on
> quality of experience, i.e. that blocking will come at no cost to access
> networks that choose to do so (which given TCP fallback is indeed the case
> in the majority of networks, unless things have changed since I last looked)
>
> then we remain at risk of a rapid reversal of fortune on deployment.
> Sorry, hadn't said that at a mic for about a year now, felt a need to
> repeat it for the record. :)
>

Thank you for the important reminder.


> As this view is incapable of gaining consensus within this working group,
> I'm fully in support of this approach to greasing the QUIC bit: we should
> be intentional about our invariants, and back them up with running code.
> And this appears to be a perfectly reasonable way to do that.
>

Before I read this ^ paragraph, I was planning to ask you whether "blocking
QUIC" merited a mention in
https://tools.ietf.org/html/draft-ietf-quic-manageability-06, because we
are in the awkward position with HTTP/3 that operators will face less
blowback blocking HTTP/3-QUIC and forcing a fallback to HTTP/2-TCP than
they will face blocking almost any non-HTTP/3 QUIC protocol (with less
clearly defined fallbacks) (see: MASQUE).

ISTM that at a minimum, the "accidental invariants" might be mentioned in
https://tools.ietf.org/html/draft-ietf-quic-manageability-06, which targets
operators.

Does any of that make sense?

Best,

Spencer


> Cheers,
>
> Brian
>
>
>