Re: Second WGLC for Multipath Extension for QUIC

[Kazuho Oku <[e-mail]>]

2025年10月7日(火) 9:24 Ian Swett <ianswett=[e-mail]>:

> 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 <[e-mail]> 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 <[e-mail]>
>> wrote:
>>
>>> Hi Lars
>>>
>>> On Mon, Oct 6, 2025, at 16:51, Lars Eggert wrote:
>>>
>>> Hi,
>>>
>>> On Oct 6, 2025, at 17:08, Lucas Pardue <[e-mail]> 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