Re: Greasing the QUIC Bit

"Brian Trammell (IETF)" <> Thu, 02 July 2020 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FDD43A0A99 for <>; Thu, 2 Jul 2020 09:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RFbBV0P9jwxJ for <>; Thu, 2 Jul 2020 09:37:12 -0700 (PDT)
Received: from ( [IPv6:2001:1600:3:17::bc09]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 91C5C3A0A98 for <>; Thu, 2 Jul 2020 09:37:11 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id 49yNzS0gBrzlhT7V; Thu, 2 Jul 2020 18:37:08 +0200 (CEST)
Received: from [IPv6:2a02:169:17b2:0:e915:a04f:d295:badc] (unknown [IPV6:2a02:169:17b2:0:e915:a04f:d295:badc]) by (Postfix) with ESMTPA id 49yNzR56Yczlh8TM; Thu, 2 Jul 2020 18:37:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20191114; t=1593707827; bh=lQ/W5/YHeT911/1eAXCT2sF7h9Hr2qLpuCseLiM2p8k=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=y0LhQcpNtom5Ipkk9hXxmOERgI4bsAA36jFKe/eK5KC6Ss73uLFuEmPHHaFh9oI9A aFH6PlmJJQ50kv0Vnx+qC/nX7r8F0i07J/UgFuHvDXDVBjqT72BgS5XBPIxmyxOSsS DJp7FcF9iVLwlHIaM7quTOa1CMg9PXikjSGfa/5Y=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Greasing the QUIC Bit
From: "Brian Trammell (IETF)" <>
In-Reply-To: <>
Date: Thu, 02 Jul 2020 18:37:07 +0200
Cc: IETF QUIC WG <>, Stephane Bortzmeyer <>, Martin Thomson <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Spencer Dawkins at IETF <>
X-Mailer: Apple Mail (2.3608.
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.
X-Antivirus-Code: 0x100000
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 16:37:16 -0000

hi Spencer,

> On 2 Jul 2020, at 15:35, Spencer Dawkins at IETF <> wrote:
> Hi, Brian, 
> On Thu, Jul 2, 2020 at 8:21 AM Brian Trammell (IETF) <> wrote:
> > 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 operators. 
> Does any of that make sense?

Yep; have had limited cycles of late to devote to things IETF, but Mirja and I are picking up applicability and manageability again next week (to finally sync with the core documents which I presume will not change that much in WGLC).

This is tracked in



> Best,
> Spencer
> Cheers,
> Brian