Re: Greasing the QUIC Bit

Spencer Dawkins at IETF <> Thu, 02 July 2020 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74EEF3A0789 for <>; Thu, 2 Jul 2020 06:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TNt-a0-nGrvr for <>; Thu, 2 Jul 2020 06:36:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89E453A079B for <>; Thu, 2 Jul 2020 06:36:17 -0700 (PDT)
Received: by with SMTP id n23so32204317ljh.7 for <>; Thu, 02 Jul 2020 06:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 02 Jul 2020 08:35:48 -0500
Message-ID: <>
Subject: Re: Greasing the QUIC Bit
To: "Brian Trammell (IETF)" <>
Cc: IETF QUIC WG <>, Stephane Bortzmeyer <>, Martin Thomson <>
Content-Type: multipart/alternative; boundary="0000000000001edd9205a9757e3e"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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) <>

> > On 2 Jul 2020, at 14:57, Stephane Bortzmeyer <> wrote:
> >
> > On Thu, Jul 02, 2020 at 09:01:08PM +1000,
> > Martin Thomson <> 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, 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, which targets

Does any of that make sense?



> Cheers,
> Brian