On 1/28/2026 12:54 PM, Mike Bishop via Datatracker wrote:
Mike Bishop has entered the following ballot position for
draft-ietf-quic-multipath-19: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
# IESG review of draft-ietf-quic-multipath-19
CC @MikeBishop
I have previously reviewed this draft as a working group member, and appreciate
the work that has been put into it so far. I have a few comments from my most
recent review, but in general am quite pleased with how the draft has
progressed since I last read it.
## Discuss
### Section 2.2, paragraph 1
```
When the QUIC multipath extension is used, the
active_connection_id_limit transport parameter [QUIC-TRANSPORT]
limits the maximum number of active connection IDs per path. As
defined in Section 5.1.1 of [QUIC-TRANSPORT] connection IDs that are
issued and not retired are considered active.
```
This seems to present a conundrum to clients trying to manage their memory
consumption. active_connection_id_limit can't be changed after the handshake. So
if a constrained implementation wants to manage no more than N CIDs total, but
also supports multipath, it cannot advertise N for this value, because its total
memory commitment is active_connection_id_limit x the current maximum number of
paths.
The `active_connection_id_limit` is set to enable migrations of paths,
and the limit will restrain how many potential 4-tuple can be tested in
parallel for a migration attempt. You argue that if multipath is
negotiated, endpoints would use creation of new paths in preference to
migrations of existing paths, and thus could use a lower limit when
multipath is negotiated. However, we do not have any data about that. We
have at least one example with "preferred address migration" of a
scenario that requires path migration even if multipath is supported.
Another example would be NAT rebinding of an existing path.
So yes, we could speculate that having separate negotiation of two
parameters would result in lower resource consumption. However, this is
speculation, and it is hard to quantify how much resource this would
actually save. The protocol is complex enough, we tried not to introduce
complexity if the requirement is fuzzy, which is why we did not define a
separate option.
But if it takes the conservative approach and advertises N / M for
active_connection_id_limit, then when it establishes a non-multipath QUIC
connection, it will be understating its willingness to handle CIDs and therefore
hampering its ability to rotate/migrate.
Did the WG discuss this and reach consensus on reusing the transport parameter
despite this challenge? I would have expected either a transport parameter that
supersedes active_connection_id_limit when multipath is negotiated, or some
post-handshake way to adjust the limit.
This point was not discussed, and did not appear to be an actual problem
in any of the interop tests.
I suspect that most memory limited implementations will converge to a
small limit, between 2 and 4 per path, satisfying both multipath and
most unipath scenarios. The one exception may be P2P extensions, but
again we do not have a lot of experience. If the "ICE in QUIC" scenarios
turn out to require many CIDs, then perhaps we can think of extensions
to allow larger number of parallel tests as part of these designs.
### Section 3.1, paragraph 2
```
A client that wants to use a new path MUST validate the peer's
address before sending any data as described in Section 8.2 of
[QUIC-TRANSPORT], unless it has previously validated the 4-tuple used
for that path.
```
Can you point me to the text in Section 8.2 of RFC 9000 you're referencing for
this prohibition on sending data? What I find there is:
An endpoint MAY include other frames with the PATH_CHALLENGE and PATH_RESPONSE
frames used for path validation.
...and more explicitly in Section 9.3:
An endpoint MAY send data to an unvalidated peer address, but it MUST protect
against potential attacks as described in Sections 9.3.1 and 9.3.2.
In fact, in Section 3.1.2 of this document, "any frame can be sent on a new path
with a new path ID at any time...."
The intent is definitely to follow RFC 9000 here. Do you have a
suggestion for improving the text?
### Section 5.8, paragraph 1
```
[QUIC-TRANSPORT] the DPLPMTUD Maximum Packet Size (MPS) is maintained
for each combination of local and remote IP addresses. Note that
with the multipath extension multiple paths could use the same
4-tuple but might have different MPS. One simple option, if the
```
How would two paths with "the same 4-tuple" ever have a different "combination
of local and remote IP address"? Isn't that a subset of the 4-tuple by
definition?
If they have different diffserv class of service, for example.
### Section 7.2, paragraph 2
```
Further, multiple paths could be initialized simultaneously. The
anti-amplification limits as specified in Section 8 of
[QUIC-TRANSPORT] limit the amplification risk for a given path, but
multiple paths could be used to further amplify an attack.
```
Why then is the anti-amplification limit per-path rather than per-address?
We never have the concept of per-address limit. Asking implementations
to perform special treatment per IP address would be rather error prone,
given NATs. We could investigate other limits, such as limiting the
number of concurrent path establishment, but I think we really need
implementation experience before writing more rules.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
## Comments
### Section 1, paragraph 7
Consider pulling some of the introduction into a Scope subsection. The
discussion of what this document does *not* cover seems excessive for an overall
introduction.
### Section 2.1, paragraph 7
```
together with the multipath extension. If such a cipher suite is
selected and the use of the multipath extension is supported,
```
...is negotiated, perhaps?
### Section 3.1.1, paragraph 5
Your figure shows bidirectional address validation, but the prose only
describes one direction. Consider adding a sentence or two that the server does
the same thing alongside its response.
### Sections 4.1, 4.4, and 4.5
It is generally recommended that figures be illustrative, rather than normative.
However, without referring to the figures, a reader cannot determine where in
the
frames this additional field is inserted.
### Section 4.2.1, paragraph 0
Presumably any error code is valid here? Might be worth clarifying that
these codes are defined for situations in which a path might be abandoned, but
this can be any QUIC error code, as well as the usual disclaimer that any
lower-level error can also be used as a reason for closing a connection.
### Section 5.6, paragraph 3
A reference to Section 13.3 of RFC 9000 might be more useful here:
QUIC packets that are determined to be lost are not retransmitted whole. The
same applies to the frames that are contained within lost packets. Instead, the
information that might be carried in frames is sent again in new frames as
needed.
This manifests as new STREAM frames for the missing data (which
don't guarantee the same frame boundaries) and either not retransmitting stale
frames
which have been superseded by newer information (PATH_ACK, PATH_STATUS_*, etc.)
or sending the most current status when an older frame was lost.
In general, examine references in the document to retransmitting frames rather
than
the information they carry.
## Nits
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.
### Typos
#### Section 2.3, paragraph 2
```
- After the handshake concluded with support for the multipath
- ^
+ After the handshake concludes with support for the multipath
+ ^
```
#### Section 2.5, paragraph 3
```
- [QUIC-TLS] which used three times the PTO of the sole single path.
- -----
```
#### Section 3.1, paragraph 6
```
- Each endpoint MUST also validate that a minimum QUIC packet MTU of
- ^
+ Each endpoint MUST also validate that the minimum QUIC packet MTU of
+ ^^^
```
#### Section 3.1, paragraph 10
```
- ID is anyway consumed, the endpoint MUST explicitly close the path,
- -------
+ ID is consumed either way, the endpoint MUST explicitly close the path,
+ +++++++++++
```
#### Section 3.1.1, paragraph 6
```
- Respectively, the client chooses the connection ID S1 as the
- ^^^^^^^^^^^^^^^
+ The client chooses the corresponding connection ID S1 as the
+ ^ ++++++++++++++
```
#### Section 3.2.2, paragraph 2
```
- An endpoint is supposed to retire any connection ID that is not being
- ^
+ An endpoint is supposed to retire any connection ID that is no longer being
+ ^^^^^^^
```
### Section 3.4, paragraph 8
```
short, limited time such as one PTO if a packet is received on a new
path before sending the CONNECTION_CLOSE frame.
```
Should this be "...to see if a packet..."?
#### Section 5.1, paragraph 2
```
- For any given path, connection ID rotation, NAT rebinding, or client
- -------
- initiated migration as specified in [QUIC-TRANSPORT] might occur,
+ client-initiated migration as specified in [QUIC-TRANSPORT] might occur,
+ +++++++
```
### Section 5.1, paragraph 5
```
the endpoints set the path's congestion controller and round-trip
```
reset?
#### Section 5.3, paragraph 3
```
- during the connection. As such, a sole change of the Connection ID
- -----
```
### Section 3.1.1, paragraph 6
```
bundled with the PATH_ACK using connection ID S1 associated with the
same path ID.
```
Shouldn't this be C1?
### Section 3.2.1, paragraph 7
```
When an endpoint finds it has not enough available unused path IDs,
```
Consider "cannot open a path because there are no unused path IDs" perhaps?
### Grammar/style
#### Section 6, paragraph 1
```
reased amplification risk for denial of service attacks if multiple paths are
^^^^^^^^^^^^^^^^^
```
It appears that hyphens are missing.
Thanks for the editorial suggestions. We will incorporate them in the
next version of the draft.
-- Christian Huitema
