Re: New Version Notification for draft-duke-quic-v2-00.txt

Lucas Pardue <> Thu, 22 April 2021 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F04053A11B8 for <>; Thu, 22 Apr 2021 11:07:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Status: No, score=-1.846 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 LfeB-Br3uczS for <>; Thu, 22 Apr 2021 11:07:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8873B3A11BE for <>; Thu, 22 Apr 2021 11:07:55 -0700 (PDT)
Received: by with SMTP id u21so70160920ejo.13 for <>; Thu, 22 Apr 2021 11:07:55 -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=POqy5CQAeT8I81cyG20HkU5994/3Ru/X0k0o1AXFNVA=; b=eQTqgecTW17yZRTGMLVIe+lG8+krTBpzF14QoL9sSvG0Vpqdb3D3/fora2RRosa+fX SP++kJZANJoRA2lXCN+fuJ6p+3xs0HQtU91AEaQ7z4tvJ2igOLmbFDksVmbY62PekHt6 iE/mQLh6lQb4gRwtShu/PfpVntfuRxxd1jZgwpLgVLvJJiUOxwlurARWTupwBQ2AIX5F 8RYxlT0PRFH46DXUJISYXzjZ3qmuJJvhPUq4VziDS6Ph8+Vyrn7pPSx+uePjbFCwBIvY PnkHrzV6MH/E+1YuiNYr+xVGlQDlqEiqicP5bjbhVEiZw4UktChYd7VyeMJf1GkljIqP TQow==
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=POqy5CQAeT8I81cyG20HkU5994/3Ru/X0k0o1AXFNVA=; b=N7S7U/+pdLPDga6QlvWZ6teg9w9DeMqDI6a+FxX7k/Qy9IBVVsAymt+HQbmTHaWCOq 8QdqpSbJlHIJE4doUHjvLPM7moZ/IRQmmS3Rb/sZyW4RbxsHvS0uBE0gCtF5IRU7/zuZ +VKt3cftI8OlqS6Rzw5gfqkrBEimmdN4oeGqsQth0UhaSAoyUofakHwig0a8TY6IxUuc NTS1eUH0VPPnfLt42mBwRCmHvIY7CBxrcjiIv9EVH5bCwypzU3SKW3TIgtxlsG9tEdaA w1YW5cFalI7nxtDVKr5lx5WNIsG87d4L+TDFcBKd4Cp7iLzlpTphvMnd9dCJpk8wwvjn aSLA==
X-Gm-Message-State: AOAM530d+b/gF5PiOYQlqOLp0GKGPlFC6wAfgVEoVqJSZzc07BoyGAL6 Nc3ktATJDDtZhUnCTCMDUIDs6EchmpKEMewG0SE=
X-Google-Smtp-Source: ABdhPJwsGmh5YbiJp/VU1efj6O2rWl9JwJ6KxFfD+itnOKOmgwMo6Z2RHG3+AvjIEH47f1iLtloZBcqTCa/a2odv3Ao=
X-Received: by 2002:a17:906:7c82:: with SMTP id w2mr4788268ejo.448.1619114868845; Thu, 22 Apr 2021 11:07:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Thu, 22 Apr 2021 19:07:37 +0100
Message-ID: <>
Subject: Re: New Version Notification for draft-duke-quic-v2-00.txt
To: Martin Duke <>
Content-Type: multipart/alternative; boundary="0000000000009bb13705c0938ef0"
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, 22 Apr 2021 18:07:58 -0000

Hi Martin,

Thanks for writing this up.

Speaking as an individual, I have some naive questions. Is this document so
trivial that it would never change between revisions? Or is there a risk
that something like initial salt in there might need to rev? To rephrase,
would the document be better off starting with a different QUIC version
value before interoperability discovers a problem and we've blown that code
point? We can always develop such a document with a target code point in
mind for use if the doc were to get adopted and run through all due process.


On Thu, Apr 22, 2021 at 6:52 PM Martin Duke <> wrote:

> Hello QUIC,
> I believe it was MT that threatened to do this a long time ago, but to
> work through compatible version negotiation I wrote up a trivial QUICv2
> (below) that just changes the initial salts. This caused me to figure out a
> couple of things about VN that may have been obvious to others but not to
> me.
> TL;DR we made the right decision to keep both in the draft.
> 1. One very possible world is one where firewalls ossify on expecting v1
> in the first packet, but don't care about subsequent packets. Compatible VN
> is well-designed for this world, as Client Initials (and 0RTT, sadly) can
> be v1 essentially forever and subsequent packets can be whatever we want.
> 2. If all versions are compatible, choice of VN method is essentially up
> to the client, but not quite deterministically: it can pick either a likely
> supported version or an unlikely one. If unlikely, the server will either
> accept it or send a VN. If likely, the server MUST use compatible VN to
> change the version, since it can't send a VN packet that contains the
> initial version unless it doesn't have full support for it.
> Anyway, this v2 draft is available for your consideration if people want
> to quickly iterate a new version, and/or we need a vehicle for fixes to v1.
> Thanks
> Martin
> ---------- Forwarded message ---------
> From: <>
> Date: Thu, Apr 22, 2021 at 10:22 AM
> Subject: New Version Notification for draft-duke-quic-v2-00.txt
> To: Martin Duke <>
> A new version of I-D, draft-duke-quic-v2-00.txt
> has been successfully submitted by Martin Duke and posted to the
> IETF repository.
> Name:           draft-duke-quic-v2
> Revision:       00
> Title:          QUIC Version 2
> Document date:  2021-04-22
> Group:          Individual Submission
> Pages:          5
> URL:  
> Status:
> Html: 
> Htmlized:
> Abstract:
>    This document specifies QUIC version 2, which is identical to QUIC
>    version 1 except for some trivial details.  Its purpose is to combat
>    various ossification vectors and exercise the version negotiation
>    framework.  Over time, it may also serve as a vehicle for needed
>    protocol design changes.
>    Discussion of this work is encouraged to happen on the QUIC IETF
>    mailing list or on the GitHub repository which contains
>    the draft:
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> The IETF Secretariat