Hello Mirja, Thanks a lot for your remarks. I also noticed that some comments and answers you made are already discussed in reviews from other directorates. I will add some comments myself following your inputs inline with the text, prefixed with [AFT].
Best regards, Antoine -----Original Message----- From: Mirja Kuehlewind <[email protected]> Sent: Friday, February 6, 2026 2:50 PM To: Antoine Fressancourt <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: draft-ietf-quic-multipath-19 telechat Intdir review Hi Antoine, thanks for your thorough review! See comments inline marked with [MK]. Mirja On 04.02.26, 15:59, "Antoine Fressancourt via Datatracker" <[email protected] <mailto:[email protected]>> wrote: Document: draft-ietf-quic-multipath Title: Managing multiple paths for a QUIC connection Reviewer: Antoine Fressancourt Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-quic-multipath-19 - *Managing multiple paths for a QUIC connection*. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/> <https://datatracker.ietf.org/group/intdir/about/> <https://datatracker.ietf.org/group/intdir/about/;>. Based on my review, if I was on the IESG I would ballot this document as YES or NO OBJECTION. The following are issues I found with this document that SHOULD be corrected before publication: * In section 3, a definition of what a path is in this document would help. Of course, there is a whole research group about this question, but the clarity of the document would be improved if it was clear from this section that a path is not only defined by a 4-tuple, and that different paths can have the same 4-tuple in your definition. [MK] We are discussing this based on Med's IESG review and I created the follow proposed PR for now: https://github.com/quicwg/multipath/pull/642/changes [MK] Do you think this would help? [AFT] I am not convinced that the proposed text adds clarity. In essence, as I understand it, the text you propose tells that a path is an entity inheriting from a 4-tuple that can be identified by an ID. Maybe suggesting that in that extend, paths can also differ by the way they schedule packets or queues, or by their use as an uplink or downlink for separate proxied connections would add clarity. * In section 3.1, it is unclear how long a path can be considered valid after it has been validated following section 8 of RFC 9000. This question is later addressed in the document in section 5.9, but this does not settle this matter. The use of PING frames as keepalives is mentioned, while its use is not recommended. This issue should be clarified and given a clear answer to better guide protocol implementers. [MK] Not sure there is a clear answer. I think this is really an implementation decision; therefore the discussion in 5.9. However, note that as you say, this is actually defined in RFC9000 and therefore would be rather an issue for the base spec than this extension. Or what do you think we should/could add as guidance here? [AFT] I agree it is also an issue with the main spec, but I think that from a single path context, the path validation and keepalive timing aspects may have been overlooked. Given some possible scenarios in which QUIC multipath might be used, I would expect a clearer keepalive mechanism to be specified, overcoming some of the shortcomings that led to discouraging the use of PING frames. All in all, I think that the implementer you have in mind for the document is quite educated to possible consequences of its implementation choices. I would just like to read some text better highlighting that those choices needs careful considerations with regards to the targeted protocol use cases. * In section 3.3, the path status management behavior is not sufficiently clear in my perspective. The document should give a minimal path selection mechanism considering available paths status to guide implementers, even if the document allows diverging from the proposed path management policy. [MK] Path selection/packet scheduling was explicitly left out of scope for this extension by working group decision. We had a lot of discussion that some scheduling is needed and keep getting questions about this but there is no straight-forward answer and therefore that's what the group decided. [AFT] My intention was not to re-ignite difficult discussions.. * In section 3.4, the document should clarify the behavior expected when a peer sends a PATH_ABANDON frame but does not receive the corresponding PATH_ABANDON frame in return. [MK] This is explicitly discussed in one of the paragraphs in section 3.4 and the group explicitly decided to leave this to the implementation as the texts says: " If a peer sends a PATH_ABANDON frame but never receives a corresponding PATH_ABANDON frame, it might not be able to remove path state. It is left to the implementation to handle this unexpected behavior as it does not impact interoperability. If the endpoint is no longer willing to process the issued connection IDs for the abandoned path, it MAY close the connection, but SHOULD wait at least 3 PTOs after sending the PATH_ABANDON frame." [MK] What else would you expect? [AFT] Sorry for this specific comment, I overlooked the PTO part of the paragraph. I am fine with the text. The following are minor issues (typos, misspelling, minor text improvements) with the document: * In section 2, as you are describing the Connection IDs and Path IDs, I would place a schema to help the reader picture properly how those IDs depend on one another in QUIC multipath. Similarly, in section 2.4, I would make a schema to present how the nonce is built. [MK] Not sure how a schema for the connection ID and path ID would look like... you mean just to illustrate that each path ID "contains" multiple connection IDs? Isn't that sufficiently clear already? [AFT] Honestly, I think a schema explicating the relationship and when Connection IDs or Path IDs are created and in which context according to the document would help. Some sort of state machine, maybe (I might be old-fashioned) [MK] We already got the comment from Deb's IESG review that the description of the nonce calculation need improvement. Not sure a schema would work as there is optional padding and an OR operation... * In section 7.2, I am wondering why, in the anti-amplification mechanism, the authors are not suggesting using a quota per path AND an overarching quota for the whole connection. [MK] we had further discussion about this based on Mike's IESG review and revised the text a bit. Other than the text is currently saying, having multiple paths actually doesn't increase the risk: it's still only amplified by 3 and you could also simply just open multiple QUIC connections to get the same effect. See here: https://github.com/quicwg/multipath/pull/636/changes
