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.
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.
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."
- 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.
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).
- 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.
== 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?
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.
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.
---
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.
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.
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/.
---
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.
---
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?
---
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.
Abstract
You should not "propose" anything. This is a protocol spec, so you
should "define" or "specify" things.
OK.
---
2.
s/as specified in Section Section 2.4/as specified in Section 2.4/
OK
---
2.2
You have a "smart" apostrophe.
---
Will check.
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/
OK.
I opened issue 626 in our Github repo to track your issues
(https://github.com/quicwg/multipath/issues/626).
-- Christian Huitema
