IETF Logo Mail Archive

Re: Greasing the QUIC Bit

"Brian Trammell (IETF)" <ietf@trammell.ch> Thu, 02 July 2020 13:19 UTC

Return-Path: <ietf@trammell.ch>
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 B48B73A0CC3 for <quic@ietfa.amsl.com>; Thu, 2 Jul 2020 06:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trammell.ch
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 xXf3YS1AtORc for <quic@ietfa.amsl.com>; Thu, 2 Jul 2020 06:19:16 -0700 (PDT)
Received: from smtp-8fae.mail.infomaniak.ch (smtp-8fae.mail.infomaniak.ch [IPv6:2001:1600:4:17::8fae]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9254C3A09D8 for <quic@ietf.org>; Thu, 2 Jul 2020 06:19:03 -0700 (PDT)
Received: from smtp-2-0001.mail.infomaniak.ch (unknown [10.5.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 49yJZr5QRhzlhhHW; Thu, 2 Jul 2020 15:19:00 +0200 (CEST)
Received: from [IPv6:2a02:169:17b2:0:428:9418:160f:9895] (unknown [IPV6:2a02:169:17b2:0:428:9418:160f:9895]) by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 49yJZr1pl3zlh8Tx; Thu, 2 Jul 2020 15:19:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=trammell.ch; s=20191114; t=1593695940; bh=Km+u3nBfzWgRo8Bwa+2cTSET5feApeFX3qUFix+ryPo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=h51OIphMc4NsIKOf3v+KHQRG+mHR3E+J/E/YNYdL8hrJcvHcnra6yQN65VoMUReOm TZ3xwm5tLybvYT7yczj+kpQWAk15xI/AGg6VFofyf+iA4pBpm8aM/8YUg7kIi/N4+R sB+lLxeYbdrKa9nR0cIX7sayNFmnQx0ilvnjmNns=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: Greasing the QUIC Bit
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
In-Reply-To: <20200702125735.GA31502@nic.fr>
Date: Thu, 2 Jul 2020 15:18:59 +0200
Cc: Martin Thomson <mt@lowentropy.net>, Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Transfer-Encoding: quoted-printable
Message-Id: <96495211-4618-4169-A45C-96EBD421AF18@trammell.ch>
References: <5943e1bd-fba9-473b-a20f-7992ad0579ab@www.fastmail.com> <20200702125735.GA31502@nic.fr>
To: IETF QUIC WG <quic@ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8
X-Antivirus-Code: 0x100000
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cw7e-o2-n4aKQs_iVHFF_a853d0>
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:19:26 -0000

> 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. :)

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.

Cheers,

Brian

v2.3.2 | Report a Bug | By Email