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/>. 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. * 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. * 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. * 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. 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. * 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.
