RE: Mohamed Boucadair's Discuss on draft-ietf-quic-multipath-19: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Mirja, Christian,

Thank you for the follow-up.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind <[e-mail]>
> Envoyé : vendredi 6 février 2026 14:07
> À : Christian Huitema <[e-mail]>; BOUCADAIR Mohamed
> INNOV/NET <[e-mail]>; The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-quic-
> multipath-19: (with DISCUSS and COMMENT)
> 
> 
> Hi Med,
> 
> yes, thanks for the review. Please see some additional comments
> inline.
> 
> Mirja
> 
> 
> On 06.02.26, 03:30, "Christian Huitema" <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
> 
> 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.)
> >
> > ----------------------------------------------------------------
> > 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]?
> 
> [MK] I think so. As you say below, RFC9000 also has no explicit
> definition and uses the term "network path" similarly as a logical
> construct as Christian explained below. The reference to RFC9000
> is only there say that what's called "network path" in RFC9000 is
> the same as what we just call "path" in this document. However not
> defining it further is intention and actually aligned with RFC9000
> as Christian explained below.

[Med] ACK on the logical construct. Clarifying this in the text would help.

> 
> >
> > ## 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.

[Med] Thanks.

> 
> [MK] I think maybe we could add one more sentence to the intro
> saying more explicitly that a path is determined by the path ID
> and not the 4-tuple.

[Med] This is an enhancement. 

> 
> 
> > # 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"
> (....
and
> "How will MPQUIC support the scenario where the client connects
> with a dual-stack server via both IPv4 and IPv6 paths?
> (...
). 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.
> 
> [MK] Actually I think Med's question was about how a client can
> learn about new server addresses. The working group decided early
> on (before taking this work item up) that we only focusing on the
> basic path management and leave things like address announcement
> (as well as scheduling as mentioned below) to future extensions.
> 
> [MK] I would say the primary use case is actually the case where
> the client has multiple address and not announcement is needed.
> There are also cases where the application knows or learns
> multiple server addresses already and can use this extension right
> away. However, there is also already a (recently expired) draft
> that proposes an extension to announce additional server
> addresses:
> 
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fdraft-piraux-quic-additional-
> addresses%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7cffa
> d976ce547a77adc08de65809e59%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C639059800263488298%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=BXwe8%2BFDdUH%2BsA9SCGUMpSZ%2FCiqcug
> EAp0%2B5jKbiAzw%3D&reserved=0
> 
> [MK] However, as the document says the group decided explicitly
> from the start to leave this out of scope for this extension.

[Med] Thanks Mirja for the pointer. This is what I was looking for.

> 
> 
> > ## 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.
> 
> 
> [MK] Not sure what exactly you are asking for here, but if this is
> still about address handling, as I said it purposefully left out
> of scope for this document.

[Med] I was confused by: 

"Addresses and the actual decision to set up ..."

Which I interpreted as address management is delegated to applications and closes the door for future extensions at the QUIC level. If you can reword that text to avoid that interpretation would be great. Thanks. 

> 
> >
> > # 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.
> 
> [MK] Having these limits is really more an implementation and
> security question than an operational aspect, as explained in the
> security considerations section, where resource exhaustion attacks
> are mentioned. Of course it makes sense to make these max number
> of paths configurable but, similar as RFC9000, we don't define an
> API.

[Med] It is an operational concern as this will impact the dimensioning of servers, etc.

> 
> 
> > * 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.

[Med] ACK

> 
> 
> > * 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.

[Med] I feel a bit uncomfortable to not identify a minimum set of guards that need to be considered. Of course, this does not need to specify how to do it.

> >
> > # 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.
> 
> [MK] First of all, we had a very lengthy discussion about making
> it a MUST (and enforcing that MUST) but at the end decided to say
> with SHOULD and require to process RFC9000 ACK frames even if the
> extension is used. There are pros and cons for both approaches
> that can make one or the other implementation approach easier but
> that's where the consensus ended up see here:
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> github.com%2Fquicwg%2Fmultipath%2Fissues%2F220&data=05%7C02%7Cmoha
> med.boucadair%40orange.com%7C7cffad976ce547a77adc08de65809e59%7C90
> c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639059800263505474%7CUnkn
> own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ic
> FvMgO%2FsnCVqslaXDF0xdM%2B5L9UgW3WD8age4IX2G0%3D&reserved=0
> 
> [MK] in the issue you can see that we also decided to add some
> guidance/examples when sending ACK is useful, which is what
> exactly the next sentence is about:
> 
> " For example, a sender could negotiate multipath support for
> later use and keep only the initial path with path ID 0 for a
> while. During this single-path period, the sender might prefer to
> send ACK frames."
> 
> [MK] I don't thing we can say more than that. There are no
> "implications" of not following the SHOULD; this was simply a
> design decision. Or what were you looking for?

[Med] I was looking for some explicit guidance in the text itself. 

> 
> >
> > 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?
> 
> [MK] Is this what the next paragraph is exactly doing?
> 
> "As packets that arrive after their decryption key has been
> discarded will be dropped, the choice of three times the largest
> PTO is a trade-off: Longer delays reduce the probability of losing
> packets but keeping old keys longer can negatively impact the
> security of the protocol. The use of three times the largest PTO
> aims to minimize packet lost for all paths and therefore limits
> the impact on performance."
> 

[Med] ACK.

> [MK] What else do you expect?
> 
> 
> 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."?
> 
> [MK] I personally don't find this too vague. But as Christian says
> identifiers are a key part, so I guess we could even put this in
> an own sentence, like:
> 
> OLD
> ...manage paths using identifiers
> 
> NEW
> ...manage paths. A path is determined by an explicit path
> identifier in this extension.
> 
> [MK] What do you think, Christian?
> 
> >
> > ## 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.
> 
> [MK] I don't see the value of a specific section. I actually find
> it better to have it right there in the intro. And we also word-
> smithed this part a lot, so I would not change it again.
> 
> >
> > # 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...
> 
> [MK] I don't think we need a reference here. I think it common
> sense that this is a well-known use case (as the term "well-known"
> implies).
> 
> >
> > # 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.
> 
> [MK] Yes, thanks! We added this recently because we thought it was
> missed. However, I was actually surprised that is wasn't there as
> in my memory I added it at some point; and apparently I did...
> 
> >
> > # 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
> >
> >
> >
> 
> 

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.