Re: Second WGLC for Multipath Extension for QUIC

[Lucas Pardue <[e-mail]>]

Hi,

On Mon, Oct 6, 2025, at 09:34, Lars Eggert wrote:
> Hi,
> 
> On Oct 1, 2025, at 07:35, Ian Swett <[e-mail]> wrote:
> > I remember us having a longish discussion about whether this should be standards track or not.  I still don't feel like it's ready for standards track
> 
> +1

Responding to both Ian and Lars, I went back over the issues and minutes of the last few meetings. I didn't find much on this topic (if I've missed something, I would appreciate you sharing that here). The most relevant was probably the discussion during IETF 121 (Dublin) and IETF 122 Bangkok, see minutes [1][2] and recording at around 57 and 26 minute mark respectively[3][4].

As a chair: my interpretation of those meeting discussions was that there were some comments stating concerns of publishing a proposed standard for a multipath QUIC extension that could appears to indicate that deployments could just flip this on for general-purpose use cases. The author/chair response at the time was that the document explicitly excludes some areas related to scheduling of paths and congestion control because those are open research topics that we agreed in the adoption phase would stay out of scope for this document.

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?

As a chair: I have not heard anyone declare a strong opinion that the draft should not be standards track, or that it should be experimental. If that is not the case, we need clearer statements based on the latest version of the documents. Please make them here.

As an individual:: My comments at IETF 122, which were not reflected in the meeting notes due to audio issues, were that we shipped QUIC version 1 with barely any information about concurrent stream scheduling [5]. For a protocol designed to solve stream concurrency head-of-line blocking as a primary motivator, not including any prioritization signal nor guidance for scheduling didn't seem great but it also didn't seem to hurt QUIC deployments. 

Cheers
Lucas

[1] - https://datatracker.ietf.org/meeting/122/materials/minutes-121-quic-00
[2] - https://datatracker.ietf.org/meeting/122/materials/minutes-122-quic-00
[3] - https://youtu.be/PVNve8USz84?t=3421
[4] - https://youtu.be/9NR_MndcJIY?t=1569
[5] - https://datatracker.ietf.org/doc/html/rfc9000#section-2.3




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