Thanks for the review, Med!
Comments in line.
On 2/5/2026 12:36 AM, Mohamed Boucadair via Datatracker wrote:
Mohamed Boucadair 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:
----------------------------------------------------------------------
Hi Yanmei, Yunfei, Quentin, Olivier, Christian, and Mirja,
Thank you for the effort put into this document.
Thanks also to Adrian Farrel for the OPSDIR and to Christian for engaging and
making changes. I checked both the draft and the discussion about the two
related PRs.
The document is well-written. I like the design as it builds on existing
features in the base spec.
Please find below some few discussion points:
# What is a path?
The document says that paths:
“refers to the notion of "network path" used in [QUIC-TRANSPORT].”
However, section 5.2 says:
It is possible to create paths that refer to the same 4-tuple. For
example, endpoints might want to create paths that use different
Differentiated Service [RFC2475] markings.
## Are we still compliant with the definition in [QUIC-TRANSPORT]?
## As a side note, there is no explicit definition in [QUIC-TRANSPORT](or I
missed it). Maybe better to have an explicit definition.
Note that MPTCP (RFC8684) has the following:
Path: A sequence of links between a sender and a receiver, defined in this
context by a 4-tuple of source and destination address/port pairs.
Likewise, RFC9897 has the following:
Path: A sequence of links between a sender and a receiver, defined
in this context by a 4-tuple of the source and destination address
and the source and destination ports. This definition follows
[RFC8684] and is illustrated in the following two examples for
IPv6 and IPv4, which each show a pair of sender IP-address:port
and a pair of receiver IP-address:port, which together form the
4-tuple:
Fair. We spent several years of debates discussing that, and the
conclusion was that we should not merely identify a "path" by the
4-tuple, that we needed a number space per path and a path identifier.
The result is that the "path" is a logical construct, kinda "a subset of
the connection defined by the path-ID". That path-ID is associated with
a 4-tuple during the creation of the path, but that 4-tuple can change
over time after NAT rebinding or path migration. There is no guarantee
that all packets sent on the same 4-tuple are associated with the same path.
I think we need to change the definition, which might have been correct
4 years ago, to reflect what we actually built.
# Available server addresses
The spec says:
If the server uses the preferred_address transport parameter, clients
cannot assume that the initial server address and the addresses
contained in this parameter can be simultaneously used for multipath
(Section 9.6.2 of [QUIC-TRANSPORT]). Use of the preferred address
with the same local address is considered as a migration event that
does not change the path ID.
with only clients can initiate new paths per:
Note that in this extension, a QUIC server does not
initiate the creation of a path, but it has to validate a new path
created by a client.
and address handling belongs to applications:
Addresses and the actual decision to set up or tear down paths are
assumed to be handled by the application.
Absent at least an option for the client to learn available addresses for
multipathing at the server side, the actual use of the extension may be
restricted in some cases (e.g., single-addressed client—multi-addressed
servers).
Unless I’m missing the point of the last excerpt above, I think this is putting
a hurdle on applications as they may not control the addresses, but more
importantly may lead to each application building its own way to manage address
referrals (if the design of the app can accommodate it at the first place).
## Is there a reason why the spec does not offer a parameter for the server to
share addresses available for multipathing?
Yes. There was ample debate around this point. See for example "should
server be allowed to open new paths"
(https://github.com/quicwg/multipath/issues/47), and "How will MPQUIC
support the scenario where the client connects with a dual-stack server
via both IPv4 and IPv6 paths?
(https://github.com/quicwg/multipath/issues/327). The high level summary
is that the WG decided to set aside server-side creation of paths, not
deal with the associated complexity, and leave that to future extensions.
## Can we please better clarify the assumptions around applications?
There is no specific requirement on applications. Applications could
indeed define ways to coordinate path creation between client and
server, and there is ongoing work on that for example for NAT traversal
by P2P applications. But we cannot speculate here on what applications
will do, and we certainly cannot mandate that they do anything in
particular.
# More operational considerations
CURRENT:
The operational considerations for QUIC are addressed in [RFC9312].
They also apply to QUIC connections using the extensions defined in
this document. An additional complexity is that applications might
use a combination of monitored and non-monitored paths, but that
complexity already exists when using path migration as defined in
[QUIC-TRANSPORT].
## There are more operational considerations that I think are important to
highlight:
* need to control the max num of paths (and avoid overloading servers)
* need for implementations to offer configuration knobs to restrict the number
of active paths per connection
That's really an implementation or API issue. Remember that the QUIC
stack is part of the application process, not part of the OS: there is
no central enforcement point for QUIC connection parameters. The
protocol definition does provide ways for application to control
resource using the Max Path ID mechanism.
* need to support configurable policy for
acceptable traffic distribution
"this document does not specify scheduling algorithms that define how
multiple, simultaneously open paths are used to send packets."
That's deliberate. The WG consensus was that trying to defined general
purpose scheduling algorithms is better left for further study.
* remind that (plugged) traffic scheduler need
to avoid aggressive use of some resources (cellular in bonding scenarios) while
other paths are available.
We do not define the traffic scheduler.
* remind that use of some available paths depends on
the user preference/consent. Some decisions may impact the user
experience/subscription given that oddly setting the priority/order of paths
may lead to unexpected experience (e.g., which is problematic for cases where
there are quota per access). This is even exacerbated given that:
CURRENT:
Note that an endpoint might not follow the peer's advertisements, but
these frames are still a clear signal of the peer's preference of
path usage.
* need for heuristics to decide when to start using multiple paths (short lived
connections, etc.) * guard to prevent too frequent adding new paths
All of this falls into standardization of scheduling, which is
definitely left for further work.
# When to ignore the PATH_ACK and PTO Recommendations?
CURRENT:
After the handshake concluded with support for the multipath
extension, endpoints SHOULD use PATH_ACK frames instead of ACK
frames, including for so far unacknowledged 0-RTT packets using path
ID 0.
CURRENT:
When this specification is used, endpoints SHOULD wait for at least
three times the largest Probe Timeout (PTO) (see Section 6.2 of
[QUIC-RECOVERY]) among all the paths before initiating a new key
update after receiving an acknowledgment that confirms the receipt of
the previous key update.
Would it be possible to clarify in the text what are the implications of not
following these SHOULDs?
We felt it was obvious... The handling of using the RFC 9000 ACK Frames
is defined as acknowledging packets on path 0. Changing the encryption
key too frequently may result in the impossibility to decrypt late packets.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# Abstract
## Putting aside that create/delete are covered by “manage”, “managing paths
using identifiers” is too vague to be useful in an abstarct
CURRENT:
It proposes a standard way to create, delete, and manage
paths using identifiers.
Using identifiers is a key part of the solution. Maybe say "manage paths
using explicit identifiers instead of merely relying on the IP addresses
and UDP ports."?
## nit
OLD: It proposes a standard way to create
NEW: It defines a standard way to create
OK.
# What’s in scope, what isn’t?
Several aspects of multipathing are declared out of scope. These are include
mostly in the introduction.
I would suggested to have all such statements groped in a specific Section.
# Use Case
CURRENT:
Specifically, while failover between Wi-Fi and mobile networks is a
well-known multipath use case,
Maybe cite rfc8041#section-2.2
I guess we should ask Olivier Bonaventure about that...
# Redundant behavior
Section 2 (Preamble)
Endpoints MUST NOT remember the value of
the initial_max_path_id transport parameter for use in a subsequent
connection.
Section 2.1:
The initial_max_path_id parameter MUST NOT be remembered for use in a
subsequent connection (Section 7.4.1 of [QUIC-TRANSPORT]).
Unless I’m missing something subtle here, I suggest to keep the normative
behavior only in one place (2.1, typically).
Yes, we should fix that.
# MAX_PATH_ID
CURRENT:
MAX_PATH_ID frames that do not increase the
path limit MUST be ignored.
Isn’t allowed that this frame can be received at any time during the
connection? If so, wouldn’t that MUST prevent lowering the limit to accommodate
local preferences?
Yes it does exactly that. This is similar to flow control: credits that
have been granted cannot be withdrawn. But note that the frame defines
the MAX_PATH_ID, not the maximum number of concurrent paths. An endpoint
that is stressed for resource will simply stock incrementing the limit.
Cheers,
Med
