jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 can not send packets on a closed state , ... ) . 
 Can you create a PR ?
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.
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 .
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
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.
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
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.
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.
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 MPPROTOCOLVIOLATION for connection close . If we have more specific error codes in the future , we can add them in the table . 
 Looks OK .
Packet Number Space Identifier: An identifier of the path packet
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,
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.
Packet Number Space Identifier: An identifier of the path packet
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,
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_PROTOCOL_VIOLATION and close the connection.
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.
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.
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 " .
The simultaneous usage of several sending uniflows 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.
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.
Draft: draft-lmbdhk-quic-multipath

Commentary: There is a SHOULD here , which I believe should be a MUST as we taking about the receiver behaviour here . 
 is this ready to merge ? 
 Sorry , I am working on several projects in parallel , missed this . Text is fine .
1-RTT packets sent to different paths SHOULD carry different
connection identifiers, if a non-zero connection ID is used.
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.
Draft: draft-lmbdhk-quic-multipath

Commentary: The draft states that Should n't be the result instead of ? 
 Yes , I submitted PR for this issue .
For example, assuming the IV value is "6b26114b9cba2b63a9e8dd4f", the
connection ID sequence number is "3", and the packet number is
"aead", the nonce will be set to "6b2611489cba2b63a9a873e2".
For example, assuming the IV value is "6b26114b9cba2b63a9e8dd4f", the
connection ID sequence number is "3", and the packet number is
"aead", the nonce will be set to "6b2611489cba2b63a9e873e2".
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 .
The MP_ACK 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
were sent on different paths.  If the frame type is TBD-01, MP_ACK
frames also contain the sum of QUIC packets with associated ECN marks
received on the connection up to this point.
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
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.
Packet Number Space Identifier: An identifier of the path packet
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,
it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.
Packet Number Space Identifier: An identifier of the path packet
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,
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.
Draft: draft-lmbdhk-quic-multipath

Commentary: I copied this sentence from draft - liu : Should n'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 .
Following QUIC-TRANSPORT, each endpoint uses NEW_CONNECTION_ID frames
to issue usable connections IDs to reach it.  Before an endpoint adds
a new path, it SHOULD check whether there is at least one unused
available Connection ID for each side.
Following QUIC-TRANSPORT, each endpoint uses NEW_CONNECTION_ID frames
to issue usable connections IDs to reach it.  Before an endpoint adds
a new path, it MUST check whether there is at least one unused
available Connection ID for each side.