Re: Second WGLC for Multipath Extension for QUIC

Lucas Pardue <lucas@lucaspardue.com> Mon, 06 October 2025 16:15 UTC

Return-Path: <lucas@lucaspardue.com>
X-Original-To: quic@mail2.ietf.org
Delivered-To: quic@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id F39A16E0BD07; Mon, 6 Oct 2025 09:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=lucaspardue.com header.b="gd6eMK4T"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="UU2yuJ33"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbV98EaoQwHN; Mon, 6 Oct 2025 09:15:13 -0700 (PDT)
Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C973E6E0B914; Mon, 6 Oct 2025 09:14:59 -0700 (PDT)
Received: from phl-compute-08.internal (phl-compute-08.internal [10.202.2.48]) by mailfhigh.phl.internal (Postfix) with ESMTP id BFF591400098; Mon, 6 Oct 2025 12:14:59 -0400 (EDT)
Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-08.internal (MEProxy); Mon, 06 Oct 2025 12:14:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucaspardue.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1759767299; x= 1759853699; bh=0BF6eN4jUdYNcXj02iDErK4irS9TVvpbtXUW8eeI2ng=; b=g d6eMK4TLKyU+35C8B8ROPagVICPKSRjOLpWRHJ6NfqOELRmOe08wHMlVehePU2MC r9uGXk4Z9OrY0uvMsx55V2g/6EBC5R+M0dKJKoiU8swJQ11fC6dA8N5VSmOaZPJD t0Nug/zlEk+DzokDYNld3SLZg86pomvID2Gp7LfnJqbok0CVwEQjUIBkrjwsO4p+ cF0H9xGn+0Gd8gUl5nwkowIRwGEkWdT3L/hSnPQM75ClBkM08O5XDHDYpORs8sqx D+TTyAeFOCHNw7achzh8GJLj8dJKbV8UQyBSz+FIFI1eFs6fXIdz2H1omFNFx4dF xEwfUsapmaM6XfqPsQemg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1759767299; x=1759853699; bh=0BF6eN4jUdYNcXj02iDErK4irS9TVvpbtXU W8eeI2ng=; b=UU2yuJ33RDIkAeMtYy63twNTJ9tdL8PDs/v6ouvU7xGxoTBi77w qUDzzD1DIvKoOIpu32KAYGxCp7xkktU0EqkWKNbPyd+f82NNEA7ucT55aRcZKTsz wRA6tygCzzhNzDVX29TGK7Shgx+yN3TywyZrdnuts+gb1yeOG6tayo5+qHOIXeyj oSFhrjivpEKllgELXxBE9QaWnT8fdMqEHz435LUqFoEPTn74j4WD8GkpS5Hf8oMN Nu4nDDQ5OkZfVQmQKkS7tPatPRT2IbugPhT2w3B2fPPDYVtdhp7ieZ9KLStN9qYr 0BVpDhfZsleiR19n3A61xf6Vpy8YlfuZiYw==
X-ME-Sender: <xms:A-vjaJvuwPdfY31KoD9L71POX0WLzH7NwqLVXQOlZdjzKpMG50yGUA> <xme:A-vjaNSt9w9_N6cJFi5Vv77qxDEtByKSrLVvoqt1lpW1peUVFt4B7cErs5wLwQuJj kei2Qh97YtNq_NHPX97Af4ghYoVRnScdvbEdPfzRPZPnrmhw68YuQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeljeellecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefoggffhffvvefkjghfufgtsegrtderreertddtnecuhfhrohhmpedfnfhutggrshcu rfgrrhguuhgvfdcuoehluhgtrghssehluhgtrghsphgrrhguuhgvrdgtohhmqeenucggtf frrghtthgvrhhnpeevheffffejhfejjeduhfffffejleefgeefudektdejueefteetiefh gfdtfffhudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehluhgtrghssehluhgtrghsphgrrhguuhgvrdgtohhmpdhnsggprhgtphhtthhopeeg pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehlrghrshesvghgghgvrhhtrdhorh hgpdhrtghpthhtohepihgrnhhsfigvthhtsehgohhoghhlvgdrtghomhdprhgtphhtthho pehquhhitgdqtghhrghirhhssehivghtfhdrohhrghdprhgtphhtthhopehquhhitgesih gvthhfrdhorhhg
X-ME-Proxy: <xmx:A-vjaKzNauwQqfSMNMtmx__v43_D2W2L1q4PmQyeFIx9jIGtM8Fd8A> <xmx:A-vjaNTaAMRZjDzFtYJCakiEVImb1_ywhuadi2njCuB7NnIiPIENIA> <xmx:A-vjaBWyUTrSs28eDLXCi_hOpX76Ls57jMIlaJpfKOziqsatjTvkWg> <xmx:A-vjaPa-Q3WDcmSU-9x6eL03UPvLdVeog5WLVX6mnf1jLcwK1oEKmg> <xmx:A-vjaL8asalVVJglVgMXtAi9gINIdxbdPgWyw5CZAQlHFFa0TgiPTr6h>
Feedback-ID: i23b94938:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id 71344700065; Mon, 6 Oct 2025 12:14:59 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: AFDg2MwXO9QJ
Date: Mon, 06 Oct 2025 17:14:37 +0100
From: Lucas Pardue <lucas@lucaspardue.com>
To: Lars Eggert <lars@eggert.org>
Message-Id: <a3365faa-5bf3-40cb-84f6-3ee2d118007d@app.fastmail.com>
In-Reply-To: <5E368233-E1A8-46E8-9B97-D69F9F3D9890@eggert.org>
References: <ea1b0721-4fc8-4477-9246-60bba0f2a1c0@app.fastmail.com> <080dcfd9-49e2-46c8-8617-38ebe2ca7185@app.fastmail.com> <CAKcm_gPD0VQx4u=BV8EoeJ6FgnVVsnJtX5vAawnmzEDftW1zQw@mail.gmail.com> <752ED5ED-9C09-48B9-ADFB-EE66895825AB@eggert.org> <358af066-6d87-4bea-81dc-1d4316fb72e7@app.fastmail.com> <5E368233-E1A8-46E8-9B97-D69F9F3D9890@eggert.org>
Subject: Re: Second WGLC for Multipath Extension for QUIC
Content-Type: multipart/alternative; boundary="f7829adf4a2d46ffb67146ea9dca5e30"
Message-ID-Hash: IG4FWDSGCH6T7H4UPSVWLH3V4ORTNPLC
X-Message-ID-Hash: IG4FWDSGCH6T7H4UPSVWLH3V4ORTNPLC
X-MailFrom: lucas@lucaspardue.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-quic.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Ian Swett <ianswett@google.com>, quic@ietf.org, QUIC WG Chairs <quic-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DYW6jboYPLoUW9xYFt1z5diBINQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Owner: <mailto:quic-owner@ietf.org>
List-Post: <mailto:quic@ietf.org>
List-Subscribe: <mailto:quic-join@ietf.org>
List-Unsubscribe: <mailto:quic-leave@ietf.org>

Hi Lars

On Mon, Oct 6, 2025, at 16:51, Lars Eggert wrote:
> Hi,
> 
> On Oct 6, 2025, at 17:08, Lucas Pardue <lucas@lucaspardue.com> wrote:
> > There were comments from individuals such as Martin Duke and Lars Eggert that I, as a chair, interpret to mean that they could live with a standards-track document (i.e. not calling for an experimental document) if it would make some editorial changes. For instance clarify and reinforce the foundational capabilities of the extension, and what things specific deployments or use cases would need to consider, while avoiding normative references on something that is a research topic. I believe the document updates made and captured in (at the time of writing) draft 16 address these requests. Do you think there are further changes needed?
> 
> I was thinking I was alone in my dissent, but then Ian emailed, and I got triggered :-)
> 
> I just briefly rechecked -16:
> 
> The title is still very generic, implying that this is a (*the*?) multipath extension for QUIC. Same in the abstract.
> 
> The last three paragraphs of the introduction then have some text that was maybe added to address the raised concern, i.e., that this doc specifies extensions for *managing multiple paths* for QUIC connection. But that that alone is not resulting in "multipath QUIC", i.e., an IETF standard for how you actually safely and effectively utilize those multiple paths at the same time. I think the document needs to be much more blunt in stating that caveat ("We give you paths. We don't tell you how to use them. This is a required piece of multipath QUIC, but not a complete standard.")
> 
> I hope this makes my concern a bit clearer. It's not that I disagree that what the doc normativley describes isn't ready for PS, it's that the doc is titled and introduced as if that was all the pieces needed for multipath QUIC when that's not the case.
> 
> Proposal: Title change to "Managing multiple paths for a QUIC connection". Abstract and introduction accurately summarize standardized content. 
Thank you, this was very helpful.

I've created a GitHub issue to track further discussion on this matter.

Cheers
Lucas
> 
> Thanks,
> Lars
> 
> 
> 
> *Attachments:*
>  • signature.asc