Hi all, To closing the loop here: a few comments were raised during WGLC, authors proposed new text on GitHub l and discussed with comment raisers. All proposals were landed and published in draft 17 [1].
Based on this, we will be progressing the document. Cheers Lucas & Matt QUIC WG Chairs [1] - https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/17/ On Tue, Oct 7, 2025, at 06:26, Kazuho Oku wrote: > > > 2025年10月7日(火) 9:24 Ian Swett <[email protected]>: >> 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. > > +1. This is a bikeshed, but being precise is always good. > >> >> 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 >>>> > > > -- > Kazuho Oku
