QUIC Versions and Applications

Martin Duke <martin.h.duke@gmail.com> Wed, 28 April 2021 15:54 UTC

Return-Path: <martin.h.duke@gmail.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 6163D3A11B8 for <quic@ietfa.amsl.com>; Wed, 28 Apr 2021 08:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tGOGRnMi669A for <quic@ietfa.amsl.com>; Wed, 28 Apr 2021 08:54:28 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04F23A11AE for <quic@ietf.org>; Wed, 28 Apr 2021 08:54:27 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id v123so12109209ioe.10 for <quic@ietf.org>; Wed, 28 Apr 2021 08:54:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Qy08N0HqLkJU3b82cm3bX81vSQ3TmnUfGnQz3zbX2T4=; b=kDMn3aGMSoVpIgYZSCul7Sue0i+zahUDSnjMlQRFgKFRoCkYVudicXa1oAusqgVKVy 38l5MMtRM3qYf1TezF8kP761vIcWJ4KHfLUSU6VABinR+2I7l/iYpe60LTcDcsI2biNv Xm8+FQYNP3lMHf8qhxk+sSF7F6V+65JYt3i0rbKm5HxFPqXJRMYfRvkkCzdj6uppGEIt NfT7NryBIFMRGzA93JuZ2snOxzPD8uD8btFa9XAfXCngCGreVhMgb4IyDk9Zb5sOXayW pZFoAIDsAwmtIutOopTckjU7iMpXstTKRIUSQEbbCoY2rbJB8kZ5scGeymyw+UWCtUok uhng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Qy08N0HqLkJU3b82cm3bX81vSQ3TmnUfGnQz3zbX2T4=; b=IpmHDgDDN8L344Y47PRo1DCzFuUjbMOvh72eHfaLmFom32EZSv/AQND6qrdcGZ7cep 9ZiQd1phz8huFb/TAlXFlDk+eVhwlvAhhT/zVadrNNGkdAwNMtV4DesR0YXt5IS7kPGj orLcyASlEzpP/JCWT58iypK1DrP7EG66ZXRjHIXRDB8Ho6+kI04yT5Ed6VHLgLcDnLw9 nTqZsDAyIWzvqMQMjxD0CIXvbvJcGXwKVdrdR6F2J9nhnk6dVrjymfyeGfn6nG5PSEzv OyuhhaQCZswB4reLBH4tPMaMOVc487ly+0TUwBCxR2kN4SZhzlW86yZiLh8RHHfw180/ C2pQ==
X-Gm-Message-State: AOAM5323x/8hOV1z9adoe5TF8gnUiLqJxrzfHH598PcxxFmPa1K5pKi0 5B5FssuV480vrw4W5n5dcBqfjw0E6Pv+5Dr9h5bd0Xsrhtc=
X-Google-Smtp-Source: ABdhPJxTXUjmjbMCTsz4nvQ+HbLx1YvdyVdTOuptw005PBbQrbmK3rg6tcriN9YymbZGNFbFtyzY162akEVNMKUlvD8=
X-Received: by 2002:a5d:81c8:: with SMTP id t8mr24701836iol.19.1619625266339; Wed, 28 Apr 2021 08:54:26 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 28 Apr 2021 08:54:16 -0700
Message-ID: <CAM4esxRiqPPWEt4HAhHinMcvF9t7QZ1rhPUqsFUwFOcRH04DQQ@mail.gmail.com>
Subject: QUIC Versions and Applications
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ab671e05c10a64b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/oW9WRJY1H7tx4oJZpJZzBaNbH7s>
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 15:54:30 -0000

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.