Hi Christian, Thank you for your speedy and detailed response.
A few comments in-line (see [AF]), but I think we're aligned. Cheers, Adrian -----Original Message----- From: Christian Huitema <[email protected]> Sent: 16 December 2025 00:25 To: Adrian Farrel <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: draft-ietf-quic-multipath-18 ietf last call Opsdir review Thanks for the review, Adrian. My main take-away is that we should probably add somewhere a pointer to RFC 9312, and explain that the multipath extension does not change much to the management of QUIC connections, and in particular does not change the wire format. Also, mention the possible QLOG extensions for multipath. Details below. [AF] Yes, from a management point of view, that sounds good. On 12/14/2025 2:58 PM, Adrian Farrel via Datatracker wrote: > 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. QUIC management is specified in RFC 9312. Maybe we need to update that RFC to manage multipath operation, although the changes would be very limited, because the extension does not change the wire image, and RFC 9000 already specifies use of multiple paths -- just not concurrent. [AF] OK, yes. Mainly adding a pointer. Probably adding a note that consideration needs to be given to the concurrency of multi-path. > 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. That is very much implied by the very first words of the introduction, "This document specifies an extension to QUIC version 1". QUIC extensions are only used if negotiated by both parties. It is explained in details in section 2, "If either of the endpoints does not advertise the initial_max_path_id transport parameter, then both endpoints MUST NOT use any frame or mechanism defined in this document." [AF] Yeah, I take your point that it is all there already. Although, not talked about explicitly in the context of incremental deployment. For example, you could add to the end of the quote you cited as "... thus enabling incremental deployment of implementations of this specification." > - 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? The Max Path ID is a state variable, but it is updated continuously over the course of the connection. How that's done is very much application dependent. Some application may configure it once and for all. Other applications will increment it after an existing path has been abandoned, so a new path can be created to replace it. [AF] OK. I didn't pick this up on reading, but that might be my unfamiliarity with QUIC. If, on the other hand, this is an implementation choice and it is not already sufficiently clear, then adding something along the lines of what you say would help. There are rarely system-wide parameters with QUIC. QUIC is mostly implemented as a library loaded by the application process, not as a system service -- the design goal was indeed to enable applications to innovate without being gated by operating systems. A given system may well run multiple applications that use different QUIC stacks. For example, Chrome and Firefox use different QUIC stacks, with different parameters. The specification does state that if the peer is not capable of running multipath, or not willing, then the connection uses QUIC s specified in RFC 9000. > - What needs to be available for monitoring (via inspection or logs)? > - Number of paths in use > - Churn in paths > - Failure incidents Apart from a potential update to RFC 9312, the other relevant work is an update to the QLOG format. We have a bit of a race condition there, because the QLOG effort is progressing in parallel with this multipath extension. The working group consensus at IETF 124 was to finish the QLOG specification as is, and then to work on an extension for multipath. (See: https://datatracker.ietf.org/meeting/124/materials/minutes-124-quic-00). [AF] Absolutely OK to get base QLOG done first. Just add a note that QLOG will (may?) need to be updated to be consistent with this spec. What we should be aiming for is "no surprises" so a deployer of multi-path with base QLOG will know to expect the potential of issues, and so will look for QLOG updates. > - What OAM tools are needed to monitor correct operation? Pretty much the same scenarios as RFC 9312. > - 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? My best guess is, nothing. Pretty much the same as if the peers had established two end-to-end connections on two separate paths, one monitored, one not. [AF] Hmmm, yes. The situation I was thinking of is that the customer might be trying to monitor the behaviour of their traffic and getting "everything is good" even though they are actually seeing poor performance. This would arrive because the OA is effectively getting different (better) treatment in the network than the user traffic. I'm not quite sure what we can say about that in the draft except possibly to point out this possibility. > == 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? That was intensely discussed in the WG. We could indeed have specified a windowing system, and in fact we had something like that in the spec at some point. However, this would add complexity, and we did not feel that it was worse the effort. Also, we did not have many scenarios in which path lasted less that a few seconds. A connection creating a new path every second could do so for a few dozens of years, and that felt good enough. A QUIC connection is limited in other ways. In particular, it is not possible to send more than 2^62-1 bytes over QUIC streams for the entire duration of the connection. It is also not advisable to encrypt too many bytes using the same keying material. If we somehow lifted the limit on the number of paths, we would bump on these other limits. The general solution today is to restart the QUIC connection before bumping into the limits. [AF] All OK on this point > 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? No. These are two different numbers. 0x0f739bbc1b666d0d is the code of the transport protocol parameter. The associated value have to be less that 3^32. [AF] Oh, wow, I entirely missed that! I think, when I read... * 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. ...it looked to me that 0x0f739bbc1b666d0d was an initial value of the variable. Perhaps change to... * initial_max_path_id (current version uses 0x0f739bbc1b666d0d as the code of the protocol parameter): a variable-length integer specifying the maximum path ID an endpoint is willing to maintain at connection initiation. > 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. The endpoints will discover that a path is not performing well. The extra delays will probably trigger a PTO on that path, and too many of them will probably lead to abandon of the path. [AF] All OK > Section 6 > > I believe you need to tell IANA the "status" to mark in the registry and > which range to make the allocations from. Yes. This matches early feedback from the designated experts for the QUIC registry. I think the IANA section is much clearer in https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/. [AF] OK, I see the text. > 6.1 > > I believe you need to ask IANA to remove the provisional values from the > registry. Quite possibly, but probably not at the same time that the document is published. We need a decent interval for applications to transition to the final values, and we would not want to see the same values reused for something else before that. [AF] Ah, good point. Conversely, I wonder whether you need to ask IANA to retain the previous code points (in case they mistakenly think that they can remove them with the publication of the RFC). > == 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? > > --- Yes. Problem is, there is only 1 example in the document, and the logic dictates that all addresses in the example belong to the same family. We could make them all IPv6, but I suspect we would get the IPv4 version of that nit. [AF] Well, t's just a nit. Who knows whether IPv6 will ever catch on ;-) A solution would be to add a second example using IPv6, but I leave that as a choice for the authors and responsible AD. [snip]
