Re: Version Ossification: Intended Scope for QUICv1

Ian Swett <> Tue, 12 November 2019 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D443612006F for <>; Tue, 12 Nov 2019 08:00:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 vh1PU4bCz_5U for <>; Tue, 12 Nov 2019 08:00:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4232612006E for <>; Tue, 12 Nov 2019 08:00:31 -0800 (PST)
Received: by with SMTP id b11so3769194wmb.5 for <>; Tue, 12 Nov 2019 08:00:31 -0800 (PST)
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=U5YGRYHyM98g4Ndh37ecZCKz5ZTYCkw1eKH9yltnwe0=; b=I5BtZYivTYoBAqbwgbExQmNftIJs+tZUaZDlpPyfuddsOIph+rNG4o0cDnbPVOoFmq X6emHkcya+e6G7/BFyTSqzR/b333RB1paCe8Z5q3Eh1qnab5PCVOXF3Ym81Mx0nCfWRG geTnEk9amFdTtMktf92kLKG7fh96DPIvxT9XH3o9T6DMgwxmGouyAes9XsAggHgh3Oz2 UFgSp7Edk0Ek0ETs0o5Huj0hvWq39rkPIqt4/AEgNjlF3paCtFTu8b7fPoeZbZtoRF3b Ki/NWNLPG+LSSXQycNta8FJJ7OcRZLn4rwst9je7NzZon2smThXoMV308VgaFZyyBqaL o48g==
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=U5YGRYHyM98g4Ndh37ecZCKz5ZTYCkw1eKH9yltnwe0=; b=ZmOKut9QnRKkZtoP4P47I9uyvgzDvikR7OVJ1MV94gsQ8ap2yPDrMoJXZvd7tNitDv 17L9JVzh4PB6M1RRuAMFm0WpH28998PrhlR4opgowvMpu7aH5Ha78kPlhhZ9BwXoDU9I gwk1XikjP7F+ploYavsml708gYoI7KzsCFz0jBPKdsVrcBinzYVvu9hiuK0jBlHT+sJH ifQt+xQqzLLj8nn/SNY4EH15rHicZrNsJ0MlS+5lC/QuLJN4Qvol3Wof0MoUgxKXhgbw iqB0FkvtdGxTfodl9fD1DF8lwnyACS3+qA0blVmvhj7VXRqx6HdcMP3hk0wByha6xjaa /anA==
X-Gm-Message-State: APjAAAUudNjvFnaLVfI7IB1B5GFEwpMLFzPAMcWb9zr7FcD2Eawfepkd 3CwFXoQUNq+feqZ5agIFIhQKmkjKNtVDvh15koiMf8ScYBA=
X-Google-Smtp-Source: APXvYqxV7KxWSRt9Xz2+/GnQArPvcFhqo0jrL0zJrNVpnsb1358FXbSFCU+5G09QZs6vXAgv/vdjellQn4WkVKfj/dM=
X-Received: by 2002:a1c:7d47:: with SMTP id y68mr4537176wmc.157.1573574429465; Tue, 12 Nov 2019 08:00:29 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Tue, 12 Nov 2019 10:59:58 -0500
Message-ID: <>
Subject: Re: Version Ossification: Intended Scope for QUICv1
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000e5df2805972858dd"
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: Tue, 12 Nov 2019 16:00:34 -0000

Past experience indicates if we don't use joints, they will not work, both
internal(ie: SETTINGS) and external ones.
It also indicates that middleboxes will want to identify QUIC.  I'm happy
to sacrifice the invariants and QUIC bit for that purpose.

I have seen no evidence that if we continue using multiple versions in
production, future version numbers with the same invariants won't work.
Google is starting to deploy the 4th public header format in the last 2
years(current IETF invariants).  These public header changes require more
outreach, but even they are still possible.

On Tue, Nov 12, 2019 at 12:44 AM Martin Thomson <>; wrote:

> On Tue, Nov 12, 2019, at 16:11, Eric Rescorla wrote:
> > ISTM that this is the scenario of interest for QUICv2 as well, namely
> > that the protocol will be public but vendors will have to adapt. If
> > they do that by reading specs and updating prompt, that seems not ideal
> > but acceptable.
> Yes, that would be tolerable.  The concern is that they stop at v1 and we
> can't properly rely on v2 working.