Managing multiple paths for a QUIC connection
draft-ietf-quic-multipath-21

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

[Ballot comment]
Hi Yanmei, Yunfei, Quentin, Olivier, Christian, and Mirja,

Thank you for the discussion and for the changes made [1]. This addresses key point in my previous ballot [2].

Looking forward to see more operational experience and hopefuly more guidance on scheduling part.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-quic-multipath-19&url2=draft-ietf-quic-multipath-20&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/quic/Kx2r3Pc7RzucmgsLkNqgqymftXA/

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

[Ballot discuss]
IANA needs to be instructed to remove, deprecate, or obsolete QUIC Transport Parameters enable_multipath provisional and  enable_multipath(-06), QUIC Frame Type PATH_STATUS, and QUIC Transport Error Code MP_PROTOCOL_VIOLATION

[Ballot comment]
Thanks for the work done in this document.

Special thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request and on short notice), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-quic-multipath-19-intdir-telechat-fressancourt-2026-02-04/

In addition to Antoine's review, and in the light of https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, I noted some SHOULD (e.g., sections 2.3, 2.5) that are without the required guidance per the IESG statement (in short, why not a MUST?).

Let me also expression my surprise (knowing many of the authors) that section 5.2 uses IPv4 only example... On this topic, a dual-stack example would have been nice (especially, as Wi-Fi is often IPv4-only and 3GPP/cellular is often IPv6-enable or IPv6-only).

[Ballot 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:

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

## Can we please better clarify the assumptions around applications?

# 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
* need to support configurable policy for acceptable traffic distribution
* remind that (plugged) traffic scheduler need to avoid aggressive use of some resources (cellular in bonding scenarios) while other paths are available.
* 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

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

[Ballot 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. 

## nit

OLD: It proposes a standard way to create

NEW: It defines a standard way to create

# 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

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

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

Cheers,
Med

[Ballot comment]
I did spend an inordinate amount of time looking at the difference in the RFC9001 AEAD nonce and the AEAD nonce in this draft.  I do believe that one *could* make this clearer.  I'll only give one suggestion.

Section 2.4, last paragraph:  This example would be easier to see/understand in a table/figure form with the IV, path ID, two bits of 0, packet number, and XOR'd result all lined up in three rows.   

Section 7.3, last para: This specification does not change how the 'AEAD' works.  It does change the calculation of the AEAD nonce that is an input to the algorithm.  I would change the first sentence to:  'This specification changes the AEAD nonce calculation by including the path ID as part of the calculation.'  Otherwise, the paragraph is inaccurate.  [Thanks to Carsten Bormann for this.  I (obviously) agree with him.]

IANA needs to be instructed to remove, deprecate, or obsolete QUIC Transport Parameters enable_multipath provisional and  enable_multipath(-06), QUIC Frame Type PATH_STATUS, and QUIC Transport Error Code MP_PROTOCOL_VIOLATION.

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-quic-multipath-19
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-quic-multipath-19.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Thanks to Carsten Bormann for the ARTART review.


## Comments

This is an impressive specification. Thanks for the work from the authors and the working group.

[Ballot comment]
# Internet AD comments for draft-ietf-quic-multipath-19
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S1

* In addition to working with QUIC v1, I assume it will work with other
  v1-compatible version, e.g. "v2"/RFC 9369?

* "There are currently no IETF specifications ..."

  Is this really true?  Does RFC 6356 count as one such specification?

[Ballot 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.

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.

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

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

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

[Ballot 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.

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Changed action holders to Gorry Fairhurst, Quentin De Coninck, Yanmei Liu, Mirja Kühlewind, Christian Huitema, Yunfei Ma, Olivier Bonaventure (Revised I-D needed after IETF LC and IANA Review)

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-quic-multipath-18. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the QUIC Transport Parameters registry in the QUIC registry group located at:

https://www.iana.org/assignments/quic/

a single, new registration will be made as follows:

Value: [ TBD-at-Registration ]
Parameter Name: initial_max_path_id
Status: permanent
Specification: [ RFC-to-be; Section 2.1 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

IANA understands that this registration should come from the 0x00-0x3f range in the registry.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the QUIC Frame Types registry also in the QUIC registry group located at:

https://www.iana.org/assignments/quic/

ten, new registrations will be made as follows:

Value: [ TBD-at-Registration ]
Frame Type Name: PATH_ACK
Status: permanent
Specification: [ RFC-to-be; Section 4.1 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Frame Type Name: PATH_ACK
Status: permanent
Specification: [ RFC-to-be; Section 4.1 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Frame Type Name: PATH_ABANDON
Status: permanent
Specification: [ RFC-to-be; Section 4.2 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Frame Type Name: PATH_STATUS_BACKUP
Status: permanent
Specification: [ RFC-to-be; Section 4.3 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Frame Type Name: PATH_STATUS_AVAILABLE
Status: permanent
Specification: [ RFC-to-be; Section 4.3 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Frame Type Name: PATH_NEW_CONNECTION_ID
Status: permanent
Specification: [ RFC-to-be; Section 4.4 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Frame Type Name: PATH_RETIRE_CONNECTION_ID
Status: permanent
Specification: [ RFC-to-be; Section 4.5 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Frame Type Name: MAX_PATH_ID
Status: permanent
Specification: [ RFC-to-be; Section 4.6 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Frame Type Name: PATHS_BLOCKED
Status: permanent
Specification: [ RFC-to-be; Section 4.7 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Frame Type Name: PATH_CIDS_BLOCKED
Status: permanent
Specification: [ RFC-to-be; Section 4.7 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

IANA understands that these ten registrations are to come from the 0x00-0x3f range in the registry.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the QUIC Transport Error Codes registry also in the QUIC registry group located at:

https://www.iana.org/assignments/quic/

four, new registrations will be made as follows:

Value: [ TBD-at-Registration ]
Code: APPLICATION_ABANDON_PATH
Description: Path abandoned at the application's request
Status: permanent
Specification: [ RFC-to-be; Section 4.2.1 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Code: PATH_RESOURCE_LIMIT_REACHED
Description: Path abandoned due to resource limitations in the transport
Status: permanent
Specification: [ RFC-to-be; Section 4.2.1 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Code: PATH_UNSTABLE_OR_POOR
Description: Path abandoned due to unstable interfaces or poor performance
Status: permanent
Specification: [ RFC-to-be; Section 4.2.1 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

Value: [ TBD-at-Registration ]
Code: NO_CID_AVAILABLE_FOR_PATH
Description: Path abandoned due to no available connection IDs for the path
Status: permanent
Specification: [ RFC-to-be; Section 4.2.1 ]
Date: [ TBD-at-Registration ]
Change Controller: IETF
Contact: [QUIC_WG]
Notes:

IANA understands that these four, new registrations are to come from the 0x00-0x3f range in the registry.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

Request for IETF Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. Sent review to list. Submission of review completed at an earlier date.

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

The following Last Call announcement was sent out (ends 2025-12-22):

From: The IESG
To: IETF-Announce
CC: draft-ietf-quic-multipath@ietf.org, gorry@erg.abdn.ac.uk, lucas@lucaspardue.com, quic-chairs@ietf.org, quic@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Managing multiple paths for a QUIC connection) to Proposed Standard


The IESG has received a request from the QUIC WG (quic) to consider the
following document: - 'Managing multiple paths for a QUIC connection'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-12-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a multipath extension for the QUIC protocol
  to enable the simultaneous usage of multiple paths for a single
  connection.  It proposes a standard way to create, delete, and manage
  paths using identifiers.  It does not specify address discovery or
  management, nor how applications using QUIC schedule traffic over
  multiple paths.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/



No IPR declarations have been submitted directly on this I-D.

AD Review: As a PS addition to a core transport protocol, I did a detailed review of this prior to and during WGLC. I have checked and all topics raised by me have been addressed in the current rev. and I have no further AD review comments. I plan to progress this to IETF-LC.

# Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The document represents the consensus of a broad group of participants. The
genesis of the document was the combination of several distinct technical
proposals. Through the lengthy WG process, the design has converged towards the
singular design now presented.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

The document followed the Github workflow, used for all QUIC WG documents. Since
the draft was adopted in 2022, almost 300 issues, and over 326 PRs were opened.
Some of the largest discussion items revolved around single vs. multiple packet
spaces and the relationship between connection IDs and path IDs. There was a lot
of interest and energy in such topics, and although they took some time to
overcome, I am confident that the final consensus is not controversial or
particularly rough.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

I have seen no such threats or indications.

4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

The authors consist of several groups that have been independently implementing
the draft iterations and carrying out regular interoperability tests (e.g.,
during hackathon events) and reporting results during WG meetings. I am aware of
Alibaba's production deployment of the document, although I believe this is
primarily a self-interop deployment.

Outside the authors, a range of other QUIC implementations have implemented the
document to some level of maturity.

I am aware of other implementation and deployment interest in the features of
the document, primarily driven by the interest in the potential for improved
durability and availability of QUIC connections that can use multiple paths.

3GPP have repeatedly expressed a strong interest in this document.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

The document describes an extension to QUIC to enable the simultaneous usage of
multiple paths for a single connection. Members of the QUIC WG are active in
many adjacent groups, and have prior relevant expertise in technologies that are
relevant. Any necessary interactions have likely happened organically through
the course of consensus.

The IETF last call is an excellent time to gather wider input. I do not think
any particular WG or area needs to pay special attention.

As noted in the previous answer, 3GPP have expressed a lot of interest in the
document over the years. My first suggestion would be to use informal means to
make them aware that we intend to send this on to the IESG. We may,
alternatively, consider issuing a formal information liasion but I would welcome
input on that from those closer to the 3GPP work.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document contains no MIB, YANG, media type or URI related contents.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

The document contains no relevant formal language sections.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes,

10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

To my knowledge, there have been no issues identified. Therefore, I expect IETF
last call to catch anything relevant.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status is Proposed Standard. This is a proper type for the QUIC
extension elements defined in the document. Care was taken throughout the
consensus process to ensure research topics were kept out of scope, meaning the
an experimental status for the protocol itself is not required.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

Yes. All authors have been reminded and have indicated they are not aware of any
IPR related to the document.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes. All authors have confirmed their willingness.

The number of authors on the front page is 6. This was discussed extensively in
the lead up to adoption with the author group, chairs and the responsible AD at
the time. This number is justified by the document being an amalgamation of
various design proposals that were unified via hard work, determination and
compromise.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

I have created https://github.com/quicwg/multipath/issues/620. Beyond that,
there are no other issues to my knowledge.

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

All references appear to be the correct type.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A, all normative references are IETF RFCs.

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

There are no new IANA registries being defined.

Several new elements are being registered in existing QUIC registries. The
registration requests are compliant with the guidance defined in RFC 9000. Some
nits were identified and reported on
https://github.com/quicwg/multipath/issues/621.

As is common for QUIC extensions, prior to publication a set of provisional
codepoints have been reserved. The IANA considerations section contains clear
instructions to IANA requesting the allocation of shorter codepoints once the
draft has been approved for publication.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

There are no new IANA registries being defined.

# Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The document represents the consensus of a broad group of participants. The
genesis of the document was the combination of several distinct technical
proposals. Through the lengthy WG process, the design has converged towards the
singular design now presented.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

The document followed the Github workflow, used for all QUIC WG documents. Since
the draft was adopted in 2022, almost 300 issues, and over 326 PRs were opened.
Some of the largest discussion items revolved around single vs. multiple packet
spaces and the relationship between connection IDs and path IDs. There was a lot
of interest and energy in such topics, and although they took some time to
overcome, I am confident that the final consensus is not controversial or
particularly rough.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

I have seen no such threats or indications.

4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

The authors consist of several groups that have been independently implementing
the draft iterations and carrying out regular interoperability tests (e.g.,
during hackathon events) and reporting results during WG meetings. I am aware of
Alibaba's production deployment of the document, although I believe this is
primarily a self-interop deployment.

Outside the authors, a range of other QUIC implementations have implemented the
document to some level of maturity.

I am aware of other implementation and deployment interest in the features of
the document, primarily driven by the interest in the potential for improved
durability and availability of QUIC connections that can use multiple paths.

3GPP have repeatedly expressed a strong interest in this document.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

The document describes an extension to QUIC to enable the simultaneous usage of
multiple paths for a single connection. Members of the QUIC WG are active in
many adjacent groups, and have prior relevant expertise in technologies that are
relevant. Any necessary interactions have likely happened organically through
the course of consensus.

The IETF last call is an excellent time to gather wider input. I do not think
any particular WG or area needs to pay special attention.

As noted in the previous answer, 3GPP have expressed a lot of interest in the
document over the years. My first suggestion would be to use informal means to
make them aware that we intend to send this on to the IESG. We may,
alternatively, consider issuing a formal information liasion but I would welcome
input on that from those closer to the 3GPP work.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document contains no MIB, YANG, media type or URI related contents.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

The document contains no relevant formal language sections.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes,

10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

To my knowledge, there have been no issues identified. Therefore, I expect IETF
last call to catch anything relevant.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status is Proposed Standard. This is a proper type for the QUIC
extension elements defined in the document. Care was taken throughout the
consensus process to ensure research topics were kept out of scope, meaning the
an experimental status for the protocol itself is not required.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

Yes. All authors have been reminded and have indicated they are not aware of any
IPR related to the document.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes. All authors have confirmed their willingness.

The number of authors on the front page is 6. This was discussed extensively in
the lead up to adoption with the author group, chairs and the responsible AD at
the time. This number is justified by the document being an amalgamation of
various design proposals that were unified via hard work, determination and
compromise.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

I have created https://github.com/quicwg/multipath/issues/620. Beyond that,
there are no other issues to my knowledge.

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

All references appear to be the correct type.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A, all normative references are IETF RFCs.

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

There are no new IANA registries being defined.

Several new elements are being registered in existing QUIC registries. The
registration requests are compliant with the guidance defined in RFC 9000. Some
nits were identified and reported on
https://github.com/quicwg/multipath/issues/621.

As is common for QUIC extensions, prior to publication a set of provisional
codepoints have been reserved. The IANA considerations section contains clear
instructions to IANA requesting the allocation of shorter codepoints once the
draft has been approved for publication.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

There are no new IANA registries being defined.

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Christian Huitema , Mirja Kuehlewind , Olivier Bonaventure , Quentin De Coninck , Yanmei Liu , Yunfei Ma , quic-chairs@ietf.org