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? * 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? * 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. * 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? 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? [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
