jiebi/CodeConvo huggingface dataset:
Change:
Attempt at moving Further, it is out of scope for this document if the old address can also be used for multipath after a client has migrated to the address provided in the preferred_address transport parameter. However, it SHOULD NOT be assumed that it is possible to use both addresses simultaneously without further confirmation from the other host. In the beginning of section where I think it would be more appropriate.
Looks good, except for the typo.

Discussion:
After completing the handshake, endpoints have agreed to enable multipath feature and can start using multiple paths.  This document <del> does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. </del> <ins> does not specify how an endpoint that is reachable via several addresses announces these addresses to the other endpoint.  In particular, if the server uses the preferred_address transport parameter, clients SHOULD NOT assume that the initial server address and the addresses contained in this parameter can be simultaneously used for multipath.  Furthermore, this document does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. </ins> This proposal adds one multipath control frame for path management:
Change:
Add some implementation considerations to handle different PMTU sizes following the discussion on . Feel free to add different implementation options here.
Looks ok to me, just a small suggestion to avoid talking about packet retransmission.

Discussion:
11. <del> TDB </del> <ins> 11.1. An implementation should take care to handle different PMTU sizes across multiple paths.  One simple option if the PMTUs are relatively similar is to apply the minimum PMTU of all paths to each path.  The benefit of such an approach is to simplify retransmission processing as the content of lost packets initially sent on one path can be sent on another path without further frame scheduling adaptations. </ins> 12.
Change:
This text will be moved to the next section in PR . Therefore this PR needs to be merged together with PR .

Discussion:
"enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. <del> Note that the transport parameter "active_connection_id_limit" QUIC- TRANSPORT limits the number of usable Connection IDs, and also limits the number of concurrent paths.  For the QUIC multipath extension this limit even applies when no connection ID is exposed in the QUIC header. </del> This extension does not change the definition of any transport <del> parameter defined in Section 18.2. of QUIC-TRANSPORT.  Inline with the definition in QUIC-TRANSPORT disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" Section 18.2. of QUIC- TRANSPORT.  Further, it is out of scope for this document to specify if the old address can also be used for multipath after a client has migrated to the address provided in the preferred_address transport parameter.  However, it SHOULD NOT be assumed that it is possible to use both addresses simultaneously without further confirmation from the other host. </del> <ins> parameter defined in Section 18.2. of QUIC-TRANSPORT. Inline with the definition in QUIC-TRANSPORT disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" Section 18.2. of QUIC- TRANSPORT. The transport parameter "active_connection_id_limit" QUIC-TRANSPORT limits the number of usable Connection IDs, and also limits the number of concurrent paths.  For the QUIC multipath extension this limit even applies when no connection ID is exposed in the QUIC header. </ins> 3.
Change:
Should we trigger an connection closure with a MPCONNECTIONERROR in the case an endpoint receives an ACK_MP frame acknowledging packets on a non-existing packet number space ID?
Yes. I just submitted PR for this issue.
PR merged.
LGTM.

Discussion:
9.2. <del> The MP_ACK frame (types TBD-00 and TBD-01; experiments use </del> <ins> The ACK_MP frame (types TBD-00 and TBD-01; experiments use </ins> 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that <del> were sent on different paths.  If the frame type is TBD-01, MP_ACK </del> <ins> were sent on different paths.  If the frame type is TBD-01, ACK_MP </ins> frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point.

number space, which is the sequence number of Destination Connection ID of the 1-RTT packets which are acknowledged by the ACK_MP frame. If the endpoint receives 1-RTT packets with 0-length Connection ID, <del> it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames. </del> <ins> it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.  If an endpoint receives a ACK_MP frame with a non-existing packet number space ID, it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </ins> 10.
Change:
It's a grammar error fix in the aead section.
from URL The path ID for 1-RTT packets is the sequence number of of {{QUIC-TRANSPORT}} maybe it should be The path ID for 1-RTT packets is the sequence number of Connection ID of {{QUIC-TRANSPORT}}
Thanks Wu! I fixed this grammar error in PR .

Discussion:
calculated by combining the packet protection IV with the packet number and with the path identifier. <del> The path ID for 1-RTT packets is the sequence number of of QUIC- </del> <ins> The path ID for 1-RTT packets is the sequence number of QUIC- </ins> TRANSPORT, or zero if the Connection ID is zero-length.  Section 19 of QUIC-TRANSPORT encodes the Connection ID Sequence Number as a variable-length integer, allowing values up to 2^62-1; in this
Change:
.
Should the spec say something about stateless reset? Suppose a node is sending on two paths with two different DCID and two corresponding stateless reset secrets, and receives a stateless reset packet that matches the reset secret on the first path. Should it: 1) Abandon that path and continue the connection with the other path? 2) Abandon the connection?
That's a good point. RFC9000 states that stateless resets should be used in last resort when the endpoint does not have access to the connection state. If hosts have still access to the connection state and want to abandon a specific path, I would expect them to rely on PATH_ABANDON frame (or on path idle timeout). So when receiving a stateless reset, I would abandon the connection. Depending on the number of impacts on existing RFC9000 mechanisms, it may be useful to write a section (or at least, a paragraph) clarifying these points.
We should review the current text and make sure we cover everything clearly. Maybe add some more text to the intro part of 3.2
Careful with implicit actions!LGTM

Discussion:
endpoint abandons a path, the peer will not receive any more non- probing packets on that path. <del> An endpoint that wants to close a path SHOULD NOT rely on implicit signals like idle time or packet losses, but instead SHOULD use explicit request to terminate path by sending the PATH_ABANDON frame (see path-abandon-frame). </del> <ins> An endpoint that wants to close a path SHOULD use explicit request to terminate the path by sending the PATH_ABANDON frame (see path- abandon-close).  Note that while abandoning a path implies Connection ID retirement, only retiring the associated Connection ID does not necessarily advertise path abandon (see retire-cid-close).  However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see idle-time-close). Note that other explicit closing mechanisms of QUIC-TRANSPORT still apply on the whole connection.  In particular, the reception of either a CONNECTION_CLOSE (Section 10.2 of QUIC-TRANSPORT) or a Stateless Reset (Section 10.3 of QUIC-TRANSPORT) closes the connection. </ins> 4.2.1.
Change:
It might be possible to be in a state where a sender retires a DCID that was used by still in-flight packets. Hence, it is possible for the sender to receive a ACKMP frame referencing the retired DCID. Depending on the situation: The sender can keep a way to track the sent packet with the retired DCID sequence number, allowing proper acknowledgement of the packets. The sender drops all the state related to the DCID, hence marking the in-flight packets as being lost and ignoring ACKMP frames having a retired DCID sequence number. While this should not affect interoperability, it might be worthwhile to add a sentence or two to mention the possible performance issue in such situation.
We could add some text to . Can you propose a PR NAME ?

Discussion:
the connection ID, but MUST use a different connection ID when doing so. <ins> Note that if the sender retires a Connection ID that is still used by in-flight packets, it may receive ACK_MP frames referencing the retired Connection ID.  If the sender stops tracking sent packets with retired Connection ID, these would be spuriously marked as lost. To avoid such performance issue without keeping retired Connection ID state, an endpoint should first stop sending packets with the to-be- retired Connection ID, then wait for all in-flight packets to be either acknowledged or marked as lost, and finally retire the Connection ID. </ins> 4.2.3. QUIC-TRANSPORT allows for closing of connections if they stay idle
Change:
Minor tweak. The text says that a path abandon "implies" retirement of the CID. Readers could be mislead and assume that they don't need to send a retire frame after sending abandon, when in fact they do.
NAME , NAME NAME please review.
This Github setting is pretty annoying. NAME I understand why only the selected authors would be able to merge a pull request, but as it stands I am also blocked from requesting reviews of a PR that I just created.
LGTMThe proposed text is indeed clearer.

Discussion:
An endpoint that wants to close a path SHOULD use explicit request to terminate the path by sending the PATH_ABANDON frame (see path- <del> abandon-close).  Note that while abandoning a path implies Connection ID retirement, only retiring the associated Connection ID does not necessarily advertise path abandon (see retire-cid-close).  However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see idle-time-close). </del> <ins> abandon-close).  Note that while abandoning a path will cause Connection ID retirement, only retiring the associated Connection ID does not necessarily advertise path abandon (see retire-cid-close). However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see idle-time- close). </ins> Note that other explicit closing mechanisms of QUIC-TRANSPORT still apply on the whole connection.  In particular, the reception of
Change:
There is a SHOULD here, which I believe should be a MUST as we taking about the receiver behaviour here.
NAME NAME is this ready to merge?
Sorry, I am working on several projects in parallel, missed this. Text is fine.

Discussion:
frames to signal acknowledgement of 1-RTT packets on path number 0, and also 0-RTT packets as specified in handling-of-0-rtt-packets. <del> 1-RTT packets sent to different paths SHOULD carry different connection identifiers, if a non-zero connection ID is used. </del> <ins> An endpoint sending 1-RTT packets MUST use different Connection IDs on different paths, if non-zero-length Connection IDs are used. Still, the receiver may observe the same Connection ID used on different 4-tuples due to, e.g., NAT rebinding.  In such case, the receiver reacts as specified in Section 9.3 of QUIC-TRANSPORT. </ins> 6.1.
Change:
Since , we now define the Path ID as (Section 1.1) And the definition of the as the field of PATHABANDON and PATHSTATUS frames directly maps to that identifier path (i.e., the sequence number of the destination Connection ID used for sending packets on that particular path, Sections 8.1 and 8.2). But in Section 6.2, the example states that I believe the current text is unclear and should be fixed. Yet, I see two possible ways of doing so. We should either state that the field of these frames refer to the Path ID used by the receiver of the frame, or add some information to indicate that it refers to the Path ID viewed from the sender's/receiver's viewpoint (that could be encoded as a bit in the frame's type)
Is there any use case for either using the sender's or receiver's ID? If not, I'd prefer we simply choose one and define it clearly.
(P.S.: I think the text in the example is just wrong. I think I messed this up in .)
IMHO it makes more sense to me to use the sender's ID by default, especially if we consider only client-initiated paths.
I would also suggest to slightly update the text related to the field of the PATHABANDON and PATHSTATUS frames to indicate it refers to the sender's Path ID.LGTM

Discussion:
1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by <del> the sequence number of the received packet's DCID over that path, hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path as path identifier, which corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for </del> <ins> the sequence number of the DCID it uses for sending packets over that path, hence using the path_id 2.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the DCID it uses to send over that path as path identifier, which corresponds to the path_id 1.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for </ins> that path. 7.
Change:
This draft only enables clients to open a new path, so the most common scenario is that the client has another interface and opens a new path from a new IP address. However, if the client knows another IP that the server is listing on to accept new paths for an existing quic connection (e.g. provided on the higher layer or out of band), that can be used as well. It would be useful to discussion this case more in the draft to ensure that it is clear that this case is supported.
I think as people who implement multipath will mostly refer to this draft, we may want to clarify all scenarios supported by this draft: (1) client has multiple IPs while server listens on single IP, (2) client uses single IP while server listens on multiple IP, and (3) client uses multiple IPs and the server also uses multiple IPs.
LGTM

Discussion:
connection IDs for distinguishing packets sent to that node over different paths. <ins> Each endhost may use several IP addresses to serve the connection. In particular, the multipath extension supports the following scenarios. The client uses multiple IP addresses and the server listens on only one. The client uses only one IP address and the server listens on several ones. The client uses multiple IP addresses and the server listens on several ones. </ins> This proposal does not cover address discovery and management. Addresses and the actual decision process to setup or tear down paths are assumed to be handled by the application that is using the QUIC <del> multipath extension.  Further, this proposal only specifies a simple basic packet scheduling algorithm, in order to provide some basic </del> <ins> multipath extension.  This is sufficient to address the first aforementioned scenario.  However, this document does not prevent future extensions from defining mechanisms to address the remaining scenarios.  Further, this proposal only specifies a simple basic packet scheduling algorithm, in order to provide some basic </ins> implementation guidance.  However, more advanced algorithms as well as potential extensions to enhance signaling of the current path state are expected as future work.
Change:
This is really a minor issue, but the word "uniflow" appears just once in the draft, in section 5, packet scheduling. I think the packet scheduling text could simply use the word "path".

Discussion:
5. <del> The simultaneous usage of several sending uniflows introduces new </del> <ins> The simultaneous usage of several sending paths introduces new </ins> algorithms (packet scheduling, path management) whose specifications are out of scope of this document.  Nevertheless, these algorithms are actually present in any multipath-enabled transport protocol like
Change:
The ACKMP text does not change, it just comes before PATHABANDON and PATHSTATUS. The rationale is that 1) the new order follows the encoding numbering (lowest to highest), and 2) the ACKMP is a critical frame, the PATHABANDON is an important one yet still "indicative" (it suggests the peer to abandon this path) and the PATHSTATUS frame is an indicative one.
Just to not forget this, but this is mostly editorial. Probably present first the ACKMP frame, and then PATHABANDON and PATHSTATUS Drop reference to I-D.liu-multipath-quic as the PATHSTATUS frame is now integrated in the draft. Based on and , and If we agree on , we could also drop the text in PATh_ABANDON stating that on any path, not only the path on which the referenced Destination Connection ID is used.
OK. It's reasonable.

Discussion:
8.1. <del> The PATH_ABANDON frame informs the peer to abandon a path.  More complex path management can be made possible with additional extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ). </del> <ins> The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01) is an extension of the ACK frame defined by QUIC- TRANSPORT.  It is used to acknowledge packets that were sent on different paths using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. ACK_MP frame is formatted as shown in fig-ack-mp-format. Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added. The sequence number of the Connection ID identifying the packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. 8.2. The PATH_ABANDON frame informs the peer to abandon a path. </ins> PATH_ABANDON frames are formatted as shown in fig-path-abandon- format.

PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. <del> PATH_ABANDON frames MAY be sent on any path, not only the path on which the referenced Destination Connection ID is used. 8.2. </del> <ins> 8.3. </ins> PATH_STATUS Frame are used by endpoints to inform the peer of the current status of one path, and the peer should send packets

if it was the last status sent for that path - as indicated by the sequence number. <del> 8.3. The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01) is an extension of the ACK frame defined by QUIC- TRANSPORT.  It is used to acknowledge packets that were sent on different paths using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. ACK_MP frame is formatted as shown in fig-ack-mp-format. Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added. The sequence number of the Connection ID identifying the packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. </del> 9. Multipath QUIC transport error codes are 62-bit unsigned integers
Change:
If we want an MP specific error type we need to also add this to the IANA section.
Submitted PR for this issue. I just added MPPROTOCOLVIOLATION for connection close. If we have more specific error codes in the future, we can add them in the table.
Looks OK.

Discussion:
it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.  If an endpoint receives a ACK_MP frame with a non-existing packet number space ID, it MUST treat this as a connection error of type <del> MP_CONNECTION_ERROR and close the connection. </del> <ins> MP_PROTOCOL_VIOLATION and close the connection. </ins> 10. <ins> Multi-path QUIC transport error codes are 62-bit unsigned integers following QUIC-TRANSPORT. This section lists the defined Multi-path QUIC transport error codes that can be used in a CONNECTION_CLOSE frame with a type of 0x1c. These errors apply to the entire connection. MP_PROTOCOL_VIOLATION (experiments use 0xba01): An endpoint detected an error with protocol compliance that was not covered by more specific error codes. 11. </ins> This document defines a new transport parameter for the negotiation of enable multiple paths for QUIC, and two new frame types.  The draft defines provisional values for experiments, but we expect IANA

The following frame types defined in frame-types should be added to the "QUIC Frame Types" registry under the "QUIC Protocol" heading. <del> 11. </del> <ins> The following transport error code defined in tab-error-code should be added to the "QUIC Transport Error Codes" registry under the "QUIC Protocol" heading. 12. </ins> TBD <del> 12. </del> <ins> 13. </ins> TBD
Change:
When negotiating the use of a single packet number space, it is not clear whether the use of ACKMP frame is acceptable or not. Should we only stick to ACK frames and consider reception of ACKMP frames to be MPPROTOCOLVIOLATION error? Or should we tolerate their reception if the packet number space identifier is 0?
Ah good point. I moved the text about ACKMP this morning because I assumed that you would only implement this frame if you use multiple packet number spaces. If that's the case receiving an ACKMP with enablemultipath=2 should be a PROTOCOLVIOLATION and we should specify that.
Look good to me.

Discussion:
The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that <del> were sent on different paths.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. </del> <ins> were sent on different paths when using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. </ins> ACK_MP frame is formatted as shown in fig-mp-ack-format.

space ID, it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection. <ins> When using a single packet number space, endhosts MUST NOT send ACK_MP frames.  If an endhost receives an ACK_MP frame while a single packet number space was negotiated, it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection. </ins> 10. Multi-path QUIC transport error codes are 62-bit unsigned integers