Thanks for the review and for the PR!
On 12/22/2025 4:38 AM, Carsten Bormann via Datatracker wrote:
Document: draft-ietf-quic-multipath
Title: Managing multiple paths for a QUIC connection
Reviewer: Carsten Bormann
Review result: Ready with Nits
[Insert ARTART boilerplate here]
This specification builds on QUIC's capabilities for connection
migration to use multiple paths simultaneously for a single
connection.
It provides a mechanism for managing state necessary for running the
QUIC protocol with multiple concurrent paths, but deliberately leaves
address discovery, scheduling of packets over multiple paths, and
congestion control out of scope.
It is refreshing to see that the mechanism for multipath is being
specified before the obvious blanks (congestion control, scheduling)
can be filled in in a normative way.
The word “application” occurs about a dozen times, often in constructs
such as “suit the needs of the application”.
For example, the "[...]decision to setup or tear down paths are
assumed to be handled by the application" (introduction).
This reader expects some considerable innovation in how these needs
and decisions are communicated to the QUIC implementation, or, where
the application is in control, modulated by the state of the QUIC
implementation.
## General editorial
In some places, the document is heavy on passive usage.
On the passive sentences, it is not always clear to a new reader who
the actor is, or whether the verb is actually used as an adjective
(e.g., see last sentence of 3.1.2).
## Minor
2.1:
Path ID is supposed to be an unsigned integer < 2**32, but then 2.4
talks about the “least significant 32 bits of path_id”.
(It is also confusing that the term “value” is used for both the type,
which is a 60-bit number during the experiment phase, and the value of
the transport parameter.)
My bad, probably. We had an intermediate draft version in which path-id
was a 62 bit integer, and we would only use the bottom 32 bits to
compute the AEAD. But that would have required some mechanism to ensure
the peer operated with the same view of the current 32 bit window, and
we decided to cut that complexity and just use 32 bits. And we missed
that edit
3.2.1: Is the “maximum path ID limit” discussed here related to
initial_max_path_id/MAX_PATH_ID?
They are indeed related. The “maximum path ID" is initialized to the
value of the initial_max_path_id transport parameter, and updated over
the course of the connection when receiving MAX_PATH_ID frames.
Is the “active path limit” the same thing?
Kinda. That name occurs only when discussing the PATHS_BLOCKED frame.
Each peer sets its own version of the “maximum path ID", which is
communicated through the transport parameter and MAX_PATH_ID frames. The
overall limit is the min of the values set by the 2 peers. In the case
of the PATHS_BLOCKED frame, one peer is complaining that the other peer
has not yet announced a high enough MAX_PATH_ID.
The associated concepts are describe in section 3: paths can only be
created if both peers have issued at least one connection ID associated
with the selected path ID, but they cannot send "PATH_NEW_CONNECTION_ID"
frames with path_id values higher than the MAX_PATH_ID announced by
their peer.
4.7 has a “maximum path ID that was allowed” — by whom?
(Maybe it would be worth to introduce clear terms for the most
recently unilaterally declared [ignoring non-monotonic MAX_PATH
messages] and the combined value state.)
See previous comment.
This reader does not understand how concurrent allocation on the
shared number space of path IDs is managed.
Do the peer applications have to run some protocol to agree on how
which path ID is used for what?
What happens when this protocol and the protocol specified here run
out of sync?
Only the client can create new paths. This is inherited from RFC 9000.
We did have intermediate draft versions in which both endpoints could
start connections, and as you say that required "some protocol" -- we
were envisaging something like even number for the client, odd for the
server. But such protocols bring quite a bit of complexity, so we
(authors and WG) cut all that and stuck with "client only".
Who controls the parameters (e.g., diffserv markings) used with a
specific path ID?
Not specified. Some applications may want to do that, and some stacks
will develop API that let them, but we treated that as out of scope.
4.3 and elsewhere (3 times):
s/monotonically increasing/strictly increasing/
Uh, not sure...
5.4:
What is “connection control” in this context?
A typo to "congestion control"...
6:
When the allocations are inserted into the registry, the specification
links need to mention the RFC number (RFC XXXX).
7.2:
Where QUIC has arrived at rather heavy normative amplification limits
(good!), this section is at the level of “might consider”.
(Maybe we need to understand potential attacks more before they can be
effectively mitigated, but this looks like it is introducing a period
of instability.)
Yes, this is an area in which we will learn from experience.
## Nits
A couple dozen nits are addressed in
https://github.com/quicwg/multipath/pull/628
(This includes internally consistent spelling for "acknowledgements",
using the spelling from RFC 7322.)
7.3:
“This specification changes the AEAD calculation”:
I hope not.
It changes the calculation of the *input* to the AEAD.
The actual text is "This specification changes the AEAD calculation by
using the path ID as part of AEAD nonce (see Section 2.4
<https://quicwg.org/multipath/draft-ietf-quic-multipath.html#nonce>)."
Which IMHO is just what it does...
Do you have suggestions for the points that need clarification?
-- Christian Huitema
