jiebi/CodeConvo huggingface dataset:
Change:
Initial attempt to solve .
One more editorial comment: This section is now somehow in the middle between the cc section and the packet scheduling section. I think it would be better to have this new section as a subsection of section 3 (on Path Setup and Removal).
Indeed, let me fix that.
Given that paths are initiating/validating/active/closed, it looks like we will need at some point to specify some path state (finite state machine?) and what behavior is acceptable in each of them (e.g., we cannot send packets on a closed state,...).
Can you create a PR?

Discussion:
for an excessive time or having to promptly reestablish a path after a spurious estimate of path abandonment by the client. <ins> 3.3. fig-path-states shows the states that an endpoint's path can have. In non-final states, hosts have to track the following information. Associated 4-tuple: The tuple (source IP, source port, destination IP, destination port) used by the endhost to send packets over the path. Associated Destination Connection ID: The Connection ID used to send packets over the path. If multiple packet number spaces are used over the connection, hosts MUST also track the following information. Path Packet Number Space: The endpoint maintains a separate packet number for sending and receiving packets over this path.  Packet number considerations described in QUIC-TRANSPORT apply within the given path. In the "Active" state, hosts MUST also track the following information. Associated Source Connection ID: The Connection ID used to receive packets over the path. A path in the "Validating" state performs path validation as described in Section 8.2 of QUIC-TRANSPORT.  An endhost should not send non-probing frames on a path in "Validating" state, as it has no guarantee that packets will actually reach the peer. The endhost can use all the paths in the "Active" state, provided that the congestion control and flow control currently allow sending of new data on a path. In the "Closing" state, the endhost SHOULD NOT send packets on this path anymore, as there is no guarantee that the peer can still map the packets to the connection.  The endhost SHOULD wait for the acknowledgment of the PATH_ABANDONED frame before moving the path to the "Closed" state to ensure a graceful termination of the path. When a path reaches the "Closed" state, the endhost releases all the path's associated resources.  Consequently, the endhost is not able to send nor receive packets on this path anymore. </ins> 4. Senders MUST manage per-path congestion status, and MUST NOT send
Change:
For issue
Ok too.
Based on the discussed from the side meeting, we need to Clarify that the goal is to only select one approach for the finally published solution in an RFC Add some discussion about the pros and cons to the appendix
Yes, I think we should have these discussions in the current draft.
Should we use a new code point for the transport parameter of the options? For 2 reasons: It's a new joint version As we use a different value definition in our current implementation, it's hard to deploy the new version in a synchronised way, at least we could keep compatible if we use a new transport parameter. What do you think? Or maybe we should keep it unchanged until the WG is ready to adopt the draft?
I think it is fine to define a new value for the transport parameter, the 00 version of this draft is not yet out anyway.
Yes, please use a new parameter.
I created to add one more sentence and a reference to the slides from the side meeting. I believe this is sufficient to address this issue for -00.
NAME please confirm that this is okay and merge!

Discussion:
as specified in QUIC-TRANSPORT.  The new transport parameter is defined as follow: <del> name: enable_multipath (TBD) </del> <ins> name: enable_multipath (TBD - experiments use 0xbabf) </ins> value: 0 (default) for disabled.  Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available
Change:
Fix issue .
In the "path abandon" frame, the path identifier is defined as: But in the identifier type 2, the "path identifier content" is empty. We should fix that.
Submitted PR for this issue.
Yes, perfect.

Discussion:
or received. Path Identifier Content: A variable-length integer specifying the <del> path identifier. </del> <ins> path identifier.  If Identifier Type is 2, the Path Identifier Content MUST be empty. </ins> Note: If the receiver of the PATH_ABANDON frame is using non-zero length Connection ID on that path, endpoint SHOULD use type 0x00 for
Change:
Given the deadline, let's first have one set of values instead of two. We may want to decide a third value set later.
Ok for me!
The current text on the defintion of ACK MP says: The figure is too wide, and I am fixing that with issue , but really we should pick just one set of identifiers, not 2. I understand that draft-liu and draft-deconinck were using these two values, but we should pick one of them, or a third one.
I submitted PR to fix this issue.
PR merged.
Fixed conflict.NAME please review and merge if you agree!

Discussion:
10.2. The ACK_MP frame (types TBD-00 and TBD-01; experiments use <del> 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that 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. </del> <ins> 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 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.
Change:
Some more text in the congestion control section explaining why coupled congestion control is suggested. We could later add SHOULD or MUST to request the utilization of coupled congestion control schemes for multipath QUIC.

Discussion:
more data on a given path than congestion control on that path allows.  This is already a requirement of QUIC-TRANSPORT. <del> Multipath TCP uses the LIA congestion control scheme specified in RFC6356.  This scheme can immediately be adapted to Multipath QUIC. Other coupled congestion control schemes have been proposed for Multipath TCP such as OLIA. </del> <ins> When a Multipath QUIC connection uses two or more paths, there is no guarantee that these paths are fully disjoint.  When two (or more paths) share the same bottleneck, using a standard congestion control scheme could result in an unfair distribution of the bandwidth with the multipath connection getting more bandwidth than competing single paths connections.  Multipath TCP uses the LIA congestion control scheme specified in RFC6356 to solve this problem.  This scheme can immediately be adapted to Multipath QUIC.  Other coupled congestion control schemes have been proposed for Multipath TCP such as OLIA. </ins> 5.
Change:
Some more text for the scheduling section to clarify it.
A suggestion to resolve Mirja's point, also agree on the proposed change in line 248.

Discussion:
3. After completing the handshake, endpoints have agreed to enable <del> multipath feature and can start using multiple paths. </del> <ins> multipath feature and can start using multiple paths.  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 multi-path control frame for path management:

6. <del> The simultaneous usage of several sending paths introduces new 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 Multipath TCP, CMT-SCTP and Multipath DCCP.  A companion draft I- D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals.  A similar document can be created to discuss path management considerations. </del> <ins> The transmission of QUIC packets on a regular QUIC connection is regulated by the arrival of data from the application and the congestion control scheme.  QUIC packets can only be sent when the congestion window of at least one path is open. Multipath QUIC implementations also need to include a packet scheduler that decides, among the paths whose congestion window is open, the path over which the next QUIC packet will be sent.  Many factors can influence the definition of these algorithms and their previse definition is outside the scope of this document.  Various packet schedulers have been proposed and implemented, notably for Multipath TCP.  A companion draft I-D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals. </ins> 7.
Change:
Based on the discussed from the side meeting, we need to Clarify that the goal is to only select one approach for the finally published solution in an RFC Add some discussion about the pros and cons to the appendix
Yes, I think we should have these discussions in the current draft.
Should we use a new code point for the transport parameter of the options? For 2 reasons: It's a new joint version As we use a different value definition in our current implementation, it's hard to deploy the new version in a synchronised way, at least we could keep compatible if we use a new transport parameter. What do you think? Or maybe we should keep it unchanged until the WG is ready to adopt the draft?
I think it is fine to define a new value for the transport parameter, the 00 version of this draft is not yet out anyway.
Yes, please use a new parameter.
I created to add one more sentence and a reference to the slides from the side meeting. I believe this is sufficient to address this issue for -00.
Ok with the PR, I can make a quick commit to fix the listed typos

Discussion:
packet number space for all paths or the use of separate packet number spaces per path.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly <del> difference latencies, this approach requires the use of a connection </del> <ins> different latencies, this approach requires the use of a connection </ins> ID.  Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the <del> connection ID in the header.  More evaluation and implementation experience is needed to select one approach before final publlication. </del> <ins> connection ID in the header.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and implementation experience is needed to select one approach before final publication.  Some discussion about pros and cons can be found here: https://github.com/mirjak/draft-lmbdhk-quic- multipath/blob/master/presentations/PacketNumberSpace_s.pdf </ins> As currently defined in this version of the draft the use of multiple packet number spaces requires the use of connection IDs is both
Change:
I copied this sentence from draft-liu: Shouldn't this be a MUST instead of a SHOULD?
We can describe it in a more accurate way: Before an endpoint adds a new path, it MUST check whether there is at lease one unused available Connection ID for each side, unless the endpoints use zero-length Connection ID.
Submitted PR for this issue.
LGTM.

Discussion:
Following QUIC-TRANSPORT, each endpoint uses NEW_CONNECTION_ID frames to issue usable connections IDs to reach it.  Before an endpoint adds <del> a new path, it SHOULD check whether there is at least one unused </del> <ins> a new path, it MUST check whether there is at least one unused </ins> available Connection ID for each side. If the transport parameter "active_connection_id_limit" is negotiated
Change:
This should be a simple fix. There was only one place where MP_ACK appeared.
In the current draft, we are having two names of multi-path ACK. I think we should stick to just one.
I have a slight preference for ACKMP, on the model of ACKECN.
I submitted PR to fix this.
I would be consistent in how the I-D identifies MP additions vs. RFC9000. Given that the document uses MPCONNECTIONERROR and MPPROTOCOLVIOLATION, I have a preference for MP_ACK.
I added changes of the tag "mp-ack-frame" to "ack-mp-frame" for consistency...

Discussion:
If the multipath option is enabled with a value of 2, each path has its own packet number space for transmitting 1-RTT packets and a new <del> ACK frame format is used as specified in mp-ack-frame.  Compared to the QUIC v1 ACK frame, the MP_ACK frames additionally contains a </del> <ins> ACK frame format is used as specified in ack-mp-frame.  Compared to the QUIC v1 ACK frame, the ACK_MP frames additionally contains a </ins> Packet Number Space Identifier (PN Space ID).  The PN Space ID used to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID.

actively using N paths, the limit is reached.  If the client wants to start a new path, it has to retire one of the established paths. <del> ACK_MP frame mp-ack-frame can be returned via either a different </del> <ins> ACK_MP frame ack-mp-frame can be returned via either a different </ins> path, or the same path identified by the Path Identifier, based on different strategies of sending ACK_MP frames.

packets with associated ECN marks received on the connection up to this point. <del> ACK_MP frame is formatted as shown in fig-mp-ack-format. </del> <ins> ACK_MP frame is formatted as shown in fig-ack-mp-format. </ins> Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added.
Change:
Lack of the reference to Section 7.4/Section 7.4.2 of 9000 where the general handling of (new) transport parameters is discussed. When the new transport parameter is not present, this does not necessarily mean multipath is not supported as it can be supported, but disabled (for this connection as a function of local policy). I would update this text
The absence of the parameter does indeed indicate that the peer will not support multipath for this connection. But yes, the current text does not read too well. I think we should simplify and just say the same as QUIc V1, i.e. "Transport parameters have a default value of 0 if the transport parameter is absent". So something like:
The negotiation only refers to "support for this connection". We cannot make any statement about whether the same server might negotiate the feature in another connection attempt. There is no practical difference between "not supported" and "supported, but disabled". It could very well be for example that some server in a farm support the feature and some don't.
NAME please review PR
Looks good to me. Thanks.

Discussion:
name: enable_multipath (TBD - experiments use 0xbabf) <del> value: 0 (default) for disabled.  Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available option value for client and server are listed in param_value_definition : If the peer does not carry the enable_multipath transport parameter, which means the peer does not support multipath, endpoint MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document.  If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </del> <ins> value: 0 (default) for disabled. Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available option value for client and server are listed in param_value_definition : If the parameter is absent or set to 0, the endpoints MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </ins> Note that the transport parameter "active_connection_id_limit" QUIC- TRANSPORT limits the number of usable Connection IDs, and also limits
Change:
Fix issue
I went ahead and replaced the references to RFC9000 by QUIC-TRANSPORT, and RFC9001 by QUIC-TLS. I have checked that this produced the expected XML V3.
RFC9000 is cited massively in the draft. It would be helpful to indicate to the reader where to look by indicating the section. Some change examples are provided below: and so on.
Side comment -- please see issue about the use of XML2RFC v3 syntax for links. We can do some of that, but not necessarily everywhere. We do expect that readers are familiar with QUIC V1. If we want to say "we are just in line with QUIC V1", then a global reference to RFC 9000 should suffice. If we want to say "please read this text in QUIC V1, we don't want to replicate here", then yes, we should refer to the specific section.
Thanks, Christian. That's the intent.
The draft is using old style references, such as "section 9 of {{RFC9000}}". Version 3 of XML2RFC defines a structure way to do that, such as: , which can be expressed in recent versions of Markdown as . The new style references don't change the text version much, but in the HTML rendering they generate direct references to the target section, which is nice for the readers.
Sorry, that's my fault because of my local build system. Will fix this for the next revision...
With the fixed references, it works now...

Discussion:
address as well as source and destination port.  Therefore there can be at most one active paths/connection ID per 4-tuple. <del> The path management specified in section 9 of QUIC-TRANSPORT fulfills </del> <ins> The path management specified in Section 9 of QUIC-TRANSPORT fulfills </ins> multiple goals: it directs a peer to switch sending through a new preferred path, and it allows the peer to release resources associated with the old path.  Multipath requires several changes to

Manage the removal of paths that have been abandoned. As such this extension specifies a departure from the specification <del> of path management in section 9 of QUIC-TRANSPORT and therefore </del> <ins> of path management in Section 9 of QUIC-TRANSPORT and therefore </ins> requires negotiation between the two endpoints using a new transport parameter, as specified in nego.

using the same mechanisms. If validation succeed, the client can send non-probing, 1-RTT packets <del> on the new paths.  In contrast with the specification in section 9 of </del> <ins> on the new paths.  In contrast with the specification in Section 9 of </ins> QUIC-TRANSPORT, the server MUST NOT assume that receiving non-probing packets on a new path indicates an attempt to migrate to that path. Instead, servers SHOULD consider new paths over which non-probing

received for a sufficiently long path-idle delay, but SHOULD only release resource for the last available path if no traffic is received for the duration of the idle timeout, as specified in <del> section 10.1 of QUIC-TRANSPORT.  This means if all paths remain idle </del> <ins> Section 10.1 of QUIC-TRANSPORT.  This means if all paths remain idle </ins> for the idle timeout, the connection is implicitly closed. Server implementations need to select the sub-path idle timeout as a
Change:
Be consistent with title.
NAME flagged in his PRs that there are many places using hyphenated "multi-path" and many using "multipath". We need to fix that.
This is due to the merge of the different drafts. I thought I fixed most of them, but I guess I could have done a search :-) Will do

Discussion:
Path Identifier (Path ID): An identifier that is used to identify a path in a QUIC connection at an endpoint.  Path Identifier is <del> used in multi-path control frames (etc.  PATH_ABANDON frame) to </del> <ins> used in multipath control frames (etc.  PATH_ABANDON frame) to </ins> identify a path.  By default, it is defined as the sequence number of the destination Connection ID used for sending packets on that particular path, but alternative definitions can be used if the

does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. <del> This proposal adds one multi-path control frame for path management: </del> <ins> This proposal adds one multipath control frame for path management: </ins> PATH_ABANDON frame for the receiver side to abandon the path

11. <del> Multi-path QUIC transport error codes are 62-bit unsigned integers </del> <ins> Multipath QUIC transport error codes are 62-bit unsigned integers </ins> following QUIC-TRANSPORT. This section lists the defined multipath QUIC transport error codes
Change:
The current text assumes that the server transport parameters are composed after seeing the client's proposal. As pointed out in issue , this is a deviation from standard QUIC practice. The proposed text fixes that and specifies what happens if both endpoints select option 3, "support both". In that case, option 2 "multiple number spaces" is selected.
In Section 2 you define a transport parameter and set of values. These are presented in a table with a column header "Allowed server responses", what does that mean? One way to read this is that it implies servers would tailor their Transport Parameters to the value sent by the client but that's conflicting with our philosophy that TPs are unilateral declarations, not active negotiation. So the question for me is, is this just a wording issue or a design one?
I think this mainly means that server are not allow to send 0x3. However, if the client sends 0x3, the server's reply will impact the client behaviour for 1-RTT packets. Is that a negotiation? However, keep in mind that the intention is not to publish this as it.
unilateral negotiation is ok by me. If that's the intent then maybe just rewording of the table to be clariy it is a matrix of combinations is ok, and state somewhere that server 0x3 is illegal. do you mean not to adopt the draft with this type of TP, or the final RFC? I think better clarity is needed for implementation and experiementation as we try and answer the PN question
NAME that's my fault. I wrote that table based on my implementation, in which the server response does depend on the client proposal. We should replace it by a matrix showing what is expected if the client proposes 0-1-2-3 and the server 0-1-2-3. The only problematic case is "3 and 3", and we should simply state what happens there.
NAME please review PR
NAME thanks for the clarification, the new text makes the intent much more clear IMO.
Just to clarify, we are not intending to have this in the final RFC. We would like to have it adopted as it to enable more experimentation.
thanks NAME that also works for me!
LTGTM just 2 nits

Discussion:
value: 0 (default) for disabled. Endpoints use 2-bits in the value field for negotiating one or more <del> PN spaces, available option value for client and server are listed in </del> <ins> PN spaces, available option values are listed in </ins> param_value_definition : <del> If the parameter is absent or set to 0, the endpoints MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. </del> <ins> If for any one of the endpoints the parameter is absent or set to 0, or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type