Hi Med, yes, thanks for the review. Please see some additional comments inline.
Mirja On 06.02.26, 03:30, "Christian Huitema" <[email protected] <mailto:[email protected]>> wrote: Thanks for the review, Med! Comments in line. On 2/5/2026 12:36 AM, Mohamed Boucadair via Datatracker wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-quic-multipath-19: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ > <https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/> > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hi Yanmei, Yunfei, Quentin, Olivier, Christian, and Mirja, > > Thank you for the effort put into this document. > > Thanks also to Adrian Farrel for the OPSDIR and to Christian for engaging and > making changes. I checked both the draft and the discussion about the two > related PRs. > > The document is well-written. I like the design as it builds on existing > features in the base spec. > > Please find below some few discussion points: > > # What is a path? > > The document says that paths: > > “refers to the notion of "network path" used in [QUIC-TRANSPORT].” > > However, section 5.2 says: > > It is possible to create paths that refer to the same 4-tuple. For > example, endpoints might want to create paths that use different > Differentiated Service [RFC2475] markings. > > ## Are we still compliant with the definition in [QUIC-TRANSPORT]? [MK] I think so. As you say below, RFC9000 also has no explicit definition and uses the term "network path" similarly as a logical construct as Christian explained below. The reference to RFC9000 is only there say that what's called "network path" in RFC9000 is the same as what we just call "path" in this document. However not defining it further is intention and actually aligned with RFC9000 as Christian explained below. > > ## As a side note, there is no explicit definition in [QUIC-TRANSPORT](or I > missed it). Maybe better to have an explicit definition. > > Note that MPTCP (RFC8684) has the following: > > Path: A sequence of links between a sender and a receiver, defined in this > context by a 4-tuple of source and destination address/port pairs. > > Likewise, RFC9897 has the following: > > Path: A sequence of links between a sender and a receiver, defined > in this context by a 4-tuple of the source and destination address > and the source and destination ports. This definition follows > [RFC8684] and is illustrated in the following two examples for > IPv6 and IPv4, which each show a pair of sender IP-address:port > and a pair of receiver IP-address:port, which together form the > 4-tuple: Fair. We spent several years of debates discussing that, and the conclusion was that we should not merely identify a "path" by the 4-tuple, that we needed a number space per path and a path identifier. The result is that the "path" is a logical construct, kinda "a subset of the connection defined by the path-ID". That path-ID is associated with a 4-tuple during the creation of the path, but that 4-tuple can change over time after NAT rebinding or path migration. There is no guarantee that all packets sent on the same 4-tuple are associated with the same path. I think we need to change the definition, which might have been correct 4 years ago, to reflect what we actually built. [MK] I think maybe we could add one more sentence to the intro saying more explicitly that a path is determined by the path ID and not the 4-tuple. > # Available server addresses > > The spec says: > > If the server uses the preferred_address transport parameter, clients > cannot assume that the initial server address and the addresses > contained in this parameter can be simultaneously used for multipath > (Section 9.6.2 of [QUIC-TRANSPORT]). Use of the preferred address > with the same local address is considered as a migration event that > does not change the path ID. > > with only clients can initiate new paths per: > > Note that in this extension, a QUIC server does not > initiate the creation of a path, but it has to validate a new path > created by a client. > > and address handling belongs to applications: > > Addresses and the actual decision to set up or tear down paths are > assumed to be handled by the application. > > Absent at least an option for the client to learn available addresses for > multipathing at the server side, the actual use of the extension may be > restricted in some cases (e.g., single-addressed client—multi-addressed > servers). > > Unless I’m missing the point of the last excerpt above, I think this is > putting > a hurdle on applications as they may not control the addresses, but more > importantly may lead to each application building its own way to manage > address > referrals (if the design of the app can accommodate it at the first place). > > ## Is there a reason why the spec does not offer a parameter for the server to > share addresses available for multipathing? Yes. There was ample debate around this point. See for example "should server be allowed to open new paths" (https://github.com/quicwg/multipath/issues/47 <https://github.com/quicwg/multipath/issues/47>), and "How will MPQUIC support the scenario where the client connects with a dual-stack server via both IPv4 and IPv6 paths? (https://github.com/quicwg/multipath/issues/327 <https://github.com/quicwg/multipath/issues/327>). The high level summary is that the WG decided to set aside server-side creation of paths, not deal with the associated complexity, and leave that to future extensions. [MK] Actually I think Med's question was about how a client can learn about new server addresses. The working group decided early on (before taking this work item up) that we only focusing on the basic path management and leave things like address announcement (as well as scheduling as mentioned below) to future extensions. [MK] I would say the primary use case is actually the case where the client has multiple address and not announcement is needed. There are also cases where the application knows or learns multiple server addresses already and can use this extension right away. However, there is also already a (recently expired) draft that proposes an extension to announce additional server addresses: https://datatracker.ietf.org/doc/draft-piraux-quic-additional-addresses/ [MK] However, as the document says the group decided explicitly from the start to leave this out of scope for this extension. > ## Can we please better clarify the assumptions around applications? There is no specific requirement on applications. Applications could indeed define ways to coordinate path creation between client and server, and there is ongoing work on that for example for NAT traversal by P2P applications. But we cannot speculate here on what applications will do, and we certainly cannot mandate that they do anything in particular. [MK] Not sure what exactly you are asking for here, but if this is still about address handling, as I said it purposefully left out of scope for this document. > > # More operational considerations > > CURRENT: > The operational considerations for QUIC are addressed in [RFC9312]. > They also apply to QUIC connections using the extensions defined in > this document. An additional complexity is that applications might > use a combination of monitored and non-monitored paths, but that > complexity already exists when using path migration as defined in > [QUIC-TRANSPORT]. > > ## There are more operational considerations that I think are important to > highlight: > > * need to control the max num of paths (and avoid overloading servers) > * need for implementations to offer configuration knobs to restrict the number > of active paths per connection That's really an implementation or API issue. Remember that the QUIC stack is part of the application process, not part of the OS: there is no central enforcement point for QUIC connection parameters. The protocol definition does provide ways for application to control resource using the Max Path ID mechanism. [MK] Having these limits is really more an implementation and security question than an operational aspect, as explained in the security considerations section, where resource exhaustion attacks are mentioned. Of course it makes sense to make these max number of paths configurable but, similar as RFC9000, we don't define an API. > * need to support configurable policy for > acceptable traffic distribution "this document does not specify scheduling algorithms that define how multiple, simultaneously open paths are used to send packets." That's deliberate. The WG consensus was that trying to defined general purpose scheduling algorithms is better left for further study. > * remind that (plugged) traffic scheduler need > to avoid aggressive use of some resources (cellular in bonding scenarios) > while > other paths are available. We do not define the traffic scheduler. > * remind that use of some available paths depends on > the user preference/consent. Some decisions may impact the user > experience/subscription given that oddly setting the priority/order of paths > may lead to unexpected experience (e.g., which is problematic for cases where > there are quota per access). This is even exacerbated given that: > > CURRENT: > Note that an endpoint might not follow the peer's advertisements, but > these frames are still a clear signal of the peer's preference of > path usage. > > * need for heuristics to decide when to start using multiple paths (short > lived > connections, etc.) * guard to prevent too frequent adding new paths All of this falls into standardization of scheduling, which is definitely left for further work. > > # When to ignore the PATH_ACK and PTO Recommendations? > > CURRENT: > After the handshake concluded with support for the multipath > extension, endpoints SHOULD use PATH_ACK frames instead of ACK > frames, including for so far unacknowledged 0-RTT packets using path > ID 0. [MK] First of all, we had a very lengthy discussion about making it a MUST (and enforcing that MUST) but at the end decided to say with SHOULD and require to process RFC9000 ACK frames even if the extension is used. There are pros and cons for both approaches that can make one or the other implementation approach easier but that's where the consensus ended up see here: https://github.com/quicwg/multipath/issues/220 [MK] in the issue you can see that we also decided to add some guidance/examples when sending ACK is useful, which is what exactly the next sentence is about: " For example, a sender could negotiate multipath support for later use and keep only the initial path with path ID 0 for a while. During this single-path period, the sender might prefer to send ACK frames." [MK] I don't thing we can say more than that. There are no "implications" of not following the SHOULD; this was simply a design decision. Or what were you looking for? > > CURRENT: > When this specification is used, endpoints SHOULD wait for at least > three times the largest Probe Timeout (PTO) (see Section 6.2 of > [QUIC-RECOVERY]) among all the paths before initiating a new key > update after receiving an acknowledgment that confirms the receipt of > the previous key update. > > Would it be possible to clarify in the text what are the implications of not > following these SHOULDs? [MK] Is this what the next paragraph is exactly doing? "As packets that arrive after their decryption key has been discarded will be dropped, the choice of three times the largest PTO is a trade-off: Longer delays reduce the probability of losing packets but keeping old keys longer can negatively impact the security of the protocol. The use of three times the largest PTO aims to minimize packet lost for all paths and therefore limits the impact on performance." [MK] What else do you expect? We felt it was obvious... The handling of using the RFC 9000 ACK Frames is defined as acknowledging packets on path 0. Changing the encryption key too frequently may result in the impossibility to decrypt late packets. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Abstract > > ## Putting aside that create/delete are covered by “manage”, “managing paths > using identifiers” is too vague to be useful in an abstarct > > CURRENT: > It proposes a standard way to create, delete, and manage > paths using identifiers. Using identifiers is a key part of the solution. Maybe say "manage paths using explicit identifiers instead of merely relying on the IP addresses and UDP ports."? [MK] I personally don't find this too vague. But as Christian says identifiers are a key part, so I guess we could even put this in an own sentence, like: OLD ...manage paths using identifiers NEW ...manage paths. A path is determined by an explicit path identifier in this extension. [MK] What do you think, Christian? > > ## nit > > OLD: It proposes a standard way to create > > NEW: It defines a standard way to create OK. > # What’s in scope, what isn’t? > > Several aspects of multipathing are declared out of scope. These are include > mostly in the introduction. > > I would suggested to have all such statements groped in a specific Section. [MK] I don't see the value of a specific section. I actually find it better to have it right there in the intro. And we also word-smithed this part a lot, so I would not change it again. > > # Use Case > > CURRENT: > Specifically, while failover between Wi-Fi and mobile networks is a > well-known multipath use case, > > Maybe cite rfc8041#section-2.2 I guess we should ask Olivier Bonaventure about that... [MK] I don't think we need a reference here. I think it common sense that this is a well-known use case (as the term "well-known" implies). > > # Redundant behavior > > Section 2 (Preamble) > > Endpoints MUST NOT remember the value of > the initial_max_path_id transport parameter for use in a subsequent > connection. > > Section 2.1: > > The initial_max_path_id parameter MUST NOT be remembered for use in a > subsequent connection (Section 7.4.1 of [QUIC-TRANSPORT]). > > Unless I’m missing something subtle here, I suggest to keep the normative > behavior only in one place (2.1, typically). Yes, we should fix that. [MK] Yes, thanks! We added this recently because we thought it was missed. However, I was actually surprised that is wasn't there as in my memory I added it at some point; and apparently I did... > > # MAX_PATH_ID > > CURRENT: > MAX_PATH_ID frames that do not increase the > path limit MUST be ignored. > > Isn’t allowed that this frame can be received at any time during the > connection? If so, wouldn’t that MUST prevent lowering the limit to > accommodate > local preferences? Yes it does exactly that. This is similar to flow control: credits that have been granted cannot be withdrawn. But note that the frame defines the MAX_PATH_ID, not the maximum number of concurrent paths. An endpoint that is stressed for resource will simply stock incrementing the limit. > > Cheers, > Med > > >
