Document: draft-ietf-quic-multipath Title: Managing multiple paths for a QUIC connection Reviewer: Adrian Farrel Review result: Has Issues
Hi, Thank you for your work on this document. I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management- related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of "Guidelines for Considering Operations and Management in IETF Specifications" can be found at https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. Please feel free to contact me for clarification and/or discussion Apologies for the nits: I can't read a document without noting them. I'd be happy to discuss any of these points with you. Regards, Adrian ====== Document: draft-ietf-quic-multipath-18 Title: Managing multiple paths for a QUIC connection Reviewer: Adrian Farrel ([email protected]) Review Date: 2025-12-12 Intended Status: Standards Track IETF last call ends: 2025-12-22 Review result: Has Issues: I have some minor concerns about this document that I think should be resolved before publication. == Summary == This document describes a way to use multiple QUIC paths to support a single connection by using path identifiers. It deliberately puts the assignment of addresses to these paths/connections and the steering of traffic over the different paths out of scope. == Operational Considerations == This document does not call out operational or manageability considerations. It does discuss "path management" but this is in the context of the QUIC protocol itself, not the management of QUIC or of the implementations. It would be best if the document included an Operational Considerations section following the guidance in draft-ietf-opsawg-rfc5706bis. But there is currently no immediate requirement to do that. In the absence of a full section, the following points do need to be discussed: - How is this feature incrementally deployed? Does it matter? I think it is as simple as noting that implementations only use the feature if the remote endpoint also support it, otherwise they continue as before. - What things need to be configured? I see: - Max Path ID - Whether to attempt multi-path system-wide or per connection - How to behave if the remote endpoint does not support this function (revert to single path, give up, log the situation) Anything else? - What needs to be available for monitoring (via inspection or logs)? - Number of paths in use - Churn in paths - Failure incidents - What OAM tools are needed to monitor correct operation? - What is the impact on other OAM tools? In particular, what happens when end-to-end traffic is monitored, but the monitoring goes on one path and the user traffic goes on another path? == Major Issues == None. == Minor Issues == Limits on the path ID Section 1 states: Path IDs are generated monotonically increasing and cannot be reused. And we know that the path ID is limited to 2^32-1 or possibly the value of initial_max_path_id. In a very long-lived system, where paths are created and released over and over again, and possibly where a large number of paths exist at a single time, is it possible that all the available path ID values are used up? Should an implementation wrap back to zero (effectively reusing Path IDs) of close and re-open in order to reset? Further, 2.1 says: * initial_max_path_id (current version uses 0x0f739bbc1b666d0d): a variable-length integer specifying the maximum path ID an endpoint is willing to maintain at connection initiation. This value MUST NOT exceed 2^32-1, the maximum allowed value for the path ID due to restrictions on the nonce calculation (see Section 2.4). If initial_max_path_id is set to 0x0f739bbc1b666d0d doesn't that exceed 2^32-1? --- Question from 2.5 Can I attack the computation of the PTO? Perhaps by delaying messages to make the RTT large? If I can do this on just one path, then I can cause a key to continue to be used for much longer than it would normally be (and that would apply across all of the path/packet number spaces). Is this different from the single path case? Possibly. In the single path case, the attack is immediately noticeable because the quality delivered by the single path is degraded. In the multi-path case, one path is degraded, but the overall behavior is, perhaps, not significantly changed. Hey! This is just me musing. --- 3. However, this document does not specify when a client decides to initiate or close a path, or how multiple open paths are used for sending. A forward pointer to Section 5 would be helpful. --- Section 6 I believe you need to tell IANA the "status" to mark in the registry and which range to make the allocations from. --- 6.1 I believe you need to ask IANA to remove the provisional values from the registry. --- It would be helpful to reviewers (including the IESG) to include an implementation status section consistent with RFC 7942. == Nits == idnits says -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? --- Abstract You should not "propose" anything. This is a protocol spec, so you should "define" or "specify" things. --- 2. s/as specified in Section Section 2.4/as specified in Section 2.4/ --- 2.2 You have a "smart" apostrophe. --- 5.4 s/are not send/are not sent/ s/over which path acknowledgement/over which path acknowledgements/ s/needs to consider cases/need to consider cases/
