Sorry for triggering you Lars, but I greatly appreciate your suggestions. I'd prefer "QUIC Extensions for Multipath Operation with Multiple Addresses" over the existing title.
That being said, RFC9000 already enables some flavors of Multipath, so a more specific title might be "QUIC Extensions for simultaneously using Multiple Paths with Multiple Addresses." Simultaneous use of multiple paths is the distinguishing feature this draft adds to QUIC. As a person who gets asked questions about QUIC Multipath at work by people who haven't looked into it as deeply as many on this list, it can be difficult to communicate the differences between RFC9000 allowing the use of multiple addresses (including Server Preferred Address) and QUIC Multipath. Some of them genuinely might benefit from this soon to be RFC, but many others could use a much simpler solution. Thanks, Ian On Mon, Oct 6, 2025 at 12:21 PM Matt Joras <[email protected]> wrote: > Since we're opening the naming bike shed, I would remind everyone that > this work does not exist in a vacuum in the IETF. There are two other > "multipath" transport protocol documents. > > RFC 8684 - TCP Extensions for Multipath Operation with Multiple Addresses > draft-ietf-tsvwg-multipath-dccp-24 - DCCP Extensions for Multipath > Operation with Multiple Addresses > draft-ietf-quic-multipath-16 - Multipath Extension for QUIC > > The DCCP naming clearly took the TCP one directly. Perhaps we should > consider doing the same. This would suggest "QUIC Extensions for Multipath > Operation with Multiple Addresses". The abstracts of the TCP and DCCP > documents is also significantly longer than the QUIC document currently is. > > I will also note that the TCP work was proposed as Standards Track, and > DCCP is also (currently) proposed as Standards Track. > > Matt > > On Mon, Oct 6, 2025 at 9:15 AM Lucas Pardue <[email protected]> wrote: > >> Hi Lars >> >> On Mon, Oct 6, 2025, at 16:51, Lars Eggert wrote: >> >> Hi, >> >> On Oct 6, 2025, at 17:08, Lucas Pardue <[email protected]> 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 >> >> >>
