IETF Logo Mail Archive

Re: QUIC Versions and Applications

"Roy T. Fielding" <fielding@gbiv.com> Wed, 28 April 2021 16:03 UTC

Return-Path: <fielding@gbiv.com>
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 E688B3A122B for <quic@ietfa.amsl.com>; Wed, 28 Apr 2021 09:03:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=gbiv.com
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 Gqz2_jvNy0VW for <quic@ietfa.amsl.com>; Wed, 28 Apr 2021 09:03:36 -0700 (PDT)
Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) (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 0365C3A122C for <quic@ietf.org>; Wed, 28 Apr 2021 09:03:01 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 652F6781DB9; Wed, 28 Apr 2021 16:02:58 +0000 (UTC)
Received: from pdx1-sub0-mail-a40.g.dreamhost.com (100-96-16-49.trex.outbound.svc.cluster.local [100.96.16.49]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E349A78207A; Wed, 28 Apr 2021 16:02:57 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from pdx1-sub0-mail-a40.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.16.49 (trex/6.2.1); Wed, 28 Apr 2021 16:02:58 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|fielding@gbiv.com
X-MailChannels-Auth-Id: dreamhost
X-White-Blushing: 4e0820664aa92a78_1619625778192_1659254176
X-MC-Loop-Signature: 1619625778192:4090651189
X-MC-Ingress-Time: 1619625778191
Received: from pdx1-sub0-mail-a40.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a40.g.dreamhost.com (Postfix) with ESMTP id 925048C4C2; Wed, 28 Apr 2021 09:02:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=gbiv.com; bh=5SvHib1kfXlZVjI8jzVhnI8fkP4=; b= SGX85rTcqAgMUircALwFTBKHuY2OHAkERFZ9ivP6cs9nxu+tWP1liVlAHHLkX8In rZRGtsOYD5GtmFrB2NzwzhtEvxNws8gnQvpJ40aUNOyjSTgsd2AQmDmobu5QeWDH 5Y+qL8/F68WtCjeA77MOdJF0AU5QPo92qYZonIXmxWU=
Received: from [192.168.1.16] (ip68-101-102-139.oc.oc.cox.net [68.101.102.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by pdx1-sub0-mail-a40.g.dreamhost.com (Postfix) with ESMTPSA id 1F6418C4A4; Wed, 28 Apr 2021 09:02:54 -0700 (PDT)
X-DH-BACKEND: pdx1-sub0-mail-a40
From: "Roy T. Fielding" <fielding@gbiv.com>
Message-Id: <F5CEBB86-1797-448A-8A74-075A28FD9EAA@gbiv.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_98AFF779-E8CE-4C74-8F3B-0D383209C62B"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
Subject: Re: QUIC Versions and Applications
Date: Wed, 28 Apr 2021 09:02:53 -0700
In-Reply-To: <CAM4esxRiqPPWEt4HAhHinMcvF9t7QZ1rhPUqsFUwFOcRH04DQQ@mail.gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
To: Martin Duke <martin.h.duke@gmail.com>
References: <CAM4esxRiqPPWEt4HAhHinMcvF9t7QZ1rhPUqsFUwFOcRH04DQQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/TAlcE5w79uMO98VpA_e74eD6Ss0>
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: Wed, 28 Apr 2021 16:03:41 -0000

It's almost as if application-layer protocols need two version numbers,
one to indicate wire syntax and another to implement semantic capability over
time within a compatible syntax. I wonder where I've heard that before?

....Roy

> On Apr 28, 2021, at 8:54 AM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> Yesterday there was an interesting conversation on Slack, about whether h3 needed a new ALPN for QUICv2, that made me realize I had a very lazy mental model where applications needn't worry about QUIC versions and QUIC versions could be oblivious to what the app is doing. This isn't true at all.
> 
> The basic dilemma here is that either 
> 
> (1) applications need explicit updates when new QUIC versions roll out, if for no other reason than to say that they are fully compatible. This would make it hard to get rid of old QUIC versions, and slow deployment of new ones, as some apps never change. Or
> 
> (2) Each QUIC version has to enumerate which applications work with it and which don't, which seems... not scalable. Or
> 
> (3) There is a compatibility matrix with quic versions as rows and applications and columns, and any time a spec adds a row or column it should fill that row or column out completely. Or
> 
> (4) There are strict limits on future versions so that they don't take away existing functionality (e.g. there MUST be an ability to get reliable streams). or
> 
> (5) Applications MUST have application-layer fallbacks if some QUIC features aren't available (the way MASQUE can use QUIC STREAM frames if DATAGRAM isn't supported) - or maybe it can throw an application error
> 
> Maybe there's an alternative I can't see. The applicability draft <https://www.ietf.org/archive/id/draft-ietf-quic-applicability-11.html#name-port-selection-and-applicat> (currently in WGLC) says that each ALPN unambiguously defines the QUIC version, which I guess is option (1).
> 
> There are second-order questions like: is this mediated through ALPN or something else? But the first-order question is which layer has to manage all this.
> 
>

v2.23.0 | Report a Bug | By Email