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
