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

Martin Duke <> Thu, 22 April 2021 18:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 002353A12C3 for <>; Thu, 22 Apr 2021 11:21:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 sAjEHz4qChbA for <>; Thu, 22 Apr 2021 11:21:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A19EF3A12C5 for <>; Thu, 22 Apr 2021 11:21:45 -0700 (PDT)
Received: by with SMTP id a11so3325586ioo.0 for <>; Thu, 22 Apr 2021 11:21:45 -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=pgROCML2m8n7Y5NJ3lHoWBc1h/6yY8R5KJLo3Tsr0f4=; b=sbkhOigziyN+aPK9Kg0gdcAgFLNu+r27ODdAboFSBEDCoGQeKY9pkztGqFSXOeKJ9v ECbBNZoQBQ0PmesnVWBTqxeTEMVQYHeSZ6KYtU4IVh+DxixdsetW8dAGe3qzzCJq7HU1 9SDLktWB0iGYX9Z6ooVorusWocRsts3kuly/AIeF8Og4LyADoK2s1LKRzFp5gl3Ukcnw r06Ww+jrFKU/1WsYbDVMcMD9uczm6RMlMxAWToN5xlSCP3/+/CggM4DFv5ppLZ2o5B/e V/1OKDIdZi0Yed+E3I1jq+1BRF22m5ko8nIH+5fQDxFmlZ6BOaBRD6CjMM4w26zgbJFh yrKA==
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=pgROCML2m8n7Y5NJ3lHoWBc1h/6yY8R5KJLo3Tsr0f4=; b=Ix7Hbev4F4BeoTen+ucYtTEIKfUqkeVLu8Txwc+TgRdSonJSo+pjKoFSpN6Ywdqncl w/RlYBYtCzoRHynbtYDdRBTWt6eu6YBiWw+Bc7ZQGNfT2gIJCtqzPEFA90cQuJ/iFhGD R1GEu+eNbcGCSpIlX+zT9SzjJ3t2DK1v8HJHHChP4Ren9zkIPqEpEeVFBki4Y+IlPNdr hQEjINvO8aYXfJfZjcxMBnzH1V/+Hh3bH/w8BS04VbtvEAFKX/IJK/e5XaUWVXQPVSkj glyq6Gri4CDNW3ulWO0iO3EM/UJWjr1s3KH4zjpxaCV6DAc17hBk1xibOMKCB9FxRKzK EJTg==
X-Gm-Message-State: AOAM531XoPsyFwoI+EfbUDGNw3QMXy9du4b/GSKDPZiD2fS8OCFGS3Te 0l4kEHGuJdsufLowFju44GstJUIgld/3TcENGZWe5HT9N3aQpQ==
X-Google-Smtp-Source: ABdhPJwTF2UYfVP4QKoR7ygboOD+q2z3or/yq8bZWXgrGqzTV3vH8sBMKf7SQdl/Rg3Q1OR+azUhp+YL9Vvx+khDYXs=
X-Received: by 2002:a5d:9682:: with SMTP id m2mr160381ion.20.1619115703902; Thu, 22 Apr 2021 11:21:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Thu, 22 Apr 2021 11:21:37 -0700
Message-ID: <>
Subject: Re: New Version Notification for draft-duke-quic-v2-00.txt
To: Lucas Pardue <>
Content-Type: multipart/alternative; boundary="00000000000061a38605c093c01c"
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:21:50 -0000

Hi Lucas,

That's a great question that I hadn't considered.

The answer depends on what the WG does with the scope of this, and how VN

1. If it turns out there are some useful v1 patches we want to land here,
then there will be some churn.
2. The VN design is baked into v2, and that is not stable yet. While "v2"
might never change, an implementation that advertises v2 may in fact
instantiate non-interoperable VN designs that should not be aggregated into
a single version codepoint (though I'd have to think through how to
negotiate through mutating VN designs; I have probably made a conceptual
error here). In fact this draft is probably a necessary component to doing
proper implementation and testing of compatible VN (unless people keep the
draft versions around).

IMO if this gets to the point of implementation, it would be wise to use
experimental versions until it progresses to RFC. I filed an issue to fix


On Thu, Apr 22, 2021 at 11:07 AM Lucas Pardue <>

> 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.
> Cheers
> Lucas
> 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